.NET 2.0 Unmanaged code

  • Thread starter Thread starter brianczako
  • Start date Start date
B

brianczako

Has anyone come across issues with migrating to .NET 2.0 from 1.1 in
dealing with unmanaged DLLs?

Brian
 
Has anyone come across issues with migrating to .NET 2.0 from 1.1 in
dealing with unmanaged DLLs?
Click to expand...

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
 
I have a C DLL that I've been working with, a legacy DLL. I have no
choice but to work with it. Rewriting the DLL in C# is not an option.

There's some work I have to do in my C# wrapper to present the data to
the DLL (and to convert responses from the DLL back to data usable by
C#).
What I was wondering is that: are there any new issues with .NET 2.0
that weren't in previous versions?
 
my ASP.NET apps (existing and new) still default to 1.1. What do I have
to do to get ASP.NET apps to default to using 2.0? I even rebooted after
the installation.
 
Back
Top