Has anyone come across issues with migrating to .NET 2.0 from 1.1 in
dealing with unmanaged DLLs?
Can you be more specific?
The CRT libraries are now supplied as side-by-side 'assemblies' (note,
not .NET assemblies, but native code). The linker will automatically
create a manifest file, but it will not embed the manifest file as a
unmanaged resource (this is true of using the compiler to create managed
and unmanaged libraries). This means that the library will not load at
run time because the DLL loader does not know what to load. Worse than
that, the linker suggests that the library 8.0.50608.0 should be used,
but this is not installed. Instead, Visual Studio will install the
version 8.0.50727.42 and will add a policy file to redirect requests for
8.0.50608.0 to 8.0.50727.42. Its a horrible mess.
To solve the problem the manifest file must be added as an unmanaged
resource. If you build C++ projects in Visual Studio 2005 the project
wizard will do this for you as a post link step. If you build on the
command line or with nmake then you have to run mt.exe on your DLLs:
mt /manifest library.dll.manifest /outputresource:library.dll;#2
library.dll is the DLL you created and library.dll.manifest is created
by the linker. Of course it is a real pain to have to change something
created by the linker, I expect the linker to create a file that I can
use straight away. If you are building a .NET library with managed C++
then you have to be careful to delay sign the library because after you
use mt.exe strong name validation will fail. Whoever thought of doing
this?
I am writing about this now, and it should be available on my web site
in the next few days at
http://www.grimes.demon.co.uk/workshops/fusWSThirteen.htm
Richard
