Re: [WiX-users] Per-user install
I went through the same exercise a while back. What I ended up doing was writing a whole new install from scratch and made sure each component worked as per-user before adding another. I received a similar result as you did when I simply tried to change over the install directory to PersonalFolder. Take a look at ClickThrough it helped me. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Van Eaton Sent: Friday, January 26, 2007 12:22 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Per-user install Anyone? JVE -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Van Eaton Sent: Thursday, January 25, 2007 1:36 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Per-user install Hello folks, I had a functional install working. Everything was being installed to "Program Files". I guess that is what we would call a 'per-machine' install. Someone suggested to me that I should make it a 'per-user' install. Naively, I thought I could just change the folder from ProgramFilesFolder to PersonalFolder. Unfortunately, that yielded a boatload of errors and warnings... error LGHT0204 : ICE38: Component Component_1 installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file. error LGHT0204 : ICE64: The directory Directory_1 is in the user profile but is not listed in the RemoveFile table. warning LGHT1076 : ICE91: The file 'File_1' will be installed to the per user directory 'Directory_1' that doesn't vary based on ALLUSERS value. This file won't be copied to each user's profile even if a per machine installation is desired. I am looking for any help on the simplest way to achieve my goal. I don't really care if each user automatically gets a copy or if they each have to do their own install. On a related note, is there a way to use 1 reg key as the KeyPath for each of the components or do they each require a separate reg key? JVE - 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.php&p=sourceforge&CID=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.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Per-user install
Anyone? JVE -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Van Eaton Sent: Thursday, January 25, 2007 1:36 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Per-user install Hello folks, I had a functional install working. Everything was being installed to "Program Files". I guess that is what we would call a 'per-machine' install. Someone suggested to me that I should make it a 'per-user' install. Naively, I thought I could just change the folder from ProgramFilesFolder to PersonalFolder. Unfortunately, that yielded a boatload of errors and warnings... error LGHT0204 : ICE38: Component Component_1 installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file. error LGHT0204 : ICE64: The directory Directory_1 is in the user profile but is not listed in the RemoveFile table. warning LGHT1076 : ICE91: The file 'File_1' will be installed to the per user directory 'Directory_1' that doesn't vary based on ALLUSERS value. This file won't be copied to each user's profile even if a per machine installation is desired. I am looking for any help on the simplest way to achieve my goal. I don't really care if each user automatically gets a copy or if they each have to do their own install. On a related note, is there a way to use 1 reg key as the KeyPath for each of the components or do they each require a separate reg key? JVE - 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.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to integarte an .cat file
Frank Büttner schrieb: > Geoff Finger schrieb: >> Wix doesn't check the validity of the keys, that happens when the file >> is actually installed into WinSxS. As far as I know it's not a bug >> although that would be some great added functionality for Wix. >> >> The public key is what you get by running pktextract on the >> certificate file. The hash file is generated using the private key but >> does not actually contain either part of the key. >> >> After running pktextract you take the results and put them in the >> manifest file, either by directly editing the file yourself, or >> putting it in the Assembly Identity section of the project properties >> as detailed above. >> >> When you're got your manifest, either by editing it directly or >> compiling the project, but before you've created the cdf or cat file >> it should have something resembling the following two lines in it: >> >> > publicKeyToken="" type="win32" >> version="a.b.c.d"> >> > hash="" hashalg="SHA1"/> >> >> If the file name element is missing you can just add it by hand. If >> you then follow the rest of the steps, using the same key files you >> got the public key from, by the end the publicKeyToken, the hash >> value, and the encryption for the cat file should all "match," in that >> the public key you've provided in the manifest will decrypt the >> encryption used on the cat file. > Who can I fount pktextract? > The windows SDK don't contain it:( > > So I have found an old platform SDK which contains it. So now it give me other error, when I try to install it. Windows say that line 11 of my manifest is invalid. Here the manifest file of the problem: http://www.w3.org/2000/09/xmldsig#";>http://www.w3.org/2000/09/xmldsig#sha1";>7kkGn2QBTAJxo8cfOLWV8HR0POM= Line 11 is the begin of the second . smime.p7s Description: S/MIME Cryptographic Signature - 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.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to integarte an .cat file
Geoff Finger schrieb: > Wix doesn't check the validity of the keys, that happens when the file > is actually installed into WinSxS. As far as I know it's not a bug > although that would be some great added functionality for Wix. > > The public key is what you get by running pktextract on the > certificate file. The hash file is generated using the private key but > does not actually contain either part of the key. > > After running pktextract you take the results and put them in the > manifest file, either by directly editing the file yourself, or > putting it in the Assembly Identity section of the project properties > as detailed above. > > When you're got your manifest, either by editing it directly or > compiling the project, but before you've created the cdf or cat file > it should have something resembling the following two lines in it: > > publicKeyToken="" type="win32" > version="a.b.c.d"> > hash="" hashalg="SHA1"/> > > If the file name element is missing you can just add it by hand. If > you then follow the rest of the steps, using the same key files you > got the public key from, by the end the publicKeyToken, the hash > value, and the encryption for the cat file should all "match," in that > the public key you've provided in the manifest will decrypt the > encryption used on the cat file. Who can I fount pktextract? The windows SDK don't contain it:( smime.p7s Description: S/MIME Cryptographic Signature - 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.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] uninstall LaunchCondition
Use a Type 19 custom action instead, then you get a messagebox with your text in it and the uninstall just exits. Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Lalande Sent: Friday, January 26, 2007 10:22 AM To: Bob Arnson Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] uninstall LaunchCondition >You didn't answer my question -- you want the uninstall to be canceled; >you just don't like the "fatal error" message, right? That's correct, I don't like the "fatal error" message. And neither does my supervisor. I understand the solution you are proposing but that user experience is actually worse. As a user, I would be very annoyed if the uninstall simply stopped with the message "User canceled installation" if I had not done anything to cancel it. Currently, the user gets the launch condition message so they know what went wrong and how to fix it. The annoying part is the fatal error message that follows. I think that I am going to have to tell my boss that we'll have to live with the fatal error message. It is benign and the user knows what they need to do to uninstall. It just looks sloppy. Which leads me to wonder why launch conditions would ever be run on uninstall if a failure in the ARP shows the fatal error message after the launch condition message. They could be very useful but informing the user of a non-existent fatal error is not very pleasant behavior. John On 1/26/07, Bob Arnson <[EMAIL PROTECTED]> wrote: John Lalande wrote: > I understand where they might be useful; that is why I am using one. > But my experiments show that a failing launch condition during > uninstall from ARP always shows the fatal error message after > displaying the launch condition message. Correct, that's how ARP works. Uninstalling from ARP shows only a basic UI so if something fails, your MSI package can't display authored UI. So ARP shows a message based on the MSI error code. A failed launch condition returns ERROR_INSTALL_FAILURE, which is "A fatal error occurred during installation." That's why I suggested a CA that returned ERROR_INSTALL_USEREXIT, which presumably would show the message "User cancelled installation." ARP doesn't let you customize the message that's shown, for better or for worse. You didn't answer my question -- you want the uninstall to be canceled; you just don't like the "fatal error" message, right? > Which leads me to your suggestion regarding the custom action that I > run. I have it set such that the return value is ignored. Don't set the continue attribute -- you want the return value to be acted on. -- 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.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] uninstall LaunchCondition
You didn't answer my question -- you want the uninstall to be canceled; you just don't like the "fatal error" message, right? That's correct, I don't like the "fatal error" message. And neither does my supervisor. I understand the solution you are proposing but that user experience is actually worse. As a user, I would be very annoyed if the uninstall simply stopped with the message "User canceled installation" if I had not done anything to cancel it. Currently, the user gets the launch condition message so they know what went wrong and how to fix it. The annoying part is the fatal error message that follows. I think that I am going to have to tell my boss that we'll have to live with the fatal error message. It is benign and the user knows what they need to do to uninstall. It just looks sloppy. Which leads me to wonder why launch conditions would ever be run on uninstall if a failure in the ARP shows the fatal error message after the launch condition message. They could be very useful but informing the user of a non-existent fatal error is not very pleasant behavior. John On 1/26/07, Bob Arnson <[EMAIL PROTECTED]> wrote: John Lalande wrote: > I understand where they might be useful; that is why I am using one. > But my experiments show that a failing launch condition during > uninstall from ARP always shows the fatal error message after > displaying the launch condition message. Correct, that's how ARP works. Uninstalling from ARP shows only a basic UI so if something fails, your MSI package can't display authored UI. So ARP shows a message based on the MSI error code. A failed launch condition returns ERROR_INSTALL_FAILURE, which is "A fatal error occurred during installation." That's why I suggested a CA that returned ERROR_INSTALL_USEREXIT, which presumably would show the message "User cancelled installation." ARP doesn't let you customize the message that's shown, for better or for worse. You didn't answer my question -- you want the uninstall to be canceled; you just don't like the "fatal error" message, right? > Which leads me to your suggestion regarding the custom action that I > run. I have it set such that the return value is ignored. Don't set the continue attribute -- you want the return value to be acted on. -- 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.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] light.exe - System.NullReferenceException
In addition to the first message, I can't say for sure that I know WHICH Merge module is causing the problem, since I tried including it by itself and it worked. Also, it's just weird that my other product that uses the same merge modules works fine. On 1/26/07, Levi Wilson <[EMAIL PROTECTED]> wrote: I have a wxs project file that I am using. It includes 3 merge modules of shared components. I built it earlier today successfully, however, I just rebuild my merge modules because some files were updated within them. Now, when I build the project again (via command line) I get a System.NullReferenceException unhandled exception. Here is some information about the crash (which I've submitted two error reports from this): AppName: light.exe AppVer: 3.0.2420.0 AppStamp:45893d6a ModName: kernel32.dll ModVer: 5.1.2600.2945 ModStamp:44ab9a84 fDebug: 0 Offset: 00012a5b Something interesting about this is that I have another product that uses the SAME merge modules, and they build fine right now, it's just this one. I'm using (as you can see above) WiX version 3. Also, I have narrowed down which merge module it is (I think) by excluding it from the project and only including the remaining two, and this builds successfully. Any suggestions? Please let me know if there is anything that I can do to help. I tried retrieving the dump file from the temp directory when it happens, but I get the error that the file is in use and it will not let me copy it. Thanks in advance! - 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.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] light.exe - System.NullReferenceException
I have a wxs project file that I am using. It includes 3 merge modules of shared components. I built it earlier today successfully, however, I just rebuild my merge modules because some files were updated within them. Now, when I build the project again (via command line) I get a System.NullReferenceException unhandled exception. Here is some information about the crash (which I've submitted two error reports from this): AppName: light.exe AppVer: 3.0.2420.0 AppStamp:45893d6a ModName: kernel32.dll ModVer: 5.1.2600.2945 ModStamp:44ab9a84 fDebug: 0 Offset: 00012a5b Something interesting about this is that I have another product that uses the SAME merge modules, and they build fine right now, it's just this one. I'm using (as you can see above) WiX version 3. Also, I have narrowed down which merge module it is (I think) by excluding it from the project and only including the remaining two, and this builds successfully. Any suggestions? Please let me know if there is anything that I can do to help. I tried retrieving the dump file from the temp directory when it happens, but I get the error that the file is in use and it will not let me copy it. Thanks in advance! - 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.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] uninstall LaunchCondition
The CA does not failit merely sets a property. If I make this change, the uninstall will abort before I get to the launch condition without a meaningful message to the user. But the CA has nothing to do with the issue. This issue exists using the tutorial SampleFirst package where there is no CA at all. Inserting a launch condition that fails during uninstall will display a fatal error when uninstalled from the ARP. On 1/26/07, Levi Wilson <[EMAIL PROTECTED]> wrote: Did you set you try telling it NOT to ignore the return value since you want it to fail if the condition fails, and returning the value ERROR_INSTALL_USEREXIT from the CA when it fails? On 1/26/07, John Lalande <[EMAIL PROTECTED]> wrote: > I understand where they might be useful; that is why I am using one. > But my experiments show that a failing launch condition during uninstall > from ARP always shows the fatal error message after displaying the launch > condition message. > > Which leads me to your suggestion regarding the custom action that I > run. I have it set such that the return value is ignored. The CA is > scheduled to run before the launch conditions and it merely sets a property > that is evaluated in the launch conditions. > > As a test, I have taken out my custom action, changed the launch > condition to fail on uninstall and I still get the fatal error. > > As I mentioned earlier, I also used the SampleFirst package from the > tutorial, created a launch condition that fails on uninstall. It also > displays a fatal error dialog when uninstalled from ARP. > > I can only conclude that launch conditions are not meant for > uninstalling. But I would sure like to be proved wrong as my boss is > putting a lot of pressure on me about this issue. > > John > > On 1/26/07, Bob Arnson <[EMAIL PROTECTED]> wrote: > > > > John Lalande wrote: > > > What situations are they useful if they always show a Fatal Error > > > dialog in ARP? > > > > If you determine that you need some prerequisite to successfully > > uninstall. > > > > > I am thinking of replacing the uninstall launch condition with a > > > dialog that has a Retry button allowing the user to close the > > program > > > and continue. Do you think that is a suitable solution? > > > > You can't show authored UI because ARP runs the uninstall in basic UI > > level. I assume your objection is just to the error message? You can > > try > > a custom action that returns ERROR_INSTALL_USEREXIT to see if ARP > > shows > > a different message in that case. > > > > -- > > 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.php&p=sourceforge&CID=DEVDEV > > ___ > 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.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] uninstall LaunchCondition
John Lalande wrote: > I understand where they might be useful; that is why I am using one. > But my experiments show that a failing launch condition during > uninstall from ARP always shows the fatal error message after > displaying the launch condition message. Correct, that's how ARP works. Uninstalling from ARP shows only a basic UI so if something fails, your MSI package can't display authored UI. So ARP shows a message based on the MSI error code. A failed launch condition returns ERROR_INSTALL_FAILURE, which is "A fatal error occurred during installation." That's why I suggested a CA that returned ERROR_INSTALL_USEREXIT, which presumably would show the message "User cancelled installation." ARP doesn't let you customize the message that's shown, for better or for worse. You didn't answer my question -- you want the uninstall to be canceled; you just don't like the "fatal error" message, right? > Which leads me to your suggestion regarding the custom action that I > run. I have it set such that the return value is ignored. Don't set the continue attribute -- you want the return value to be acted on. -- 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.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] uninstall LaunchCondition
Did you set you try telling it NOT to ignore the return value since you want it to fail if the condition fails, and returning the value ERROR_INSTALL_USEREXIT from the CA when it fails? On 1/26/07, John Lalande <[EMAIL PROTECTED]> wrote: I understand where they might be useful; that is why I am using one. But my experiments show that a failing launch condition during uninstall from ARP always shows the fatal error message after displaying the launch condition message. Which leads me to your suggestion regarding the custom action that I run. I have it set such that the return value is ignored. The CA is scheduled to run before the launch conditions and it merely sets a property that is evaluated in the launch conditions. As a test, I have taken out my custom action, changed the launch condition to fail on uninstall and I still get the fatal error. As I mentioned earlier, I also used the SampleFirst package from the tutorial, created a launch condition that fails on uninstall. It also displays a fatal error dialog when uninstalled from ARP. I can only conclude that launch conditions are not meant for uninstalling. But I would sure like to be proved wrong as my boss is putting a lot of pressure on me about this issue. John On 1/26/07, Bob Arnson <[EMAIL PROTECTED]> wrote: > > John Lalande wrote: > > What situations are they useful if they always show a Fatal Error > > dialog in ARP? > > If you determine that you need some prerequisite to successfully > uninstall. > > > I am thinking of replacing the uninstall launch condition with a > > dialog that has a Retry button allowing the user to close the program > > and continue. Do you think that is a suitable solution? > > You can't show authored UI because ARP runs the uninstall in basic UI > level. I assume your objection is just to the error message? You can try > a custom action that returns ERROR_INSTALL_USEREXIT to see if ARP shows > a different message in that case. > > -- > 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.php&p=sourceforge&CID=DEVDEV ___ 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.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] uninstall LaunchCondition
I understand where they might be useful; that is why I am using one. But my experiments show that a failing launch condition during uninstall from ARP always shows the fatal error message after displaying the launch condition message. Which leads me to your suggestion regarding the custom action that I run. I have it set such that the return value is ignored. The CA is scheduled to run before the launch conditions and it merely sets a property that is evaluated in the launch conditions. As a test, I have taken out my custom action, changed the launch condition to fail on uninstall and I still get the fatal error. As I mentioned earlier, I also used the SampleFirst package from the tutorial, created a launch condition that fails on uninstall. It also displays a fatal error dialog when uninstalled from ARP. I can only conclude that launch conditions are not meant for uninstalling. But I would sure like to be proved wrong as my boss is putting a lot of pressure on me about this issue. John On 1/26/07, Bob Arnson <[EMAIL PROTECTED]> wrote: John Lalande wrote: > What situations are they useful if they always show a Fatal Error > dialog in ARP? If you determine that you need some prerequisite to successfully uninstall. > I am thinking of replacing the uninstall launch condition with a > dialog that has a Retry button allowing the user to close the program > and continue. Do you think that is a suitable solution? You can't show authored UI because ARP runs the uninstall in basic UI level. I assume your objection is just to the error message? You can try a custom action that returns ERROR_INSTALL_USEREXIT to see if ARP shows a different message in that case. -- 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.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] uninstall LaunchCondition
John Lalande wrote: > What situations are they useful if they always show a Fatal Error > dialog in ARP? If you determine that you need some prerequisite to successfully uninstall. > I am thinking of replacing the uninstall launch condition with a > dialog that has a Retry button allowing the user to close the program > and continue. Do you think that is a suitable solution? You can't show authored UI because ARP runs the uninstall in basic UI level. I assume your objection is just to the error message? You can try a custom action that returns ERROR_INSTALL_USEREXIT to see if ARP shows a different message in that case. -- 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.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] uninstall LaunchCondition
What situations are they useful if they always show a Fatal Error dialog in ARP? I don't want to skip the launch condition as I put it there. I don't want users trying to uninstall while the program or Outlook are running because it leaves files behind and this has been deemed unacceptable by our QA dept. This launch condition is not evaluated during install. I am thinking of replacing the uninstall launch condition with a dialog that has a Retry button allowing the user to close the program and continue. Do you think that is a suitable solution? On 1/26/07, Bob Arnson <[EMAIL PROTECTED]> wrote: John Lalande wrote: > In both cases I *do* get the launch condition error message. But with > ARP uninstall, I receive an extra message indicating a fatal error. Fair point. Yes, it's probably not MSI showing the error but ARP. MSI returns 1603 to indicate that the launch condition failed, which is "fatal error during installation." Hence the error. > I get the impression that launch conditions should not be used during > an uninstall. Yet they are scheduled and do run. It is only when one > fails during an ARP uninstall that I am having problems. It depends -- they're useful in some situations. But you can always skip a particular launch condition during uninstall by adding "Installed OR" to those conditions. -- 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.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] uninstall LaunchCondition
John Lalande wrote: > In both cases I *do* get the launch condition error message. But with > ARP uninstall, I receive an extra message indicating a fatal error. Fair point. Yes, it's probably not MSI showing the error but ARP. MSI returns 1603 to indicate that the launch condition failed, which is "fatal error during installation." Hence the error. > I get the impression that launch conditions should not be used during > an uninstall. Yet they are scheduled and do run. It is only when one > fails during an ARP uninstall that I am having problems. It depends -- they're useful in some situations. But you can always skip a particular launch condition during uninstall by adding "Installed OR" to those conditions. -- 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.php&p=sourceforge&CID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Registry keys not being removed
Please keep /wix-users/ on the thread so everyone can participate. Simon Topley wrote: In the new version of our product all of the Files and registry keys are in different places apart from a few third party things (which is what I suspect the log is telling me it will not remove). We have build numbers for each generation of our product, so the previous version put all it's reg values under 14000, the new one under 15000. The same goes for the program files folder. From what I can tell this means that the component GUIDs should be changed at each release. However the 15000 hive is still found in the registry after uninstallation... if the 14000 hive is there. Every release that you want to live side-by-side with others must have different component GUIDs with different paths -- unless it's a shared resource, in which case it must have the same component GUID. And that's an oversimplification. I'd expect versioned paths to get uninstalled when the matching SxS product is uninstalled. If you uninstall all versions, do all the keys get uninstalled? Maybe there's a lingering component... -- 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.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] uninstall LaunchCondition
Isn't this the same UI level as when I choose uninstall from the package's context menu? Both methods of uninstall log this message: "Client-side and UI is none or basic: Running entire install on the server." In both cases I *do* get the launch condition error message. But with ARP uninstall, I receive an extra message indicating a fatal error. So the problem isn't that I need *some* UI to display, it is that there is too much UI...namely, that Fatal Error message. I get the impression that launch conditions should not be used during an uninstall. Yet they are scheduled and do run. It is only when one fails during an ARP uninstall that I am having problems. On 1/26/07, Bob Arnson <[EMAIL PROTECTED]> wrote: John Lalande wrote: An interesting thought, but the LaunchCondition message *does* display. The Fatal Error message appears after it is dismissed Levi's right -- uninstall from ARP runs in "basic" UI mode. As there's no authored UI (dialog boxes), the rule is that *some* message indicating failure must be displayed, so MSI uses a generic error message box. -- 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.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to integarte an .cat file
Frank Büttner schrieb: > These steps has I all do. But the build fails with the error above. > Here is my file that I have tried: > > http://schemas.microsoft.com/wix/2006/wi";> > > InstallerVersion="300"/> > > > > Assembly="win32" KeyPath="yes" > Source="F:\Temp\Qt4\Mergemodule\QtCore4.dll" > AssemblyManifest="qtcoredllmanifest" /> > Name="QtCore4.dll.manifest" > Source="F:\Temp\Qt4\Mergemodule\QtCore4.dll.manifest" /> >Name="QtCore4.dll.cat" > Source="F:\Temp\Qt4\Mergemodule\QtCore4.dll.cat"/> > > > > > > So after some trys I found out, that the sort of the files are important. When the file is the catalog file, that Wix will compile it.(Is this normal or an Bug)?? But when I will install it, then I get an error, that the public key token for catalog file not match the manifest one. But I have used the same certificate. The public key token are the last 8 bytes of the SHA1 Hash of the certificate or not? smime.p7s Description: S/MIME Cryptographic Signature - 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.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to integarte an .cat file
Geoff Finger schrieb: > I'm not sure what steps you've already completed so here's the entire > process I followed. In my case I was using MS VS 2005, obviously some > steps my have to be addapted depending on the enviroment you're > working under. > > First you have to create a key if you don't have one already: > > makecert -n "CN=" -sv > -len 2048 -r > > pvk2pfx.exe -pvk -spc -pfx > [-po Password] > > pktextract > > The password, if any, will be the one you enter for the first step. > The last step generates the public key token you'll be needing later. > > You'll need a manifest file, you can write it yourself or take the > easy way out by compiling the project once after going to project > properties and selecting General->Manifest. Set the Assembly Identity > to: > > , type=win32, version=, > processorArchitecture=X86, publicKeyToken= > > DllName is the name without the extension, VersionNumber is of the > form 1.2.3.4, and the PublicKeyToken is the one you got from > pktextract. Make sure you have "Embed Manidest" under "Input and > Output" set to no for this first time. > > Depending on the compiler you're using you may need to edit the > resulting manifest file and add the line > > hash="" hashalg="SHA1"/> > > before any dependency elements. the file name is the final name of the > file, with the extension. The value of the hash bit is unimportant > because it will be overwritten later. You can save the resulting > manifest file and reuse it for the following steps multiple times as > long as none of the fundamental values change (file name, version > number, encryption key, etc) > > You then run > > mt.exe -manifest -hashupdate -makecdfs > > which updates the hash value and creates a cdf ffile. Next you run: > > makecat -v > > to create the cat file. FInally you run > > signtool sign /f [/p password] /t > http://timestamp.verisign.com/scripts/timestamp.dll > > to sign the catalog file using the key. > > Now the wix bit, which I had a lot of trouble with and sent a couple > messages to the list about without resulting in much progress. Once I > figured out what the missiing bits were however it turned out to be > pretty simple: > > > src="Path\dllFile.dll.manifest" Vital="yes" DiskId="1"> > > src="Path\dllFile.dll.cat" Vital="yes" DiskId="1"> > > KeyPath="yes" > src="Path\dllFile.dll" Vital="yes" DiskId="1" > Assembly="win32" AssemblyManifest="ManFile"> > > > > And of course finally once you've installed your new assembly you need > to reference it in any other projects that will be using it by going > to Project Options->Linker->Manifest File->Additional Manifest > Dependencies and adding > > "type='win32' name='' version='' > processorArchitecture='X86' publicKeyToken='' > language='*'" > > There are a couple pages that halped me figure this stuff out if you > want to take a look at them: > > http://msdn2.microsoft.com/en-us/library/aa376307.aspx > http://msdn2.microsoft.com/en-us/library/ms235512.aspx > and especially: > http://msdn2.microsoft.com/en-gb/library/aa374228.aspx > These steps has I all do. But the build fails with the error above. Here is my file that I have tried: http://schemas.microsoft.com/wix/2006/wi";> smime.p7s Description: S/MIME Cryptographic Signature - 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.php&p=sourceforge&CID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
