views:

94

answers:

2

This popup comes up as soon as the app is started:

The program can't start because MSVCP90.dll is missing from your computer.

Before anyone says "install the VC++ runtimes", wait! If I rename the folder containing my .EXE then the app runs. If I rename it back, it breaks. The app has been running for weeks without any changes to my system/VS installation (2008 SP1), we suddenly spotted this error a few days ago.

Lost as to why the name of the dir is causing issues... again this has not changed in months and all our resource paths are relative anyway, e.g "../someOtherDir/...."

It doesn't just do this on my PC, we have the /bin dir (the one containing EXE) in SVN and suddenly everyone started seeing the same issue, even though the binaries themselves seem just fine. Is it possible some additional data got put into SVN and that's the cause? Since it's not just one PC, there must be something either in SVN or the EXE itself...

Note this popup comes before our code even gets to run.

+2  A: 

It seems that there is a .exe.manifest file lying around, specifying some other version of MSVCP90.dll. Removing this file should do the trick (In theory the manifest is the solution against dll hell, but in reality it is just a new PITA).

Rudi
Nice try, but no luck I'm afraid. There is no manifest in the /bin dir. There was one in the folder the compiler writes the EXE but copying this made no difference. Deleting it from the folder it _does_ work in _did_ cause the issue there though.
John
Note that a manifest could also be present in the resources of an EXE.
MSalters
How would VS but one in a C++ app, and why would it suddenly decide to, or to change it? Looks like release build is not spitting out a manifest.
John
You can look in project->properties(Alt+F7)->configuration properties->Linker->manifest file if there are differences for the debug and release configuration. The items may be spelled different, I have the German version of VS installed here.
Rudi
A: 

Try rolling back to some earlier SVN revisions and see if you can identify a change which made it stop working. A binary search will be most efficient for this. PATH settings might also be an issue?

crazyscot
PATH hasn't changed. Must be something weird...
John