Migrating from Visual Studio 2005 to Visual Studio 2015 Still Tries to Link MFC 8
-
Hi...
I am trying to migrate a large MFC solution from VS2005 to VS2015. The solution contains 170 projects. After a lot of work, all projects compile and 168 of them link. One that does not link is petty, but pesky, and I may return to that in another post. The other that does not link is the project that generates the program executable.
* The error that it generates is LNK1104: Cannot Open 'mfc80d.lib'.
* If I ignore MFC80d.lib, I get LNK1104: Cannot Open 'mfcs80d.lib'.
* If I ignore that, I get LNK1104: Cannot Open 'daouuid.lib'
* And if I ignore that, I get any number of undefined externals such as CRect::...(), CSize::...(), CFile::...() and so on. This is presumably because I am not linking MFC at all.I have found a lot of discussion about this but none of it seems to help me. I can find no explicit or implicit references to MFC 8 in my properties or any project file. I have searched for 'mfc80d' both internally in VS2015 and externally in the Windows 7 search tool.
My target platform is 8.1 and my platform toolset is 140.
I will begin configuring a release build next week after the new year.
Can anyone offer any suggestion?
If I may slip in a second question, do I need to worry about migrating DAO?Thank you very much for any help that you can offer and have a Happy New Year.
SPC
S.P. Chapman Digital Engineer Radiant Technologies, Inc. Albuquerque, NM. radiant@ferrodevices.com
-
Hi...
I am trying to migrate a large MFC solution from VS2005 to VS2015. The solution contains 170 projects. After a lot of work, all projects compile and 168 of them link. One that does not link is petty, but pesky, and I may return to that in another post. The other that does not link is the project that generates the program executable.
* The error that it generates is LNK1104: Cannot Open 'mfc80d.lib'.
* If I ignore MFC80d.lib, I get LNK1104: Cannot Open 'mfcs80d.lib'.
* If I ignore that, I get LNK1104: Cannot Open 'daouuid.lib'
* And if I ignore that, I get any number of undefined externals such as CRect::...(), CSize::...(), CFile::...() and so on. This is presumably because I am not linking MFC at all.I have found a lot of discussion about this but none of it seems to help me. I can find no explicit or implicit references to MFC 8 in my properties or any project file. I have searched for 'mfc80d' both internally in VS2015 and externally in the Windows 7 search tool.
My target platform is 8.1 and my platform toolset is 140.
I will begin configuring a release build next week after the new year.
Can anyone offer any suggestion?
If I may slip in a second question, do I need to worry about migrating DAO?Thank you very much for any help that you can offer and have a Happy New Year.
SPC
S.P. Chapman Digital Engineer Radiant Technologies, Inc. Albuquerque, NM. radiant@ferrodevices.com
-
Hi...
I am trying to migrate a large MFC solution from VS2005 to VS2015. The solution contains 170 projects. After a lot of work, all projects compile and 168 of them link. One that does not link is petty, but pesky, and I may return to that in another post. The other that does not link is the project that generates the program executable.
* The error that it generates is LNK1104: Cannot Open 'mfc80d.lib'.
* If I ignore MFC80d.lib, I get LNK1104: Cannot Open 'mfcs80d.lib'.
* If I ignore that, I get LNK1104: Cannot Open 'daouuid.lib'
* And if I ignore that, I get any number of undefined externals such as CRect::...(), CSize::...(), CFile::...() and so on. This is presumably because I am not linking MFC at all.I have found a lot of discussion about this but none of it seems to help me. I can find no explicit or implicit references to MFC 8 in my properties or any project file. I have searched for 'mfc80d' both internally in VS2015 and externally in the Windows 7 search tool.
My target platform is 8.1 and my platform toolset is 140.
I will begin configuring a release build next week after the new year.
Can anyone offer any suggestion?
If I may slip in a second question, do I need to worry about migrating DAO?Thank you very much for any help that you can offer and have a Happy New Year.
SPC
S.P. Chapman Digital Engineer Radiant Technologies, Inc. Albuquerque, NM. radiant@ferrodevices.com
As Richard said you are linking the lib files manually of which there are only three ways to do 1.) #pragma comment(lib, "mfc80d.lib") .. given you have searched for mfc80d.lib it can only be a macro name so just search for "#pragma comment". Something stupid like #pragma comment(lib, "mfc" _MFC_FILENAME_VER "d.lib") 2.) Under project properties Linker->Input->Additional Dependencies .. look for the name 3.) Under project properties Linker->command Line->Additional Options .. look for name (its usually blank) Has to be in one of those 3. daouuid.lib is an obsolete XP service pack 2 library file it wont be available in none XP builds. There is an XP build option on VS2015 it will probably link in that build.
In vino veritas
-
As Richard said you are linking the lib files manually of which there are only three ways to do 1.) #pragma comment(lib, "mfc80d.lib") .. given you have searched for mfc80d.lib it can only be a macro name so just search for "#pragma comment". Something stupid like #pragma comment(lib, "mfc" _MFC_FILENAME_VER "d.lib") 2.) Under project properties Linker->Input->Additional Dependencies .. look for the name 3.) Under project properties Linker->command Line->Additional Options .. look for name (its usually blank) Has to be in one of those 3. daouuid.lib is an obsolete XP service pack 2 library file it wont be available in none XP builds. There is an XP build option on VS2015 it will probably link in that build.
In vino veritas
I did, indeed, find "#pragma comment(lib, "mfc" _MFC_FILENAME_VER "d.lib")" in Afx.h under C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\atlmfc\include\afx.h. However, _MFC_FILENAME_VER is declared by: #ifndef _MFC_FILENAME_VER #define _MFC_FILENAME_VER "140" #endif in afxver.h. I tried adding the declaration explicitly to the project StdAfx.h file but it made no change to the linker error. "#pragma comment" is not found anywhere in the project itself. There are no explicit references to MFC 80 in the linker settings. Once I get a few beginning of the year things cleaned up, I am going to try a release build. As for DAO, I am no longer targeting XP or Vista. I will need to fight that battle once I win this one. Thanks for your advice. I will continue to tilt at this as I may, but I may be stuck with VS2005 compilations for some time. Happy New Year to you. FF
-
I did, indeed, find "#pragma comment(lib, "mfc" _MFC_FILENAME_VER "d.lib")" in Afx.h under C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\atlmfc\include\afx.h. However, _MFC_FILENAME_VER is declared by: #ifndef _MFC_FILENAME_VER #define _MFC_FILENAME_VER "140" #endif in afxver.h. I tried adding the declaration explicitly to the project StdAfx.h file but it made no change to the linker error. "#pragma comment" is not found anywhere in the project itself. There are no explicit references to MFC 80 in the linker settings. Once I get a few beginning of the year things cleaned up, I am going to try a release build. As for DAO, I am no longer targeting XP or Vista. I will need to fight that battle once I win this one. Thanks for your advice. I will continue to tilt at this as I may, but I may be stuck with VS2005 compilations for some time. Happy New Year to you. FF
The simpler way is simply delete all the project and solution files and set them up from scratch using the create project from existing code option on the menu :-)
In vino veritas
-
The simpler way is simply delete all the project and solution files and set them up from scratch using the create project from existing code option on the menu :-)
In vino veritas
Yes, I am just about to that point. I have been redirecting my energies the past week or so, so I haven't had at this problem very much. I was actually considering moving the older library files into the project just to get things to link. I haven't tried a release build, yet, but if the release build does not link, moving the older files may resolve the problem but then cause a distribution nightmare, requiring 2005 and 2015 manifests. A new project with old code and resource files is a much better approach. Thanks for your time SPC
-
Yes, I am just about to that point. I have been redirecting my energies the past week or so, so I haven't had at this problem very much. I was actually considering moving the older library files into the project just to get things to link. I haven't tried a release build, yet, but if the release build does not link, moving the older files may resolve the problem but then cause a distribution nightmare, requiring 2005 and 2015 manifests. A new project with old code and resource files is a much better approach. Thanks for your time SPC
If any of your projects links another 3rd party library, that library, too, needs to be compiled with VS2015 - otherwise it will attract old MFC libs. There's a very useful tool called depends that can show for each executable or dll what other binaries it depends on. You can use it to locate the dependency path that is responsible for attracting mfc80.dll. See Dependency Walker (depends.exe) Home Page[^]
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
-
If any of your projects links another 3rd party library, that library, too, needs to be compiled with VS2015 - otherwise it will attract old MFC libs. There's a very useful tool called depends that can show for each executable or dll what other binaries it depends on. You can use it to locate the dependency path that is responsible for attracting mfc80.dll. See Dependency Walker (depends.exe) Home Page[^]
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Hi Stefan... Thanks for the observation. And yes, I have been pursuing this same line. I am having trouble getting a reply from the the third party vendor. Meanwhile, other matters have pushed this to the side, so I haven't been giving it a lot of attention. I will leave this reply up for the weekend, then remove/resolve this message. Thanks again and have a great weekend. SPC