/clr:pure and unmanaged lib

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a small C++/CLI application which calls an unmanaged lib.

It seems like I can't use /clr:pure and link with the unmanaged lib (LNK1313
error).

The problem I have is that compiling with /clr adds a dependency on several
msvc*.dll:s which adds some unwanted complexity to the installation.

Is it possible to avoid the msvc*.dll dependency without explicit p/invoke?
 
wpcmame said:
I have a small C++/CLI application which calls an unmanaged lib.

It seems like I can't use /clr:pure and link with the unmanaged lib
(LNK1313
error).
Click to expand...

Of course. /clr:pure means your assembly contains only MSIL, but you're
putting in machine code from a native library.
The problem I have is that compiling with /clr adds a dependency on
several
msvc*.dll:s which adds some unwanted complexity to the installation.

Is it possible to avoid the msvc*.dll dependency without explicit
p/invoke?
Click to expand...

No. But this shouldn't surprise anyone, if you compile for .NET you will
need the .NET runtime installed. The .NET runtime is built using C++, so it
deploys msvc*.dll

Now the whole side-by-side versioning problem is another story. I think it
might be fixed if MS deployed the C++ updates in a .NET 2.0 runtime patch,
but for some reason they insist on distributing old versions of the library
(even though the new ones are compatible and include bug fixes).
 
Hi Ben!
No. But this shouldn't surprise anyone, if you compile for .NET you will
need the .NET runtime installed. The .NET runtime is built using C++, so it
deploys msvc*.dll
Click to expand...

????

The .NET runtime does not depend on the msvc*.dlls!
Only if you compiler in C++/CLI with "/clr", then your application will
depend on the CRT!

The .NET runtime does not deply msvc*.dlls....

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
 
Jochen Kalmbach said:
Hi Ben!


????

The .NET runtime does not depend on the msvc*.dlls!
Only if you compiler in C++/CLI with "/clr", then your application will
depend on the CRT!

The .NET runtime does not deply msvc*.dlls....
Click to expand...

Jochen,
mscorjit.dll, mscorwks.dll etc are linked against the MSVCRXX.dll, where XX
stands for the version of the VC runtime, a simple dumpbin /imports may show
you that.

Willy.
 
Hi Willy!
Jochen,
mscorjit.dll, mscorwks.dll etc are linked against the MSVCRXX.dll,
where XX stands for the version of the VC runtime, a simple dumpbin
/imports may show you that.
Click to expand...

Upps... interesting feature....

But this does not mean, that you do not need to redistribute the
vcredist_x86.exe if you compile with "/clr".

I assume that the mscor*.dll are linked agains the RTM (or previous)
version of the CRT. So if you build your app with VS2005SP1, you need to
deploy the SP1 DLLS...

I general you can say:
If you compile with /clr:pure, you only need the .NET-Redistributable.
Otherwise you also need the vcredist_x86.exe
Also if you use MFC/ATL/OpenMP, you need to use vcredist_x86.exe


--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
 
Jochen Kalmbach said:
Hi Willy!


Upps... interesting feature....

But this does not mean, that you do not need to redistribute the
vcredist_x86.exe if you compile with "/clr".
Click to expand...

If you are building against a newer version, somehow you'll have to add the
VC runtime too (or link statically).
I assume that the mscor*.dll are linked agains the RTM (or previous)
version of the CRT. So if you build your app with VS2005SP1, you need to
deploy the SP1 DLLS...

Yep.

I general you can say:
If you compile with /clr:pure, you only need the .NET-Redistributable.
Otherwise you also need the vcredist_x86.exe
Also if you use MFC/ATL/OpenMP, you need to use vcredist_x86.exe
Click to expand...

Nope, a pure is not MSIL only assembly, "pure" assemblies still have the
VCRT linked in, take a look at the assembly manifest generated by the
compiler, this manifest contains the assembly's depencies, something like.

<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC90.CRT'
version='9.0.20706.1' processorAr
chitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />

only "safe" assemblies do not depend on VCRT, all others depend on the VCRT
and are not verifiable.

Willy.
 
Hi Willy!
If you are building against a newer version, somehow you'll have to add
the VC runtime too (or link statically).
Click to expand...

