Manifest question!
in [Visual C]
|
From: Atmapuri on 23 Jan 2009 11:27 Hi! I am using VS2008 to build dlls which were before built with VS2003. When I start the application, which is not written in MS VC++, but is using these dll's, I get message a: R6034 application tried to load the C runtime library incorrectly Now the question. After VS2008 compiler finished its job on the dll's, what is still neccessary to make the application using these dll's run? I have read about manifests, and have embedded the manifests in the two dll's (those produced by the compiler). That did not help. What else is missing? Thanks! Atmapuri
From: Giovanni Dicanio on 23 Jan 2009 11:42 "Atmapuri" <janez.makovsek(a)usa.net> ha scritto nel messaggio news:3012D618-754F-4075-BC8D-CEC04006C670(a)microsoft.com... > I am using VS2008 to build dlls which were before built with > VS2003. When I start the application, which is not written in > MS VC++, but is using these dll's, I get message a: > > R6034 application tried to load the C runtime library incorrectly My understanding is that your DLLs are set to do dynamic linking with VS2008 CRT, and this dynamic linking is failing. If my understanding is correct, have you tried so called "app local deployment" that Jochen describes so well in his blog here? http://blog.kalmbach-software.de/2008/05/03/howto-deploy-vc2008-apps-without-installing-vcredist_x86exe/ HTH, Giovanni
From: Atmapuri on 23 Jan 2009 11:54 Hi! >> I am using VS2008 to build dlls which were before built with >> VS2003. When I start the application, which is not written in >> MS VC++, but is using these dll's, I get message a: >> >> R6034 application tried to load the C runtime library incorrectly > > My understanding is that your DLLs are set to do dynamic linking with > VS2008 CRT, Yes. > and this dynamic linking is failing. I would say so. My dlls only use the mscvrt.lib. Nothing else. > If my understanding is correct, have you tried so called "app local > deployment" that Jochen describes so well in his blog here? > > http://blog.kalmbach-software.de/2008/05/03/howto-deploy-vc2008-apps-without-installing-vcredist_x86exe/ Well. This requires access to the application. I only make dll's. If I understand correctly, until now (using VS2003), it was possible: To deploy the dll and the msvcrt71.dll and copy to System32 dll. But with VS2005 and anwards you need something much more. How much more? Is it even possible to deploy dll's linked to msvcrt.lib without the need to update the manifests for all aplications using it? Can dll's produced by VS2005 and later be used by other development environments? For example if the compiler produces exe, that exe would have to be signed with a manifest before the debugger could start, if the application uses a dll which depends upon msvcrt90.dll? Thanks! Atmapuri -
From: Giovanni Dicanio on 23 Jan 2009 12:11 "Atmapuri" <janez.makovsek(a)usa.net> ha scritto nel messaggio news:B39C6563-20A6-4A66-AFAD-DD1A65AACD02(a)microsoft.com... > If I understand correctly, until now (using VS2003), > it was possible: > > To deploy the dll and the msvcrt71.dll and copy to System32 dll. IMHO, I would put some DLLs in the same folder of an application, but I would not "pollute" a "global" system directory like Windows\System32. > But with VS2005 and anwards you need something much more. > How much more? Since VS2005 they proposed the idea of manifests to fight the "DLLHell" (but now we kind of have a "Manifest Hell"...). Frankly speaking, I am in favour of *static* linking to CRT/ATL/MFC; that makes deployment much easier. Have you tried building your DLLs with CRT static linked to them? In case it is not possible for you, the app local deployment that Jochen describes on his blog is a good path. Or you should download and run vcredist_x86 on the target machine: [For VS2005] http://www.microsoft.com/downloads/details.aspx?familyid=200b2fd9-ae1a-4a14-984d-389c36f85647&displaylang=en > Can dll's produced by VS2005 and later be used by other > development environments? It depends on the DLLs. If the DLLs have a C++ interface, it is even dangerous to use these DLLs from EXEs built with the same compiler, but with different compiler settings/switches! DLLs that export a pure C interface are safer (e.g. you don't have STL classes on the DLL boundaries, etc.). If you want your DLLs to be well "shielded" from particular compilers, and compiler switches, and you want to safely use these DLLs from different languages, COM is the way to go (and also in this case, I would do a static linking with both CRT and ATL, assuming that you use ATL as an helper tool to build your COM DLLs). Giovanni
From: Atmapuri on 23 Jan 2009 12:49
Hi! > Frankly speaking, I am in favour of *static* linking to CRT/ATL/MFC; that > makes deployment much easier. > Have you tried building your DLLs with CRT static linked to them? Yes. It did not work. There are some other problems. > In case it is not possible for you, the app local deployment that Jochen > describes on his blog is a good path. The problem is that I cant make my dll's work with my app on the development machine. I have not even got to the deployment. > Or you should download and run vcredist_x86 on the target machine: > > [For VS2005] > http://www.microsoft.com/downloads/details.aspx?familyid=200b2fd9-ae1a-4a14-984d-389c36f85647&displaylang=en > > >> Can dll's produced by VS2005 and later be used by other >> development environments? > > It depends on the DLLs. The dll only exports ansi C style functions. No classes and no ActiveX. When dlls is made with VS2003 it works and when made with VS2005 it gives errorL: R6034 application tried to load the C runtime library incorrectly I was hoping for some instructions, what must the manifest contents be like. How do I debug exactly what the problem is. And most importantly off all: Is it possible for an application which does not have a manifest to use dll which uses msvcrt90 at all? Thanks! Atmapuri |