How do I find out what needs Microsoft.VC90.CRT.Manifest from .NET client

1.8k Views Asked by At

I have a WPF application that references binaries in a released version of our software. However, it does not build because it cannot locate the Microsoft.VC90.CRT.Manifest in the runtime folder. I know this is an old VC++ 2008 CRT thing. However, I have two questions:

[1] How can I find out what needs the manifest file, I presume there's a bit of a dependency chain at work here? All I reference directly are .NET assemblies.

[2] Is there a way I can install the 2008 CRT stuff so that my project builds without needing to locate the manifest file (i.e. it's get installed and found at a common location - WinSxS?)? I am assuming that we should not be distributing this manifest file.

1

There are 1 best solutions below

0
On

Right, I can provide some answers to my question, even if it's not the full answer.

To work out what required the manifest, I ended up setting my build output level to diagnostic and then searching the log. This revealed the deepest and highest dependency in the chain, but not the references between these.

...

1>  bin\x64\Debug\Microsoft.VC90.CRT.manifest
1>                  CopyLocal=true
1>                  FusionName=
1>                  HintPath=<path to the reference in my project that pulls in this file (indirectly)>
1>                  OriginalItemSpec=<path to the output folder>\Kitware.VTK.dll < The dll at the bottom of the chain that needs the manifest
1>                  ResolvedFrom=<path to the folder containing the referenced binaries>
1>                  SpecificVersion=False
1>                  Version=7.1.0.1009

From this I could see that the Kitware.VTK.dll was causing the CopyLocalFiles error and which of the immediate references was pulling this in. However, I could not see the reference chain that lead to this. I loaded the top level reference (the .dll) into dotPeek and used the assembly dependency graph to examine the reference chain between these two dlls - NB this worked but was non optimal and the GUI really struggled with the dependency diagram.

I now need to figure out how to break this chain or if I can embed the manifest in the assembly we control.