views:

1283

answers:

3

I was trying to figure out why a debug build was blowing up with the "dependent assembly microsoft.vc80.debugcrt could not be found" event error.

After deleting everything (anything not .cpp or .h) and recreating the solution - I still had the problem.

A google search was fruitless and a re-install of VS didn't produce any change.

I did have the dlls in C:\WINDOWS\WinSxS\x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_f75eb16c.

I opened the \debug\.exe.intermediate.manifest file and it had 2 (dependentAssembly) entries:
1st: name='Microsoft.VC80.DebugCRT' version='8.0.50608.0'
2nd: name='Microsoft.VC80.DebugCRT' version='8.0.50727.762'

If I delete one and change the other one to name='Microsoft.VC80.DebugCRT' version='8.0.50727.42'

I can get a build that will start.

Granted I did have VS2008 installed - but what is controlling the versions ? or How can I get the right debug dll version to "stick".

VS2008 was de-installed through the control panel.

EDIT: Found nothing in the registry if DebugCRT is searched for.
the environment path points to the VS8 folders .
There is only 1 DebugCRT folder in the c:\windows\winsxs\policies folder
(8.0.50.727.42)
The c:\windows\winsxs\manifests folder only has the .42 version of .cat and .manifest
The .manifest file (in above manifest folder) has version="8.0.50727.42"

Clarification: the manifest file has 2 "dependentAssembly" entries each with different versions and not the .42. I can delete 1 entry and change the version on the other to match the .42 to get a debug build that starts.

EDIT2:I'm also using boost and inside the DLLs there is the .762 version

A: 

VS 2008 is VC90 not VC80, so that's not part of the problem. The relation between manifest-requested assembly and SxS-loaded assenbly is found in C:\WINDOWS\WinSxS\Policies. IIRC, "8.0.50608.0" is generated by VS2005 pre-SP1. It's wrong, and should have been 8.0.50727.42, but this is caught by the policy.

I'm not sure how you're getting two manifests. What are your manifest settings?

MSalters
+1  A: 

The version was picked up by from the Boost DLLs which were a download, pre-compiled version of Boost. Once the libraries were re-compiled (and re-installed) a re-build of the solution produced a manifest with a single version and the program linked and ran.

So -Check the libs and dlls that are imported into the solution for version used.

jim
A: 

I'd suggest rebuilding Boost in your particular environment. Also, you could do away with the Side by Side assemblies altogether by linking the CRT statically...

Kapil Kapre
Yep - I've done that but got bitten by MFC not wanting to link. I'm looking to replace the MFC printer classes and dump MFC completely.
jim