Re: [WiX-users] One patch to rule them all
Chad, I may not be fully understanding your requirements, but it sounds like you want to create a patch that does not patch every file in the installer? I have not yet tried to create patches with WIX, I still use msimsp to create patches with a .pcp file for the input, so I cant tell you the WIX way to create the patch that ignores this file, but I assume this process will work for both since it is outside the patch creation process. What you can do is to create your Target image and your Upgrade image, and then simply delete the file that you don't want patched from the administrative Upgrade image and it won't be included in the patch. You do not need to modify your installer .msi in any way, or change the .pcp to ignore the file. Just deleting the file from disk in the administrative Upgrade image will prevent it from being included in the patch. -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Monday, November 03, 2008 10:28 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] One patch to rule them all I'm not a patching expert, but there is a feature in pyro that allows you to filter out Fragments and target only the portions of the install that you want. -Original Message- From: Rob Lange [mailto:[EMAIL PROTECTED] Sent: Monday, November 03, 2008 22:09 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] One patch to rule them all I assume the patch fails because it was created with an installer set (both base[v1] and upgrade[v2]) that had a different DLL than the current installer being used on the machine. It all comes down to me being able to ask WiX to please ignore the DLL and just patch my other files, no matter how different the DLL is from the V2 or V1 of my installer the patch was created from. I have other ugly/non-professional/hack non-WiX solutions, but getting that code reviewed is an ugly prospect. -Original Message- From: Chad Miles [mailto:[EMAIL PROTECTED] Sent: Monday, November 03, 2008 8:15 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] One patch to rule them all Could you baseline a Patch Target msi and patch off that? I'm not big on patching, but it sounds like the msp is baselined and not the msi. I'd definitely take someone else's word though. Just an opening thought. If you want it included no matter what (as you stated), maybe script based on file version? On Mon, Nov 3, 2008 at 10:00 PM, Rob Lange <[EMAIL PROTECTED]> wrote: > > I have a strange question that I've been trying to find a solution to for > awhile and I'm hoping people who work with WiX more than me might have a > good suggestion. I've got an installer that is built every day, using WiX, > that contains a DLL taken from a project in development. I also have a > patch, built using WiX, for the installer that adds a few files to the > program. The patch is hosted on a server that our feature fetches the > location to then downloads and installs the patch. The problem is that the > patch will only work for that day's build because the DLL constantly > changes. I need to find a way to include this DLL in the installer package, > but not have the patch care that the DLL has changed. So, *gulp* is this > possible with WiX? > - > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ---
Re: [WiX-users] vc9 mergemodule and long uninstallation times
This is true, but the .Net Framework also shows up in the ARP, and removing that can also break not just my app, but lots of apps. I guess users are conditioned not to do this, as we have not had any issues with this. -Original Message- From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2008 10:02 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] vc9 mergemodule and long uninstallation times Bryan Turner wrote: > We have also experienced this issue. Fortunately, we have a > bootstrapper/chainer that allows us to install vcredist_x86.exe and > vcredist_x64.exe instead of merging those modules into our installer directly. The downside is that the redist has its own entry in ARP/P&F and users can easily uninstall it, breaking your app. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question regarding the attribute "Win64" in"Component"
One approach to this that I have seen work is where you have one .wxs file that generates both a 32-bit and a 64-bit .msi through conditional logic. You then wrap both the 32-bit and 64-bit .msi in a bootstrapper that determines the correct .msi to install at runtime. The bootstrapper can be pretty simple, with no UI that does nothing other than determine the OS and launch the correct .msi. While not perfect, this allows you to only have to manage one set of .wxs files to generate two almost identical installations, targeting two different platforms. To generate two installers, one 32-bit and one 64-bit from a single .wxs file, you would do something like this... http://schemas.microsoft.com/wix/2006/wi";> -Original Message- From: Michael Owings [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 28, 2008 8:32 AM To: Pally Sandher Cc: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question regarding the attribute "Win64" in"Component" A mixed install will *always* be unavoidable for us. Some of our components are plugins for other applications -- which may themselves be 32-bit or 64-bit (even on a 64-bit platform, a 32-bit app could be in use, or a particular app may ONLY be 32-bit), which requires the plugins built for the appropriate architecture. We don't know what's installed where until runtime. We actually determine the correct place to drop the plugins via custom actions sequenced prior to LaunchConditions. The plugin install paths could be anywhere -- very possibly (and not uncommonly) NOT under ProgramFiles64Folder or even ProgramFilesFolder. In fact, we really for the most part don't care about the values of these properties and don't use them, as we have to determine component locations via custom actions, always. There is a single exception to this rule -- a 32-bit app, but the MSI always does the right thing with this (we use ProgramFilesFolder, and it drops it into the correct place) However, I might be concerned if our *own* location properties were bing transformed somehow. In other words, If I set a property to C:\Program Files\foo on a 64-bit machine and I get redirected to c:\Program Files (x86)\foo on the component install I might be concerned -- but I haven't seen evidence of this (yet -- I have a lot more 64-bit testing to do). Nothing is dropped into System32 in all cases. Having said all that -- I'm not averse to building a 64-bit installer, but (per another email) 64-bit MSIs with WIX 2.x don't seem to work for me: I've noticed that my MSI will not run on a Vista-64 box if I add the Platforms="x64" attribute. The error is something to the effect of : "This installation package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer package." Should my custom actions dll be built 64-bit? The MSI can be opened with Orca and examined without issues. Any help on *that* issue would be appreciated, as I do have an upcoming install where I really will need a 64-bit MSI. Pally Sandher wrote: > If your MSI is built for x86 (i.e. Platform = "Intel") try as you may, > you will *not* be able to access the 64-bit system directories > ProgramFiles64Folder, System64Folder or CommonFiles64Folder. You may get > an MSI to build & even look as though it installs but it won't ever > access these areas. When (if) you check the log you'll see properties > being transformed by something called WIN64DUALFOLDERS from the 64-bit > directory to the corresponding 32-bit directory. > > You can however build a x64 MSI which can access both 64-bit & 32-bit > system directories which WIN64DUALFOLDERS won't touch but as stated > before you will get ICE80 errors for every 32-bit directory you > reference. > > Why does your application have 32-bit & 64-bit components? > > > Palbinder Sandher > Software Deployment and IT Administrator > > T: +44 (0) 141 945 8500 > F: +44 (0) 141 945 8501 > http://www.iesve.com > > **Design, Simulate + Innovate with the ** > > Integrated Environmental Solutions Limited. Registered in Scotland No. > SC151456 > Registered Office - Helix Building, West Of Scotland Science Park, > Glasgow G20 0SP > > Email Disclaimer > > > > -Original Message- > From: Christopher Karper [mailto:[EMAIL PROTECTED] > Sent: 28 October 2008 14:28 > To: [EMAIL PROTECTED] > Cc: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Question regarding the attribute "Win64" > in"Component" > > MSI doesn't support a single installer for multiple architectures. > That's > the problem. You'll never get a 32bit installer to validate with 64 > bit > components in it, period. MSI requires that you build a single > installer for each architecture you target. You can use conditional > statements and variable replacement in your .wxs file to have a single > source file, but generate the two .msi files, but you mus
Re: [WiX-users] vc9 mergemodule and long uninstallation times
We have also experienced this issue. Fortunately, we have a bootstrapper/chainer that allows us to install vcredist_x86.exe and vcredist_x64.exe instead of merging those modules into our installer directly. We like this method better as it keeps our installer just a little bit cleaner and is easier to update as you move from VS 2003-> VS 2005 -> VS 2005 SP1 -> VS 2008 -> VS 2008 SP1 -> you get the idea. If you have a bootstrapper, you can simply install those freely redistributable .exe's as pre-requisites of your product and be done. -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2008 3:34 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] vc9 mergemodule and long uninstallation times Importance: Low Don't know if you can avoid it. All I can do is confirm that the behavior is exactly as expected. The CustomAction that does the slow scan is very, very unfortunate. -Original Message- From: Jon W [mailto:[EMAIL PROTECTED] Sent: Monday, October 27, 2008 15:22 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] vc9 mergemodule and long uninstallation times I am installing the Visual Studio 2008 (vc9) runtime libs by incorporating the vc9 mergemodule into my msi. The problem is as follows... If a user has multiple side-by-side installations and wants to uninstall an installation, then the msiexec process takes minutes when evaluating whether it can uninstall the vc9 runtime libs from the WinSxS directory. Is there a way to avoid uninstalling the mergemodule and/or avoid the long dependency checking? I would have assumed that msiexec would be able to quickly see that other installations depend upon the runtime libs, but instead it consumes minutes analyzing the uninstallation of these files. Thanks, Jon - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstall takes 3 times longer timeframe than install
Yan, Try uninstalling from the command line with the option DISABLEROLLBACK=1. For example, msiexec /x yourmsi.msi DISABLEROLLBACK=1. This might make the uninstall quicker if it does not need to create copies of all the files as it removes them in case you hit the cancel button during uninstallation. Something else that I think has been done in the past is to group large numbers of files into components, so you have maybe 1000 files associated with 1 component. This may or may not be appropriate for your installation. This works because it reduces the number of writes/deletes to the registry. -Original Message- From: Yan Sklyarenko [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 07, 2008 8:32 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Uninstall takes 3 times longer timeframe than install Hello WiX community, My installation source contains 25,000+ files. I used heat.exe to create a WiX authoring out of the root directory. This gave me a *.wxs file with approximately the same number of components, which is claimed to be handled OK by Windows Installer. After some rough tweaking, I managed to build the MSI package (again, it contains only files, nothing else). The idea is just to test the performance. So, the installation took about 7 minutes, while the uninstallation time is 3 times bigger, about 22 minutes. Is it normal? If not, then where should I look to troubleshoot the problem? I apologize if this was already discussed somewhere one day. In this case, I'd appreciate a link. Thank you. -- Yan - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] embedding cab files in .msi
Hello, I think I am missing something obvious I am using Wix 3.0.4429. In my .wxs file, I have the following elements: When I link with Light, I get this warning, and my files are not compressed into an internal cab inside the .msi, but are instead uncompressed next to the .msi light.exe Core.wixobj -out Core.msi -nologo Core.wxs(24) : warning LGHT1079 : The cabinet 'product.cab' does not contain any files. If this installation contains no files, this warning can likely be safely ignored. Otherwise, please addfiles to the cabinet or remove it. If anyone can see the obvious, please let me know. Thanks - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Moving from InstallShield 12 to wix
Q: I'm also curious why you chose to use an Include instead of using a Fragment with a ComponentGroup in it that is pulled in at link time? A: Ignorance. It seems like what you are suggesting is more complicated than my current solution, but its more likely that I simply don't fully understand what you are suggesting. My problem came in automatically generating the list of files. It looked like Heat would do the job, but when I implemented, I got errors when I tried to bring that into my install because the Heat generated file included the DirectoryRef as well. I also liked that using my current implementation, I can clearly identify the entire directory structure, component GUID, and if necessary, registry entries associated with a given component, the only thing in my include file is the list of files to be included in that component... Again, most of what I have done is because I still don't fully understand WIX. -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 11:07 AM To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED] Subject: Re: [WiX-users] Moving from InstallShield 12 to wix Understood and I'm just trying to ensure that everyone understands that the reasons the WiX toolset doesn't have a general purpose tool that solves this problem because a "correct and complete" solution is very, very difficult to implement. I'm also curious why you chose to use an Include instead of using a Fragment with a ComponentGroup in it that is pulled in at link time? -Original Message- From: Bryan Turner [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 10:49 To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED] Subject: Re: [WiX-users] Moving from InstallShield 12 to wix Rob, You are correct, it does require some diligence on the source control side. In my case, I do dynamic file pickup on files that are not to be patched or updated . For example, we don't patch sample files, so the dynamically included files are locked down after we release, thereby eliminating this problem. This requires some planning to be properly implemented. By creating the list of files dynamically, and then using them in an include file, I can check the include file in once we are locked down for a release and then I don't have to worry about new files being dynamically picked up. I am not advocating this for everyone, I just do not want to be manually updating files in the install every time something is changed. -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 10:14 AM To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED] Subject: Re: [WiX-users] Moving from InstallShield 12 to wix 1. What happens if you want to add or remove one of those sample files? You can't technically add or remove resources from a Component so that would break things... unless you guaranteed a major upgrade. Like I said, it gets tricky. 3. Did you actually specify any Files to be compressed? Either set the Compress attribute on the File or compress everything by default by setting Package/@Compress. -Original Message- From: Bryan Turner [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 10:00 To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED] Subject: Re: [WiX-users] Moving from InstallShield 12 to wix Rob, I am using one component for a group of files, not all my files. For example, non-versioned files like samples that are all grouped into the same directory (and therefore the same component) should be safely grouped in one component, I believe. Regarding the embed cab, it does not work for me, I simply get this warning: warning LGHT1079 : The cabinet 'product.cab' does not contain any files. If this installation contains no files, this warning can likely be safely ignored. Otherwise, please addfiles to the cabinet or remove it. Here is the email I sent on this earlier, although I never did see it hit the message board (probably user error)... Hello, I think I am missing something obvious I am using Wix 3.0.4429. In my .wxs file, I have the following elements: When I link with Light, I get this warning, and my files are not compressed into an internal cab inside the .msi, but are instead uncompressed next to the .msi light.exe Core.wixobj -out Core.msi -nologo Core.wxs(24) : warning LGHT1079 : The cabinet 'product.cab' does not contain any files. If this installation contains no files, this warning can likely be safely i
Re: [WiX-users] Moving from InstallShield 12 to wix
Rob, You are correct, it does require some diligence on the source control side. In my case, I do dynamic file pickup on files that are not to be patched or updated . For example, we don't patch sample files, so the dynamically included files are locked down after we release, thereby eliminating this problem. This requires some planning to be properly implemented. By creating the list of files dynamically, and then using them in an include file, I can check the include file in once we are locked down for a release and then I don't have to worry about new files being dynamically picked up. I am not advocating this for everyone, I just do not want to be manually updating files in the install every time something is changed. -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 10:14 AM To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED] Subject: Re: [WiX-users] Moving from InstallShield 12 to wix 1. What happens if you want to add or remove one of those sample files? You can't technically add or remove resources from a Component so that would break things... unless you guaranteed a major upgrade. Like I said, it gets tricky. 3. Did you actually specify any Files to be compressed? Either set the Compress attribute on the File or compress everything by default by setting Package/@Compress. -Original Message----- From: Bryan Turner [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 10:00 To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED] Subject: Re: [WiX-users] Moving from InstallShield 12 to wix Rob, I am using one component for a group of files, not all my files. For example, non-versioned files like samples that are all grouped into the same directory (and therefore the same component) should be safely grouped in one component, I believe. Regarding the embed cab, it does not work for me, I simply get this warning: warning LGHT1079 : The cabinet 'product.cab' does not contain any files. If this installation contains no files, this warning can likely be safely ignored. Otherwise, please addfiles to the cabinet or remove it. Here is the email I sent on this earlier, although I never did see it hit the message board (probably user error)... Hello, I think I am missing something obvious I am using Wix 3.0.4429. In my .wxs file, I have the following elements: When I link with Light, I get this warning, and my files are not compressed into an internal cab inside the .msi, but are instead uncompressed next to the .msi light.exe Core.wixobj -out Core.msi -nologo Core.wxs(24) : warning LGHT1079 : The cabinet 'product.cab' does not contain any files. If this installation contains no files, this warning can likely be safely ignored. Otherwise, please addfiles to the cabinet or remove it. If anyone can see the obvious, please let me know. -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 9:22 AM To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED] Subject: Re: [WiX-users] Moving from InstallShield 12 to wix 1. One Component with all your files in it is a can be a very dangerous design. There are a lot of servicing scenarios where you might be very unhappy with that decision. The difficulty of autogenerating Components that meet all "good design guidelines" is why we don't have a good tool in WiX yet... knowingly painful. 2. No doubt. I believe, there are several tools around who's strengths are on UI editing. 3. It is simple: also set Package/@Compressed="yes" to get everything compressed, or compress File elements individually. -Original Message- From: Bryan Turner [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 09:06 To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED] Subject: Re: [WiX-users] Moving from InstallShield 12 to wix I just moved a project from IS 12 to WIX, other than what has been pointed out below, here is what I did: 1. Created my IS 12 generated msm's 2. Ripped out all the IS tables in the .msm's with ORCA 3. Ripped out all the IS custom actions, binaries, properties, etc... in the .msm's with ORCA 4. Ran dark.exe on the now gutted merge modules and diffed them against the IS generated ones 5. Checked in my .wxs files that generate my .msm's 1. Created my IS 12 generated .msi, without merging in all my .msm's, just wanted the bare .msi 2. Ripped out all the IS tables in the .msi 3. Ripped out all the IS custom actions, binaries, properties, etc... in the .msi 4. Ran the now gutted install to make
Re: [WiX-users] Moving from InstallShield 12 to wix
Rob, I am using one component for a group of files, not all my files. For example, non-versioned files like samples that are all grouped into the same directory (and therefore the same component) should be safely grouped in one component, I believe. Regarding the embed cab, it does not work for me, I simply get this warning: warning LGHT1079 : The cabinet 'product.cab' does not contain any files. If this installation contains no files, this warning can likely be safely ignored. Otherwise, please addfiles to the cabinet or remove it. Here is the email I sent on this earlier, although I never did see it hit the message board (probably user error)... Hello, I think I am missing something obvious I am using Wix 3.0.4429. In my .wxs file, I have the following elements: When I link with Light, I get this warning, and my files are not compressed into an internal cab inside the .msi, but are instead uncompressed next to the .msi light.exe Core.wixobj -out Core.msi -nologo Core.wxs(24) : warning LGHT1079 : The cabinet 'product.cab' does not contain any files. If this installation contains no files, this warning can likely be safely ignored. Otherwise, please addfiles to the cabinet or remove it. If anyone can see the obvious, please let me know. -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 9:22 AM To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED] Subject: Re: [WiX-users] Moving from InstallShield 12 to wix 1. One Component with all your files in it is a can be a very dangerous design. There are a lot of servicing scenarios where you might be very unhappy with that decision. The difficulty of autogenerating Components that meet all "good design guidelines" is why we don't have a good tool in WiX yet... knowingly painful. 2. No doubt. I believe, there are several tools around who's strengths are on UI editing. 3. It is simple: also set Package/@Compressed="yes" to get everything compressed, or compress File elements individually. -Original Message- From: Bryan Turner [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 09:06 To: General discussion for Windows Installer XML toolset.; [EMAIL PROTECTED] Subject: Re: [WiX-users] Moving from InstallShield 12 to wix I just moved a project from IS 12 to WIX, other than what has been pointed out below, here is what I did: 1. Created my IS 12 generated msm's 2. Ripped out all the IS tables in the .msm's with ORCA 3. Ripped out all the IS custom actions, binaries, properties, etc... in the .msm's with ORCA 4. Ran dark.exe on the now gutted merge modules and diffed them against the IS generated ones 5. Checked in my .wxs files that generate my .msm's 1. Created my IS 12 generated .msi, without merging in all my .msm's, just wanted the bare .msi 2. Ripped out all the IS tables in the .msi 3. Ripped out all the IS custom actions, binaries, properties, etc... in the .msi 4. Ran the now gutted install to make sure it still worked 5. Ran dark on the now gutted .msi's 6. compiled and tested with my merged modules 7. modified my build scripts to use WIX instead of IS to build This was just finished, and it seems to be working OK. WIX files are so much easier to maintain, and you can simply check the WIX folder into your source tree and your entire development/QA team can create installations without having to have IS installed. However, here is what you will lose, in my opinion, and you need to be ready for this: 1. the niceness that IS provides, like being able to just point it at a directory tree and telling the install to go gather up all the files and folders and add them to the install. My dev team almost choked on that, so I had to role my own implementation of dynamically picking up files from a directory (but not recursively) and making sure that all the files were assigned only one GUID. There are tools for this, like Heat.exe, Parafin, Tallow, etc... but I was unable to find one that would allow me to just use a wix include file to insert multiple files under a single component (and GUID). This could be user error/ignorance on my part. 2. UI changes - If you need to modify the UI of your installer, you have lost that nice interface you get with a GUI based install tool like IS 3. Still can't figure out how to embed the cab files into the .msi with WIX 3.0, even though it is supposed to be simple. I am sure this is user error. -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 7:49 AM To: [EMAIL PROTECTED]; General discussion for Wi
Re: [WiX-users] Moving from InstallShield 12 to wix
I just moved a project from IS 12 to WIX, other than what has been pointed out below, here is what I did: 1. Created my IS 12 generated msm's 2. Ripped out all the IS tables in the .msm's with ORCA 3. Ripped out all the IS custom actions, binaries, properties, etc... in the .msm's with ORCA 4. Ran dark.exe on the now gutted merge modules and diffed them against the IS generated ones 5. Checked in my .wxs files that generate my .msm's 1. Created my IS 12 generated .msi, without merging in all my .msm's, just wanted the bare .msi 2. Ripped out all the IS tables in the .msi 3. Ripped out all the IS custom actions, binaries, properties, etc... in the .msi 4. Ran the now gutted install to make sure it still worked 5. Ran dark on the now gutted .msi's 6. compiled and tested with my merged modules 7. modified my build scripts to use WIX instead of IS to build This was just finished, and it seems to be working OK. WIX files are so much easier to maintain, and you can simply check the WIX folder into your source tree and your entire development/QA team can create installations without having to have IS installed. However, here is what you will lose, in my opinion, and you need to be ready for this: 1. the niceness that IS provides, like being able to just point it at a directory tree and telling the install to go gather up all the files and folders and add them to the install. My dev team almost choked on that, so I had to role my own implementation of dynamically picking up files from a directory (but not recursively) and making sure that all the files were assigned only one GUID. There are tools for this, like Heat.exe, Parafin, Tallow, etc... but I was unable to find one that would allow me to just use a wix include file to insert multiple files under a single component (and GUID). This could be user error/ignorance on my part. 2. UI changes - If you need to modify the UI of your installer, you have lost that nice interface you get with a GUI based install tool like IS 3. Still can't figure out how to embed the cab files into the .msi with WIX 3.0, even though it is supposed to be simple. I am sure this is user error. -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 7:49 AM To: [EMAIL PROTECTED]; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Moving from InstallShield 12 to wix Sorry, caught the end of this thread. 1. You need to maintain Component/@Guids according to the Component Rules. It doesn't matter what tool you use to create the MSI. Once you ship, you must maintain the GUIDs appropriately. 2. ProductCodes and UpgradeCodes need to be updated following the Windows Installer rules for upgrades. Major upgrade? Change the ProductCode... etc. 3. Dark.exe can help get all of your authoring and it will preserve all the GUIDs for you. Technically speaking, you should be able to switch at any time and rebuild a functionally identical MSI file (although it may be a little smaller since WiX tries very hard to only add the things you need). -Original Message- From: Michael Owings [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 18:01 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Moving from InstallShield 12 to wix I'm currently in the process of moving from an InstallShield 12 (which I loathe) project over to wix. I'd ideally like to be able to update the next version of this project via wix. I'm wondering if I use the the same product and component IDs if I'd be in good shape as far as an upgrading goes. Any gotchas I should be aware of? Thanx in advance -- m -- Teleoperate a roving mobile robot from the web: http://www.swampgas.com/robotics/rover.html - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ---
[WiX-users] Wix 3.0.4429.0 and Suppressing Modularization on a directory
With Wix 2.0, I used this: With Wix 3.0.4429.0, I see this warning: My.wxs(62) : warning CNDL1085 : The IgnoreModularization element has been deprecated. Use the Binary/@SuppressModularization, CustomAction/@SuppressModularization, or property/@SuppressModularization attribute instead. It does not mention what to do with Directory names to suppress modularization. And if I try the new SuppressModularization element, I get this: My.wxs(62) : error CNDL0004 : The Directory element contains an unexpected attribute 'SuppressModularization'. What is the correct way to remove these warnings? Thanks - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
