I’m working on a project which integrates a lot of legacy C++ code in several DLLs with a C# wrapper application. Of course, the legacy code also references several third party libraries, just to make things interesting.
Everything was going well until I tried to run the application on a test VM and it displayed a very unhelpful error message:
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.
The first thing I discovered, was that in order to run exectutables on a test machine that are linked to the DEBUG versions the VC runtime libraries, I’d need to copy the appropriate folders from the C:Program FilesMicrosoft Visual Studio 9.0VCredistDebug_NonRedist folder to the executable’s directory on the test machine. Here’s some relevant information on MSDN regarding this:
http://msdn.microsoft.com/en-us/library/aa985618(VS.80).aspx
Unfortunately this was just the tip of the iceberg.
After copying the correct runtime library DLLs, I was still greeted with the same error when I tried to run my application. The system event log contained a clue in the form of a SideBySide error:
A component version required by the application conflicts with another component version already active.
Hmm. Some component wasn’t playing nice with some other component!
After a lot of googling, I ran across this Stack Overflow question which led to the eventual resolution:
http://stackoverflow.com/questions/59635/app-does-not-run-with-vs-2008-sp1-dlls-previous-version-works-with-rtm-versions
Apparently, some of the third party libraries were causing the linker to reference older VC runtime library versions, so our component’s manifest file was listing multiple versions.
This was apparently what was causing the problems on the test machine.
The fix was to add the following to the pre-processor directives for each of our projects which forces everything to reference the latest runtime libraries:
_BIND_TO_CURRENT_VCLIBS_VERSION
If you run into this, pay attention to this paragraph from the accepted answer which details a great way to debug this problem:
A great way to debug which libraries don’t have the preprocessor directives set: temporarily modify your platform headers so that compilation stops when it tries to embed the old manifest. Open C:Program FilesMicrosoft Visual Studio 9.0VCcrtincludecrtassem.h. Search for the ‘21022’ string. In that define, put something invalid (change ‘define’ to ‘blehbleh’ or so). This way, when you’re compiling a project where the _BIND_TO_CURRENT_CRT_VERSION preprocessor flag is not set, your compilation will stop and you’ll know that you need to add them or made sure that it’s applied everywhere.
This tip really helped me to identify and correct the projects which where causing the problem.
It’s amazing to me how far we’ve come from the days when this type of problem was routine. With the advent of .NET, this sort of thing is rarely a problem until you try to use some old C++ libraries. I hope you never have to deal with this sort of thing!
