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: Target Name=GetTargetPath Outputs=$(TargetPath) / 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
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 iis:WebDirProperties 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 / iis:WebApplication Id=TESTWebApplication Name=TEST AllowSessions=yes SessionTimeout=20 Buffer=yes DefaultScript=VBScript ScriptTimeout=90 / iis:WebApplication Id=TESTWSApplication Name=TESTWS AllowSessions=yes DefaultScript=VBScript ScriptTimeout=90 SessionTimeout=20 / iis:WebApplication Id=TEST_UtilsApplication Name=TEST_Utils AllowSessions=yes DefaultScript=VBScript ScriptTimeout=90 SessionTimeout=20 / DirectoryRef Id=WEBROOT Component Id=CreateServerWebsite Guid=9a752184-1828-4ebc-a882-406ec659b2fd KeyPath=yes iis:WebSite Id=TESTWebsite ConfigureIfExists=no Directory=WEBROOT Sequence=1 Description=TEST ConnectionTimeout=300 AutoStart=yes StartOnInstall=yes WebApplication=TESTWebApplication DirProperties=TESTDirProperties iis:WebAddress Id=TESTWebAddress Port=[IISPORT] / iis:WebVirtualDir Id=TESTWSvDir Directory=TESTWS WebApplication=TESTWSApplication DirProperties=TESTDirProperties Alias=TESTWS / iis:WebVirtualDir Id=TEST_UtilsvDir Directory=TEST_UTILS WebApplication=TEST_UtilsApplication DirProperties=TESTDirProperties Alias=TEST_Utils iis:WebVirtualDir Id=SharedControlsvDir Directory=SHARED DirProperties=TESTDirProperties Alias=SharedControls / /iis:WebVirtualDir /iis:WebSite Condition![CDATA[USESSL 1]]/Condition /Component iis:WebDirProperties 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 / Component Id=CreateSecureWebsite Guid=a04ad24b-fcc2-483a-9830-e3307a693311 KeyPath=yes iis:WebSite Id=SecureTESTWebsite ConfigureIfExists=no Directory=WEBROOT Sequence=1 Description=TEST ConnectionTimeout=300 AutoStart=yes StartOnInstall=yes WebApplication=TESTWebApplication
[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. Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=dirManufacturer Name=Acme Tooling Directory Id=dirProductName Name=Tools Directory Id=dirEnvironment Name=test 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: Property Id=Environmenttest/Property . . . Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=Manufacturer Directory Id=ProductName Directory Id=Environment 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. Property Id=Environmenttest/Property . . . CustomAction Id=SetAppManufacturer Property=AppManufacturer Value=[Manufacturer] / CustomAction Id=SetAppProductName Property=AppProductName Value=[ProductName] / . . . Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=AppManufacturer Directory Id=AppProductName Directory Id=Environment 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] prerequisites .net , sqlce etc
I would suggest considering http://www.devage.com/Wiki/ViewArticle.aspx?name=dotnetinstallerversion=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
