Thanks for the info Mike, I think I had the general idea about the
static version vs the import library, though I wouldn't have known what
to call them.  I mentioned that when I included it, my installer kind of
worked, because I thought it might be helpful in providing some sort of
basis that the code was working in some scenarios.

 

            I never include a #pragma comment(lib)

 

I went and removed all of the #pragma comment(lib) lines and added the
following as my additional dependencies:

 

            Are there any more libraries listed in the Link section of
the project properties?

 

After removing the #pragma comment(lib) lines, I put the following under
"additional dependencies" in the linker input tab. 

libcmt.lib msi.lib dutil.lib wcautil.lib shlwapi.lib advapi32.lib

 

I've been suspicious that I might not be using the right libraries
together... here are my "additional library directories" as listed in
the properties gui.

"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Lib";

"C:\Program Files\Microsoft Visual Studio 8\VC\lib";

"C:\Program Files\Windows Installer XML v3\SDK\lib";

"C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Lib"

 

If I build with those settings, it succeeds, but the installer quits
when it tries to use the dll.

 

If I remove libcmt.lib from the dependency list, I get lots of
unresolved external symbol compile errors, ex.

LicenseFileUtils.obj : error LNK2019: unresolved external symbol "void
__cdecl operator delete(void *)"

wcautil.lib(wcautil.obj) : error LNK2001: unresolved external symbol
__RTC_InitBase

 

 

 

________________________________

From: Mike Dimmick [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 15, 2007 2:25 PM
To: Rowland, Chris; WiX-users@lists.sourceforge.net
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [WiX-users] CustomAction = .VC Runtime Dependency?

 

I never include a #pragma comment(lib) for any C runtime library,
whether static or dynamic. For that I always use the /MT[d] or /MD[d]
switch (normally set through the IDE). You can't link to multiple
versions of the CRT. libcmt.lib is the static version of the CRT;
msvcrt.lib is the import library for the CRT DLL. In case you're not
familiar with the concept, the import library simply consists of a set
of stubs and information to the linker to build the necessary import
table. libcmt.lib and msvcrt.lib therefore contain 'implementations' of
the same functions so you get link errors.

 

I'm guessing dutil.lib and wcautil.lib are from WiX itself. They're
static libraries, so that shouldn't be a problem. advapi32.lib and
msi.lib are import libraries that are guaranteed to be present on any
Windows system with Windows Installer; shlwapi.lib is the import library
for shlwapi.dll, which was added in Internet Explorer 4.0 and should
therefore be present on Windows 98, Windows 2000 and newer. The WiX
custom actions don't support Windows 9X IIRC.

 

Are there any more libraries listed in the Link section of the project
properties?

 

-- 

Mike Dimmick

 

________________________________

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: 15 May 2007 18:42
To: WiX-users@lists.sourceforge.net
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [WiX-users] CustomAction = .VC Runtime Dependency?

 

I'd appreciate any advice that could point me in the direction of
solving this problem.

 

With my project settings as they are, if I build the dll and the
installer, the installer will fail with the usual premature termination
error, because my dll failed to load.

 

I started working from a template I found online, so I may have been
following bad practices.

 

I'm compiling with /MT and have the following lines in my source

#pragma comment(lib,"msi.lib")

#pragma comment(lib,"shlwapi.lib")

#pragma comment(lib,"libcmt.lib")

#pragma comment(lib,"dutil.lib")

#pragma comment(lib,"advapi32.lib")

#pragma comment(lib,"wcautil.lib")

 

If I add this line

#pragma comment(lib,"msvcrt.lib")

Before the libcmt line, I get the warning LNK4098: defaultlib
'libcmt.lib' conflicts with use of other libs

 

That makes sense to me, because from what I understand, msvcrt is the
dynamic multi-threaded library, and libcmt is the static one.  The dll
that results from having that line added is much smaller, which makes me
believe its now dynamically linking dispite the /MT flag.

 

The part I'm having trouble understanding is that with msvcrt.lib, the
installer works (on systems where the runtime is installed), but without
it, the installer dies un able to run the dll code.  

 

I'm assuming its either an issue with the project properties and/or my
use of those #pragma directives, but I'm not sure how to proceed.

Any ideas? (Obvious ones included :-) )

 

________________________________

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Tuesday, May 15, 2007 11:34 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; WiX-users@lists.sourceforge.net
Subject: Re: [WiX-users] CustomAction = .VC Runtime Dependency?

 

So now's the time to add logging or even a MessageBox call to verify
that the function is now being loaded and executed.

 

Based on everything I've learned to this point, all signs point to
something wrong in how I built the dll.

 

I have logging throughout the dll already, and the project settings are
all that changed (it was semi-working before.)

 

In the past these "executing action failed" errors have meant a missing
dependency.  My tendency here is to suspect I have mismatched libraries
or something along those lines, though I've got nothing to base that on.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Reply via email to