Starting with VS2005 it is not supported to use /clr and link statically
against the CRT ;)
only "safe" assemblies do not depend on VCRT, all others depend on the
VCRT and are not verifiable.
Click to expand...

Upps... thanks for clarification...


--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/
 
But this does not mean, that you do not need to redistribute the
If you are building against a newer version, somehow you'll have to add
the VC runtime too (or link statically).


Yep.
Click to expand...

Unless you use redirection. The public interface isn't changed, so you can
use any version of the VC8 runtime -- as long as you manifest is set that
way.

But because the VC8 runtime is backward compatible, there is no excuse for
Microsoft not to include the newer dlls in the next .NET 2.0 patch. If they
are compiling patches to .NET 2.0 using RTM.... that's bad news, there were
a lot of compiler and library bugs fixed in SP1.
Nope, a pure is not MSIL only assembly, "pure" assemblies still have the
VCRT linked in, take a look at the assembly manifest generated by the
compiler, this manifest contains the assembly's depencies, something like.
Click to expand...

Pure is MSIL only, but the CRT includes an MSIL version of some functions,
so the dependency still exists.
 
Ben Voigt said:
Unless you use redirection. The public interface isn't changed, so you
can use any version of the VC8 runtime -- as long as you manifest is set
that way.

Agreed.

But because the VC8 runtime is backward compatible, there is no excuse for
Microsoft not to include the newer dlls in the next .NET 2.0 patch. If
they are compiling patches to .NET 2.0 using RTM.... that's bad news,
there were a lot of compiler and library bugs fixed in SP1.
Click to expand...

The actual patches are compiled with the vs2005 SP1 bug fixes (and more)
included. With Orcas comes a new version of the CLR including more fixes and
a new version of the VC run time.
Pure is MSIL only, but the CRT includes an MSIL version of some functions,
so the dependency still exists.
Click to expand...

It was my understanding that the C compiler team had reserved the right to
"inject" MSIL as well as native code whenever they see fit.
I remember this was done to allow them to inject native code when MSIL was't
really an option, I'll try to find the source of this info and post back
when I've found it. In the mean time consider my understanding to be wrong.

Willy.
 
But because the VC8 runtime is backward compatible, there is no excuse
The actual patches are compiled with the vs2005 SP1 bug fixes (and more)
included. With Orcas comes a new version of the CLR including more fixes
and a new version of the VC run time.
Click to expand...

But if you go to Windows Update (repeatedly) and install .NET 2.0 and all
patches, you get an old, buggy, runtime library installed and not the new
one with the bug fixes. I think this is poor behavior.
 
Ben Voigt said:
But if you go to Windows Update (repeatedly) and install .NET 2.0 and all
patches, you get an old, buggy, runtime library installed and not the new
one with the bug fixes. I think this is poor behavior.
Click to expand...


Oh, but there are more patches (hotfixes) than those supplied via WUS, there
are the fixes released through "PSS" and fixes available via "Premium
Contract" Services. That' said, the latest fix I got for an issue on
mscorjit.dll (X64) was build against the SP1 msvcrt80.dll (not that it had
anything to do with the CRT itself).
The RTM downloads of the V2 framework, are all build against the pre-VS2005
SP1 CRT libraries, SP1 for VC2005 contains fixes for C++ tools and
libraries like MFC, ATL and a some OLE, but (AFAIK) no msvcrt80.dll fixes.
The CLR doesn't depend on MFC nor on ATL, so IMO the version of the msvcrt
is a non-issue, unless you have found a bug in the CLR code that relates to
the C run-time.

Willy.
 
The RTM downloads of the V2 framework, are all build against the
pre-VS2005
SP1 CRT libraries, SP1 for VC2005 contains fixes for C++ tools and
libraries like MFC, ATL and a some OLE, but (AFAIK) no msvcrt80.dll fixes.
The CLR doesn't depend on MFC nor on ATL, so IMO the version of the msvcrt
is a non-issue, unless you have found a bug in the CLR code that relates
to the C run-time.
Click to expand...

If there were no fixes, then why'd they change the version and automatically
manifest all apps built with SP1 to require the new version?
 
Ben Voigt said:
If there were no fixes, then why'd they change the version and
automatically manifest all apps built with SP1 to require the new version?
Click to expand...


