/clr:pure and unmanaged lib

[=?Utf-8?B?d3BjbWFtZQ==?=]

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?

[Ben Voigt [C++ MVP]]

"wpcmame" <wp*****@discussions.microsoft.comwrote in message
news:05**********************************@microsof t.com...

>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).

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?

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).

[Jochen Kalmbach [MVP]]

Hi Ben!

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

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

????

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/

[Willy Denoyette [MVP]]

"Jochen Kalmbach [MVP]" <no********************@holzma.dewrote in message
news:eY*************@TK2MSFTNGP02.phx.gbl...

Hi Ben!

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

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

????

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....

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.

[Jochen Kalmbach [MVP]]

Hi Willy!

>>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

????

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....

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.

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 [MVP]]

Hi Willy!

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

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.

Upps... thanks for clarification...
--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

[Willy Denoyette [MVP]]

"Jochen Kalmbach [MVP]" <no********************@holzma.dewrote in message
news:O6*************@TK2MSFTNGP05.phx.gbl...

Hi Willy!

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

Starting with VS2005 it is not supported to use /clr and link statically
against the CRT ;)

True :-(

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

Upps... thanks for clarification...
--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

[Willy Denoyette [MVP]]

"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in message
news:Od**************@TK2MSFTNGP04.phx.gbl...

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

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.

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.

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.

>>

>>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

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.

Pure is MSIL only, but the CRT includes an MSIL version of some functions,
so the dependency still exists.

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.

[Ben Voigt [C++ MVP]]

>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.

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.

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.

[Willy Denoyette [MVP]]

"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in message
news:OR**************@TK2MSFTNGP06.phx.gbl...

>>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.

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.

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.

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.

[Ben Voigt [C++ MVP]]

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.

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?

[Willy Denoyette [MVP]]

"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

>

>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.

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?

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.

[Ben Voigt [C++ MVP]]

"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:e0*************@TK2MSFTNGP05.phx.gbl...

"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

>>

>>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.

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?

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.

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?

>
Willy.

[Willy Denoyette [MVP]]

"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in message
news:uw**************@TK2MSFTNGP02.phx.gbl...

>
"Willy Denoyette [MVP]" <wi*************@telenet.bewrote in message
news:e0*************@TK2MSFTNGP05.phx.gbl...

>"Ben Voigt [C++ MVP]" <rb*@nospam.nospamwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

>>>
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.

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?

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.

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.

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?

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.