Re: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules in thesame MSI
Your comments are very useful, Edwin. I generally agree with you that we need to buckle down in WiX v4.0 (where we can introduce breaking language changes if necessary) and really try to simplify the language, as per: http://robmensching.com/blog/posts/2010/1/16/Glimpses-of-life-with-WiX-v4.0 On Tue, Mar 23, 2010 at 3:23 PM, Castro, Edwin G. (Hillsboro) < edwin.cas...@fiserv.com> wrote: > The library is useful for simple setup requirements. The library becomes > difficult to use if you have complex requirements that could benefit from > WiX extensions. The library allows the install engineer to define managed > custom actions in the same code that defines the installer so it makes it > very convenient to author setup code that may perform the same activities > that standard WiX extensions already perform in more robust fashion. > > I like WiX# for very, very simple cases. For example, I would prefer WiX# > over Visual Studio setup projects for simple cases where Visual Studio setup > projects might be enough. Once the installer becomes large enough to require > lots of modularization, then I would stop using WiX#. Or when I need to use > WiX features that are not directly exposed by WiX# which includes all WiX > extensions. There are some core bits that are not directly exposed too. For > example, I'd need to write C# code to modify the generated *.wxs if I want > to install an *.exe as service using the ServiceInstall table. > > I personally believe some of the usability changes the WiX team has > addressed in 3.5 thus far are the types of changes that will make libraries > like Wix# less interesting. I tried to expose more of WiX in a Wix# style > once and kept getting a C# version of the WiX XML schema. > > My intention is not to bash Wix# but to be open about its applicability and > usefulness as there will be times when it won't be as useful as it appears > to be originally. > > Edwin G. Castro > Software Developer - Staff > Electronic Banking Services > Fiserv > Office: 503-746-0643 > Fax: 503-617-0291 > www.fiserv.com > Please consider the environment before printing this e-mail > > > > -Original Message- > > From: s...@pacaccess.com [mailto:s...@pacaccess.com] > > Sent: Tuesday, March 23, 2010 2:55 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules > > in thesame MSI > > > > > In general, I personally find the library to be limiting but it does > > try > > > to follow some reasonable design principles for simple projects. It > > has a > > > > I'm not sure if WiX# ready for prime time or not, as there are parts of > > WiX which aren't supported in WiX#, but I've found it helpful in > > learning > > WiX and the author (Oleg) has been very helpful and responsive. > > > > Jeff > > > > > > > > > > --- > > --- > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find bugs > > proactively, and fine-tune applications for parallel performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- virtually, Rob Mensching - http://RobMensching.com LLC -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing from embedded CAB file and Folder
Yeah, that's a weird behavior of Windows Installer. If your Package is compressed but the File is not compressed, Windows Installer expects the file in the root of the install (where the .msi file is). On Tue, Mar 23, 2010 at 8:01 AM, Sanjay Poria wrote: > I'm finding that the Directory/@SourceName property seems to have no > effect. If I define my source files in a fragment as follows (using the > initial example I gave): > > > > > > > > Compressed="no" Source="$(var.DocDir)\doc1.pdf" /> > > > > > The installer still tries to find "doc1.pdf" at the same level as the msi > (instead of in the relative DocFiles\ subdir). Is this some kind of bug? > > sanjay > > > -Original Message- > > From: Bob Arnson [mailto:b...@joyofsetup.com] > > Sent: 23 March 2010 02:09 > > Subject: Re: [WiX-users] Installing from embedded CAB file and Folder > > > > On 3/22/2010 6:46 PM, Sanjay Poria wrote: > > > The problem is that when I run the installer, it still expects to > > find files (doc1, doc2) in the main directory (at the same level as the > > msi) instead of the "DocFiles" directory. When building, the installer > > actually creates the source structure as above (which made me think > > everything was specified ok). > > > > > > > The Layout attribute controls where the files are written, not where > > they're installed from. For that, use Directory/@SourceName. See also > > the Directory table in the MSI SDK. > > > > -- > > sig://boB > > http://joyofsetup.com/ > > > > > > > > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- virtually, Rob Mensching - http://RobMensching.com LLC -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] de-globalizing a variable referenced by a Directory?
I inherited an installer with some code that looks like the following: The LOGDIRECTORY is a variable, and the directory name is derived from it. Unfortunately, this means that LOGDIRECTORY must always be defined, even when I'm trying to install a component that has nothing to do with the LOGDIRECTORY. Is there some way around this or should I simply make this a global variable and deal with the fact that it's ugly? Andrew -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules in thesame MSI
The library is useful for simple setup requirements. The library becomes difficult to use if you have complex requirements that could benefit from WiX extensions. The library allows the install engineer to define managed custom actions in the same code that defines the installer so it makes it very convenient to author setup code that may perform the same activities that standard WiX extensions already perform in more robust fashion. I like WiX# for very, very simple cases. For example, I would prefer WiX# over Visual Studio setup projects for simple cases where Visual Studio setup projects might be enough. Once the installer becomes large enough to require lots of modularization, then I would stop using WiX#. Or when I need to use WiX features that are not directly exposed by WiX# which includes all WiX extensions. There are some core bits that are not directly exposed too. For example, I'd need to write C# code to modify the generated *.wxs if I want to install an *.exe as service using the ServiceInstall table. I personally believe some of the usability changes the WiX team has addressed in 3.5 thus far are the types of changes that will make libraries like Wix# less interesting. I tried to expose more of WiX in a Wix# style once and kept getting a C# version of the WiX XML schema. My intention is not to bash Wix# but to be open about its applicability and usefulness as there will be times when it won't be as useful as it appears to be originally. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail > -Original Message- > From: s...@pacaccess.com [mailto:s...@pacaccess.com] > Sent: Tuesday, March 23, 2010 2:55 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules > in thesame MSI > > > In general, I personally find the library to be limiting but it does > try > > to follow some reasonable design principles for simple projects. It > has a > > I'm not sure if WiX# ready for prime time or not, as there are parts of > WiX which aren't supported in WiX#, but I've found it helpful in > learning > WiX and the author (Oleg) has been very helpful and responsive. > > Jeff > > > > > --- > --- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Registering a COM DLL
The recommended way now is typically to run heat.exe to "harvest" the com registration information out of your DLL. This way it won't actually run the code from the DLL at install-time (which is more likely to fail, won't handle all of MSI's transactionality appropriately, and is generally a non-recommended solution) and instead will figure out what exactly what registry keys your DLL needs, and put that information into the MSI (the recommended, more robust way). Generally you run the tool something like this: Heat file -template:fragment file.dll -out fragment.wxs This should generate some registry, etc. fragments which you can reference from the rest of your authoring via ComponentRef or ComponentGroupRef elements. -Original Message- From: s...@pacaccess.com [mailto:s...@pacaccess.com] Sent: Tuesday, March 23, 2010 2:49 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Registering a COM DLL I'm moving from a Visual Studio Deployment Project to WiX. In my old visual studio deployment project I'm installing a DLL and registering it via setting the Register property to vsdrfCOMSelfReg, and I wish to do the same thing with WiX. I didn't see anything about registering COM DLLs in the WiX documents, but after searching I found a page on registering a COM DLL: http://blogs.msdn.com/robmen/archive/2004/04/28/122491.aspx Within the blog the author says to use a AssemblyRegisterComInterop property in a file node: This must have been for an older version of WiX because WiX3 doesn't seem to have this. Are there any tutorials on how to have WiX register a COM DLL? Thanks, Jeff -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] .NET Applications
I'm working on an installer project that has a mix of legacy VB applications and .NET applications. Originally, I exposed /dark /to an existing MSI, but I wasn't happy with the output. So I thought I'd give /heat/ a try; I used /heat /to melt the old VB apps down to wxs files and I can sort of see where all that's heading with all the various fragments and component groups. Then I noticed that my WiX project has references to all the .NET projects that I'd like to install and I don't recall adding the references. Is this something that /dark /did? Or is this a consequence of having my WiX project part of a solution with all the other .NET projetcts? Is this something that is required for installing .NET applications? Should I be using /heat/ to melt the bin\Release of my .NET projects? Or is there a better/easier method? Where can I get detailed info on all the Extensions (WixNetFxExtension, WixUIExtension, et. al.)? Thanks, Bill -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules in thesame MSI
> In general, I personally find the library to be limiting but it does try > to follow some reasonable design principles for simple projects. It has a I'm not sure if WiX# ready for prime time or not, as there are parts of WiX which aren't supported in WiX#, but I've found it helpful in learning WiX and the author (Oleg) has been very helpful and responsive. Jeff -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Registering a COM DLL
I'm moving from a Visual Studio Deployment Project to WiX. In my old visual studio deployment project I'm installing a DLL and registering it via setting the Register property to vsdrfCOMSelfReg, and I wish to do the same thing with WiX. I didn't see anything about registering COM DLLs in the WiX documents, but after searching I found a page on registering a COM DLL: http://blogs.msdn.com/robmen/archive/2004/04/28/122491.aspx Within the blog the author says to use a AssemblyRegisterComInterop property in a file node: This must have been for an older version of WiX because WiX3 doesn't seem to have this. Are there any tutorials on how to have WiX register a COM DLL? Thanks, Jeff -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules in thesame MSI
http://www.csscript.net/WixSharp.html "Wix# (WixSharp) is a new member in the CS-Script family. Wix# is a managed interface to WiX (Windows Installer XML toolset for building Windows installation packages from XML source code)." "Wix# allows building a complete MSI or WiX source code by executing script files written with the C# syntax. It uses a C# class structure to mimic WiX entities and their relationships in order to produce a valid deployment model." In general, I personally find the library to be limiting but it does try to follow some reasonable design principles for simple projects. It has a bad policy of including the compiled EXE used to generate the MSI once for each and every managed custom action you define rather than including it once and referencing the binary multiple time. That's just one of my complaints on Wix#. I see that it does include nbsbuilder.exe: PS C:\WixSharp.0.1.30> .\nbsbuilder.exe /? Building bootstrapper... Native Bootstrapper Builder v 1.0.0 Copyright (C) 2010 Oleg Shilo. Builds simple native (Win32) bootstrapper. It alows building a bootstrapper for two deployment applications: primary setup and its prerequisite. NBSBUILDER /out: /first: /second: /regkey: [/verify:] [/icon:] first - the setup application to be run the first (prerequisite). second - the setup application to be run the second (after running prerequisite) out- name of the output file (bootstrapper) to produce reg- the registry key that indicates if firstMSI should be run. If the 'reg' value exists in registry the firstMSI will be considered already installed and will not run. Registry value should comply with the following pattern. ::ValueName> Examples: 'HLKM:SOFTWARE\Microsoft\.NETFramework\v2.0.50727:' .NET v2.0, 'HLKM:SOFTWARE\Microsoft\.NETFramework:' any version of .NET, 'HLKM:SOFTWARE\MyCompany\MiProduct:InstallDir' InstallDir value verify - flag (yes/no) indicating if the registry key (/regkey:) should be checked again after running prerequisite. Default: yes. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail > -Original Message- > From: Ken Halprin [mailto:khalp...@autosoln.com] > Sent: Tuesday, March 23, 2010 1:32 PM > To: 'General discussion for Windows Installer XML toolset.' > Subject: Re: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules > in thesame MSI > > What is Wix# and nbsbuilder? Where can I get more information about > them? > > Thanks, > Ken > > > -Original Message- > From: s...@pacaccess.com [mailto:s...@pacaccess.com] > Sent: Tuesday, March 23, 2010 9:55 AM > To: nor...@acm.org; General discussion for Windows Installer XML > toolset. > Subject: Re: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules > in > thesame MSI > > This is a timely thread for me as I have been recently going through > this > myself. In my research I found there are two ways to bundle the VC++ > runtime: > > * With a merge module. This approach is documented > (http://wix.sourceforge.net/manual-wix3/install_vcredist.htm) but has > the > disadvantage of taking A LONG time when uninstalled. On my machine, it > takes 3-4 minutes for them to be uninstalled and unmerged when my > product > is uninstalled. This is not good as it appears to the user as if the > uninstaler has locked up, and can be canceled at any time. A 'fix' I > made > for this approach was to modify the default UI strings and change the > text > which appears in the wizard page to say: > Please wait while the Setup > Wizard > removes [ProductName]. PLEASE > NOTE: > This process takes several minutes - please be patient. > > * With a bootstrapper. If I understand the term correctly, a > bootstrapper > merges two installers into one and runs them sequentially. Along with > WiX > I have been playing with WiX#. Within the WiX# package is an > application > called nbsbuilder.exe which I'm using to bootstrap the vc++ runtime > along > with my installer. For the moment I'm not using WiX# - just > nbsbuilder.exe, and my post-build script is: > > nbsbuilder.exe /out:MyProductSetup.exe /first:vcredist_x86.exe > "/second:MyProductSetup.msi" > /reg:HKLM:SOFTWARE\Classes\Installer\Products\3e43b73803c7c394f8a6b2f04 > 02e19 > c2:DeploymentFlags > /verify:yes > > With the registry key that's there, that's going to be specific to the > version of vcredist_x86 you are installing. I used a registry diff > tool > to see what changes were made to the registry when vcredist_x86 was > installed. > > > For the moment, it looks like the bootstapping approach is better for > me > so I'm going with it. > > Jeff > > > > > > > > I would be interested in whether you are able to *remove* your > ap
Re: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules in thesame MSI
http://www.csscript.net/WixSharp.html As far as info, there is a tutorial on CodeProject on WiX#. Jeff > What is Wix# and nbsbuilder? Where can I get more information about them? > > Thanks, > Ken > > > -Original Message- > From: s...@pacaccess.com [mailto:s...@pacaccess.com] > Sent: Tuesday, March 23, 2010 9:55 AM > To: nor...@acm.org; General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules in > thesame MSI > > This is a timely thread for me as I have been recently going through this > myself. In my research I found there are two ways to bundle the VC++ > runtime: > > * With a merge module. This approach is documented > (http://wix.sourceforge.net/manual-wix3/install_vcredist.htm) but has the > disadvantage of taking A LONG time when uninstalled. On my machine, it > takes 3-4 minutes for them to be uninstalled and unmerged when my product > is uninstalled. This is not good as it appears to the user as if the > uninstaler has locked up, and can be canceled at any time. A 'fix' I made > for this approach was to modify the default UI strings and change the text > which appears in the wizard page to say: > Please wait while the Setup > Wizard > removes [ProductName]. PLEASE NOTE: > This process takes several minutes - please be patient. > > * With a bootstrapper. If I understand the term correctly, a bootstrapper > merges two installers into one and runs them sequentially. Along with WiX > I have been playing with WiX#. Within the WiX# package is an application > called nbsbuilder.exe which I'm using to bootstrap the vc++ runtime along > with my installer. For the moment I'm not using WiX# - just > nbsbuilder.exe, and my post-build script is: > > nbsbuilder.exe /out:MyProductSetup.exe /first:vcredist_x86.exe > "/second:MyProductSetup.msi" > /reg:HKLM:SOFTWARE\Classes\Installer\Products\3e43b73803c7c394f8a6b2f0402e19 > c2:DeploymentFlags > /verify:yes > > With the registry key that's there, that's going to be specific to the > version of vcredist_x86 you are installing. I used a registry diff tool > to see what changes were made to the registry when vcredist_x86 was > installed. > > > For the moment, it looks like the bootstapping approach is better for me > so I'm going with it. > > Jeff > > > > >> >> I would be interested in whether you are able to *remove* your >> application >> after having installed the VC libs via Merge Modules. >> I am seeing the UNinstallation take approximately 5 minutes (while the >> VC >> libs are being removed), with the dialog appearing to be 'hung'. >> Most users will give up and cancel the uninstallation before it >> completes. >> This of course is unacceptable. >> >> -Clift >> >> >> -Original Message- >> From: Pally Sandher [mailto:pally.sand...@iesve.com] >> Sent: Tuesday, March 23, 2010 5:54 AM >> To: ma...@thejunkroom.co.uk; General discussion for Windows Installer >> XML >> toolset. >> Subject: Re: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules >> in >> thesame MSI >> >> You can safely ignore them. They're caused by having either of the VC++ >> runtime merge modules consumed by your MSI. It's not an artifact of >> having both v8.0 & v9.0. >> >> Palbinder Sandher >> Software Deployment & IT Administrator >> >> >> -Original Message- >> From: Mark Simonetti [mailto:ma...@thejunkroom.co.uk] >> Sent: 23 March 2010 09:20 >> To: wix-users@lists.sourceforge.net >> Subject: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules in >> thesame MSI >> >> Hi all, >> I am currently writing an installer that needs to install both Visual >> Studio 2005 AND 2008 C Runtime Libraries. The reason is that some of >> the binaries I have to install (PostgreSQL) are built with Visual Studio >> 2005, and my own binaries are built with Visual Studio 2008. Everything >> must be installed easily with one installer, hence why I am handling the >> PostgreSQL install in my own installer. >> >> The problem is when I try and use the merge modules for both runtime >> libraries, I get the warnings listed at the bottom of this post. >> >> When I run the installer, all seems to go okay so maybe there isn't a >> problem, though the test machine is not currently clean so it might just >> seem okay. I'm going to wipe the test machine and give it another try, >> but either way I thought it prudent to check with others if there could >> be any potential issues, and to see if there is perhaps a better way of >> doing all of this. >> >> I did try just running the setup for the redistributable installs from >> my installer, but then I got errors about not being able to run multiple >> msi installs, etc >> >> Warnings listed below .. thanks! >> >> >> >> > > -- >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> p
Re: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules in thesame MSI
What is Wix# and nbsbuilder? Where can I get more information about them? Thanks, Ken -Original Message- From: s...@pacaccess.com [mailto:s...@pacaccess.com] Sent: Tuesday, March 23, 2010 9:55 AM To: nor...@acm.org; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules in thesame MSI This is a timely thread for me as I have been recently going through this myself. In my research I found there are two ways to bundle the VC++ runtime: * With a merge module. This approach is documented (http://wix.sourceforge.net/manual-wix3/install_vcredist.htm) but has the disadvantage of taking A LONG time when uninstalled. On my machine, it takes 3-4 minutes for them to be uninstalled and unmerged when my product is uninstalled. This is not good as it appears to the user as if the uninstaler has locked up, and can be canceled at any time. A 'fix' I made for this approach was to modify the default UI strings and change the text which appears in the wizard page to say: Please wait while the Setup Wizard removes [ProductName]. PLEASE NOTE: This process takes several minutes - please be patient. * With a bootstrapper. If I understand the term correctly, a bootstrapper merges two installers into one and runs them sequentially. Along with WiX I have been playing with WiX#. Within the WiX# package is an application called nbsbuilder.exe which I'm using to bootstrap the vc++ runtime along with my installer. For the moment I'm not using WiX# - just nbsbuilder.exe, and my post-build script is: nbsbuilder.exe /out:MyProductSetup.exe /first:vcredist_x86.exe "/second:MyProductSetup.msi" /reg:HKLM:SOFTWARE\Classes\Installer\Products\3e43b73803c7c394f8a6b2f0402e19 c2:DeploymentFlags /verify:yes With the registry key that's there, that's going to be specific to the version of vcredist_x86 you are installing. I used a registry diff tool to see what changes were made to the registry when vcredist_x86 was installed. For the moment, it looks like the bootstapping approach is better for me so I'm going with it. Jeff > > I would be interested in whether you are able to *remove* your application > after having installed the VC libs via Merge Modules. > I am seeing the UNinstallation take approximately 5 minutes (while the VC > libs are being removed), with the dialog appearing to be 'hung'. > Most users will give up and cancel the uninstallation before it completes. > This of course is unacceptable. > > -Clift > > > -Original Message- > From: Pally Sandher [mailto:pally.sand...@iesve.com] > Sent: Tuesday, March 23, 2010 5:54 AM > To: ma...@thejunkroom.co.uk; General discussion for Windows Installer XML > toolset. > Subject: Re: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules in > thesame MSI > > You can safely ignore them. They're caused by having either of the VC++ > runtime merge modules consumed by your MSI. It's not an artifact of > having both v8.0 & v9.0. > > Palbinder Sandher > Software Deployment & IT Administrator > > > -Original Message- > From: Mark Simonetti [mailto:ma...@thejunkroom.co.uk] > Sent: 23 March 2010 09:20 > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules in > thesame MSI > > Hi all, > I am currently writing an installer that needs to install both Visual > Studio 2005 AND 2008 C Runtime Libraries. The reason is that some of > the binaries I have to install (PostgreSQL) are built with Visual Studio > 2005, and my own binaries are built with Visual Studio 2008. Everything > must be installed easily with one installer, hence why I am handling the > PostgreSQL install in my own installer. > > The problem is when I try and use the merge modules for both runtime > libraries, I get the warnings listed at the bottom of this post. > > When I run the installer, all seems to go okay so maybe there isn't a > problem, though the test machine is not currently clean so it might just > seem okay. I'm going to wipe the test machine and give it another try, > but either way I thought it prudent to check with others if there could > be any potential issues, and to see if there is perhaps a better way of > doing all of this. > > I did try just running the setup for the redistributable installs from > my installer, but then I got errors about not being able to run multiple > msi installs, etc > > Warnings listed below .. thanks! > > > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.s
[WiX-users] Upgrade Table
Hi, I have read that the Upgrade Table must be populated based on the Server 2008 certification guidelines. My setup msi program is not designed to do upgrades of previous versions. Should I still populate the Upgrade table? If so, what Upgrade code should I use? (Since it is not designed to upgrade anything). Thanks! Uma Harano- -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to handle shared files
It's about file versions, and always has been (with the exception of the GAC sometimes). Higher file versions replace lower. The latest version and the winner is the highest file version. This is a standard Windows Installer thing, no matter what you use to build the MSI file: http://msdn.microsoft.com/en-us/library/aa368599(VS.85).aspx Phil Wilson -Original Message- From: Bill McCormick (LIST) [mailto:wpmccorm...@ace-co.com] Sent: Tuesday, March 23, 2010 8:27 AM To: WiX Subject: [WiX-users] How to handle shared files Hello, What is the best practice for dealing with shared binaries like .NET assemblies or DLL's? If I have some number of VS projects that each output a a COMMON.DLL to their respective bin\Release folder, how can WiX know which COMMON.DLL is the latest version? Does WiX have any features similar to the VS installer, where you can add the output of a project in the solution to the build process? I have already used heat to create wxs files for legacy VB applications. Is heat also the right tool to use for .NET applications as well? If this is all well documented somewhere, please point me in the right direction. If all of this is covered in the tutorial, I seem to have missed it. Thanks, Bill McCormick -- ACE-CO 5355 Dietrich Rd. San Antonio, TX 78219 (210) 661-4111 x512 (800) 676-4111 Toll Free (210) 662-6177 Fax (210) 216-6641 Cell mailto:wpmccorm...@ace-co.com http://www.ace-co.com -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at Portland House, Bressenden Place, London, SW1E 5BF (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77&nav_id=80&prev_id=77. You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail inet.hqhelpd...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to handle shared files
Hello, What is the best practice for dealing with shared binaries like .NET assemblies or DLL's? If I have some number of VS projects that each output a a COMMON.DLL to their respective bin\Release folder, how can WiX know which COMMON.DLL is the latest version? Does WiX have any features similar to the VS installer, where you can add the output of a project in the solution to the build process? I have already used heat to create wxs files for legacy VB applications. Is heat also the right tool to use for .NET applications as well? If this is all well documented somewhere, please point me in the right direction. If all of this is covered in the tutorial, I seem to have missed it. Thanks, Bill McCormick -- ACE-CO 5355 Dietrich Rd. San Antonio, TX 78219 (210) 661-4111 x512 (800) 676-4111 Toll Free (210) 662-6177 Fax (210) 216-6641 Cell mailto:wpmccorm...@ace-co.com http://www.ace-co.com -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing from embedded CAB file and Folder
I'm finding that the Directory/@SourceName property seems to have no effect. If I define my source files in a fragment as follows (using the initial example I gave): The installer still tries to find "doc1.pdf" at the same level as the msi (instead of in the relative DocFiles\ subdir). Is this some kind of bug? sanjay > -Original Message- > From: Bob Arnson [mailto:b...@joyofsetup.com] > Sent: 23 March 2010 02:09 > Subject: Re: [WiX-users] Installing from embedded CAB file and Folder > > On 3/22/2010 6:46 PM, Sanjay Poria wrote: > > The problem is that when I run the installer, it still expects to > find files (doc1, doc2) in the main directory (at the same level as the > msi) instead of the "DocFiles" directory. When building, the installer > actually creates the source structure as above (which made me think > everything was specified ok). > > > > The Layout attribute controls where the files are written, not where > they're installed from. For that, use Directory/@SourceName. See also > the Directory table in the MSI SDK. > > -- > sig://boB > http://joyofsetup.com/ > > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules in thesame MSI
This is a timely thread for me as I have been recently going through this myself. In my research I found there are two ways to bundle the VC++ runtime: * With a merge module. This approach is documented (http://wix.sourceforge.net/manual-wix3/install_vcredist.htm) but has the disadvantage of taking A LONG time when uninstalled. On my machine, it takes 3-4 minutes for them to be uninstalled and unmerged when my product is uninstalled. This is not good as it appears to the user as if the uninstaler has locked up, and can be canceled at any time. A 'fix' I made for this approach was to modify the default UI strings and change the text which appears in the wizard page to say: Please wait while the Setup Wizard removes [ProductName]. PLEASE NOTE: This process takes several minutes - please be patient. * With a bootstrapper. If I understand the term correctly, a bootstrapper merges two installers into one and runs them sequentially. Along with WiX I have been playing with WiX#. Within the WiX# package is an application called nbsbuilder.exe which I'm using to bootstrap the vc++ runtime along with my installer. For the moment I'm not using WiX# - just nbsbuilder.exe, and my post-build script is: nbsbuilder.exe /out:MyProductSetup.exe /first:vcredist_x86.exe "/second:MyProductSetup.msi" /reg:HKLM:SOFTWARE\Classes\Installer\Products\3e43b73803c7c394f8a6b2f0402e19c2:DeploymentFlags /verify:yes With the registry key that's there, that's going to be specific to the version of vcredist_x86 you are installing. I used a registry diff tool to see what changes were made to the registry when vcredist_x86 was installed. For the moment, it looks like the bootstapping approach is better for me so I'm going with it. Jeff > > I would be interested in whether you are able to *remove* your application > after having installed the VC libs via Merge Modules. > I am seeing the UNinstallation take approximately 5 minutes (while the VC > libs are being removed), with the dialog appearing to be 'hung'. > Most users will give up and cancel the uninstallation before it completes. > This of course is unacceptable. > > -Clift > > > -Original Message- > From: Pally Sandher [mailto:pally.sand...@iesve.com] > Sent: Tuesday, March 23, 2010 5:54 AM > To: ma...@thejunkroom.co.uk; General discussion for Windows Installer XML > toolset. > Subject: Re: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules in > thesame MSI > > You can safely ignore them. They're caused by having either of the VC++ > runtime merge modules consumed by your MSI. It's not an artifact of > having both v8.0 & v9.0. > > Palbinder Sandher > Software Deployment & IT Administrator > > > -Original Message- > From: Mark Simonetti [mailto:ma...@thejunkroom.co.uk] > Sent: 23 March 2010 09:20 > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules in > thesame MSI > > Hi all, > I am currently writing an installer that needs to install both Visual > Studio 2005 AND 2008 C Runtime Libraries. The reason is that some of > the binaries I have to install (PostgreSQL) are built with Visual Studio > 2005, and my own binaries are built with Visual Studio 2008. Everything > must be installed easily with one installer, hence why I am handling the > PostgreSQL install in my own installer. > > The problem is when I try and use the merge modules for both runtime > libraries, I get the warnings listed at the bottom of this post. > > When I run the installer, all seems to go okay so maybe there isn't a > problem, though the test machine is not currently clean so it might just > seem okay. I'm going to wipe the test machine and give it another try, > but either way I thought it prudent to check with others if there could > be any potential issues, and to see if there is perhaps a better way of > doing all of this. > > I did try just running the setup for the redistributable installs from > my installer, but then I got errors about not being able to run multiple > msi installs, etc > > Warnings listed below .. thanks! > > > > -- > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/s
Re: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules in thesame MSI
I would be interested in whether you are able to *remove* your application after having installed the VC libs via Merge Modules. I am seeing the UNinstallation take approximately 5 minutes (while the VC libs are being removed), with the dialog appearing to be 'hung'. Most users will give up and cancel the uninstallation before it completes. This of course is unacceptable. -Clift -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Tuesday, March 23, 2010 5:54 AM To: ma...@thejunkroom.co.uk; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules in thesame MSI You can safely ignore them. They're caused by having either of the VC++ runtime merge modules consumed by your MSI. It's not an artifact of having both v8.0 & v9.0. Palbinder Sandher Software Deployment & IT Administrator -Original Message- From: Mark Simonetti [mailto:ma...@thejunkroom.co.uk] Sent: 23 March 2010 09:20 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules in thesame MSI Hi all, I am currently writing an installer that needs to install both Visual Studio 2005 AND 2008 C Runtime Libraries. The reason is that some of the binaries I have to install (PostgreSQL) are built with Visual Studio 2005, and my own binaries are built with Visual Studio 2008. Everything must be installed easily with one installer, hence why I am handling the PostgreSQL install in my own installer. The problem is when I try and use the merge modules for both runtime libraries, I get the warnings listed at the bottom of this post. When I run the installer, all seems to go okay so maybe there isn't a problem, though the test machine is not currently clean so it might just seem okay. I'm going to wipe the test machine and give it another try, but either way I thought it prudent to check with others if there could be any potential issues, and to see if there is perhaps a better way of doing all of this. I did try just running the setup for the redistributable installs from my installer, but then I got errors about not being able to run multiple msi installs, etc Warnings listed below .. thanks! -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] uninstall sequence
Any file you put on the machine during install will be removed during uninstall unless you specifically say not to. Same goes for any directories created during install as long as they are empty when msiexec tries to remove them. If your application has created any logs or configs in those directories when it was run you'll need to write RemoveFile Elements for those if you want to delete them during uninstall. You shouldn't need to write any RemoveFolder Elements unless your application creates new directories when it's run (special exception is shortcut folders but the how to topic in the WiX documentation covers that). RemoveFolder will only remove empty directories. Palbinder Sandher Software Deployment & 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: shabbir [mailto:shabbir_ah...@hotmail.com] Sent: 23 March 2010 11:43 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] uninstall sequence Thanks Pally and Phil. I have marked the service as stop at uninstall and the remove file is now after the stop service. I ahve put remove folders commands in place - would this automatically delete the files within the folder or would I ahve to put remove file for each file contained within it? Thanks -- View this message in context: http://n2.nabble.com/uninstall-sequence-tp4778623p4783422.html Sent from the wix-users mailing list archive at Nabble.com. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] installing on windows server 2008 -BUMP-
thanks Pally -the condition worked perfectly! -- View this message in context: http://n2.nabble.com/Re-installing-on-windows-server-2008-BUMP-tp4777496p4783442.html Sent from the wix-users mailing list archive at Nabble.com. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] install SQL server with mixed mode authentication
Thanks Asiri. yup did that. need the following arguments: SECURITYMODE=SQL SAPWD= -- View this message in context: http://n2.nabble.com/install-SQL-server-with-mixed-mode-authentication-tp4757132p4783438.html Sent from the wix-users mailing list archive at Nabble.com. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] uninstall sequence
Thanks Pally and Phil. I have marked the service as stop at uninstall and the remove file is now after the stop service. I ahve put remove folders commands in place - would this automatically delete the files within the folder or would I ahve to put remove file for each file contained within it? Thanks -- View this message in context: http://n2.nabble.com/uninstall-sequence-tp4778623p4783422.html Sent from the wix-users mailing list archive at Nabble.com. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules in thesame MSI
You can safely ignore them. They're caused by having either of the VC++ runtime merge modules consumed by your MSI. It's not an artifact of having both v8.0 & v9.0. Palbinder Sandher Software Deployment & 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: Mark Simonetti [mailto:ma...@thejunkroom.co.uk] Sent: 23 March 2010 09:20 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules in thesame MSI Hi all, I am currently writing an installer that needs to install both Visual Studio 2005 AND 2008 C Runtime Libraries. The reason is that some of the binaries I have to install (PostgreSQL) are built with Visual Studio 2005, and my own binaries are built with Visual Studio 2008. Everything must be installed easily with one installer, hence why I am handling the PostgreSQL install in my own installer. The problem is when I try and use the merge modules for both runtime libraries, I get the warnings listed at the bottom of this post. When I run the installer, all seems to go okay so maybe there isn't a problem, though the test machine is not currently clean so it might just seem okay. I'm going to wipe the test machine and give it another try, but either way I thought it prudent to check with others if there could be any potential issues, and to see if there is perhaps a better way of doing all of this. I did try just running the setup for the redistributable installs from my installer, but then I got errors about not being able to run multiple msi installs, etc Warnings listed below .. thanks! 2>V:\opal\clients\monika\project\installer\Product.wxs(119,0): warning LGHT1055: The InstallExecuteSequence table contains an action 'SxsInstallCA' which cannot be merged from the merge module 'files\runtime80\policy_8_0_Microsoft_VC80_CRT_x86.msm'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. If this is a standard action, it is likely colliding due to a difference in the condition for the action in the database and merge module. If this is a custom action, it should only be declared in the database or one merge module. 2>V:\opal\clients\monika\project\installer\Product.wxs(119,0): warning LGHT1055: The InstallExecuteSequence table contains an action 'SxsUninstallCA' which cannot be merged from the merge module 'files\runtime80\policy_8_0_Microsoft_VC80_CRT_x86.msm'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. If this is a standard action, it is likely colliding due to a difference in the condition for the action in the database and merge module. If this is a custom action, it should only be declared in the database or one merge module. 2>V:\opal\clients\monika\project\installer\Product.wxs(120,0): warning LGHT1055: The InstallExecuteSequence table contains an action 'AllocateRegistrySpace' which cannot be merged from the merge module 'files\runtime90\Microsoft_VC90_CRT_x86.msm'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. If this is a standard action, it is likely colliding due to a difference in the condition for the action in the database and merge module. If this is a custom action, it should only be declared in the database or one merge module. 2>V:\opal\clients\monika\project\installer\Product.wxs(120,0): warning LGHT1055: The InstallExecuteSequence table contains an action 'SxsInstallCA' which cannot be merged from the merge module 'files\runtime90\Microsoft_VC90_CRT_x86.msm'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. If this is a standard action, it is likely colliding due to a difference in the condition for the action in the database and merge module. If this is a custom action, it should only be declared in the database or one merge module. 2>V:\opal\clients\monika\project\installer\Product.wxs(120,0): warning LGHT1055: The InstallExecuteSequence table contains an action 'SxsUninstallCA' which cannot be merged from the merge module 'files\runtime90\Microsoft_VC90_CRT_x86.msm'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. If this is a standar
[WiX-users] Wix 3.0 improvements
Hi all, I was going through the improvements that have been made in Wix 3.0. I want further information about some of them like: 1. Support for all MSI 4.0 features where can I find the list of new MSI 4.0 features and how they are supported in Wix 3.0. 2. Standard UI support, what are the improvements that have gone in the new Wix 3.0 related to better UI. Thanks, Nutesh -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Using Microsoft CRT 8.0 and 9.0 merge modules in the same MSI
Hi all, I am currently writing an installer that needs to install both Visual Studio 2005 AND 2008 C Runtime Libraries. The reason is that some of the binaries I have to install (PostgreSQL) are built with Visual Studio 2005, and my own binaries are built with Visual Studio 2008. Everything must be installed easily with one installer, hence why I am handling the PostgreSQL install in my own installer. The problem is when I try and use the merge modules for both runtime libraries, I get the warnings listed at the bottom of this post. When I run the installer, all seems to go okay so maybe there isn't a problem, though the test machine is not currently clean so it might just seem okay. I'm going to wipe the test machine and give it another try, but either way I thought it prudent to check with others if there could be any potential issues, and to see if there is perhaps a better way of doing all of this. I did try just running the setup for the redistributable installs from my installer, but then I got errors about not being able to run multiple msi installs, etc Warnings listed below .. thanks! 2>V:\opal\clients\monika\project\installer\Product.wxs(119,0): warning LGHT1055: The InstallExecuteSequence table contains an action 'SxsInstallCA' which cannot be merged from the merge module 'files\runtime80\policy_8_0_Microsoft_VC80_CRT_x86.msm'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. If this is a standard action, it is likely colliding due to a difference in the condition for the action in the database and merge module. If this is a custom action, it should only be declared in the database or one merge module. 2>V:\opal\clients\monika\project\installer\Product.wxs(119,0): warning LGHT1055: The InstallExecuteSequence table contains an action 'SxsUninstallCA' which cannot be merged from the merge module 'files\runtime80\policy_8_0_Microsoft_VC80_CRT_x86.msm'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. If this is a standard action, it is likely colliding due to a difference in the condition for the action in the database and merge module. If this is a custom action, it should only be declared in the database or one merge module. 2>V:\opal\clients\monika\project\installer\Product.wxs(120,0): warning LGHT1055: The InstallExecuteSequence table contains an action 'AllocateRegistrySpace' which cannot be merged from the merge module 'files\runtime90\Microsoft_VC90_CRT_x86.msm'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. If this is a standard action, it is likely colliding due to a difference in the condition for the action in the database and merge module. If this is a custom action, it should only be declared in the database or one merge module. 2>V:\opal\clients\monika\project\installer\Product.wxs(120,0): warning LGHT1055: The InstallExecuteSequence table contains an action 'SxsInstallCA' which cannot be merged from the merge module 'files\runtime90\Microsoft_VC90_CRT_x86.msm'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. If this is a standard action, it is likely colliding due to a difference in the condition for the action in the database and merge module. If this is a custom action, it should only be declared in the database or one merge module. 2>V:\opal\clients\monika\project\installer\Product.wxs(120,0): warning LGHT1055: The InstallExecuteSequence table contains an action 'SxsUninstallCA' which cannot be merged from the merge module 'files\runtime90\Microsoft_VC90_CRT_x86.msm'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. If this is a standard action, it is likely colliding due to a difference in the condition for the action in the database and merge module. If this is a custom action, it should only be declared in the database or one merge module. 2>V:\opal\clients\monika\project\installer\Product.wxs(121,0): warning LGHT1055: The InstallExecuteSequence table contains an action 'AllocateRegistrySpace' which cannot be merged from the merge module 'files\runtime90\policy_9_0_Microsoft_VC90_CRT_x86.msm'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. If this is a standard action,
Re: [WiX-users] Votive - MergeModule dependency
Ah! I think now I got it. I have to add the Merge / MergeRef tags in the app / setup file; right !? -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Dienstag, 23. März 2010 03:07 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Votive - MergeModule dependency On 3/22/2010 11:32 AM, Johann Taferl, T-AU wrote: > Yes, but in merge modules them self, I can't referece through Merge or > MergeRef: > Correct, it must be authored in the product. Like I said, WiX doesn't automatically try to find dependent merge modules. -- sig://boB http://joyofsetup.com/ -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
