A dll I've written in umanaged C++ on VS 2005 pro has an automatically
generated, embedded manifest that refers to version 8.0.50608.0 of the CRT
(msvcr80.dll).
Looking through WinSxS on the same machine, there's only a version
8.0.50727.42 listed, and needless to say my dll won't run.
Any ideas why I've got Visual Studio generating one version number, and
Window's only aware of another?
Should I ever get this resolved on my dev machine, what happens if a
deployment machine has a different version number in its cache?
Might this have anything to do with me installing the W2003 SP1 Platform SDK
after installing VS2005?
This is the first app I've written using 2005 and I'm not happy!!!!
Any help much appreciated - please let me know nicely if there's a more
appropriate forum to post this on.

Think I've found out the answer to this one - seems that there's a "policy
version redirect" implemented in WinSxS/Policies that maps my VS version
number to the listed 50727 version.
Of course. Haven't got a clue why, but at least I know that's not the reason
for my dll not to run. Is dependancy walker able to take this convoluted
route into account - certainly doesn't seem to.


"wanzelbin" wrote:

> A dll I've written in umanaged C++ on VS 2005 pro has an automatically
> generated, embedded manifest that refers to version 8.0.50608.0 of the CRT
> (msvcr80.dll).
> Looking through WinSxS on the same machine, there's only a version
> 8.0.50727.42 listed, and needless to say my dll won't run.
> Any ideas why I've got Visual Studio generating one version number, and
> Window's only aware of another?
> Should I ever get this resolved on my dev machine, what happens if a
> deployment machine has a different version number in its cache?
> Might this have anything to do with me installing the W2003 SP1 Platform SDK
> after installing VS2005?
> This is the first app I've written using 2005 and I'm not happy!!!!
> Any help much appreciated - please let me know nicely if there's a more
> appropriate forum to post this on.