Re: [WiX-users] Generate MSI during install
To expand on some of the earlier suggestions, I would offer the following:
* As suggested earlier, create two WiX projects--one for the server and one
for the client.
* Create the client so that all options (or at least a many as possible)
will be used as properties. To get the client WiX project to compile, you
may need to define default properties and values in your WiX source files.
* As was also suggested, take a look at the Windows Installer SDK.
Specifically, I would take a look at the "%ProgramFiles%\Microsoft
SDKs\Windows\v6.1\Samples\SysMgmt\Msi\scripts" directory if you have the
lastest Windows SDK installed. In this folder, you will find a number of
"Wi" prefixed VBScript files for interacting with Windows Installer. Of
particular interest might be WiRunSQL.vbs. There are a few caveats, but you
can essentially perform basic queries against an MSI file. If you have
defined all your configurable options as properties, you can simply UPDATE
the Properties table with the custom values. If you adapt the WiRunSQL
vbScript file and embed it in the MSI to use as a VBScript CustomAction, you
can use Session.Property("PropertyName") to set and/or retrieve property
values from the currently-running setup process. Feed those values to your
MSI queries, and you should be able to update the client MSI file.
* There are some quirks in VBScript while running under Windows Installer.
For example, from my experience, timed dialog boxes always seem to spike the
CPU and then just hang. So, just forewarning you that a VBScript that
behaves one way as a standalone script might behave differently under
Windows Installer.
* Install Orca.msi from the "%ProgramFiles%\Microsoft
SDKs\Windows\v6.1\bin" directory if you have not done so already. This will
allow you to view the MSI "database" structure and view/edit table contents,
which can be helpful in verifying that an MSI file was configured correctly.
Though your desired process is a little different, I am essentially doing
other steps similar to those describe above to achieve a similar result.
Hope this helps,
Matthew
Phil Sayers wrote:
>
> I'd love to be able to "touch" or "generate" the client MSI as part of the
> server installation, based on information entered by a network admin as
> part of the server MSI install.
>
> This way the client side of the application would already have server
> name, ip address, remoting endpoints written into it's config file and the
> end user woudln't need to enter that info as part of the client install.
>
--
View this message in context:
http://www.nabble.com/Generate-MSI-during-install-tp17275539p17283646.html
Sent from the wix-users mailing list archive at Nabble.com.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Using Web Deployment Projects as Project References in WiX Visual Studio Projects
In the "Add Reference" dialog for a WiX project in Visual Studio, Web Deployment Projects (*.wdproj) are not included in the list of projects that can be selected as project references. If I manually add a project reference (i.e. open the WiX project file in a text editor and enter the project name, path, and GUID), I receive an error message upon building stating "The target 'GetTargetPath' does not exist in the project". I can add a target to the Web Deployment Project as follows (based on how other Microsoft targets files appear), though, to eliminate the error message: I'm not sure if that is an appropriate solution, though. How should the "GetTargetPath" issue be addressed? Would it be something on the WiX side or the Web Deployment Project side? http://blogs.msdn.com/webdevtools/archive/2008/01/25/announcing-rtw-of-visual-studio-2008-web-deployment-projects-wdp.aspx Link to Web Deployment Projects Thank you, Matthew -- View this message in context: http://www.nabble.com/Using-Web-Deployment-Projects-as-Project-References-in-WiX-Visual-Studio-Projects-tp15816501p15816501.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Performing a Major Upgrade when only the Fourth Field of the Product Version Has Changed
Using WiX v3, I would like to * Create a "major" upgrade installer, even when only the fourth field of the Product Version has changed * Skip installation if a newer version is installed (again, even if only the fourth field of the Product Version has changed) For example, if the new Product Version is 2.3.4.5, I need to create a single MSI file that can do any of the following: oPerform an "clean" install oUpgrade older versions (e.g. 1.5.2.1, 2.0.0.5, and 2.3.4.2) oAbort installation if a newer version is already installed (e.g. 2.3.4.9) For each new version, the values of following properties are changed: * Product Code GUID * Package Code GUID * Product Version Number The Upgrade Code GUID, all Component GUIDS, and ALLUSERS=1 remain unchanged from version to version. I know that according to the MSI documentation, "Windows Installer only uses the first three fields of the product version. If you include a fourth field in your product version, the installer ignores the fourth field" [ http://msdn2.microsoft.com/en-us/library/aa370859(VS.85).aspx ]. However, an earlier WiX post from 9/12/2006 seems to indicate that even if only the fourth field has changed, some form of a Major Upgrade is still possible. MSI ignores the fourth field in ProductVersion so it doesn't differentiate among ProductVersions that differ only in the fourth field. So if you set UpgradeVersion elements to detect when the "same" version is installed, it will treat all 1.0.0.x versions as the same. You can do "blind" major upgrades so any version is installed (or any version greater-than-or-equal-to), which would let you increment just the fourth field. -- sig://boB [ http://www.nabble.com/Re%3A-Several-doubts-on-Upgrades-p6272185.html ] I am unclear on what is meant by a "blind" major upgrade. In the InstallExecuteSequence, I have the entry If I do not include an section, the following things seem to hold true: * Both older and newer versions can install * Both the old and new versions are listed in Add/Remove Programs * Rerunning the installer after that version has been installed appears to shortcut the installation If I do include an section, the following things seem to hold true: * A newer version will uninstall the older version IF any of the first three version parts have changed * Only the most recently installed version is listed in Add/Remove Programs (good) * If only the fourth version part has changed, the executing MSI will "upgrade" the current installation, even if the Product Version of the executing MSI is less than the currently installed version (bad) * Rerunning the installer after that version has been installed appears to shortcut the installation Is it possible to obtain the desired behavior? I appreciate any suggestions or information. Thank you, Matthew - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Setting Directories Based on Property Values (WiX 3.0.2925.0)
I would like to assign a directory name based on the value of a property. According to the wix-user group message http://sourceforge.net/mailarchive/message.php?msg_id=457FBE32.5050704%4 0bobs.org, "the general approach is to make the directory ID the same as the property name." That approach works fine for the property [ProgramFilesFolder], such as used below. It installs to C:\Program Files\Acme Tooling\Tools, which is what I would expect. Unfortunately, this static approach will not work for me, as the requirements dictate a more dynamic approach, such as changing the value of the property [Environment]. So, the next revision was as follows: test . . . That failed with errors in light, as [Manufacturer] and [ProductName] are also MSI Public Properties and can cause unforeseen side effects. OK, so I'll use a custom action and just copy those property values over to a different property. test . . . . . . So, that gets me by the light error. When installing the MSI, though, I shortly receive the error "Could not access network location Acme Tools" ([Manufacturer] = "Acme Tooling"). (Side Note: if [Manufacturer] is an 8.3-compliant name [e.g. "Acme"], the MSI will hang for 40 - 60 seconds before failing with a similar error message: "Could not access network location Acme.") I'm not sure how to get around this "Could not access network location" error. At the time of the error, the log is as follows: MSI (s) (2C:F0) [12:26:48:236]: Note: 1: 2205 2: 3: Patch MSI (s) (2C:F0) [12:26:48:236]: Note: 1: 2205 2: 3: Condition MSI (s) (2C:F0) [12:26:48:236]: Note: 1: 1314 2: Acme Tooling MSI (s) (2C:F0) [12:26:48:236]: Note: 1: 1606 2: Acme Tooling MSI (c) (0C:D8) [12:26:48:252]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg MSI (s) (2C:F0) [12:26:52:689]: Product: Tools -- Error 1606. Could not access network location Acme Tooling. MSI (s) (2C:F0) [12:26:52:705]: Note: 1: 1606 2: Acme Tooling MSI (c) (0C:D8) [12:26:52:705]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg MSI (s) (2C:F0) [12:27:30:423]: Product: Tools -- Error 1606. Could not access network location Acme Tooling. Again, the properties need to support values declared or assigned at install time, so the preprocessor-based workarounds described in other posts won't work under this scenario. Even [PropertyName] needs to be easily changeable. If necessary, I think I could even swing utilizing a bootstrapper (such as dotNetInstaller) and/or WiRunSQL.vbs to make the necessary property changes. A second issue is how to get the path of a parent directory from a folder path that exists in the registry. Examples I saw in other WiX-users posts seemed to deal with finding the parent directory of a specific file; in this case, I want the parent directory of a folder. For instance, if a third-party program is installed to D:\Applications\UtilityApp, I need to default the installation to install under D:\Applications (and, yes, the case of installation to the root of a drive is covered). I can pull the directory path (e.g. "D:\Applications\UtilityApp") from the registry, but I'm not sure how to derive the parent directory. I tried adding a child Directory element with a name of ".."; however, that was disallowed as an invalid name. I then tried changing the path D:\Applications\UtilityApp\ to D:\Applications\UtilityApp\..\ (via custom actions); however, that failed during install with an error message, "the folder path '..' contains an invalid character." Apart from these issues, I think I have the other multi-instance items addressed. I would appreciate any insight. Thank you, Matthew - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with ConfigureIIs
I experienced a similar issue, but based on what I found, I think the problem is with the use of the iis:WebAddress element. From the XML listed below, in the second iis:WebDirProperties block (Id="SecureTESTDirProperties") is an iis:WebSite block, and then under that is only one iis:WebAddress element, which has its Secure attribute set to yes. In the Microsoft IIS Manager GUI, you cannot define a secure port without also defining a non-secure (TCP) port, even if you are not going to use the non-secure port. I thought I would see if WiX would let me get around having to declare an unused non-secure, but I received a leak error. After declaring a second iis:WebAddress with a non-secure port, the problem went away. I don't think this is a problem with the IIS code, per se. A simple fix is to update the documentation to state that if a secure iis:WebAddress is defined, a non-secure iis:WebAddress must also be defined. An integrity-checked fix might be to change the iis:WebAddress as follows: 1) Keep the Port attribute required, but redefine it to be the non-secure (TCP) port 2) Remove the Secure yes/no attribute 3) Add an optional SecurePort attribute, which will set the secure port (if present) Of course, others may have alternate ideas, but I think this is consistent with the constraints that are enforced in the Microsoft IIS Manager GUI. Thank you, Matthew Rob Mensching-2 wrote: > > That means the custom action crashed. First thing is to do is try the > latest WiX build. There have been tiny surgical fixes to take care of a > couple crashes in the last few months. Your issue may be fixed. If not, > then I would encourage you to build a debug version of the custom actions, > drop a debugger on the install, and see if you can capture a callstack of > the failure. A bug with that callstack will go a long way to helping us > get rid of every bug in the custom actions. > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Shurts > Sent: Tuesday, August 14, 2007 10:11 AM > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Problem with ConfigureIIs > > I am getting a leaked MSI handle error. Everything was working fine until > I added an additional website component for SSL. Here is a snippet of the > installer. > Microsoft (R) Windows Installer Xml Compiler version 3.0.2925.0 -- btw > Id="TESTDirProperties" > AnonymousAccess="no" > BasicAuthentication="yes" > DefaultDocuments="Default.asp,Default.htm,Default.aspx " > Read="yes" > Index="yes" > Write="no" > Execute="no" > Script="yes" > WindowsAuthentication="no" /> >Id="TESTWebApplication" > Name="TEST" > AllowSessions="yes" > SessionTimeout="20" > Buffer="yes" > DefaultScript="VBScript" > ScriptTimeout="90" /> >Id="TESTWSApplication" > Name="TESTWS" > AllowSessions="yes" > DefaultScript="VBScript" > ScriptTimeout="90" > SessionTimeout="20" /> >Id="TEST_UtilsApplication" > Name="TEST_Utils" > AllowSessions="yes" > DefaultScript="VBScript" > ScriptTimeout="90" > SessionTimeout="20" /> > > Guid="9a752184-1828-4ebc-a882-406ec659b2fd" KeyPath="yes"> >ConfigureIfExists="no" > Directory="WEBROOT" > Sequence="1" > Description="TEST" > ConnectionTimeout="300" > AutoStart="yes" > StartOnInstall="yes" > WebApplication="TESTWebApplication" > DirProperties="TESTDirProperties"> > > Id="TESTWSvDir" > Directory="TESTWS" > WebApplication="TESTWSApplication" > DirProperties="TESTDirProperties" > Alias="TESTWS" /> >Id="TEST_UtilsvDir" > Directory="TEST_UTILS" > WebApplication="TEST_UtilsApplication" > DirProperties="TESTDirProperties" > Alias="TEST_Utils"> > Id="SharedControlsvDir" > Directory="SHARED" > DirProperties="TESTDirProperties" > Alias="SharedControls" /> > > > > > >Id="SecureTESTDirProperties" > AnonymousAccess="no" > AccessSSL="yes" > AccessSSLNegotiateCert="yes" > BasicAuthentication="yes" > DefaultDocuments="Default.asp,Default.htm,Default.aspx" > Read="yes" > Index="yes" > Write="no" > Execute="no" > Script="yes" > WindowsAuthentication="no" /> > Guid="a04ad24b-fcc2-483a-9830-e3307a693311" KeyPath="yes"> >ConfigureIfExists="no" > Directory="WEBROOT" > Sequence="1" > Description="TEST" > ConnectionTimeout="300" > AutoStart="yes" > StartOnInstall="yes" > WebApplication="TESTWebApplication" > DirProperties="SecureTESTDirProperties"> > Secure="yes" /> > Id="SslTESTWSvDir" > Directory="TESTWS" > WebApplica
Re: [WiX-users] prerequisites .net , sqlce etc
I would suggest considering http://www.devage.com/Wiki/ViewArticle.aspx?name=dotnetinstaller&version=0 dotNetInstaller . In addition to supporting prerequisite installations of the .NET Framework, it also supports installing other prerequisites such as SQL Express. There is also a GUI to help with creating the bootstrapper configuration. Additionally, the source code is available for download. Hope this helps. Thanks, Matthew Glen Harvy wrote: > > Hi, > > Where can I find some information of having a WiX project check for > prerequisites like .Net2 and SQL Compact Edition and download them from > MS and install them if not already on on a users machine. > > Thanks, > > Glen. > -- View this message in context: http://www.nabble.com/prerequisites-.net-%2C-sqlce-etc-tf4435638.html#a12659909 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Performing both New Installs and Upgrades with a Common MSI
Thank you for the reply. I have removed the OnlyDetect attribute from the UpgradeVersion element. When moving from one version to the next, I perform the following changes: * Product Version number * Product GUID * Package GUID All other GUID's remain unchanged. Based on http://support.microsoft.com/kb/870714, I made the "later" scheduling of RemoveExistingProducts be after InstallFinalize in the InstallExecuteSequence. According to http://msdn2.microsoft.com/en-us/library/aa372038.aspx, InstallFinalize appears by default to be the last action in the InstallExecuteSequence. After implementing those described changes, the generated MSI can both upgrade an existing installation (while preserving existing data and not firing the uninstall actions) as well as load a new install; however, multiple entries are still generated in Add or Remove Programs. I have attached the updated wxs file. Have I missed something, or is there a better time to schedule the RemoveExistingProducts action? Thank you, Matthew From: Bob Arnson Sent: Wednesday, August 15, 2007 2:01 AM Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Performing both New Installs and Upgrades with a Common MSI Matthew Sheets wrote: Major Upgrade Advantages * Can set the UpgradeVersion OnlyDetect attribute to prevent a clearing out of data during an upgrade uninstall/reinstall Issues * Creates multiple entries under Add or Remove Programs If you use OnlyDetect, you're not creating a major upgrade; that's why you have multiple entries in ARP. As the name implies, OnlyDetect doesn't remove the previous version. If you keep your component GUIDs stable and schedule RemoveExistingProducts late, then MSI won't uninstall the component and the WiX custom actions won't trigger uninstall behavior. -- sig://boB http://joyofsetup.com/ ManagedCASample.wxs Description: ManagedCASample.wxs - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Performing both New Installs and Upgrades with a Common MSI
Hello, WiX 2.0 is being considered for use in a project since it is stable and essentially final (escrow). The target systems are Windows XP and Windows 2003. The objectives for setup are as follows, but there have been issues attempting to meet these: * Single setup MSI that will dynamically handle both new installs and upgrades * Ability to perform configuration on new install (e.g. SQL Server, IIS, Permissions) * Ability to persist configuration when upgrading (e.g. database) * Ability to perform cleanup on uninstall (e.g. drop database, force deletion of installation directory [even if new files/folders have been added], remove virtual IIS sites/applications) Background Various searches have been done related to these issues. Some of the more informative web pages found include the following: * http://support.microsoft.com/kb/555184 * http://www.tramontana.co.hu/wix/lesson4.php * http://sourceforge.net/mailarchive/message.php?msg_id=a2e077d70604031123 w3ee591c7ma684a8449b0a2ddb%40mail.gmail.com (appears very similar to my issue, but doesn't seem to solve this particular case) * http://blog.opennetcf.org/ncowburn/2005/01/04/UsingCustomActionsWithWiX. aspx Methods Attempted Custom Actions Advantages * Can detect in code whether each install, commit, rollback, and uninstall action is occurring as part of a new install, reinstall, upgrade, or removal. Disadvantages * Have to write code (sometimes a lot) for what would otherwise be simple WiX elements (e.g. database, IIS, permissions, etc.) Issues * There is a major custom actions bug-during an upgrade, old actions are executed instead of the new ones. This has been replicated with both Visual Studio 2005's default installer AND WiX. See Microsoft KB at http://support.microsoft.com/kb/555184 (note that no resolution is provided). Minor Upgrade Issues * Have not found a way for the same MSI to handle both new installs and upgrades * Property arguments have to be provided on the command line when the upgrade is minor, but REINSTALL and REINSTALLMODE cannot be present when it is a new install. Major Upgrade Advantages * Can set the UpgradeVersion OnlyDetect attribute to prevent a clearing out of data during an upgrade uninstall/reinstall Issues * Creates multiple entries under Add or Remove Programs To try to get started, I have been building off a sample WiX project available for download from http://blog.opennetcf.org/ncowburn/2005/01/04/UsingCustomActionsWithWiX. aspx. I have attached the .wxs file with which I have been working. Given the stated objectives, is it possible to generate such an MSI with WiX? If there were a way to prevent the duplicate Add or Remove Programs entries, the Major Upgrade method using OnlyDetect might work. I would appreciate any insight or pointers. Thank you, Matthew ManagedCASample.wxs Description: ManagedCASample.wxs - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