Take a look at the list of the bug fixes in SP1, there are very few CRT
related fixes, and IMO none of them relate to the CLR.
Anyway, the (latest) CLR modules (like mscorwks.dll, mscorjits.dll) are
built against VC 2005 SP1 (VC compiler version 14.00.50727.762) and they get
a version number which is = or > 8.0.50727.762, the manifests in these
modules however still refer to: "Mcrosoft.VC80.CRT" version="8.0.50608.0" .
That means that the "patched" framework libraries don't explicitly depend on
SP1 of the CRT.
If you have VC++ 2005 SP1 installed on a system that runs a "patched" CLR,
you'll see the CRT 8.0.50727.762 loaded into your process, if you don't have
SP1, you'll get 8.0.50727.42 loaded and all CLR apps. are working as
expected.

Now, when you are building C++ (/clr or clr:pure) apps. against VC2005 SP1,
the default manifest specifies the version number of the CRT your
application was built with (8.0.50727.762) , so you need to have this
version installed to be able to run, the CLR will load this same version (or
an higher version when available) without any problem.

Willy.
 
Willy Denoyette said:
Take a look at the list of the bug fixes in SP1, there are very few CRT
related fixes, and IMO none of them relate to the CLR.
Anyway, the (latest) CLR modules (like mscorwks.dll, mscorjits.dll) are
built against VC 2005 SP1 (VC compiler version 14.00.50727.762) and they
get a version number which is = or > 8.0.50727.762, the manifests in these
modules however still refer to: "Mcrosoft.VC80.CRT" version="8.0.50608.0"
. That means that the "patched" framework libraries don't explicitly
depend on SP1 of the CRT.
If you have VC++ 2005 SP1 installed on a system that runs a "patched" CLR,
you'll see the CRT 8.0.50727.762 loaded into your process, if you don't
have SP1, you'll get 8.0.50727.42 loaded and all CLR apps. are working as
expected.

Now, when you are building C++ (/clr or clr:pure) apps. against VC2005
SP1, the default manifest specifies the version number of the CRT your
application was built with (8.0.50727.762) , so you need to have this
version installed to be able to run, the CLR will load this same version
(or an higher version when available) without any problem.
Click to expand...

And if you load a C++ assembly compiled with SP1 into a C# main app.... all
hell breaks loose, because the main app controls the version of the runtime
loaded.

My basic premise is that Microsoft should not continue distributing the old
CRT, except possibly as a special download. Any and all apps which use the
CRT (including the Framework) should have the very latest CRT rolled into
the installer at the first update. Of course, MS should also update their
Framework installer with the latest patches, so you don't have a window of
vulnerability. That's what slipstreamed Windows Service Packs do, why not
..NET?
 
Ben Voigt said:
And if you load a C++ assembly compiled with SP1 into a C# main app....
all hell breaks loose, because the main app controls the version of the
runtime loaded.
Click to expand...

No, the CLR (v2.0.50727.xx) loads the CRT with highest version installed in
WinSxS (using WinSxS manifest). Now, as your C++ assembly (a DLL built
against SP1) depend on the SP1 bits, you need to install the SP1 bits so the
CLR loads the same CRT as required by your assembly. Build a C# main that
calls a C++/CLI SP1 assembly on a V2 RTM (2.0.50727.42) box with VC2005 SP1
installed, what makes you think hell will break loose?


My basic premise is that Microsoft should not continue distributing the
old CRT, except possibly as a special download. Any and all apps which
use the CRT (including the Framework) should have the very latest CRT
rolled into the installer at the first update. Of course, MS should also
update their Framework installer with the latest patches, so you don't
have a window of vulnerability. That's what slipstreamed Windows Service
Packs do, why not .NET?
Click to expand...

Why? The CLR does not depend on any version of the CRT as long as it's equal
or higher than (VC80.CRT) 8.0.50727.42, he's quite happy to load and run
with VC80.CRT v2.0.50727.762. Keep in main that SP1 is not a Framework SP
it's a VS2005 SP. The majority of the bug fixes relate to VC++, a very few
are related to VS2005 (the IDE) and none have something to do with the
managed framework.

Willy.
 
Back
Top