From: Atmapuri on 23 Jan 2009 15:47 Hi! I found out I have the exact same problem as Tuesday, August 21, 2007 8:40 AM by Wengyik Yeong posted here: http://blogs.msdn.com/nikolad/articles/427101.aspx " If I put an external firefox.exe.manifest file into the folder where the firefox.exe executable resides, the error goes away, but I can't do that when redistributing my DLL. I also have no control over the Firefox executable. So what can I do in this scenario, where I have a DLL that depends on the Microsoft.VC80.CRT assembly (and which has a correct manifest that reflects that), but which is being used by an executable (Firefox, over which I have no control) that doesn't have the VC80 runtime dependency, and whose embedded manifest does not refer to Microsoft.VC80.CRT? " Anybody found a solution for this? Thanks! Atmapuri "Giovanni Dicanio" <giovanniDOTdicanio(a)REMOVEMEgmail.com> wrote in message news:e6Sgf2XfJHA.4728(a)TK2MSFTNGP05.phx.gbl... > > "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: Giovanni Dicanio on 23 Jan 2009 16:31 "Atmapuri" <janez.makovsek(a)usa.net> ha scritto nel messaggio news:OFMFEvZfJHA.2384(a)TK2MSFTNGP04.phx.gbl... > So what can I do in this scenario, where I have a DLL that depends on the > Microsoft.VC80.CRT assembly (and which has a correct manifest that > reflects that), but which is being used by an executable (Firefox, over > which I have no control) that doesn't have the VC80 runtime dependency, > and whose embedded manifest does not refer to Microsoft.VC80.CRT? > > " > Anybody found a solution for this? You have control on the DLLs, because you build them, is this correct? If so, could you static link your DLLs with the CRT? Giovanni
From: Atmapuri on 23 Jan 2009 16:36 Hi! >> Anybody found a solution for this? > > You have control on the DLLs, because you build them, is this correct? > If so, could you static link your DLLs with the CRT? The dll's depend upon other static libraries (openMP) which do not support statically linked run time library. Thanks! Atmapuri
From: Giovanni Dicanio on 24 Jan 2009 04:37 "Atmapuri" <janez.makovsek(a)usa.net> ha scritto nel messaggio news:%23JCsbLafJHA.5956(a)TK2MSFTNGP06.phx.gbl... >> You have control on the DLLs, because you build them, is this correct? >> If so, could you static link your DLLs with the CRT? > > The dll's depend upon other static libraries (openMP) > which do not support statically linked run time library. If you can't use static-linking to CRT for your DLLs, and you must use dynamic-linking to CRT, then I think that you may consider downloading and installing the vcredist_x86.exe: http://www.microsoft.com/downloads/details.aspx?familyid=D5692CE4-ADAD-4000-ABFE-64628A267EF0&displaylang=en This is a free download and your clients can use it to install the VC++2008 CRT required by your DLLs. Giovanni
From: Atmapuri on 26 Jan 2009 04:28
Hi! > If you can't use static-linking to CRT for your DLLs, and you must use > dynamic-linking to CRT, then I think that you may consider downloading and > installing the vcredist_x86.exe: > > http://www.microsoft.com/downloads/details.aspx?familyid=D5692CE4-ADAD-4000-ABFE-64628A267EF0&displaylang=en > > This is a free download and your clients can use it to install the > VC++2008 CRT required by your DLLs. I cant make the dll run on the development machine anyway. So why use a redistribution package? Atmapuri |