From: Atmapuri on
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

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

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