[WiX-users] Changing uninstall string of an update
Hi, I have noticed that Windows Installer create a registry entry upon product installation and puts an uninstall string there. It is being used when uninstalling the product from control panel. I did not find a similar entry for update although it looks similar in control panel. Any idea how can I replace the command invoked for update uninstall? Thanks, Dov -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Looking for up to date example for Burn project
Hi, I have download the latest build of WiX 3.6 and tried to create a simple chainer with no luck. I have looked into the sources and got even more confused. It looks like there are some pieces of code using old stand alone Burn tool and some using Candle and Light for creating a target executable. Can somebody point me out how to create a simple, self extracting setup package with default UX behavior? Thanks, Dov -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] .NET Custom Action fails intermittently on some machines
Hi, I'm facing the same problem for quite some time. Same OS (W2K8R2), same conditions (VM) without a decent explanation. I have an immediate custom action gathering some info and finally setting a property. Sometimes it fails without a reasonable explanation. Investigating the DFT source code suggests it may correlate to the amount of memory the machine has available. Do you get more failures while decreasing the allocated VM memory? What WiX build number are you using? Maybe this flaw sneaked-in in a certain build and if we track it we can resolve it. Thanks, Dov -Original Message- From: Michael Bednarek [mailto:michael.bedna...@eu.citrix.com] Sent: Tuesday, March 02, 2010 11:46 AM To: Michael Bednarek; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] .NET Custom Action fails intermittently on some machines Update: I installed/uninstalled the product 100 times on a particular machine (using a script) and the problem with my custom action occurred just once out of those 100 attempts From: Michael Bednarek Sent: 02 March 2010 08:37 To: General discussion for Windows Installer XML toolset. Subject: .NET Custom Action fails intermittently on some machines Hi all, Our product fails to install (seemingly at random) once every so often. Once this failure occurs on a given machine, it is not usually possible to reproduce the problem again (re-installing the product will work fine). The machines on which the install fails are VMs which all come from the same base image (Windows 2008 R2 x64). The install always fails during one of our custom actions, which is written in .NET using DTF. The custom action (called SetUserLanguage) is quite simple: it detects the .NET current culture and puts the two-letter language code of the culture (e.g. en) into a property called UserLanguage. According to the MSI logs, this code is running successfully - we see our own log statements appearing, and we see MSI report that the UserLanguage property has been set. However, an error seems to occur somewhere between the .NET code completing, and the MSI continuing with the next action. Here's the pertinent part of the MSI log: --- MSI (s) (6C:08) [08:29:01:854]: Doing action: SetUserLanguage MSI (s) (6C:08) [08:29:01:886]: Creating MSIHANDLE (33847) of type 790542 for thread 4616 MSI (s) (6C:38) [08:29:01:886]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI3B7B.tmp, Entrypoint: SetUserLanguage MSI (s) (6C!40) [08:29:02:276]: Creating MSIHANDLE (33848) of type 790531 for thread 4672 Action start 8:29:01: SetUserLanguage. MSI (s) (6C!40) [08:29:02:276]: Closing MSIHANDLE (33848) of type 790531 for thread 4672 MSI (s) (6C!40) [08:29:02:525]: Creating MSIHANDLE (33849) of type 790531 for thread 4672 SFXCA: Extracting custom action to temporary directory: C:\Windows\Installer\MSI3B7B.tmp-\ MSI (s) (6C!40) [08:29:02:525]: Closing MSIHANDLE (33849) of type 790531 for thread 4672 MSI (s) (6C!40) [08:29:02:806]: Creating MSIHANDLE (33850) of type 790531 for thread 4672 SFXCA: Binding to CLR version v2.0.50727 MSI (s) (6C!40) [08:29:02:822]: Closing MSIHANDLE (33850) of type 790531 for thread 4672 MSI (s) (6C!40) [08:29:02:993]: Creating MSIHANDLE (33851) of type 790531 for thread 4672 Calling custom action CustomActions!CustomActions.CustomActions.SetUserLanguage MSI (s) (6C!40) [08:29:02:993]: Closing MSIHANDLE (33851) of type 790531 for thread 4672 MSI (s) (6C!40) [08:29:02:993]: PROPERTY CHANGE: Adding UserLanguage property. Its value is 'en'. Detected culture as en-US and converted to language en MSI (s) (6C:38) [08:29:03:024]: Closing MSIHANDLE (33847) of type 790542 for thread 4616 CustomAction SetUserLanguage returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) Action ended 8:29:03: SetUserLanguage. Return value 3. Action ended 8:29:03: INSTALL. Return value 3. --- Does anyone have any ideas why our custom action (or DTF) might be failing, and how we could investigate further? Thanks! Mike Bednarek -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] MakeSfxCA do not copy file version from C# assembly to output dll.
Hi, I am using MakeSfxCA utility (Wix 3.0) to create a DLL with CSharp custom actions. Recently I have noticed that this DLL has the file version info exactly as the SDK sfxca.dll . I have tested it with both build #5217 #5332 . When reverting the SDK in use to build #4827 I have gained the normal behavior of copying the version info form the C# DLL to the output DLL. Anybody else encountered this issue? Thanks, Dov -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to identify the custom action type in run time.
I’d like to write a generic custom action which can be run either immediate or deferred. In order to pass arguments to this custom action I need to use two different approaches since it is a given fact of Windows Installer behavior. On the caller side (Wix) it is quite clear. I have a problem with how to identify the mode the CA is currently running. Anybody has an idea? Thanks, Dov -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://www.creativitycat.com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wrong Assembly version in MsiAssemblyName table after
Bob Arnson wrote: It appears to be by design, based on this comment in the code: IMHO, it is a bug, by design, but still a bug. According to Aaron Stebner's blog http://blogs.msdn.com/astebner/archive/2005/02/12/371646.aspx the fusion bug was fixed long time ago (.Net 1.1 SP1 .Net 2.0) and I see no reason to keep this limitation in Wix. At least let the user choose (a command switch will do) whether light should produce .Net 1.1 compatible code or a more general one. Do you have any best practice suggestion for registering and installing an assembly with vesion=4.0.0.0 and fileversion=4.0.767.0 ? I don't want the assembly version to be hardcoded in the Wix source files. I want to get it dynamically from the actual assembly being packed in the MSI file. Thanks, Dov -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wrong Assembly version in MsiAssemblyName table after
Bob Arnson wrote: Sounds familiar -- try upgrading to the RC2 release for a fix. Well, I've tried both 3.0.5217.0 and 3.0.5224.0. Still the same. Any idea? Thanks, Dov -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Wrong Assembly version in MsiAssemblyName table after
Hi, I have a .Net assembly file with file version 4.0.763.0 and assembly version 4.0.0.0. In order to install it into the GAC I have used latest Wix3 toolset and faced a wrong registration issue. Taking a look into the MSI file with Orca tool shows that in MsiAssemblyName table the file version is as expected 4.0.763.0 however the version is 4.0.0.000 (with two redundant zeros). I would not mind it if I was not using the bind feature of the light for creating registry keys for COM registration. It all worked fine when file version and assembly version were the same number. Oddly enough when assembly version has less meaningful digits, light adds zeros to have both versions with the same number of digits. Am I the only one to face this problem? How do others register .Net assemblies? Do you always use the same numbers for file version and assembly? Thanks, Dov -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
