1

I have VS2005, VS2008, and VS2010 installed on my Win7 development machine. I have one particular project that uses a 3rd party DLL that gets an exception during the LoadLibrary() call when the EXE project is built by VS2010 (when targeting either the v100 or v90 toolset.) It works perfectly when built by directly VS2005 or VS2008.

According to Li Shao's (of Microsoft) 2009 blog entry:

http://blogs.msdn.com/b/vcblog/archive/2009/12/08/c-native-multi-targeting.aspx

I should be able to open the VS2010 project and change the Platform Toolset from v100 to v90 and then VS2010 will actually use the VS2008 compiler, headers and libraries to build the program. If it is, then it isn't doing it "right" because the DLL will not load when the project is built this way. I tried looking at the build log to verify which compiler is used, but there are no paths or version numbers in my logs, so that was a bust.

This is a plain C (not C++, not MFC, not .NET) project written directly to the Win32Apis. Is there any way for this to work, or am I just stuck using a different compiler for a single project (out of over 100 that comprise the whole system)?

HELP!

Steve Valliere
  • 1,119
  • 7
  • 12
  • What is the LoadLibrary exception? Also, are you using 32-bit or 64-bit? (Are you mixing a 32-bit build with a 64-bit DLL?) – jeffrey_t_b Oct 04 '12 at 19:54
  • jeffery: Here's an example of what the debugger logs when the error is triggered: "First-chance exception at 0x00515210 in mcr2.exe: 0xC0000005: Access violation." The actual address varies, but the rest of the message is constant. Everything is compiled as 32-bit but it is all running under a 64-bit install of Windows 7, if that matters. – Steve Valliere Oct 05 '12 at 12:11

2 Answers2

1

Have a look at Daffodil: http://daffodil.codeplex.com/

After installing Daffodil, you'll be able to use VS 2010 to build projects using older versions of the libraries.

Derek
  • 1,104
  • 13
  • 35
  • Daffodil would allow us to use VS2005, but since VS2008 is already installed; can also create a working copy of our program; and is known/understood(?) by VS2010 out of the box, I'm not sure why I'd want to add even /more/ new software to the mix. Especially since I expect VS2010 building against the VS2005 libs to have the same problem it does building against the VS2008 libs. But thanks anyway, I may get desperate enough to try it. – Steve Valliere Oct 05 '12 at 12:14
  • FWIW, once I realized Daffodil was only some config settings for VS2010 I gave it a try. Unfortunately, I got exactly the results I expected: Failure. It seems that even when building against an older toolset, VS2010 does **something** to the program being built that causes the DLL we are using to trigger an exception when LoadLibrary() is called to load it. Compiling directly with VS2008/2005 **does not** cause this same problem, so it is **ABSOLUTELY** a VS2010 problem. I may need to get VS2012 and see if itt, too, has the same problem. – Steve Valliere Oct 05 '12 at 12:30
0

I think I've solved it. It seems that, while VS2010 will happily run the VS2008 compiler, linker, etc. VS2010 will NOT leave the project alone. When the project is imported to VS2010 there are some new default settings added to the command line and, apparently, at least one of them is different enough from VS2008 to make the DLL I'm using fail to load.

When I changed the Advanced Linker setting for Data Execution Prevention (DEP) from Yes (the default) to NO, my program started working again! In fact, I no longer even need to compile using the v90 toolset -- the ENTIRE problem was caused by the new default for the /NXCOMPAT linker command line switch. The /NXCOMPAT switch isn't even referenced in the project settings in the VS2005 IDE (where the project was created), but running "link /?" in the VC8 bin folder shows that the switch was known and the default was NO.

Too bad the Visual Studio IDE doesn't include a list of default settings that were in use by a project that have CHANGED in the new version. If that is too difficult, the importer should specify the changed settings using the old default values, otherwise the project was imported incorrectly, wasn't it?

Steve Valliere
  • 1,119
  • 7
  • 12