Rob Mensching-5 wrote:
>
> I'm admittedly hardcore about this but IMHO custom actions should be
> native code DLLs that have as few dependencies as physically possible
> (certainly should have no dependency on WTL). Statically linking the
> CRT then use as few DLLs from the system provides t
I'm admittedly hardcore about this but IMHO custom actions should be
native code DLLs that have as few dependencies as physically possible
(certainly should have no dependency on WTL). Statically linking the
CRT then use as few DLLs from the system provides the highest
probability that the cod
In regards to Rob Mensching's comment,
>
>Statically link. That's what all the WiX CustomActions do and while it
>makes the DLLs a bit bigger it totally minimizes the number of
>dependencies (especially nasty ones like the Win32 SxS CRT junk).
Static linking definitely seems like the right thing
Aris Green wrote:
>
>
> A question, how do VC 2005 CA's requiring the C++ CRT Dll work on
> Vista? Any
> CRT using C++/CLI require a DLL link to the CRT.
>
Statically link. That's what all the WiX CustomActions do and while it
makes the DLLs a bit bigger it totally minimizes the number of
dep
Try embedding the other DLL as a custom resource using the .rc file.
Extract
the DLL first thing when the CA is called. Use delayload linker option or
LoadLibrary to call the function in the extracted DLL. I've done this
before.
A question, how do VC 2005 CA's requiring the C++ CRT Dll work on V
If my CA in MyCA.dll needs to call a fn in MyUtils.dll then I'm currently
expecting to have to write a separate pair of CAs that pull MyUtils.dll out
of the Binary table and then delete it at end-of-setup.
InstallShield provides just such a handy pair of Custom Actions
(ISSETUPFILESEXTRACT & co.),
6 matches
Mail list logo
