[WiX-users] Crash in MsiGetProperty call (did not close MSIHANDLEs)
I'm having a problem where it appears that my custom action is terminating during a MsiGetProperty call. Hopefully someone could provide some insight into the issue. I've simplified reproducing the problem to this /* Get the Installation directory from the installer / WcaLog(LOGMSG_STANDARD, Get TARGETDIR); TCHAR* installDirBuf = NULL; uiStat = MsiGetProperty(hInstall, TEXT(TARGETDIR), TEXT(), cchValueBuf); return WcaFinalize(ERROR_SUCCESS); With the return before the call to MsiGetProperty, the install completes without issue. With the return following the MsiGetProperty call, I get the following error in the log. DEBUG: Error 2769: Custom Action AddToPaths did not close 1 MSIHANDLEs. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: AddToPaths, 1, Action ended 15:14:15: AddToPaths. Return value 3. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Crash in MsiGetProperty call (did not closeMSIHANDLEs)
I'm using the technique shown here http://msdn2.microsoft.com/En-US/library/aa370134.aspx to dynamically determine the size of the buffer required. I just removed the rest of the code because it doesn't make it that far. I've used this technique in the past with no problem. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wilson, Phil Sent: Thursday, August 02, 2007 3:58 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Crash in MsiGetProperty call (did not closeMSIHANDLEs) There's supposed to be an output buffer as the 3rd parameter whose length is cchValueBuf. Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, August 02, 2007 12:38 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Crash in MsiGetProperty call (did not close MSIHANDLEs) I'm having a problem where it appears that my custom action is terminating during a MsiGetProperty call. Hopefully someone could provide some insight into the issue. I've simplified reproducing the problem to this /* Get the Installation directory from the installer / WcaLog(LOGMSG_STANDARD, Get TARGETDIR); TCHAR* installDirBuf = NULL; uiStat = MsiGetProperty(hInstall, TEXT(TARGETDIR), TEXT(), cchValueBuf); return WcaFinalize(ERROR_SUCCESS); With the return before the call to MsiGetProperty, the install completes without issue. With the return following the MsiGetProperty call, I get the following error in the log. DEBUG: Error 2769: Custom Action AddToPaths did not close 1 MSIHANDLEs. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: AddToPaths, 1, Action ended 15:14:15: AddToPaths. Return value 3. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Crash in MsiGetProperty call (did notcloseMSIHANDLEs)
I did switch it so it was always 0 and that fixed the problem. I somehow thought that wasn't the real problem, but I guess it was :) I have bad memories of the problem being somewhere entirely different than it appears. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wilson, Phil Sent: Thursday, August 02, 2007 4:22 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Crash in MsiGetProperty call (did notcloseMSIHANDLEs) Right, but your code example doesn't say what you set the value of cchValueBuf to. Is it in fact zero? Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, August 02, 2007 1:06 PM To: Wilson, Phil; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Crash in MsiGetProperty call (did not closeMSIHANDLEs) I'm using the technique shown here http://msdn2.microsoft.com/En-US/library/aa370134.aspx to dynamically determine the size of the buffer required. I just removed the rest of the code because it doesn't make it that far. I've used this technique in the past with no problem. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wilson, Phil Sent: Thursday, August 02, 2007 3:58 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Crash in MsiGetProperty call (did not closeMSIHANDLEs) There's supposed to be an output buffer as the 3rd parameter whose length is cchValueBuf. Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, August 02, 2007 12:38 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Crash in MsiGetProperty call (did not close MSIHANDLEs) I'm having a problem where it appears that my custom action is terminating during a MsiGetProperty call. Hopefully someone could provide some insight into the issue. I've simplified reproducing the problem to this /* Get the Installation directory from the installer / WcaLog(LOGMSG_STANDARD, Get TARGETDIR); TCHAR* installDirBuf = NULL; uiStat = MsiGetProperty(hInstall, TEXT(TARGETDIR), TEXT(), cchValueBuf); return WcaFinalize(ERROR_SUCCESS); With the return before the call to MsiGetProperty, the install completes without issue. With the return following the MsiGetProperty call, I get the following error in the log. DEBUG: Error 2769: Custom Action AddToPaths did not close 1 MSIHANDLEs. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: AddToPaths, 1, Action ended 15:14:15: AddToPaths. Return value 3. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] CustomAction = .VC Runtime Dependency?
Running depends on a problem machine is just showing me issues with MSJAVA.DLL and MPR.DLL. The depends FAQ makes me think they aren't really issues to be concerned with. Also, building statically, I don't know of a machine that it does work on. I have only been testing on my development XP machine. When I was mistakenly building dynamically, it worked anywhere with .NET 2.0 (and on problem machines, depends showed MSVCP80.dll) From: Dustin Andrews [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 15, 2007 7:08 PM To: Rowland, Chris; [EMAIL PROTECTED]; WiX-users@lists.sourceforge.net Subject: RE: Re: [WiX-users] CustomAction = .VC Runtime Dependency? Ok. Now profile (run) the program under depends.exe on the machine having problems. Compare that to a run on a working machines and I bet you find what you need. -D From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, May 15, 2007 2:01 PM To: [EMAIL PROTECTED]; WiX-users@lists.sourceforge.net Subject: Re: [WiX-users] CustomAction = .VC Runtime Dependency? The dependency walker doesn't use any unusual Dlls. If you haven't already tried this, get to a system where your custom action Dll fails, just copy depends.exe and your Dll onto it and see what it says about any missing dependencies. The only missing dll is MSJAVA.dll, which is not an issue as far as I understand. My preference with included libs and h files is to make sure that they are compatible, and I prefer the SDK to take preference over Visual Studio. I'd put the R2 directory at the top for h and lib if R2 was my target base OS. I ordered my additional library directories C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Lib; 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 and my additional include directories C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include; C:\Program Files\Windows Installer XML v3\SDK\inc The installer needs to run on XP and Vista. I'm using the 2003 R2 SDK because it was the newest SDK I saw, and was always pushed to the forefront when I searched Microsoft's site. Will that cause a problem when running on XP? Because the dll works to a degree when dynamically linked to the CRT, and doesn't work at all when statically linked, I'm thinking that libcmt.lib is a good suspect. One thing I've noticed, and maybe this is expected, is that my 2003 SDK Lib directory doesn't contain libcmt.lib. The AMD64 and IA64 subdirectories do, though. So with the above library directory sequence, libcmt.lib will be found in the VS8 SDK lib directory, while other dependencies (msi.lib, shlwapi.lib, and advapi32.lib) are all found in the 2003 SDK directory. Does that sound like a problem? It's not just that dependent Dlls need to be present - it's also all the exports that have to match the lib you included. How would one go about verifying this? - 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
Re: [WiX-users] CustomAction = .VC Runtime Dependency?
I'm compiling my CA dll with the /MT flag. Running dependency walker on the system where it won't install shows the dll is dependent on msvcr80.dll. Why would the dll continue to be dependent on msvcr80.dll even though I've specified to link statically? A co-worker told me it's impossible to create a dll that statically links to a library, but that's certainly not the vibe I'm getting from everyone's comments. Additionally, the size of the dll doesn't change if I change the flag between /MT (multi-threaded static) and /MD (multi-threaded dynamic) As someone who doesn't know my way around visual studio very well, it sure seems like the flag is being ignored... Any ideas? - 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
Re: [WiX-users] CustomAction = .VC Runtime Dependency?
Thanks for the suggestion. It didn't seem to have any effect though. The size of the dll (and all the other files in the build directory) stayed the same, and the msvcr80.dll dependency still exists. From: Brian Simoneau [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 15, 2007 9:35 AM To: Rowland, Chris; WiX-users@lists.sourceforge.net Cc: [EMAIL PROTECTED] Subject: RE: [WiX-users] CustomAction = .VC Runtime Dependency? In the General Configuration Properties, you also need to set Use of MFC to Use MFC in a Static Library. That should get rid of the dependency and increase the size of the dll. -Brian Simoneau -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, May 15, 2007 9:32 AM To: WiX-users@lists.sourceforge.net Cc: [EMAIL PROTECTED] Subject: Re: [WiX-users] CustomAction = .VC Runtime Dependency? I'm compiling my CA dll with the /MT flag. Running dependency walker on the system where it won't install shows the dll is dependent on msvcr80.dll. Why would the dll continue to be dependent on msvcr80.dll even though I've specified to link statically? A co-worker told me it's impossible to create a dll that statically links to a library, but that's certainly not the vibe I'm getting from everyone's comments. Additionally, the size of the dll doesn't change if I change the flag between /MT (multi-threaded static) and /MD (multi-threaded dynamic) As someone who doesn't know my way around visual studio very well, it sure seems like the flag is being ignored... Any ideas? - 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
Re: [WiX-users] CustomAction = .VC Runtime Dependency?
While its not the stupid error you pointed out, it was the result of another stupid error... I think. I'm still not good with the VS environment. It turns out, for whatever reason, I had been specifying msvcrtd.lib as an additional dependency. My interpretation is that it made the linker dynamically link to that instead of the correct static library. Adjusting my additional dependency list looked promising. It caused my dll to increase in size (seems good) and caused the Dependency Walker to show the dependency had gone away (also good.) However, in a throwback to days I thought I had left in my wake, the installer now bails when trying to access the dll with the handy failed to execute error... Dependency Walker isn't throwing up any (noteworthy) red flags this time around, so I might be stuck experimenting with build settings some more. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 15, 2007 10:12 AM To: Rowland, Chris; WiX-users@lists.sourceforge.net Subject: RE: [WiX-users] CustomAction = .VC Runtime Dependency? Chris, Just for stupidity's sake, make sure you have changed that setting for the correct build. I spent almost an hour one morning wondering why something wasn't linking the way I expected, only to find that I had made the change in the release settings and was trying to use the debug build! :-) Boy did I feel stupid when I found that one! Serves me right for doing a batch build each time and thinking that if the file modified time was correct I must be using the right file! Regards, Richard P.S. I just looked at the configuration for the custom action we have. (Visual Studio 2005 - your mileage may vary.) We are apparently using the Use Standard Windows Libraries option instead of the static / dynamic MFC choices. Dependency walker shows just three direct dependencies - MSI.dll, USER32.dll and KERNEL32.dll. P.P.S. I also thought it is worth mentioning that for the purpose of this exercise you are probably only interested in direct dependencies. It is perfectly possible that Microsoft may decide to make some of their libraries dependent on msvcr80.dll, but if you are not using the runtime directly its use by other parts of the system should be transparent to your code. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, May 15, 2007 9:48 AM To: [EMAIL PROTECTED]; WiX-users@lists.sourceforge.net Cc: [EMAIL PROTECTED] Subject: Re: [WiX-users] CustomAction = .VC Runtime Dependency? Thanks for the suggestion. It didn't seem to have any effect though. The size of the dll (and all the other files in the build directory) stayed the same, and the msvcr80.dll dependency still exists. * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Peek Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - 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
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
Re: [WiX-users] CustomAction = .VC Runtime Dependency?
The dependency walker doesn't use any unusual Dlls. If you haven't already tried this, get to a system where your custom action Dll fails, just copy depends.exe and your Dll onto it and see what it says about any missing dependencies. The only missing dll is MSJAVA.dll, which is not an issue as far as I understand. My preference with included libs and h files is to make sure that they are compatible, and I prefer the SDK to take preference over Visual Studio. I'd put the R2 directory at the top for h and lib if R2 was my target base OS. I ordered my additional library directories C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Lib; 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 and my additional include directories C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include; C:\Program Files\Windows Installer XML v3\SDK\inc The installer needs to run on XP and Vista. I'm using the 2003 R2 SDK because it was the newest SDK I saw, and was always pushed to the forefront when I searched Microsoft's site. Will that cause a problem when running on XP? Because the dll works to a degree when dynamically linked to the CRT, and doesn't work at all when statically linked, I'm thinking that libcmt.lib is a good suspect. One thing I've noticed, and maybe this is expected, is that my 2003 SDK Lib directory doesn't contain libcmt.lib. The AMD64 and IA64 subdirectories do, though. So with the above library directory sequence, libcmt.lib will be found in the VS8 SDK lib directory, while other dependencies (msi.lib, shlwapi.lib, and advapi32.lib) are all found in the 2003 SDK directory. Does that sound like a problem? It's not just that dependent Dlls need to be present - it's also all the exports that have to match the lib you included. How would one go about verifying this? - 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
Re: [WiX-users] CustomAction = .NET dependancy?
One system in question had version 1 of the .NET framework, and installing version 2 made the problem go away. Any tips on how to find out what the dependency is, and how I can configure my build setting to remove it? From: Rowland, Chris Sent: Thursday, May 10, 2007 2:07 PM To: 'Bob Arnson' Cc: WiX-users@lists.sourceforge.net Subject: RE: [WiX-users] CustomAction = .NET dependancy? I was having this issue on a Vista machine and I changed my build settings to use the setting No Common Language Runtime support and the problem went away. Now the same type of issue (use of a CA in the DLL fails) has popped up on a couple of XP and a 2K system, while it works fine on others. Is there a way to get more information than Error 2896? From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Monday, April 30, 2007 10:34 PM To: Rowland, Chris Cc: WiX-users@lists.sourceforge.net Subject: Re: [WiX-users] CustomAction = .NET dependancy? [EMAIL PROTECTED] wrote: My installer is failing on some systems, and it appears that its dependant on the .NET framework. My CustomActions were authored in VC++. Is .NET always a requirement of installers that use CustomActions or is this a result of the build settings I used to build the DLL? It's definitely your settings. Are you sure it's a dependency on .NET? The typical problem is using the DLL CRT and not having it installed on the target system. -- sig://boB http://joyofsetup.com/ - 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
Re: [WiX-users] ServiceInstall error 1923
Did you run as an administrator?
Error 1923 looks like a permissions problem.
1923: Service '[2]' ([3]) could not be installed. Verify that you have
sufficient privileges to install system services.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of fiordean
dacian
Sent: Friday, May 04, 2007 1:37 PM
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] ServiceInstall error 1923
Hi,
I'm getting a 1923 error during a service install. The message displayed
by Windows Installer is
Here is the WiX source code:
Component Id=DcIs Guid={9A5E7B2C-9B5F-42A3-9715-BC1384C95F15}
File Id=DcSrvc Name=DcIS.exe
LongName=DcIS.exe
Source=$(var.CoreDir)DcIS.exe
DiskId=1 KeyPath=yes/
ServiceInstall Id=DcSrvcInstall
DisplayName=DC Interface Server
Name=DC Interface Server
ErrorControl=normal Interactive=no
Start=demand Type=ownProcess
Vital=yes
/ServiceInstall
/Component
I can't see anything wrong with ServiceInstall/ tag. Any ideas why
this happens?
Thanks,
Dacian
Sucker-punch spam with award-winning protection.
Try the free Yahoo! Mail Beta.
-
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
Re: [WiX-users] Stuck with an uninstall that doesn't work?
I've also discovered that you can use msizap to force remove
uninstallable applications. Msizap comes with the windows platform sdk
and is used like so...
msizap T {product code}
Is using msiexec /fv the preferred method Rob?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Mensching
Sent: Friday, May 04, 2007 2:05 PM
To: JCWrs; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Stuck with an uninstall that doesn't work?
1. Build a fixed MSI.
2. Recache/reinstall the fixed MSI over top the busted installed MSI:
msiexec /fv your.msi
3. Repeat 1 2 until MSI is fixed enough to happily uninstall.
smile/
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of JCWrs
Sent: Friday, May 04, 2007 11:03 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Stuck with an uninstall that doesn't work?
So I ran my installer and all was well. On my attempt to uninstall,
however,
I run into an error. I understand why I'm getting the error and I'm
pretty
sure I can fix it, but because of it I can't uninstall the app.
Everytime I
try to re-run the installer (after I've made the changes to make sure
the
uninstall will work next time) the changes are not there and I still get
the
error (I checked the verbose log and its like the changes never
happened).
Any ideas to make this app go away so I can start over?
--
View this message in context:
http://www.nabble.com/Stuck-with-an-uninstall-that-doesn%27t-work--tf369
3395.html#a10327330
Sent from the wix-users mailing list archive at Nabble.com.
-
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
-
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
-
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
Re: [WiX-users] Stuck with an uninstall that doesn't work?
I'm not sure, but maybe it's trying to compare the property
INSTALLUNINSTALL to the (nonexistent) property INSTALLER?
Maybe you need INSTALLUNINSTALL=INSTALLER
-Original Message-
From: Alex Steen [mailto:[EMAIL PROTECTED]
Sent: Friday, May 04, 2007 2:26 PM
To: Rowland, Chris; [EMAIL PROTECTED];
wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Stuck with an uninstall that doesn't work?
One more thing I'm not getting and maybe this deserves its own thread,
but I've got the following two CA's:
Custom Action=WebInstaller After=InstallFiles
INSTALLUNINSTALL=INSTALLER/Custom
Custom Action=WebUninstall
After=WebInstallerINSTALLUNINSTALL=UNINSTALLER/Custom
In my log I see this line:
MSI (s) (38:84) [13:20:49:941]: PROPERTY CHANGE: Modifying
INSTALLUNINSTALL property. Its current value is 'NOTSET'. Its new value:
'INSTALLER'.
Then this line:
MSI (s) (38:84) [13:20:50:003]: Skipping action: WebInstaller (condition
is false)
How can the condition be false?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, May 04, 2007 1:14 PM
To: [EMAIL PROTECTED]; Alex Steen;
wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Stuck with an uninstall that doesn't work?
I've also discovered that you can use msizap to force remove
uninstallable applications. Msizap comes with the windows platform sdk
and is used like so...
msizap T {product code}
Is using msiexec /fv the preferred method Rob?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Mensching
Sent: Friday, May 04, 2007 2:05 PM
To: JCWrs; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Stuck with an uninstall that doesn't work?
1. Build a fixed MSI.
2. Recache/reinstall the fixed MSI over top the busted installed MSI:
msiexec /fv your.msi
3. Repeat 1 2 until MSI is fixed enough to happily uninstall.
smile/
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of JCWrs
Sent: Friday, May 04, 2007 11:03 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Stuck with an uninstall that doesn't work?
So I ran my installer and all was well. On my attempt to uninstall,
however,
I run into an error. I understand why I'm getting the error and I'm
pretty
sure I can fix it, but because of it I can't uninstall the app.
Everytime I
try to re-run the installer (after I've made the changes to make sure
the
uninstall will work next time) the changes are not there and I still get
the
error (I checked the verbose log and its like the changes never
happened).
Any ideas to make this app go away so I can start over?
--
View this message in context:
http://www.nabble.com/Stuck-with-an-uninstall-that-doesn%27t-work--tf369
3395.html#a10327330
Sent from the wix-users mailing list archive at Nabble.com.
-
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
-
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
-
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
Re: [WiX-users] WixLocalization, not quite getting it.
In WiX 2.0 you would use Text=$(loc.ButtonNext) to reference the string you defined in your localization file. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pseudonymic Wannabe Sent: Thursday, May 03, 2007 5:38 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WixLocalization, not quite getting it. I didn't quite get your tutorial since it messes around with user-selection and using $loc quite heavily. I thought if you create a WixLocalization file and have say String Id=ButtonNextNeste/String inn it and you loaded that file then a button with Text=[ButtonNext] would have Neste as the appropriate text? Don't quite see in your tutorial how you specify which loc.wxs file to use either. - 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
[WiX-users] WiX 3.0 Localization
Due to my unfortunate need for 8.3 paths, I'm finding it necessary to convert from 2.0 to 3.0. One error I got in converting was: error LGHT0010 : The WixLocalization/@Culture attribute was not found; it is required. I took a guess and changed WixLocalization to WixLocalization Culture=en-us and that resolved the compilation error. Long question short... is that correct? I'm calling light with the following arguments. %WIX_HOME%\light -cultures:en-us -out Setup.msi ... -loc ./FUI/WixUI_en-us.wxl I'm having an (unrelated?) issue and wanted to rule that out as the source. - 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
[WiX-users] CustomAction = .NET dependancy?
My installer is failing on some systems, and it appears that its dependant on the .NET framework. My CustomActions were authored in VC++. Is .NET always a requirement of installers that use CustomActions or is this a result of the build settings I used to build the DLL? - 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
[WiX-users] Trouble building with wcautil.lib
In Visual C++ 2005 Express, everything compiles ok until I add the line: WcaInitialize(hInstall, VerifyLicenseDir); which yields the message: LicenseFileUtils.obj : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function [EMAIL PROTECTED] If I add #pragma comment(lib,wcautil.lib) I get wcautil.lib(wcalog.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function int __stdcall IsVerboseLogging(void) (?IsVerboseLogging@@YGHXZ) wcautil.lib(wcalog.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function int __stdcall IsVerboseLogging(void) (?IsVerboseLogging@@YGHXZ) wcautil.lib(wcalog.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function int __stdcall IsVerboseLogging(void) (?IsVerboseLogging@@YGHXZ) I'm not sure what these messages are telling me. Do I have the wrong version of some library? This all worked ok in Visual Studio .NET 2005. --Chris - 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
Re: [WiX-users] Logging in a custom action
As in /MD instead of /MT? From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Friday, April 27, 2007 12:08 PM To: Rowland, Chris Cc: [EMAIL PROTECTED]; WiX-users@lists.sourceforge.net Subject: Re: [WiX-users] Logging in a custom action [EMAIL PROTECTED] wrote: Is there any way to determine from the log why a CA is failing to execute, if it appears that its never even getting into the CA in the first place? That almost always means that the DLL has a dependency not being met, which almost always means you're linking with the DLL version of the runtime library and it's not present on the target. Set the compiler options to link with the static CRT and your life will be much simpler (at least as far as CA DLLs go). -- sig://boB http://bobs.org - 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
Re: [WiX-users] How do you have a component work only on an install?
I have used a condition like this (amp;Complete = 3) AND NOT (!Complete = 3) Where Complete was the id of my main feature. Check out http://www.tramontana.co.hu/wix/lesson5.php It seems to work for me. Maybe someone with more experience has a better suggestion though. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Sam Sent: Friday, April 27, 2007 4:02 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How do you have a component work only on an install? I have a component that updates an XML file using the XmlFile element. I only want this to be ran on a clean install, and not on an upgrade. I'm using wix v3. Here is what my component looks like: DirectoryRef Id=INSTALLDIR Component Id=UpdateDataCollectionCfg Guid=383D9716-7731-4357-B2A8-8DDB2AE86E09 CreateFolder / util:XmlFile Id=DCUpdate1 ElementPath=/configuration/DataCollection/Vals/add Name=Value File=[INSTALLDIR]DataCollectionService.exe.config Action=setValue Value=data source=[DBSERVERNAME];initial catalog=xwDataCollector;trusted_connection=true; / util:XmlFile Id=DCUpdate2 ElementPath=/configuration/connectionStrings/add File=[INSTALLDIR]DataCollectionService.exe.config Action=setValue Value=data source=[DBSERVERNAME];initial catalog=xwEDB;trusted_connection=true; Name=connectionString / ConditionNot Installed/Condition /Component /DirectoryRef I thought that the condition element would achieve the desired results, but that is not the case. Anyone have any ideas on this? - 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 - 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
Re: [WiX-users] Logging in a custom action
I was able to build with a colleague's VC2005 install with no issues (build wise) but in trying to move my project into VC++ 2005 Express on my own system, I get linkage errors. 1wcautil.lib(wcalog.obj) : error LNK2019: unresolved external symbol [EMAIL PROTECTED] referenced in function int __stdcall IsVerboseLogging(void) (?IsVerboseLogging@@YGHXZ) In my project settings I have 2 additional Include directories, and 2 additonal library directories each, corresponding to the wix2 sdk and win2k3 platform sdk include lib directories. Is this evidence of a missing library or version incompatibility? From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Friday, April 27, 2007 11:53 AM To: Rowland, Chris Cc: [EMAIL PROTECTED]; WiX-users@lists.sourceforge.net Subject: Re: [WiX-users] Logging in a custom action [EMAIL PROTECTED] wrote: No, I haven't tried that. The WiX chm explicitly says you need VS 2005 to build. I guess I could try it with 03 anyways. That's why I'm not sure you can use wcautil.lib from VS 7.1. -- sig://boB http://bobs.org - 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
Re: [WiX-users] Logging in a custom action
Thanks, that looks like what I wanted. I'm having trouble linking everything correctly though, and I get a ton of errors in wcautil.h, like E:\Program Files\WiX\sdk\inc\wcautil.h(48): error C2065: '__in' : undeclared identifier And E:\Program Files\WiX\sdk\inc\wcautil.h(48): error C2182: 'WcaGlobalInitialize' : illegal use of type 'void' I've tried to include dutil.lib and wcautil.lib. Is there something else that needs to be configured to use wcautil.lib (specifically WcaLog)? From: Brian Simoneau [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 4:20 PM To: Rowland, Chris; WiX-users@lists.sourceforge.net Subject: RE: [WiX-users] Logging in a custom action If you are writing a C++ custom action, then the WcaLog function in wcautil will write to the install log or show you how to do it yourself. -Brian Simoneau - 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
Re: [WiX-users] Logging in a custom action
I was able to resolve my build errors by defining everything missing
myself (to /**/ ).
I read that they might be defined by default in VS05, but not in VS03
(what I'm using.)
However, I rebuilt my installer with the new DLL and ran it with *cv
logging, and I still don't see anything.
The CA call seems to execute properly in all other regards.
I put a WcaLog statement as the first line in my method.
extern C UINT __stdcall VerifyLicenseDir(MSIHANDLE hInstall)
{
WcaLog(LOGMSG_STANDARD, Enter VerifyLicenseDir);
Here's the section of log where I expected to see some output.
MSI (c) (4C:98) [13:21:11:484]: Doing action: VerifyLicenseDir
MSI (c) (4C:98) [13:21:11:484]: Note: 1: 2205 2: 3: ActionText
Action 13:21:11: VerifyLicenseDir.
Action start 13:21:11: VerifyLicenseDir.
MSI (c) (4C:E8) [13:21:11:500]: Invoking remote custom action. DLL:
C:\... Entrypoint: VerifyLicenseDir
MSI (c) (4C:A4) [13:21:11:500]: Cloaking enabled.
MSI (c) (4C:A4) [13:21:11:500]: Attempting to enable all disabled
priveleges before calling Install on Server
MSI (c) (4C:A4) [13:21:11:500]: Connected to service for CA interface.
MSI (c) (4C!C0) [13:21:11:625]: PROPERTY CHANGE: Modifying NIDPATH
property. ...
MSI (c) (4C!C0) [13:21:11:625]: PROPERTY CHANGE: Modifying FIDPATH
property. ...
Action ended 13:21:11: VerifyLicenseDir. Return value 1.
Any thoughts?
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 12:42 PM
To: [EMAIL PROTECTED]; WiX-users@lists.sourceforge.net
Subject: Re: [WiX-users] Logging in a custom action
Thanks, that looks like what I wanted.
I'm having trouble linking everything correctly though, and I get a ton
of errors in wcautil.h, like
E:\Program Files\WiX\sdk\inc\wcautil.h(48): error C2065: '__in' :
undeclared identifier
And
E:\Program Files\WiX\sdk\inc\wcautil.h(48): error C2182:
'WcaGlobalInitialize' : illegal use of type 'void'
I've tried to include dutil.lib and wcautil.lib. Is there something
else that needs to be configured to use wcautil.lib (specifically
WcaLog)?
-
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
Re: [WiX-users] Logging in a custom action
Thanks for the continuing advice. I'm still not seeing any log out put
though. I've commented out the guts of my CA, so now I have just:
extern C UINT __stdcall VerifyLicenseDir(MSIHANDLE hInstall)
{
WcaInitialize(hInstall, VerifyLicenseDir);
WcaLog(LOGMSG_STANDARD, Enter VerifyLicenseDir);
return WcaFinalize(ERROR_SUCCESS);
}
MSI (c) (04:F4) [14:19:38:375]: Doing action: VerifyLicenseDir
MSI (c) (04:F4) [14:19:38:375]: Note: 1: 2205 2: 3: ActionText
Action 14:19:38: VerifyLicenseDir.
Action start 14:19:38: VerifyLicenseDir.
MSI (c) (04:C8) [14:19:38:390]: Invoking remote custom action. DLL:
C:\... Entrypoint: VerifyLicenseDir
MSI (c) (04:C0) [14:19:38:390]: Cloaking enabled.
MSI (c) (04:C0) [14:19:38:390]: Attempting to enable all disabled
priveleges before calling Install on Server
MSI (c) (04:C0) [14:19:38:390]: Connected to service for CA interface.
Action ended 14:19:38: VerifyLicenseDir. Return value 1.
Did I feed WcaInitialize a bad 2nd argument? I was guessing it was just
going to be used as an identifier in the log output.
Do I need to call WcaGlobalInitialize/WcaGlobalFinalize in some way as
well?
Thanks again for your help. Google doesn't reveal much on this subject
:-(
From: Brian Simoneau [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 1:58 PM
To: Rowland, Chris; WiX-users@lists.sourceforge.net
Subject: RE: [WiX-users] Logging in a custom action
You have to call WcaInitialize in your method before you can call
WcaLog. You also need to call WcaFinalize before you exit the method.
So your last line could look something like:
return WcaFinalize(ERROR_SUCCESS);
-Brian Simonea
-
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
Re: [WiX-users] Logging in a custom action
It's an immediate CA. I tried wrapping my strings with _T() but _T is
not defined. Another VS05 difference?
Could my definitions be causing a problem? I more or less copied them
from a forum post I saw regarding a similar problem.
#define __out /* ? */
#define __in /* ? */
#define __inout /* ? */
#define __in_bcount(THING) /* ? */
From: Brian Simoneau [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 2:59 PM
To: Rowland, Chris; WiX-users@lists.sourceforge.net
Subject: RE: [WiX-users] Logging in a custom action
That code looks the same as what I am using except that I have _T()
around my strings. Are you running your custom action immediate or
deferred?
-Brian Simoneau
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 2:31 PM
To: Brian Simoneau; WiX-users@lists.sourceforge.net
Subject: RE: [WiX-users] Logging in a custom action
Thanks for the continuing advice. I'm still not seeing any log
out put though. I've commented out the guts of my CA, so now I have
just:
extern C UINT __stdcall VerifyLicenseDir(MSIHANDLE hInstall)
{
WcaInitialize(hInstall, VerifyLicenseDir);
WcaLog(LOGMSG_STANDARD, Enter VerifyLicenseDir);
return WcaFinalize(ERROR_SUCCESS);
}
MSI (c) (04:F4) [14:19:38:375]: Doing action: VerifyLicenseDir
MSI (c) (04:F4) [14:19:38:375]: Note: 1: 2205 2: 3: ActionText
Action 14:19:38: VerifyLicenseDir.
Action start 14:19:38: VerifyLicenseDir.
MSI (c) (04:C8) [14:19:38:390]: Invoking remote custom action.
DLL: C:\... Entrypoint: VerifyLicenseDir
MSI (c) (04:C0) [14:19:38:390]: Cloaking enabled.
MSI (c) (04:C0) [14:19:38:390]: Attempting to enable all
disabled priveleges before calling Install on Server
MSI (c) (04:C0) [14:19:38:390]: Connected to service for CA
interface.
Action ended 14:19:38: VerifyLicenseDir. Return value 1.
Did I feed WcaInitialize a bad 2nd argument? I was guessing it
was just going to be used as an identifier in the log output.
Do I need to call WcaGlobalInitialize/WcaGlobalFinalize in some
way as well?
Thanks again for your help. Google doesn't reveal much on this
subject :-(
From: Brian Simoneau [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 1:58 PM
To: Rowland, Chris; WiX-users@lists.sourceforge.net
Subject: RE: [WiX-users] Logging in a custom action
You have to call WcaInitialize in your method before you can
call WcaLog. You also need to call WcaFinalize before you exit the
method. So your last line could look something like:
return WcaFinalize(ERROR_SUCCESS);
-Brian Simonea
-
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
Re: [WiX-users] Logging in a custom action
After an obscene amount of headbanging, I finally managed to get it to
build (with warnings) with the almighty T() call.
Unfortunately that resulted in a CA that caused the installer to quit
due to an error. If only I could log what was going on
Assuming the lack of wrapping my strings was not the issue, is there
anything else (no matter how obvious, cause it might not be obvious to
me) that I might be doing wrong?
From: Brian Simoneau [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 3:18 PM
To: Rowland, Chris; WiX-users@lists.sourceforge.net
Subject: RE: [WiX-users] Logging in a custom action
_T is a macro defined in tchar.h. I believe this was included in
earlier Visual Studios because my custom actions were originally written
in VS2003. It looks like __out and others are defined in sal.h.
-Brian Simoneau
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 3:05 PM
To: Brian Simoneau; WiX-users@lists.sourceforge.net
Subject: RE: [WiX-users] Logging in a custom action
It's an immediate CA. I tried wrapping my strings with _T() but
_T is not defined. Another VS05 difference?
Could my definitions be causing a problem? I more or less copied
them from a forum post I saw regarding a similar problem.
#define __out /* ? */
#define __in /* ? */
#define __inout /* ? */
#define __in_bcount(THING) /* ? */
From: Brian Simoneau [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 2:59 PM
To: Rowland, Chris; WiX-users@lists.sourceforge.net
Subject: RE: [WiX-users] Logging in a custom action
That code looks the same as what I am using except that I have
_T() around my strings. Are you running your custom action immediate or
deferred?
-Brian Simoneau
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 2:31 PM
To: Brian Simoneau; WiX-users@lists.sourceforge.net
Subject: RE: [WiX-users] Logging in a custom action
Thanks for the continuing advice. I'm still not seeing
any log out put though. I've commented out the guts of my CA, so now I
have just:
extern C UINT __stdcall VerifyLicenseDir(MSIHANDLE
hInstall)
{
WcaInitialize(hInstall, VerifyLicenseDir);
WcaLog(LOGMSG_STANDARD, Enter VerifyLicenseDir);
return WcaFinalize(ERROR_SUCCESS);
}
MSI (c) (04:F4) [14:19:38:375]: Doing action:
VerifyLicenseDir
MSI (c) (04:F4) [14:19:38:375]: Note: 1: 2205 2: 3:
ActionText
Action 14:19:38: VerifyLicenseDir.
Action start 14:19:38: VerifyLicenseDir.
MSI (c) (04:C8) [14:19:38:390]: Invoking remote custom
action. DLL: C:\... Entrypoint: VerifyLicenseDir
MSI (c) (04:C0) [14:19:38:390]: Cloaking enabled.
MSI (c) (04:C0) [14:19:38:390]: Attempting to enable all
disabled priveleges before calling Install on Server
MSI (c) (04:C0) [14:19:38:390]: Connected to service for
CA interface.
Action ended 14:19:38: VerifyLicenseDir. Return value 1.
Did I feed WcaInitialize a bad 2nd argument? I was
guessing it was just going to be used as an identifier in the log
output.
Do I need to call WcaGlobalInitialize/WcaGlobalFinalize
in some way as well?
Thanks again for your help. Google doesn't reveal much
on this subject :-(
From: Brian Simoneau
[mailto:[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 1:58 PM
To: Rowland, Chris; WiX-users@lists.sourceforge.net
Subject: RE: [WiX-users] Logging in a custom action
You have to call WcaInitialize in your method before you
can call WcaLog. You also need to call WcaFinalize before you exit the
method. So your last line could look something like:
return WcaFinalize(ERROR_SUCCESS);
-Brian Simonea
-
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
Re: [WiX-users] Logging in a custom action
Yeah, the error was in the custom action. (It returned the value 3)
I had tried to attach to msiexec.exe before to debug, but didn't make
any progress with that.
Can you show me how you fired off the MessageBox from within your CA?
This is a lot of debugging just so I can debug :-)
From: Brian Simoneau [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 4:57 PM
To: Rowland, Chris; WiX-users@lists.sourceforge.net
Subject: RE: [WiX-users] Logging in a custom action
Was the error in the custom action itself? If so, then you can always
try to debug the custom action in Visual Studio. I was able to do this
by adding a MessageBox to the beginning of the custom action and then
attaching to the MessageBox when the custom action was run. If the
error was when launching the custom action, there may be a missing
dependency.
-Brian Simoneau
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 4:51 PM
To: Brian Simoneau; WiX-users@lists.sourceforge.net
Subject: RE: [WiX-users] Logging in a custom action
After an obscene amount of headbanging, I finally managed to get
it to build (with warnings) with the almighty T() call.
Unfortunately that resulted in a CA that caused the installer to
quit due to an error. If only I could log what was going on
Assuming the lack of wrapping my strings was not the issue, is
there anything else (no matter how obvious, cause it might not be
obvious to me) that I might be doing wrong?
From: Brian Simoneau [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 3:18 PM
To: Rowland, Chris; WiX-users@lists.sourceforge.net
Subject: RE: [WiX-users] Logging in a custom action
_T is a macro defined in tchar.h. I believe this was included
in earlier Visual Studios because my custom actions were originally
written in VS2003. It looks like __out and others are defined in sal.h.
-Brian Simoneau
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 3:05 PM
To: Brian Simoneau; WiX-users@lists.sourceforge.net
Subject: RE: [WiX-users] Logging in a custom action
It's an immediate CA. I tried wrapping my strings with
_T() but _T is not defined. Another VS05 difference?
Could my definitions be causing a problem? I more or
less copied them from a forum post I saw regarding a similar problem.
#define __out /* ? */
#define __in /* ? */
#define __inout /* ? */
#define __in_bcount(THING) /* ? */
From: Brian Simoneau
[mailto:[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 2:59 PM
To: Rowland, Chris; WiX-users@lists.sourceforge.net
Subject: RE: [WiX-users] Logging in a custom action
That code looks the same as what I am using except that
I have _T() around my strings. Are you running your custom action
immediate or deferred?
-Brian Simoneau
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, April 26, 2007 2:31 PM
To: Brian Simoneau;
WiX-users@lists.sourceforge.net
Subject: RE: [WiX-users] Logging in a custom
action
Thanks for the continuing advice. I'm still not
seeing any log out put though. I've commented out the guts of my CA, so
now I have just:
extern C UINT __stdcall
VerifyLicenseDir(MSIHANDLE hInstall)
{
WcaInitialize(hInstall,
VerifyLicenseDir);
WcaLog(LOGMSG_STANDARD, Enter
VerifyLicenseDir);
return WcaFinalize(ERROR_SUCCESS);
}
MSI (c) (04:F4) [14:19:38:375]: Doing action:
VerifyLicenseDir
MSI (c) (04:F4) [14:19:38:375]: Note: 1: 2205 2:
3: ActionText
Action 14:19:38: VerifyLicenseDir.
Action start 14:19:38: VerifyLicenseDir.
MSI (c) (04:C8) [14:19:38:390]: Invoking remote
custom action. DLL: C:\... Entrypoint: VerifyLicenseDir
MSI (c) (04:C0) [14:19:38:390]: Cloaking
enabled.
MSI (c) (04:C0)
Re: [WiX-users] How to get 8.3 path for INSTALLDIR
Will doing a deferred execution of my CA work in my situation? My understanding is that I can't set a property in a deferred custom action, all I can do is read the property CustomActionData If this is the case, my only hope seems to be to set the environment variable in the custom action, which I think makes rollback impossible anyways. I need my Environment element to use the 8.3 path for INSTALLDIR, and my CA was trying to set Property with this value. I'm not sure it would even be possible to order the sequence in a way that the property would ever exist when the Environment element was processed. Is there even a way to acomplish this? -Original Message- From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 12:24 AM To: Rowland, Chris Cc: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to get 8.3 path for INSTALLDIR [EMAIL PROTECTED] wrote: As far as I understand, I cannot install a component after InstallFinalize, and I had to run my CA after InstallFinalize so that the directory has been created. You don't have to run a CA after InstallFinalize -- in fact, you shouldn't, because it can't be rolled back -- but it does have to be deferred. -- sig://boB http://bobs.org - 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
Re: [WiX-users] How to get 8.3 path for INSTALLDIR
So try this: An immediate CA after CostFinalize uses [!fileId] to get the short path, chops off the filename, and sets another property to just the directory, which you then use in an Environment element. Worth a shot. I think I've found an acceptable solution by creating the INSTALL dir folder in a CA so that the folder already exists when my other CA to get the 8.3 name is called. We copy files to the installation directory anyways, so we don't expect the folder to be removed on uninstall anyways (though I've got a RemoveFolder element in there, if that isn't redundant) Otherwise, I don't see how to accomplish what you're trying to do. Other than to suggest fixing broken software that requires a short path.g Ya caught that did ya? ;-) -- sig://boB http://bobs.org - 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
[WiX-users] Logging in a custom action
Is there any way to write a message to the install log from a custom action? Chris Rowland* Software Engineer * SunGard * Data Management Solutions * 1194 Oak Valley Drive, Suite 100 * Ann Arbor, MI 48108 * Tel 734.332.4423 * Fax 734.332.4440 * http://www.sungard.com/datamanagementsolutions http://www.sungard.com/datamanagementsolutions - 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
Re: [WiX-users] How to get 8.3 path for INSTALLDIR
I'm back on task trying to resolve this 8.3 INSTALLDIR path issue, and I can get the path in question using the method Phil suggested, but I'm not certain how to use that to set the environment variable. As far as I understand, I cannot install a component after InstallFinalize, and I had to run my CA after InstallFinalize so that the directory has been created. Therefore I can't use an Environment element, nor can I find anything in the Windows API to let me do it in a CA. So I'm assuming I'm missing something in regards to the Windows Installer, or something in the Windows API doc. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wilson, Phil Sent: Tuesday, April 03, 2007 12:53 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to get 8.3 path for INSTALLDIR If you do this with code, C++, the GetShortPathName API works on directories. You'd do this after the directory has in fact been created. Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, April 03, 2007 6:48 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to get 8.3 path for INSTALLDIR I'm trying to set an environment variable to be the value of INSTALLDIR, but I need it to be the 8.3 style path. I saw an old mailing list thread about this topic that Rob responded to with: You could always just use [!FileId] to get the short name of a file. This thread was in the context of WiX 3.0, however. When I try to do this with WiX 2.0, my environment variable ends up unset. Is this a WiX 3 specific feature? --Chris - 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
[WiX-users] How to get 8.3 path for INSTALLDIR
I'm trying to set an environment variable to be the value of INSTALLDIR, but I need it to be the 8.3 style path. I saw an old mailing list thread about this topic that Rob responded to with: You could always just use [!FileId] to get the short name of a file. This thread was in the context of WiX 3.0, however. When I try to do this with WiX 2.0, my environment variable ends up unset. Is this a WiX 3 specific feature? --Chris - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditional RemoveFiles on Uninstall
There's your problem: Without a guid, the component is unmanaged and never removed. Take a look at a verbose log around the InstallValidate action to see which components and features are scheduled for installation/removal. I gotcha, I figured I didn't need a guid because the intent was to remove unmanaged files. I'm still having a couple of issues, however. I've tried several combinations of the code below. If I use the RemoveFile block, it succeeds. If I use the RemoveFolder block, nothing happens. If I uncomment the Condition element, it fails to delete anything in either case. I'm guessing this means the property isn't getting passed correctly? Component Id=Comp_RemoveAllFiles Guid= !--ConditionREMOVEALLFILES/Condition-- !-- RemoveFolder Id=RemoveRootFolder On=uninstall/ -- RemoveFile Id=RemoveRootFiles On=uninstall Name=*/ /Component - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditional RemoveFiles on Uninstall
I'm trying to do the same thing, but when check the checkbox to remove the Installation directory, it's not deleting the directory, or the 2 files that are left behind. I cant imagine you have to explicitly remove files before removing the directory, do you? I have a hidden feature to enable my removal component as follows: Component Id=Comp_RemoveAllFiles Guid= ConditionRemoveAllFiles/Condition RemoveFolder Id=RemoveRootFolder On=uninstall Property=[INSTALLDIR]/ /Component FeatureId=Feat_RemoveAllFiles Display='hidden' Level=1 ComponentRef Id=Comp_RemoveAllFiles/ /Feature In the log I see Property(C): RemoveAllFiles = TRUE I also see this, but im not sure if its of any use... UnpublishFeatures: Feature: Feat_RemoveAllFiles -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gareth at Serif Sent: Thursday, March 29, 2007 1:09 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Conditional RemoveFiles on Uninstall You can probably declare your 'RemoveFile' ines in a component that has a component condition triggered by a property that your user can configure via a checkbox in your UI. I believe that 'RemoveFile' lines work on install and all files will be removed on uninstall so probably won't be the solution for your described needs. Best of luck. -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] User specific permissions
I'm trying to create a folder that's either writable by the installing user, or by all users, depending on ALLUSERS. What would I need to do to set permissions specific to the installing user? I attempted to use the USERSID property, and got no error, but the resulting older had an odd BUILTIN\BUILTIN user entry with a question mark, instead of one for the user who performed the install. Ive basically done the following: Component Id=workfolder.all ... Location=either ConditionALLUSERS/Condition CreateFolder Permission User=Everyone GenericAll=yes / /CreateFolder /Component Component Id=workfolder.single ... Location=either ConditionNOT ALLUSERS/Condition CreateFolder Permission User=[USERSID] GenericAll=yes / /CreateFolder /Component - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Another version of this product is already installed
Does WI support any sort of automated backup of files that have changed since installation when performing the un-installation? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Bardon Sent: Wednesday, March 28, 2007 8:47 AM To: Bob Arnson Cc: Wilson, Phil; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Another version of this product is already installed The way I understand things, a major upgrade will effectively do a full uninstall of the previous version before installing the new version, correct? Just thinking that the install would take a whole lot longer this way, and that I'd have to make sure that certain files (e.g. user-modified configuration files) aren't wiped out in the process. I'll give that a shot though-it means that I should just change the product code with every build, but leave the upgrade code the same, right? -Original Message- From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 27, 2007 11:48 PM To: Chris Bardon Cc: Wilson, Phil; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Another version of this product is already installed Chris Bardon wrote: -Force all upgrades to be major-Other than performance, is there any reason that this is a bad idea? Our apps are reasonably small, so it shouldn't take all that long, but I understand that in principle this is a bad idea. Says who? Major upgrades are a great idea. For almost no effort, you have one build process that creates packages both for initial installs and upgrades. The only downside is that you have to ship full product packages; if you have a big product, creating patches for minor or small updates saves download time. But creating patches isn't a small endeavor -- use major upgrades wherever you can and your sanity will thank you. -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Conditional feature install
I'm trying to show one of 2 mutually exclusive features in the customize dialog based on the value of ALLUSERS. For some reason, one is always shown, and the other is always hidden, no matter what I think the value of ALLUSERS is. Additionally, other aspects of the installation that are dependant on the ALLUSERS property are working fine I've defined my Features like so: Feature Id=Feat_WorkDirectorySingle Title=$(loc.FUI_Feature.Work.Title) Description=$(loc.FUI_Feature.Work.Description) Level=1 ConfigurableDirectory=WORKDIRSINGLE Absent=disallow AllowAdvertise='no' ComponentRef Id=workfolder.single / !-- If ALLUSERS install, disable -- Condition Level=0ALLUSERS/Condition /Feature Feature Id=Feat_WorkDirectoryAll Title=$(loc.FUI_Feature.Work.Title) Description=$(loc.FUI_Feature.Work.Description) Level=1 ConfigurableDirectory=WORKDIRALL Absent=disallow AllowAdvertise='no' ComponentRef Id=workfolder.all / !-- If Single user install, disable -- Condition Level=0NOT ALLUSERS/Condition /Feature Feat_WorkDirectoryAll is always displayed in the Customize dialog, and the other feature never is. I've looked in the log to verify ALLUSERS and the appearance of the Customize dialog is the same in either case (1 or nothing). I'm setting the ALLUSERS property with a CA a few dialogs earlier but in the single user case it's null. . Is there an error in my Condition logic? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] identify the product code of an existing installation
Is it possible to determine the product code (if any) for an arbitrary
file that resides on the system?
The idea would be to offer to uninstall the application that lives in a
given directory using msiexec /x{product-code}
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Another version of this product is already installed
I'm trying to come to grips with how upgrades are handled, and I was wondering if someone could shed some light on the subject for me. In an attempt to understand better, I've been trying to install a pseudo minor upgrade. I installed the base version, then I tried to install the slightly modified upgrade version. I changed: Product Version attribute. Package Id (auto generated) The contents of one text file. I left unchanged: Everything else, including Product Id UpgradeCode Each time I've tried, I get the Another version of this product is already installed dialog. What gives? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Help uninstalling
I've managed to install my package in such a way that I cannot uninstall it. I was experimenting with utilizing properties on the command line, and did a successful quiet install using a particular property. I then noticed that the UI based uninstall would fail because it was dependant on said property (though it shouldn't have been.) I wrote a fix, and proceeded to overwrite my MSI before first uninstalling with the command line property set. So now I'm stuck unable to uninstall as I lack the original MSI that I used to perform the original install. I'm assuming the info I need is still there though, as I can start the uninstall process with Add/Remove Programs. Is there any way to pass the property I need to set to the Add/Remove process? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] public properties, saving state
I don't know if the functionality you're thinking of exists, but alternatively you could set the property based on a registry entry you set during installation. Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lindsay Harris Sent: Thursday, March 22, 2007 1:33 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] public properties, saving state Hi, I was wondering, is there a certain way to define a public property so that whatever value u give it on install for example, will still be there when u initiate a repair, or modify, or uninstall. For example, this is how I define a public property: Property Id=ARCHIVEFOLDERDIREDIT Value=someValue/Property Is this expected behavior and I am doing something wrong? Any advice would be appreciated, Thanks, Lindsay Harris - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Installing locally hosted files
For a particular installation, the user has some of the files required for installation already on their system prior to running the installer. I want to copy these files into the installation directory. Is there a preferred method for doing this? Would I need a Custom Action, can I manually insert these locally hosted files into the database tables at install time, or is there another method? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing locally hosted files
I don't want to set my directory to the current location of the files on their machine, rather I want to copy those files to the location they choose to install the software. So say the required files were in c:\myfiles\ and they chose to install to c:\program files\installdir\ then I want to basically have the effect of copy c:\myfiles\filex.txt c:\program files\installdir\filex.txt From: Levi Wilson [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 21, 2007 10:48 AM To: Rowland, Chris Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Installing locally hosted files You could do a file or a directory search at the beginning where the result of the search will be saved in a Property /, and I believe that you can then set your launch condition based upon that property. Also, if everything checks out with the directory or file search, then you could set your installation directory to the result of that? Is that what you're looking for? Check out the FileSearch / and DirectorySearch / elements out if so. On 3/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: For a particular installation, the user has some of the files required for installation already on their system prior to running the installer. I want to copy these files into the installation directory. Is there a preferred method for doing this? Would I need a Custom Action, can I manually insert these locally hosted files into the database tables at install time, or is there another method? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE V ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing locally hosted files
Ah, yes I see CopyFile now (I assume that's what you're referring to.) I think that should work, I'll give it a shot. Thanks again. From: Levi Wilson [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 21, 2007 10:59 AM To: Rowland, Chris Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Installing locally hosted files Well, you could probably still use that search to verify that the files DO exist and base your launch conditions off of that. Then you could use the FileCopy / to move the files. I think, however, that with this they will not be removed upon uninstall. On 3/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I don't want to set my directory to the current location of the files on their machine, rather I want to copy those files to the location they choose to install the software. So say the required files were in c:\myfiles\ and they chose to install to c:\program files\installdir\ then I want to basically have the effect of copy c:\myfiles\filex.txt c:\program files\installdir\filex.txt From: Levi Wilson [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 21, 2007 10:48 AM To: Rowland, Chris Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Installing locally hosted files You could do a file or a directory search at the beginning where the result of the search will be saved in a Property /, and I believe that you can then set your launch condition based upon that property. Also, if everything checks out with the directory or file search, then you could set your installation directory to the result of that? Is that what you're looking for? Check out the FileSearch / and DirectorySearch / elements out if so. On 3/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: For a particular installation, the user has some of the files required for installation already on their system prior to running the installer. I want to copy these files into the installation directory. Is there a preferred method for doing this? Would I need a Custom Action, can I manually insert these locally hosted files into the database tables at install time, or is there another method? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE V ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] verify file existance custom action
Ok, I finally have access to the machine I need and I'm trying this out.
I tried to build in Visual Studio 03 as a C++ project, and right off the
bat I got some build errors that I don't understand. I'm sure they're
pretty typical, I'm just unfamiliar with VC++.
error LNK2001: unresolved external symbol unsigned int __stdcall
MsiSetPropertyA(unsigned long,char const *,char const *)
(?MsiSetPropertyA@@[EMAIL PROTECTED])
error LNK2001: unresolved external symbol int __stdcall
PathFileExistsA(char const *) (?PathFileExistsA@@[EMAIL PROTECTED])
error LNK2001: unresolved external symbol unsigned int __stdcall
MsiGetPropertyA(unsigned long,char const *,char *,unsigned long *)
(?MsiGetPropertyA@@[EMAIL PROTECTED])
I'd guess it must be something with my setup, because I get the same
errors about the Set and Get methods when I use the tiny CheckPID
example from http://www.tramontana.co.hu/wix/lesson3.php#3.3
I know not really a WiX issue, but I'd appreciate any advise you had.
From: Levi Wilson [mailto:[EMAIL PROTECTED]
Sent: Friday, March 16, 2007 8:56 AM
To: Rowland, Chris
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] verify file existance custom action
Sorry, prematurely sent it. Here is what I was getting at:
extern C UINT __stdcall LocateFile(MSIHANDLE hInstall)
{
char* pDirPath = NULL;
DWORD dw = 0;
if( ERROR_MORE_DATA!=MsiGetProperty(hInstall,MYFOLDER,NULL,dw) )
return ERROR_INSTALL_FAILURE;
dw += strlen(requiredfile.txt) + 1 /* term. NULL */;
pDirPath = new char[dw];
pDirPath[0] = '\0';
if( ERROR_SUCCESS!=MsiGetProperty(hInstall,MYFOLDER,pDirPath,dw) )
{
delete[] pDirPath;
return ERROR_INSTALL_FAILURE;
}
_ASSERTE( 0!=strlen(pDirPath) );
if( PathFileExists(pDirPath) ) {
MsiSetProperty(hInstall,MYFILEEXISTS,pDirPath); // Dr. Evil
assumption
}
delete[] pDirPath;
return ERROR_SUCCESS;
}
I believe that something like this would work.
On 3/16/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
If I look at the log after a completed installation, I can see the
following property values.
Property(S): MYFOLDER = C:\FTP\#This is the folder I
selected in the dialog
...
Property(S): MYFILEEXISTS = C:\requiredfile.txt #this is
where the file was found (MYFOLDER was initialized to 'c:\')
So MYFOLDER did get set, but it seems to happen after the directory
search took place. Would it be possible to have AppSearch happen
sometime in the UI sequence, or would that break something else? It
looks like by default It happens very early on.
From: Levi Wilson [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 4:36 PM
To: Rowland, Chris
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] verify file existance custom action
Hmmm, I've never used a directory search like that. So you're saying
that your MYFOLDER property isn't getting set when the directory search
is performed? I think you probably will need to maybe use a custom
action then since I don't think you can dynamically manipulate a
directory search, or tell it when to perform it as I think file searches
get executed during the AppSearch sequence? I could be wrong, but I
don't think you can use the FileSearch like this.
On 3/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
That actually looks like exactly what I want... much cleaner than my C++
hackjob.
That gives me a followup question, however. I plugged your suggestion
(with Depth=0) into my dialog I use to browse to the directory that
contains the file.
It appears that the property I'm trying to set to the browsed-to
directory doesn't contain the browsed-to directory when the
DirectorySearch is performed.
Dialog Id=GetExistingFilesDlg Width=370 Height=270
Title=[ProductName] [Setup] NoMinimize=yes
Control Id=PathEdit Type=PathEdit X=84 Y=202
Width=261 Height=18 Property=MYFOLDER/
Control Id=Next Type=PushButton X=236 Y=243 Width=56
Height=17 Default=yes Text=Next
Property Id=MYFILEEXISTS
DirectorySearch Id=MyDirSearch
Path=[MYFOLDER] Depth=0
FileSearch Id=MyFileSearch
Name=requiredfile.txt /
/DirectorySearch
/Property
Publish Event=SpawnDialog Value=InvalidDirDlgNOT
MYFILEEXISTS/Publish
Publish Event=NewDialog
Value=SetupTypeDlgMYFILEEXISTS/Publish
/Control
I initialized MYFOLDER with Property Id='MYFOLDER' Value='c:\' /
This works if requiredfile.txt is in c:\ (I can see
MYFILEEXISTS=c:\requiredfile.txt in the log)
It doesn't work if I browse to the directory that contains the file (and
of course I remove the file from c:\ )
Thanks for the help so far, this feels like a much better way than what
I was previously attempting.
Re: [WiX-users] verify file existance custom action
Thanks Levi, I'll give that a shot as soon as I get access to my
development box back.
From: Levi Wilson [mailto:[EMAIL PROTECTED]
Sent: Friday, March 16, 2007 8:56 AM
To: Rowland, Chris
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] verify file existance custom action
Sorry, prematurely sent it. Here is what I was getting at:
extern C UINT __stdcall LocateFile(MSIHANDLE hInstall)
{
char* pDirPath = NULL;
DWORD dw = 0;
if( ERROR_MORE_DATA!=MsiGetProperty(hInstall,MYFOLDER,NULL,dw) )
return ERROR_INSTALL_FAILURE;
dw += strlen(requiredfile.txt) + 1 /* term. NULL */;
pDirPath = new char[dw];
pDirPath[0] = '\0';
if( ERROR_SUCCESS!=MsiGetProperty(hInstall,MYFOLDER,pDirPath,dw) )
{
delete[] pDirPath;
return ERROR_INSTALL_FAILURE;
}
_ASSERTE( 0!=strlen(pDirPath) );
if( PathFileExists(pDirPath) ) {
MsiSetProperty(hInstall,MYFILEEXISTS,pDirPath); // Dr. Evil
assumption
}
delete[] pDirPath;
return ERROR_SUCCESS;
}
I believe that something like this would work.
On 3/16/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
If I look at the log after a completed installation, I can see the
following property values.
Property(S): MYFOLDER = C:\FTP\#This is the folder I
selected in the dialog
...
Property(S): MYFILEEXISTS = C:\requiredfile.txt #this is
where the file was found (MYFOLDER was initialized to 'c:\')
So MYFOLDER did get set, but it seems to happen after the directory
search took place. Would it be possible to have AppSearch happen
sometime in the UI sequence, or would that break something else? It
looks like by default It happens very early on.
From: Levi Wilson [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 4:36 PM
To: Rowland, Chris
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] verify file existance custom action
Hmmm, I've never used a directory search like that. So you're saying
that your MYFOLDER property isn't getting set when the directory search
is performed? I think you probably will need to maybe use a custom
action then since I don't think you can dynamically manipulate a
directory search, or tell it when to perform it as I think file searches
get executed during the AppSearch sequence? I could be wrong, but I
don't think you can use the FileSearch like this.
On 3/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
That actually looks like exactly what I want... much cleaner than my C++
hackjob.
That gives me a followup question, however. I plugged your suggestion
(with Depth=0) into my dialog I use to browse to the directory that
contains the file.
It appears that the property I'm trying to set to the browsed-to
directory doesn't contain the browsed-to directory when the
DirectorySearch is performed.
Dialog Id=GetExistingFilesDlg Width=370 Height=270
Title=[ProductName] [Setup] NoMinimize=yes
Control Id=PathEdit Type=PathEdit X=84 Y=202
Width=261 Height=18 Property=MYFOLDER/
Control Id=Next Type=PushButton X=236 Y=243 Width=56
Height=17 Default=yes Text=Next
Property Id=MYFILEEXISTS
DirectorySearch Id=MyDirSearch
Path=[MYFOLDER] Depth=0
FileSearch Id=MyFileSearch
Name=requiredfile.txt /
/DirectorySearch
/Property
Publish Event=SpawnDialog Value=InvalidDirDlgNOT
MYFILEEXISTS/Publish
Publish Event=NewDialog
Value=SetupTypeDlgMYFILEEXISTS/Publish
/Control
I initialized MYFOLDER with Property Id='MYFOLDER' Value='c:\' /
This works if requiredfile.txt is in c:\ (I can see
MYFILEEXISTS=c:\requiredfile.txt in the log)
It doesn't work if I browse to the directory that contains the file (and
of course I remove the file from c:\ )
Thanks for the help so far, this feels like a much better way than what
I was previously attempting.
From: Levi Wilson [mailto: [EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 3:50 PM
To: Rowland, Chris
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] verify file existance custom action
Can you post your CA C++ code? Also, you don't need to have a DLL
custom action to check for the existence of a file. You can do
something like this in your WiX source:
Property Id=MyFileExists
DirectorySearch Id=MyDirSearch Path=some path here Depth=1
FileSearch Id=MyFileSearch Name=myfile.extension /
/DirectorySearch
/Property
If the file has been found, then the MyFileExists property will be set
to the full path of your file. Is this what you're looking for?
On 3/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I read that managed code in a custom action is a no-no (please forgive
me if I use the wrong terminology) so I am attempting to write my custom
action without using
Re: [WiX-users] Locate a required file during an install
Thanks for the advice Rob. I've got the directory browsing dialog in
place, but I'm having issues getting my dll to work.
When I hit the Next button in my dialog, I get an 'installer
information' message window that says There is a problem with this
Windows Installer package. A DLL required for this install to complete
could not be run.
My dll is mostly a duplicate of the sample custom action example in the
tutorial (http://www.tramontana.co.hu/wix/lesson3.php )
#include stdafx.h
#include windows.h
#include msi.h
#include msiquery.h
#pragma comment(linker,
/EXPORT:[EMAIL PROTECTED])
#pragma comment(lib, msi.lib)
extern C UINT __stdcall CheckLicenseFiles (MSIHANDLE hInstall) {
char Pid[MAX_PATH];
DWORD PidLen = MAX_PATH;
MsiGetProperty (hInstall, MYFOLDER, Pid, PidLen);
MsiSetProperty (hInstall, LicenseFilesFound, true);
return ERROR_SUCCESS;
} // CheckLicenseFiles
I have a property MYFOLDER defined, as well as LicenseFilesFound
Property Id='MYFOLDER' Value='c:\'/
Property Id=LicenseFilesFound Value='false' /
Here's snippet from my dialog:
Control Id=Next Type=PushButton X=236 Y=243 Width=56
Height=17 Default=yes Text=Next
Publish Event=DoAction
Value=CheckForLicenseFiles1/Publish
Publish Event=SpawnDialog
Value=InvalidDirDlgLicenseFilesFound = false/Publish
Publish Event=NewDialog
Value=SetupTypeDlgLicenseFilesFound = true/Publish
/Control
I have noticed that in Visual Studio the source platform for the dll is
Win32 as opposed to .NET. Could that be an issue? I'm entirely
unexperienced with the .NET platform.
Thanks again,
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Hamflett
Sent: Tuesday, March 13, 2007 12:47 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Locate a required file during an install
Here's a sample of what you're (hopefully) looking for. As I understand
it, you want the user to
browse to a directory where getyour existing files are, and then you
want to verify them. The
attached include files are put together from a couple of our products,
and have had the usual secret
stuff sanitised. So they might not work as-is, but will at least give
you an idea of what you're
looking for.
In GetExistingFilesDlg the user is prompted for a path. This value will
be stored in the property
MYFOLDER. When they click next, this will call a custom action called
checkFiles. This will have
to be a DLL custom action which you need to write. It will need to get
the MYFOLDER property, look
for the files, and then write back a property called FILES_EXIST with
yes if they exist, and
something else if they don't. You need to set [EMAIL PROTECTED] to
'check' or 'ignore' because
you need the action to finish before the installer continues. The other
actions attached to the
'Next' button are based on the value of FILES_EXIST which you've just
written. The installation
will either continue, or the user will get a pop-up dialog. This is
FilesAbsentDlg. The user is
told the files are not there, and clicks OK to go back to
GetExistingFilesDlg.
The mailing list appears to be banning zip files, so I've renamed the
extension to .piz
Rob
P.S. I've not attached the binary files for the background images.
[EMAIL PROTECTED] wrote:
I'm working on an installer that depends upon files that the user has
received prior to performing the installation.
Our current installer (not windows installer based) prompts the user
to
browse for the location of the files... I'm trying to replicate this,
but I'm not exactly sure how to go about it.
On one hand I think I might need a custom action, on the other hand,
that functionality is already part of WiX (i.e. using
ConfigurableDirectory in a Feature) I'm not sure if it's accessible in
the context I'd like, a separate step in the install sequence.
Can anyone offer a suggestion on the correct course of action?
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE
V
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Locate a required file during an install
I have the following elements defined. Do they look right?
CustomAction Id=CheckForLicenseFiles
BinaryKey=Bin_CheckForLicenseFiles DllEntry=Bin_CheckForLicenseFiles
/
And
Binary Id=Bin_CheckForLicenseFiles SourceFile=LicenseFileCheck.dll
/
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Hamflett
Sent: Thursday, March 15, 2007 10:02 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Locate a required file during an install
No, Win32 should be right. I can't really see what the problem would be
with your installer. Just
as a sanity check, you do have an entry for it in the Binary table,
right?
[EMAIL PROTECTED] wrote:
Thanks for the advice Rob. I've got the directory browsing dialog in
place, but I'm having issues getting my dll to work.
When I hit the Next button in my dialog, I get an 'installer
information' message window that says There is a problem with this
Windows Installer package. A DLL required for this install to
complete
could not be run.
My dll is mostly a duplicate of the sample custom action example in
the
tutorial (http://www.tramontana.co.hu/wix/lesson3.php )
#include stdafx.h
#include windows.h
#include msi.h
#include msiquery.h
#pragma comment(linker,
/EXPORT:[EMAIL PROTECTED])
#pragma comment(lib, msi.lib)
extern C UINT __stdcall CheckLicenseFiles (MSIHANDLE hInstall) {
char Pid[MAX_PATH];
DWORD PidLen = MAX_PATH;
MsiGetProperty (hInstall, MYFOLDER, Pid, PidLen);
MsiSetProperty (hInstall, LicenseFilesFound, true);
return ERROR_SUCCESS;
} // CheckLicenseFiles
I have a property MYFOLDER defined, as well as LicenseFilesFound
Property Id='MYFOLDER' Value='c:\'/
Property Id=LicenseFilesFound Value='false' /
Here's snippet from my dialog:
Control Id=Next Type=PushButton X=236 Y=243 Width=56
Height=17 Default=yes Text=Next
Publish Event=DoAction
Value=CheckForLicenseFiles1/Publish
Publish Event=SpawnDialog
Value=InvalidDirDlgLicenseFilesFound = false/Publish
Publish Event=NewDialog
Value=SetupTypeDlgLicenseFilesFound = true/Publish
/Control
I have noticed that in Visual Studio the source platform for the dll
is
Win32 as opposed to .NET. Could that be an issue? I'm entirely
unexperienced with the .NET platform.
Thanks again,
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Hamflett
Sent: Tuesday, March 13, 2007 12:47 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Locate a required file during an install
Here's a sample of what you're (hopefully) looking for. As I
understand
it, you want the user to
browse to a directory where getyour existing files are, and then you
want to verify them. The
attached include files are put together from a couple of our products,
and have had the usual secret
stuff sanitised. So they might not work as-is, but will at least give
you an idea of what you're
looking for.
In GetExistingFilesDlg the user is prompted for a path. This value
will
be stored in the property
MYFOLDER. When they click next, this will call a custom action called
checkFiles. This will have
to be a DLL custom action which you need to write. It will need to
get
the MYFOLDER property, look
for the files, and then write back a property called FILES_EXIST with
yes if they exist, and
something else if they don't. You need to set [EMAIL PROTECTED] to
'check' or 'ignore' because
you need the action to finish before the installer continues. The
other
actions attached to the
'Next' button are based on the value of FILES_EXIST which you've just
written. The installation
will either continue, or the user will get a pop-up dialog. This is
FilesAbsentDlg. The user is
told the files are not there, and clicks OK to go back to
GetExistingFilesDlg.
The mailing list appears to be banning zip files, so I've renamed the
extension to .piz
Rob
P.S. I've not attached the binary files for the background images.
[EMAIL PROTECTED] wrote:
I'm working on an installer that depends upon files that the user has
received prior to performing the installation.
Our current installer (not windows installer based) prompts the user
to
browse for the location of the files... I'm trying to replicate this,
but I'm not exactly sure how to go about it.
On one hand I think I might need a custom action, on the other hand,
that functionality is already part of WiX (i.e. using
ConfigurableDirectory in a Feature) I'm not sure if it's accessible
in
the context I'd like, a separate step in the install sequence.
Can anyone offer a suggestion on the correct course of action?
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share your
opinions on IT business
Re: [WiX-users] Locate a required file during an install
I honestly don't know :-) I'm totally inexperienced in this area.
I tried to mimic a working example I had, and both the wix elements and
the c++ source look equivalent (to me)
Is there some documentation that describes what you're talking about?
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Levi
Wilson
Sent: Thursday, March 15, 2007 10:15 AM
To: Rob Hamflett
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Locate a required file during an install
Did you set up the proper [EMAIL PROTECTED] attribute for the entry
point?
On 3/15/07, Rob Hamflett [EMAIL PROTECTED] wrote:
No, Win32 should be right. I can't really see what the problem would be
with your installer. Just
as a sanity check, you do have an entry for it in the Binary table,
right?
[EMAIL PROTECTED] wrote:
Thanks for the advice Rob. I've got the directory browsing dialog in
place, but I'm having issues getting my dll to work.
When I hit the Next button in my dialog, I get an 'installer
information' message window that says There is a problem with this
Windows Installer package. A DLL required for this install to
complete
could not be run.
My dll is mostly a duplicate of the sample custom action example in
the
tutorial ( http://www.tramontana.co.hu/wix/lesson3.php
http://www.tramontana.co.hu/wix/lesson3.php )
#include stdafx.h
#include windows.h
#include msi.h
#include msiquery.h
#pragma comment(linker,
/EXPORT:[EMAIL PROTECTED])
#pragma comment(lib, msi.lib)
extern C UINT __stdcall CheckLicenseFiles (MSIHANDLE hInstall) {
char Pid[MAX_PATH];
DWORD PidLen = MAX_PATH;
MsiGetProperty (hInstall, MYFOLDER, Pid, PidLen);
MsiSetProperty (hInstall, LicenseFilesFound, true);
return ERROR_SUCCESS;
} // CheckLicenseFiles
I have a property MYFOLDER defined, as well as LicenseFilesFound
Property Id='MYFOLDER' Value='c:\'/
Property Id=LicenseFilesFound Value='false' /
Here's snippet from my dialog:
Control Id=Next Type=PushButton X=236 Y=243 Width=56
Height=17 Default=yes Text=Next
Publish Event=DoAction
Value=CheckForLicenseFiles1/Publish
Publish Event=SpawnDialog
Value=InvalidDirDlgLicenseFilesFound = false/Publish
Publish Event=NewDialog
Value=SetupTypeDlgLicenseFilesFound = true/Publish
/Control
I have noticed that in Visual Studio the source platform for the dll
is
Win32 as opposed to .NET. Could that be an issue? I'm entirely
unexperienced with the .NET platform.
Thanks again,
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Hamflett
Sent: Tuesday, March 13, 2007 12:47 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Locate a required file during an install
Here's a sample of what you're (hopefully) looking for. As I
understand
it, you want the user to
browse to a directory where getyour existing files are, and then you
want to verify them. The
attached include files are put together from a couple of our products,
and have had the usual secret
stuff sanitised. So they might not work as-is, but will at least give
you an idea of what you're
looking for.
In GetExistingFilesDlg the user is prompted for a path. This value
will
be stored in the property
MYFOLDER. When they click next, this will call a custom action called
checkFiles. This will have
to be a DLL custom action which you need to write. It will need to
get
the MYFOLDER property, look
for the files, and then write back a property called FILES_EXIST with
yes if they exist, and
something else if they don't. You need to set [EMAIL PROTECTED] to
'check' or 'ignore' because
you need the action to finish before the installer continues. The
other
actions attached to the
'Next' button are based on the value of FILES_EXIST which you've just
written. The installation
will either continue, or the user will get a pop-up dialog. This is
FilesAbsentDlg. The user is
told the files are not there, and clicks OK to go back to
GetExistingFilesDlg.
The mailing list appears to be banning zip files, so I've renamed the
extension to .piz
Rob
P.S. I've not attached the binary files for the background images.
[EMAIL PROTECTED] wrote:
I'm working on an installer that depends upon files that the user has
received prior to performing the installation.
Our current installer (not windows installer based) prompts the user
to
browse for the location of the files... I'm trying to replicate this,
but I'm not exactly sure how to go about it.
On one hand I think I might need a custom action, on the other hand,
that functionality is already part of WiX (i.e. using
ConfigurableDirectory in a Feature) I'm not sure if it's accessible
in
the context I'd like, a separate step in the install sequence.
Can anyone offer a suggestion on the correct course of action?
Re: [WiX-users] Locate a required file during an install
Ah, thanks! That did the trick.
It makes a lot more sense when you start to realize what things are
being used to reference.
Thank you both for your help.
From: Levi Wilson [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 15, 2007 10:25 AM
To: Rowland, Chris
Cc: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Locate a required file during an install
No, I think that your @DllEntry should be set to CheckLicenseFiles.
On 3/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I have the following elements defined. Do they look right?
CustomAction Id=CheckForLicenseFiles
BinaryKey=Bin_CheckForLicenseFiles DllEntry=Bin_CheckForLicenseFiles
/
And
Binary Id=Bin_CheckForLicenseFiles SourceFile=LicenseFileCheck.dll
/
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Hamflett
Sent: Thursday, March 15, 2007 10:02 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Locate a required file during an install
No, Win32 should be right. I can't really see what the problem would be
with your installer. Just
as a sanity check, you do have an entry for it in the Binary table,
right?
[EMAIL PROTECTED] wrote:
Thanks for the advice Rob. I've got the directory browsing dialog in
place, but I'm having issues getting my dll to work.
When I hit the Next button in my dialog, I get an 'installer
information' message window that says There is a problem with this
Windows Installer package. A DLL required for this install to
complete
could not be run.
My dll is mostly a duplicate of the sample custom action example in
the
tutorial ( http://www.tramontana.co.hu/wix/lesson3.php )
#include stdafx.h
#include windows.h
#include msi.h
#include msiquery.h
#pragma comment(linker,
/EXPORT:[EMAIL PROTECTED])
#pragma comment(lib, msi.lib)
extern C UINT __stdcall CheckLicenseFiles (MSIHANDLE hInstall) {
char Pid[MAX_PATH];
DWORD PidLen = MAX_PATH;
MsiGetProperty (hInstall, MYFOLDER, Pid, PidLen);
MsiSetProperty (hInstall, LicenseFilesFound, true);
return ERROR_SUCCESS;
} // CheckLicenseFiles
I have a property MYFOLDER defined, as well as LicenseFilesFound
Property Id='MYFOLDER' Value='c:\'/
Property Id=LicenseFilesFound Value='false' /
Here's snippet from my dialog:
Control Id=Next Type=PushButton X=236 Y=243 Width=56
Height=17 Default=yes Text=Next
Publish Event=DoAction
Value=CheckForLicenseFiles1/Publish
Publish Event=SpawnDialog
Value=InvalidDirDlgLicenseFilesFound = false/Publish
Publish Event=NewDialog
Value=SetupTypeDlgLicenseFilesFound = true/Publish
/Control
I have noticed that in Visual Studio the source platform for the dll
is
Win32 as opposed to .NET. Could that be an issue? I'm entirely
unexperienced with the .NET platform.
Thanks again,
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Hamflett
Sent: Tuesday, March 13, 2007 12:47 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Locate a required file during an install
Here's a sample of what you're (hopefully) looking for. As I
understand
it, you want the user to
browse to a directory where getyour existing files are, and then you
want to verify them. The
attached include files are put together from a couple of our products,
and have had the usual secret
stuff sanitised. So they might not work as-is, but will at least give
you an idea of what you're
looking for.
In GetExistingFilesDlg the user is prompted for a path. This value
will
be stored in the property
MYFOLDER. When they click next, this will call a custom action called
checkFiles. This will have
to be a DLL custom action which you need to write. It will need to
get
the MYFOLDER property, look
for the files, and then write back a property called FILES_EXIST with
yes if they exist, and
something else if they don't. You need to set [EMAIL PROTECTED] to
'check' or 'ignore' because
you need the action to finish before the installer continues. The
other
actions attached to the
'Next' button are based on the value of FILES_EXIST which you've just
written. The installation
will either continue, or the user will get a pop-up dialog. This is
FilesAbsentDlg. The user is
told the files are not there, and clicks OK to go back to
GetExistingFilesDlg.
The mailing list appears to be banning zip files, so I've renamed the
extension to .piz
Rob
P.S. I've not attached the binary files for the background images.
[EMAIL PROTECTED] wrote:
I'm working on an installer that depends upon files that the user has
received prior to performing the installation.
Our current installer (not windows installer based) prompts the user
to
browse for the location of the files... I'm trying to replicate this,
but I'm not exactly sure how to go about it.
On one hand I think I
[WiX-users] verify file existance custom action
I read that managed code in a custom action is a no-no (please forgive me if I use the wrong terminology) so I am attempting to write my custom action without using managed code. Most examples I find seem to use it, however, so I'm doing the best I can. I wrote a simple VC++ app (.exe) that will determine if some files exist. I probably did it badly, but it worked in that context. I took the same code, and cut paste into a VC++ file I had setup to create my dll. The code was previously a working snippet that would simply set a msi property to true and return ERROR_SUCCESS. I am now trying to make it do something useful. After the cut paste I got some build errors and followed (somewhat) the steps listed here to resolve them. http://support.microsoft.com/?kbid=814472 The dll built successfully, but when I run the installer I get error 2896, Executing action [2] failed. That doesn't tell me too much. I stepped backwards until I had one line that I could comment/uncomment to make the dll work(return true)/not work(error 2896) The one line that causes it to fail (and concequently causes the dll to double in size) is: ifstream fin1(filename); Down the road I was doing 'if (fin1.good())' to see if the file exists (like I said, probably a bad way, but it was the first thing I did that seemed to work) Is attempting to do this fundamentally wrong? Also, I'm running the installer with /l* but I'm still not getting anything particularly helpful. Are there better techniques for debugging? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Locate a required file during an install
I'm working on an installer that depends upon files that the user has received prior to performing the installation. Our current installer (not windows installer based) prompts the user to browse for the location of the files... I'm trying to replicate this, but I'm not exactly sure how to go about it. On one hand I think I might need a custom action, on the other hand, that functionality is already part of WiX (i.e. using ConfigurableDirectory in a Feature) I'm not sure if it's accessible in the context I'd like, a separate step in the install sequence. Can anyone offer a suggestion on the correct course of action? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
