 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / October 2007/clr:pure and unmanaged lib
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? >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). 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....  SignatureGreetings Jochen My blog about Win32 and .NET http://blog.kalmbachnet.de/ > Hi Ben! > [quoted text clipped - 12 lines] > > 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. 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 [quoted text clipped - 12 lines] > 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 SignatureGreetings Jochen My blog about Win32 and .NET http://blog.kalmbachnet.de/ > Hi Willy! > [quoted text clipped - 19 lines] > 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. > 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. <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). 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... SignatureGreetings Jochen My blog about Win32 and .NET http://blog.kalmbachnet.de/ > Hi Willy! > [quoted text clipped - 3 lines] > 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... >> But this does not mean, that you do not need to redistribute the >> vcredist_x86.exe if you compile with "/clr". [quoted text clipped - 7 lines] > > 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. 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. >> I general you can say: >> If you compile with /clr:pure, you only need the .NET-Redistributable. [quoted text clipped - 4 lines] > 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. > <dependency> > <dependentAssembly> [quoted text clipped - 6 lines] > > Willy. >>> But this does not mean, that you do not need to redistribute the >>> vcredist_x86.exe if you compile with "/clr". [quoted text clipped - 11 lines] > 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. [quoted text clipped - 8 lines] > 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. >> 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. [quoted text clipped - 4 lines] > 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. >>> 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. [quoted text clipped - 8 lines] > 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. > The RTM downloads of the V2 framework, are all build against the > pre-VS2005 [quoted text clipped - 3 lines] > 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? >> The RTM downloads of the V2 framework, are all build against the >> pre-VS2005 [quoted text clipped - 6 lines] > 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. >>> The RTM downloads of the V2 framework, are all build against the >>> pre-VS2005 [quoted text clipped - 26 lines] > 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. >>>> The RTM downloads of the V2 framework, are all build against the >>>> pre-VS2005 [quoted text clipped - 30 lines] > 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 [quoted text clipped - 3 lines] > 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. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.