MFC程序中使用到打开文件,打包后,自己电脑运行正常,别人电脑显示找不到文件路径
困扰了好久的问题,大哭!
问题现象:写了一个升级软件,其中需要读取升级文件并将其内容写入到设备中,使用VS2015软件编写代码,使用VS2017打包工具打包后,在自己电脑上测试可以正常使用。找到旁边win7 64bits中测试可以正常升级。win10 64bits server2012R2 64bits系统同样可以使用。以为万事大吉!无意中win7 32bits电脑测试一下,软件正常运行。但发现无法升级,win8.1 64bits同样出现此问题。打log分析,无法打开升级文件。
代码定位到此句:f=fopen(path,'rb+'); f=NULL;
打log,path显示出的内容竟然都是对的,但就是f=null;百思不得其解
问题分析:
心路1:以为是软件编写使用vs2015,但打包使用的VS2017版本太高导致的此问题。引出这个原因主要因为使用VS2017打开软件后,一些项目属性的设置会提示是否更改为2017默认的值,点击是的话,会导致没有问题的代码报错。缺少package生成包什么的....
尝试方法:安装了vs2015的installshield的工具,打包后,满怀期待的放到测试机器上发现,照样打不开路径,唉,看来不能怪机器了,肯定是代码的原因了。
心路2:难不成getcwd函数的问题?这个函数应该没有问题吧,尝试使用GetModuleFileName
结果2:问题仍在。
新路3:char *gPath=path[256]
OpenHexFile(path)
本来参数传递的是数组名,后来将参数改为gPath:OpenHexFile(gPath)
发现:单步调试的时候发现传递到这里的指针值不正确,但使用数组的值是正确的。但代码中没有对指针作修改。
找不到修改的地方,但指针值就是不正确。
解决方法:干脆就将获得文件的路径放到打开文件前一句,最终解决,在win10/win8 32bits系统中可以正常运行。
分析:应该是指针在某个地方修改了,这个应该好好研究下指针的使用
新路4:以为上述方式将此问题解决了,然而...,在win8.1 32系统中测试时此问题仍存在。简直要疯了!
解决方法:开始将文件的路径打log分析,发现,setup.exe选择了默认的安装路径,C\Program files(x86)\...系统文件夹;桌面产生了快捷方式。双击桌面的快捷方式启动文件。代码中使用getcwd()获得文件的路径名,发现获得的文件名为空(NULL)。大跌眼镜,什么情况???
随后打印文件的log,getcwd()获得的文件路径为文件快捷方式存在的路径,即桌面的路径,由于桌面没有升级文件,肯定打开失败;将升级文件拷贝到桌面后,可以实现正常升级。使用GetModuleFileName()时发现,此时打印的log为安装路径中exe的绝对路径,也是升级文件中存放的位置。虽然地址正确,但仍打开文件失败。
到此可以简单总结下:win8.1 32bits系统中,getcwd()获得了快捷方式所在的路径;GetModuleFileName()获得exe所在的真正路径。
冥思苦想,怎么回事?怎么回事?
最终解决方法:由于系统默认的安装路径在C盘中,当前系统使用的账户不是管理员账户,没有权限到C\Program files(x86)中读取到升级文件,故无法升级。若提示用户不安装在此路径下或者运行此软件在管理员账户下,就不会出现此问题。
目前我出现的问题是此种原因导致。