[WiX-users] Question: Migrating Existing Installer to Windows Installer
Hello, Ive spent the last two days getting familiar with WiX, the windows installer, and going through the great tutorial on WiX (http://www.tramontana.co.hu/wix/). I especially liked the article posted a year ago (http://msdn.microsoft.com/smartclient/default.aspx?pull=/library/en-us/dnwingen/html/wixsetup.asp) that talks about doing the installer during the development cycle and not at the end of it. We are badly in need of doing this. I have a question however. How do we migrate from our current installer to the Windows Installer for existing customers? We just released version 5.0 of our product. Spending 6 weeks updating our installer (we have a custom C# installer). I can see our new customers instead using a new .msi for later versions (5.5, 6.0, etc). What do I do about our existing customers when they wish to upgrade? Theyve never installed originally with a Windows Installer. How do I get them on the same track? Thanks for any advice, Rick Glos - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Difx, Authenticode and Driver Signing
To be perfectly clear, you are trying to bypass a feature that was put in place to protect users. I don't work with drivers and don't really know a whole lot about them, in general, but I don't think you'll get a lot of support trying to hack around the protection. The whole thing sounds pretty sketchy to me. What product are you shipping? It really doesn't sound like something I want to install on my machine or have my Mom install. - From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shmarya Rubenstein Sent: Thursday, July 27, 2006 1:59 AM To: Stefan Pavlik Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Difx, Authenticode and Driver Signing Unfortunately, WHQL signing is not an option I know its not a good practice, but if there's any way to do it... :) - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [WiX-devs] GAC and call Custom Action
Yeah, that scenario just doesnt work right. The problem is that Assemblies going to the GAC arent committed until the very end of the install. That means your InstallUtil calls (assuming InstallUtil can reach into the GAC, Ive never tried) have to come after InstallFinalize. That means that your InstallUtil CustomActions cant be part of the installation transaction so when they fail, the install succeeds but is broken. This is just one more example of why using InstallUtil is a bad thing. My suggestion (which is rarely popular smile/) is to just do the right thing the first time and save yourself the time you'll spend later trying to manage the InstallUtil hack. What is the CustomAction you're trying to do anyway? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hidey Sent: Wednesday, July 26, 2006 1:36 PM To: wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.net Subject: [WiX-devs] GAC and call Custom Action Here is my problem everyone. I have a msi that installs several files into the gac. I DO NOT create a shadow copy of these files on the file system until my property called CREATESHADOW has a value of 1. These assemblies have installers in them that I need to call. (I know managed installers in not recommended but have to get done quickly) When I put my custom action in and call InstallUtilLib the file isnt actually on the file system. Is there a way to have InstallUtilLib refer the file via its temporary location that is used by the installer? Thoughts? Thanks everyone in advance. John - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Fwd: FW: [WiX-devs] GAC and call Custom Action
Rob,We're having issues with our mail server at work here so I don't know if you received this or not so I'm going to send to you again. I moved my email off my work account and only my personal mail so i know the messages get through. Sorry if you received it twice. Below is my answer to your question and also additional questions for you. Thanks for all your helpJohn-Original Message-From: John HideySent: Thursday, July 27, 2006 11:06 AMTo: '[EMAIL PROTECTED] '; wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.netSubject: RE: [WiX-devs] GAC and call Custom Action My custom action in install the Microsoft Enterprise Library into the gac and register all their Instrumentation classes.This is Microsoft code and they have the installers in the code so I assumed it would be easiest to just call them. Let me ask you this.I am not a c++ developer by any means.Can you point me to or give me some guidance on how to do this the right way.I would love to get this done right one time instead of wrong several times. ThanksJohn-Original Message-From: Rob Mensching [mailto:[EMAIL PROTECTED]]Sent: Thursday, July 27, 2006 11:01 AMTo: John Hidey; wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.netSubject: RE: [WiX-devs] GAC and call Custom Action Yeah, that scenario just doesn't work right.The problem is that Assemblies going to the GAC aren't committed until the very end of the install.That means your InstallUtil calls (assuming InstallUtil can reach into the GAC, I've never tried) have to come after InstallFinalize.That means that your InstallUtil CustomActions can't be part of the installation transaction so when they fail, the install succeeds but is broken. This is just one more example of why using InstallUtil is a bad thing.My suggestion (which is rarely popular smile/) is to just do the right thing the first time and save yourself the time you'll spend later trying to manage the InstallUtil hack. What is the CustomAction you're trying to do anyway?From: [EMAIL PROTECTED][mailto: [EMAIL PROTECTED]] On Behalf Of John HideySent: Wednesday, July 26, 2006 1:36 PMTo: wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.netSubject: [WiX-devs] GAC and call Custom ActionHere is my problem everyone. I have a msi that installs several files into the gac. I DO NOT create a shadow copy of these files on the file system until my property called CREATESHADOW has a value of 1. These assemblies have installers in them that I need to call. (I know managed installers in not recommended but have to get done quickly) When I put my custom action in and call InstallUtilLib the file isn't actually on the file system. Is there a way to have InstallUtilLib refer the file via its temporary location that is used by the installer? Thoughts? Thanks everyone in advance.John-- csharpJohn Hidey/csharp[EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] [WiX-devs] GAC and call Custom Action
Rob,We're having issues with our mail server at work here so I don't know if you received this or not so I'm going to send to you again. I moved my email off my work account and only my personal mail so i know the messages get through. Sorry if you received it twice. Below is my answer to your question and also additional questions for you. Thanks for all your help John-Original Message-From: John HideySent: Thursday, July 27, 2006 11:06 AMTo: ' [EMAIL PROTECTED] '; wix-users@lists.sourceforge.net ; wix-devs@lists.sourceforge.netSubject: RE: [WiX-devs] GAC and call Custom Action My custom action in install the Microsoft Enterprise Library into the gac and register all their Instrumentation classes.This is Microsoft code and they have the installers in the code so I assumed it would be easiest to just call them. Let me ask you this.I am not a c++ developer by any means.Can you point me to or give me some guidance on how to do this the right way.I would love to get this done right one time instead of wrong several times. ThanksJohn-Original Message-From: Rob Mensching [mailto: [EMAIL PROTECTED]]Sent: Thursday, July 27, 2006 11:01 AMTo: John Hidey; wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.net Subject: RE: [WiX-devs] GAC and call Custom Action Yeah, that scenario just doesn't work right.The problem is that Assemblies going to the GAC aren't committed until the very end of the install.That means your InstallUtil calls (assuming InstallUtil can reach into the GAC, I've never tried) have to come after InstallFinalize.That means that your InstallUtil CustomActions can't be part of the installation transaction so when they fail, the install succeeds but is broken. This is just one more example of why using InstallUtil is a bad thing.My suggestion (which is rarely popular smile/) is to just do the right thing the first time and save yourself the time you'll spend later trying to manage the InstallUtil hack. What is the CustomAction you're trying to do anyway?From: [EMAIL PROTECTED][mailto: [EMAIL PROTECTED]] On Behalf Of John HideySent: Wednesday, July 26, 2006 1:36 PMTo: wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.net Subject: [WiX-devs] GAC and call Custom ActionHere is my problem everyone. I have a msi that installs several files into the gac. I DO NOT create a shadow copy of these files on the file system until my property called CREATESHADOW has a value of 1. These assemblies have installers in them that I need to call. (I know managed installers in not recommended but have to get done quickly) When I put my custom action in and call InstallUtilLib the file isn't actually on the file system. Is there a way to have InstallUtilLib refer the file via its temporary location that is used by the installer? Thoughts? Thanks everyone in advance.John -- csharpJohn Hidey/csharp[EMAIL PROTECTED] -- csharpJohn Hidey/csharp[EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Difx, Authenticode and Driver Signing
There is no public APIs to adjust driver signing policy from the application. Even though there are some hacks for that, it is a tempering for operating systems and highly discouraged. The only right way to achieve your goal is to get WHQL certification. Authenticode signing is also applicable only for Windows 2003 Server or later platforms. Regards, Chesong Lee From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shmarya Rubenstein Sent: Wednesday, July 26, 2006 6:32 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Difx, Authenticode and Driver Signing Hi all, I have a driver package which I'm installing using DifX and WiX. For various reasons (Cash, Time, Confidentiality...) I can't submit the driver to WHQL for certification. I would, however, love to get rid of the annoying boxes which are displayed during installation to warn [read: iritate] the user. I read on various WDK/DDK pages that Authenticode signing the drivers should do the trick, but it seems that this is only applicable to Windows Server 2003+, which kinda sucks for my Win2K and XP users... BTW: I only found out that it doesn't work for XP and 2K, after purchasing a Thawte certificate and signing all the drivers - bleh :P. I know that it is possible to ignore these warnings globally by changing a setting on the computer manually. I've also seen installations for drivers which automatically turn driver signing warnings off for the duration of the installation, and turn it back on when they're done. Does anyone know how to acheive this? Better yet, have I made a mistake with my authenticode signing? Thanks, -- Shmarya --- [EMAIL PROTECTED] - http://shmarya.net NUnit rocks! http://nunit.com - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Is there a way to suppress license agreement dialogin stock dialog sets?
WiX 3.0 has a very different method of customizing the dialogs than WiX 2.0 which is so far undocumented. It's (hopefully) much more simple. Basically, just grab a sequence file from the sources that is similar to what you want (like WixUI_Mondo.wxs) and put that in your sources and modify it to only include the dialogs you want. Depending upon the dialog, it might need to the following to get removed: Dialogs added via DialogRef - just remove the element. Dialogs referred to via a Publish element - change the sequencing of the dialogs so the one you don't want is no longer in there. There are different steps because dialogs are displayed via different methods (its an artifact of how MSI works). Derek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rafuse Robert Sent: Wednesday, July 26, 2006 9:21 AM To: 'wix-users@lists.sourceforge.net' Subject: Re: [WiX-users] Is there a way to suppress license agreement dialogin stock dialog sets? Okay, I'm confused. The section Customizing dialog sets at http://wix.sourceforge.net/manual-wix2/WixUI_dialog_library.htm mentions the files CustomDialogSet.build, CustomDialogSet.wxs and TestCustom.wxs but I can not find them in the WiX 2.0 binaries or source package (they don't seem to be in 3.0 either). Am I missing something? _ Bob Rafuse -Original Message- From: Rafuse Robert Sent: Wednesday, July 26, 2006 12:08 PM To: 'wix-users@lists.sourceforge.net' Subject: RE: Is there a way to suppress license agreement dialog in stock dialog sets? Okay, ignore the question... Immediately after I hit Send, I stumbled across Customizing dialog sets in the online docs. I ~swear~ I looked for this earlier... I must have mis-typed. Sorry to bother. _ Bob Rafuse -Original Message- From: Rafuse Robert Sent: Wednesday, July 26, 2006 12:04 PM To: wix-users@lists.sourceforge.net Subject: Is there a way to suppress license agreement dialog in stock dialog sets? WiX 2.0.4305.0 I am creating an .msi that will only be used internally by my associatesy. This install does not require a license agreement dialog. I was wondering, is it at all possible to suppress this dialog while still using the stock WiX dialog sets? Thanks, --- Bob Rafuse Important Note: This email and any attachment hereto are confidential and may contain trade secrets or may be otherwise protected from disclosure. If you have received it in error you are in notice of this fact. Please notify us immediately by reply email and then delete this email and any attachment from your system. Please understand that you are not allowed to copy this email or any attachment hereto or disclose its contents to any other person. Thank you. --- Important Note: This e-mail message and any attachments are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient you must not use, copy, disclose or take any action based on this e-mail or any information and attachment contained in the message. If you have received this e-mail in error, please advise the sender immediately by reply e-mail or telephone and delete this message and any attachment from your system. Thank you. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] conditions
What are you trying to do overall? Using feature conditions in a components condition is a little awkward usually features directly determine if a component will be installed. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Sam Sent: Wednesday, July 26, 2006 12:25 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] conditions I have a component that looks like: Component Id=DbInstallationDirectoryService Guid=A4B5E633-D715-4e8e-8C4A-E58D1BAFFBAE XmlFile Action="" ElementPath=//DBInstallation/FeaturesInstalled File=[DBCREATION]dbinstallation.xml Id=dbInstallationConfig20 Name=Feature Sequence=19 Value=Feat1 / Condition![CDATA[(Feature1 = 3) AND (!Feature1 = 3)]]/Condition /Component From my understanding, it should right out FeatureFeat1/Feature if the Feature1 feature is being installed, and it is not an upgrade. That is not what is happening. What am I doing wrong? What is the best way to do this? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Making Use Of Properties In Cutom Actions
I am trying to run a batch file post install. In my Custom Action I specify the location of the batch file using the FileKey attribute. I then want to pass a parameter (file system location) into the batch file, so I use the ExeCommand attribute. When I hard code this parameter, everything works fine, however I really want to use a property value read in from the registry but I cant the Custom Action to use the property which is working fine in other parts of my installer: Property Id='INSTALLDIR' RegistrySearch Id='IDRegistry' Type='directory' Root='HKLM' Key='Software\Exchange FS\Exweb' Name='InstallDir' / /Property CustomAction Id='TestBat' FileKey ='batch' ExeCommand='[INSTALLDIR]' Return='check'/ Any Ideas? Can I not use properties in this way in custom actions? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Question about repeat installation of the same MSI
Hello. My installation package consists of MSI-file and set of directory with additional files. Those files are used by type 1 custom action (DLL file stored in a Binary table stream). Since these directory is required, in MSI there is a property that checks for the directory existence (via 'DirectorySearch ... Path=[SourceDir][MY_REDIST_DIR]...') and a custom action that aborts installation if that property is empty. My installation should not have maintainence installation. It should simple install everything as it is first-time installation. When I run installation for the first time on a clear machine every thing works fine. When I repeat same installation on the same machine the custom action that checks for the directory existence property triggers and aborts installations. Learning log I found that MSI-engine after first installation copies my msi into its internal directories and runs this copied msi instead. And this cause a problem since MSI-engine does not copy my additional directory. Is there any way to disable copying? How can make MSI-engine to use my msi but not copied? -- Best regards, Peter G. Sakhno C-MAP RUSSIA Ltd http://www.c-map.ru/ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] GAC and call Custom Action
Here is my problem everyone. I have a msi that installs several files into the gac. I DO NOT create a shadow copy of these files on the file system until my property called CREATESHADOW has a value of 1. These assemblies have installers in them that I need to call. (I know managed installers in not recommended but have to get done quickly) When I put my custom action in and call InstallUtilLib the file isnt actually on the file system. Is there a way to have InstallUtilLib refer the file via its temporary location that is used by the installer? Thoughts? Thanks everyone in advance. John - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0library (wixlib) files
It would take some work to rebuild our wixlibs, but we plan to rebuild them anyway when moving to 3.0 to take advantage of the embedded localization information. So, no problem here without wixlib backwards-compatibility. Regards, Martin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Cicerone Sent: Thursday, July 27, 2006 7:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0library (wixlib) files WiX 3.0 currently has the ability to read library (.wixlib) files generated by the WiX 2.0 version of the toolset. However, weve recently identified several reasons why wed like to stop maintaining backwards-compatibility with the 2.0 format. The overall goal here is to make the changes necessary so that we never need to touch the wixobj or wixlib file formats ever again. All the proposed changes should make the contents of the wixobj and wixlib files so generic that all future improvements can be made by merely working with the existing concept of unreal tables instead of special 1-off xml and unreal columns. Drawbacks The one obvious drawback of this change is that customers using WiX 2.0 and 3.0 will not be able to share wixlibs from 2.0 to 3.0 as they may have done before. All 2.0 libraries must be converted to the 3.0 format (or re-built in 3.0) to work. For most groups, we anticipate that this will not be a problem since the move to 3.0 should only be done for a new product release and mixing versions of WiX in your build process is currently not advisable (its not a scenario we test very often). From 3.0 onward, however, we should be able to keep a consistent file format for wixobj/wixlib/wixout files. Advantages 1. Remove unreal columns from real tables Currently WiX internally uses a concept of unreal columns to associate additional information with standard MSI tables. For example, to associate a file path with a File row, WiX has a special Source column in the File table which is considered an unreal column. This basically means that wixobj and wixlib files carry the column but the final MSI file does not. The big danger with using this method of persisting additional information about standard tables is that should the MSI team ever decide to add additional columns to the tables, WiX will need to add hacks to ignore its unreal columns since all columns are addressed by their index (not the name of the column). In order to prepare for the possibility of the MSI team adding new columns to existing standard tables, wed like to remove the unreal column concept. This doesnt mean that metadata can no longer be associated with standard tables it just means it needs to be stored in a separate table like a WixFile table with a foreign key matching a File table entry. 2. Prefix wix-specific unreal tables with Wix There are currently several WiX-specific tables used between candle and light which do not actually appear in any MSI files. However, these tables do reside in the same namespace as normal tables that will be put in the MSI file. Some of these tables include: - FeatureGroup supports ComponentGroup authoring concepts - ComponentGroup support ComponentGroup authoring concept - Merge supports merge modules - Actions supports scheduling for standard and custom actions - SuppressAction supports suppression of actions - CustomTables supports custom tables without needing an extension - EnsureTables supports ensuring a table exists in an MSI file - RowData contains row information for CustomTables - UI supports UI elements The danger is that should MSI or any other group decide to use one of these names for a table in their setup package, a collision will occur and WiX will not be able to represent it properly. In order to prepare for this scenario, wed like to preface all WiX-specific table names with Wix similar to how MSI deals with collisions since MSI 2.0 but prefixing all their tables with Msi. This prefix will essentially become a namespace for WiX-specific tables and should not collide with other products. This change will not affect custom action tables like IIsWebSite, SecureObj, XmlFile, etc These must now stay consistent since they ship in MSI files to avoid breaking scenarios in which customers already use these tables. 3. Remove custom xml in wixobj wixlib files Currently WiX passes special information between the compiler and linker in the form of special xml in the wixobj and wixlib files. Over time, we came to recognize that usage of this custom xml was not very extensible and cause a lot of problems whenever a change needed to be made because it basically invalidated the entire wixobj and wixlib file formats. Going forward, we have recognized that the best way to avoid this problem is to persist information between the compiler and linker using unreal tables. This is why WiX 3.0 recently stopped using complexReference elements in
Re: [WiX-users] Question: Migrating Existing Installer to Windows Installer
When we moved over to MSI we had to deal with existing InstallShield installs. I got round the problem by looking in the registry for the key InstallShield writes under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall using a RegistrySearch. I then used the set property as the condition for a custom error telling the user to uninstall the existing version. This might seem crude, but it does the job and each customer only has to do it once. Rob Rick Glos wrote: Hello, I’ve spent the last two days getting familiar with WiX, the windows installer, and going through the great tutorial on WiX (http://www.tramontana.co.hu/wix/). I especially liked the article posted a year ago (http://msdn.microsoft.com/smartclient/default.aspx?pull=/library/en-us/dnwingen/html/wixsetup.asp) that talks about doing the installer during the development cycle and not at the end of it. We are badly in need of doing this. I have a question however. How do we migrate from our current installer to the Windows Installer for existing customers? We just released version 5.0 of our product. Spending 6 weeks updating our installer (we have a custom C# installer). I can see our *new* customers instead using a new .msi for later versions (5.5, 6.0, etc). What do I do about our existing customers when they wish to upgrade? They’ve never installed originally with a Windows Installer. How do I get them on the same track? Thanks for any advice, Rick Glos - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] GAC and call Custom Action
John Hidey wrote: Here is my problem everyone. I have a msi that installs several files into the gac. I DO NOT create a shadow copy of these files on the file system until my property called CREATESHADOW has a value of 1. These assemblies have installers in them that I need to call. (I know managed installers in not recommended but have to get done quickly) When I put my custom action in and call InstallUtilLib the file isnt actually on the file system. Is there a way to have InstallUtilLib refer the file via its temporary location that is used by the installer? Thoughts? There is no temporary location. Files to be installed into the GAC aren't put down until the install is being committed. -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] conditions
I need to write out to a config file what features are being installed, so that the program that update/creates the database knows what database to create/update if any at all. From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Thursday, July 27, 2006 6:12 PM To: Scott Sam; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] conditions What are you trying to do overall? Using feature conditions in a components condition is a little awkward usually features directly determine if a component will be installed. Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Sam Sent: Wednesday, July 26, 2006 12:25 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] conditions I have a component that looks like: Component Id=DbInstallationDirectoryService Guid=A4B5E633-D715-4e8e-8C4A-E58D1BAFFBAE XmlFile Action="" ElementPath=//DBInstallation/FeaturesInstalled File=[DBCREATION]dbinstallation.xml Id=dbInstallationConfig20 Name=Feature Sequence=19 Value=Feat1 / Condition![CDATA[(Feature1 = 3) AND (!Feature1 = 3)]]/Condition /Component From my understanding, it should right out FeatureFeat1/Feature if the Feature1 feature is being installed, and it is not an upgrade. That is not what is happening. What am I doing wrong? What is the best way to do this? - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to set one File for two Components
Hello. I have two Components installed into different directories. And these Components include the same file, so the same file appears in two different directories. I have authored an MSM with two Component elements under different Directory elements. Those Component elements include File elements with different Id's pointing to the same source file. But I do not like this way. The file is twice copied into the database. How can do it in another, better way? -- Best regards, Peter G. Sakhno C-MAP RUSSIA Ltd http://www.c-map.ru/ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [WiX-devs] GAC and call Custom Action
This is actually the primary reason why I started the thread about WiX and support for installation of Windows instrumentation features. I too use Enterprise Library and have suffered with some of these very issues. All EL does is install some event sources, performance counters and WMI schema for instrumentation. In order to do this in WiX, it varies from not too bad to . Event logs are really just a set of registry entries and are pretty straightforward. .NET event sources (for the most part) always use the messages dll that comes with the .NET framework, so you don't even need to install a messages dll. You just need to point to the existing one. The rest of the registry stuff is easy. It is actually easy to do a better job than .NET does at creating event sources this way, especially with .NET 1.1, as you get more control over how they are created and behave. Perf counters are harder. WiX has support for perf counters and has some documentation on how to do them. I think we also determined that .NET perf counters can be installed this way. The problem is that the .NET perf counter install mechanism actually dynamically generates some of the files (the .h and .ini), and there isn't a very straightforward way to harvest those that I know of besides installing with the installer classes once and finding the resulting files. It is a little ugly. I had a suggestion for Derek that it would be cool if Heat could reverse engineer a perf counter installer to make it easier to generate the authoring for this stuff. WMI seems to be a bit of a black hole. I've never bothered to reverse engineer those installer classes to see what they actually do, but it does not seem to be very well understood. One other thing that could be done for EL specifically would be to harvest all of the installer classes from the actual EL source (which they give you) and create your own little assembly that just has the installer stuff in it, but gets installed to the file system instead of the GAC. You'd still be using InstallUtil to install the various components, but you at least wouldn't have the GAC problem. Ideally though, you'd just create the appropriate authoring and do it that way. And BTW, a wixlib or merge module for EL would be a nice contribution to the EL community. I think the EL team at Microsoft actually looked at WiX for a while, as I know Peter Provost was posting here and was asking questions (although that could have been for the Smart Client block instead), but it doesn't look like they ever decided to package things as an MSI for whatever reason. Joe K. -Original Message- From: Rob Mensching [mailto: [EMAIL PROTECTED] Sent: Thursday, July 27, 2006 11:01 AM To: John Hidey; wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.net Subject: RE: [WiX-devs] GAC and call Custom Action Yeah, that scenario just doesn't work right. The problem is that Assemblies going to the GAC aren't committed until the very end of the install. That means your InstallUtil calls (assuming InstallUtil can reach into the GAC, I've never tried) have to come after InstallFinalize. That means that your InstallUtil CustomActions can't be part of the installation transaction so when they fail, the install succeeds but is broken. This is just one more example of why using InstallUtil is a bad thing. My suggestion (which is rarely popular smile/) is to just do the right thing the first time and save yourself the time you'll spend later trying to manage the InstallUtil hack. What is the CustomAction you're trying to do anyway? From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of John Hidey Sent: Wednesday, July 26, 2006 1:36 PM To: wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.net Subject: [WiX-devs] GAC and call Custom Action Here is my problem everyone. I have a msi that installs several files into the gac. I DO NOT create a shadow copy of these files on the file system until my property called CREATESHADOW has a value of 1. These assemblies have installers in them that I need to call. (I know managed installers in not recommended but have to get done quickly) When I put my custom action in and call InstallUtilLib the file isn't actually on the file system. Is there a way to have InstallUtilLib refer the file via its temporary location that is used by the installer? Thoughts? Thanks everyone in advance. John -- csharpJohn Hidey/csharp[EMAIL PROTECTED] -- csharpJohn Hidey/csharp[EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list
Re: [WiX-users] Question: Migrating Existing Installer to WindowsInstaller
First off. Thanks for the warm welcome. Second. Thanks for the quick response and ideas by all three of you (Derek, Richard, and Bob). Answers to your questions Derek: Ive been told we usually release on a quarterly cycle although that isnt set in stone (I just started working here in Feb 06 and assisted with the release in Mar 06. Then rolled the Jul 06 release myself the complexity and difficulty is what led me to WiX, knowing that theres got to be a better way than this spaghetti, procedural code.) Our next release is targeted for end of November 06. Our product is a help desk/support, task, and issue tracking solution. The Visual Studio solution file actually consists of 14 projects (any code is C# fyi). We install 2 services, 4 libraries, 3 websites and 4 sql server databases (as well as a couple unit test and database projects). We interact with SQL, IIS, and Services. Ive done some investigation into the System.Configuration.Installer classes and it looked promising. Not sure how that integrates with WiX though (?). Our current installer is basically a custom rolled C# Windows Application that looks like an installer. Using a wizard like interface, it prompts the user for a series of configuration values (virtual directory names, user name, password, sql server name, etc) and then runs an install or upgrade method to do the work. It has to do things like create/upgrade SQL databases, install aspx files, configure IIS (create an app pool, create 3 virtual directories), it also creates a user account (to run the app pool under), joins it to a group, modifies the permissions on some files and folders, installs and starts 2 services, modifies the web.config to store and encrypt connection strings and so on... J [I know you mentioned in your article that you are interested in this stuff]. It doesnt use installer classes yet although Im thinking that perhaps it should but Im not sure I understand how that integrates with the Windows Installer. Sorry this paragraph is so long. Based on what the 3 of you have said, it sounds like perhaps what I should consider for the upgrade is save off the current settings/data (web.config, sql databases, and any custom files theyve added to the web sites) then perform an uninstall. Then let the windows installer do an install and then restore those settings/data and then theyd be go to go for future upgrades using the windows installer. Does this sound reasonable? Would I be able to do this within the context of the windows installer (msi)? Or would I have our customers run a Setting Saver app. Run the uninstall app. Then run the new windows installer (msi) and then run a Setting Restorer app. That seems like a lot of steps but Im thinking aloud here. Perhaps this could all be handled within the context of the msi. Anyway. Thanks for reading this far if you made it and thanks for the advice. Hope to keep the discussion going. Rick From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Thursday, July 27, 2006 11:52 PM To: Rick Glos; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Question: Migrating Existing Installer to WindowsInstaller First off, welcome! Theres some information that can help guide our answers for you: When does your product ship? What is your product (just curious)? More specifically, what does it interact with (COM, services, MSMQ, IIS, SQL, etc)? How does the C# installer install things? Does it use the Installer classes or manually set registry keys and copy files? To answer some of your questions: Im not sure how the upgrade story would work it all depends on how you currently handle uninstall and upgrade scenarios. Is there something youd need to run to perform an uninstall on the previous version (would it be managed code)? Once you get all customers on an MSI deployed setup it should be easy to have them all use the same technology after that point. Thanks, Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Glos Sent: Thursday, July 27, 2006 12:09 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Question: Migrating Existing Installer to WindowsInstaller Hello, Ive spent the last two days getting familiar with WiX, the windows installer, and going through the great tutorial on WiX (http://www.tramontana.co.hu/wix/). I especially liked the article posted a year ago (http://msdn.microsoft.com/smartclient/default.aspx?pull=/library/en-us/dnwingen/html/wixsetup.asp) that talks about doing the installer during the development cycle and not at the end of it. We are badly in need of doing this. I have a question however. How do we migrate from our current installer to the Windows Installer for existing customers? We just released version 5.0 of our product. Spending 6 weeks
[WiX-users] ISAPI Filter installation hangs IIS
Has anyone encountered this? I'm trying to install a single sign on isapi filter, and at the very end of the installation when it says install to metabase or something like that, the thing hangs and eventually all resources are eaten up causing the need for a reboot. Is this what was fixed in 3.0.1926.0 ?I've been trying to get 3.0.1926.0 to compile my installer, but keep getting the following error:[exec] Microsoft (R) Windows Installer Xml Linker version 3.0.1926.0 [exec] Copyright (C) Microsoft Corporation 2003. All rights reserved.[exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(70) : error LGHT0102 : The localization variable !(loc.ConfigureIIs ) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(71) : error LGHT0102 : The localization variable !( loc.StartMetabaseTransaction) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(72) : error LGHT0102 : The localization variable !( loc.RollbackMetabaseTransaction) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(73) : error LGHT0102 : The localization variable !( loc.CommitMetabaseTransaction) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(74) : error LGHT0102 : The localization variable !( loc.WriteMetabaseChanges) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(36) : error LGHT0102 : The localization variable !( loc.msierrIISCannotConnect) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(37) : error LGHT0102 : The localization variable !( loc.msierrIISFailedReadWebSite) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(38) : error LGHT0102 : The localization variable !( loc.msierrIISFailedReadWebDirs) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(39) : error LGHT0102 : The localization variable !( loc.msierrIISFailedReadVDirs) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(40) : error LGHT0102 : The localization variable !( loc.msierrIISFailedReadFilters) is unknown. Please ensure the variable is defined. [exec] E:\delivery\Dev\wix_public\src\ext\iisextension\wixlib\IIsExtension.wxs(41) : error LGHT0102 : The localization variable !( loc.msierrIISFailedReadMimeMap) is unknown. Please ensure the variable is defined. Any help would be appreciated, thanks.-James - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] password is incorrectly set during ServiceInstall
It turned out to be Local Security Policy issue than of password. Adding the service user to the Log on as a service rights under Administrative Tools - Local Security policy /Secutity Settings/Local Policies/User Rights Management in XP and similar one in 2003 fixed the issue. Apparently setting the logon as user/password thru the services.msc service properties is setting this rights by default, so it was working thru that path. Is it possible to add this as part of the ServiceInstall code in Wix? Thanks to chris leon from wix list for finding this solution. - chandra -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chandra Rentachintala Sent: Tuesday, July 11, 2006 10:09 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] password is incorrectly set during ServiceInstall Yes. It has a $ at the beginning of password. How to overcome this problem as we can't predict what kind of passwords people use at customer locations?. Is there a way to tell wix/msi to take Password string as it is? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Wilson Sent: Tuesday, July 11, 2006 7:14 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] password is incorrectly set during ServiceInstall Is there a $ at the start of the password? It occurs to me that if Windows Installer is seeing a $ at the start of the password in square brackets it could be attempting to do substitution for a component path (that's what $ at the start of a name means). Phil Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Wilson Sent: Monday, July 10, 2006 7:48 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] password is incorrectly set during ServiceInstall A dependency issue seems most likely in the circumstances. What happens if you install the service but don't attempt to start it during the installation? Does it start manually from the services applet? If it does you know that the account is fine but something like a dependent Dll or assembly is missing when the service is started. If it doesn'r start at reboot time, this can be a dependency on another service that you haven't configured. As an aside, you should look at MsiHiddenProperties as a way of not exposing passwords in a log! Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, July 07, 2006 6:00 PM To: 'Chandra Rentachintala'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] password is incorrectly set during ServiceInstall The error message from StartServices is pretty dismal. The same message is presented for pretty much all reasons. More like than not, you service won't start because some dependency is missing or something else. You should be able to try diagnosing the service start while the dialog box is up... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chandra Rentachintala Sent: Friday, July 07, 2006 1:41 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] password is incorrectly set during ServiceInstall I have my service installed like this and it installs the service correctly, but service is unable to start due to login failure. ServiceInstall Id='MyServiceInstall' DisplayName='myservice' Name='myservice' ErrorControl='ignore' Type='ownProcess' Vital=no Start=auto Account='[SERVICEDOMAIN]\[SERVICEUSERNAME]' Password='[SERVICEPASSWORD]' / I traced the logs and the password is correct there. If I set the same password in services.msc, it works fine. ServicePassword has couple of '$' chars in it, if that is of any significance. Anyone hit this issue and found the solution, let me know. Thanks Chandra - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net
[WiX-users] ANSI Characters
I'm having a lot of trouble getting an MSI installer to work with file names or folders containing characters like Á or ó. Whenever I attempt to run the .msi it says that ?_propos_du_bouton_d_ic?ne.htm was an invalid file name, but that's not what I even named the file. The file was called Á_propos_du_bouton_d_icóne.htm How do I get my installer to let me use characters like Á or ó with my file namesand directory names. I'm using the most recent version of the Wix 2.0 toolset. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] password is incorrectly set during ServiceInstall
I think there is already a Bug or Feature Request tracking this. Yes, it's possible... just hasn't been done yet. -Original Message- From: Chandra Rentachintala [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 10:52 AM To: Chandra Rentachintala; [EMAIL PROTECTED]; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: RE: [WiX-users] password is incorrectly set during ServiceInstall It turned out to be Local Security Policy issue than of password. Adding the service user to the Log on as a service rights under Administrative Tools - Local Security policy /Secutity Settings/Local Policies/User Rights Management in XP and similar one in 2003 fixed the issue. Apparently setting the logon as user/password thru the services.msc service properties is setting this rights by default, so it was working thru that path. Is it possible to add this as part of the ServiceInstall code in Wix? Thanks to chris leon from wix list for finding this solution. - chandra -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chandra Rentachintala Sent: Tuesday, July 11, 2006 10:09 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] password is incorrectly set during ServiceInstall Yes. It has a $ at the beginning of password. How to overcome this problem as we can't predict what kind of passwords people use at customer locations?. Is there a way to tell wix/msi to take Password string as it is? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Wilson Sent: Tuesday, July 11, 2006 7:14 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] password is incorrectly set during ServiceInstall Is there a $ at the start of the password? It occurs to me that if Windows Installer is seeing a $ at the start of the password in square brackets it could be attempting to do substitution for a component path (that's what $ at the start of a name means). Phil Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Phil Wilson Sent: Monday, July 10, 2006 7:48 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] password is incorrectly set during ServiceInstall A dependency issue seems most likely in the circumstances. What happens if you install the service but don't attempt to start it during the installation? Does it start manually from the services applet? If it does you know that the account is fine but something like a dependent Dll or assembly is missing when the service is started. If it doesn'r start at reboot time, this can be a dependency on another service that you haven't configured. As an aside, you should look at MsiHiddenProperties as a way of not exposing passwords in a log! Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, July 07, 2006 6:00 PM To: 'Chandra Rentachintala'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] password is incorrectly set during ServiceInstall The error message from StartServices is pretty dismal. The same message is presented for pretty much all reasons. More like than not, you service won't start because some dependency is missing or something else. You should be able to try diagnosing the service start while the dialog box is up... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chandra Rentachintala Sent: Friday, July 07, 2006 1:41 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] password is incorrectly set during ServiceInstall I have my service installed like this and it installs the service correctly, but service is unable to start due to login failure. ServiceInstall Id='MyServiceInstall' DisplayName='myservice' Name='myservice' ErrorControl='ignore' Type='ownProcess' Vital=no Start=auto Account='[SERVICEDOMAIN]\[SERVICEUSERNAME]' Password='[SERVICEPASSWORD]' / I traced the logs and the password is correct there. If I set the same password in services.msc, it works fine. ServicePassword has couple of '$' chars in it, if that is of any significance. Anyone hit this issue and found the solution, let me know. Thanks Chandra - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Using Tomcat but need to do more? Need to support web
Re: [WiX-users] GAC and call Custom Action
Is there a way to do what I want to do. I would think that this can be done. Many installers do this, but maybe they use a C++ custom action which does the registry for them. Any thoughts? John From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Thursday, July 27, 2006 3:50 AM To: John Hidey Cc: wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.net Subject: Re: [WiX-users] GAC and call Custom Action John Hidey wrote: Here is my problem everyone. I have a msi that installs several files into the gac. I DO NOT create a shadow copy of these files on the file system until my property called CREATESHADOW has a value of 1. These assemblies have installers in them that I need to call. (I know managed installers in not recommended but have to get done quickly) When I put my custom action in and call InstallUtilLib the file isnt actually on the file system. Is there a way to have InstallUtilLib refer the file via its temporary location that is used by the installer? Thoughts? There is no temporary location. Files to be installed into the GAC aren't put down until the install is being committed. -- sig://boBhttp://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX and web applications
Tallow (for WiX 2.0) and Heat (for WiX 3.0) are the standard ways of creating WiX authoring based on existing data like directories full of files and such. Note that to do this the right way is somewhat non-trivial. The thing about WI is that you shouldn't be changing component GUIDs all the time for files that you've previously installed, so you don't necessarily want to regenerating your authoring from scratch every time. As I recall, Tallow sidesteps this issue by not creating GUIDs for your components and making you do that by hand (or with some sort of script you write). It isn't an easy problem to solve. Another thing you might consider doing is generating the authoring dynamically from the existing source for the initial build and then just tweaking the authoring by hand thereafter. Typically, this isn't too hard to keep on top of if you do it as you go. Other people on this list have created some really sophisticated build systems that do automate this task while keeping track of existing components and such. There is probably a significant investment in time to get something like this, but it might pay off. Perhaps someone else will share their solution. The email archives probably have some pointers as well. Joe K. - Original Message - From: David Keaveny To: wix-users@lists.sourceforge.net Sent: Thursday, July 27, 2006 8:30 PM Subject: [WiX-users] WiX and web applications Is there an equivalent in WiX to Visual Studio 2003's web deployment project? In other words, a simple way of adding all the .ascx, .config, .jpg etc files to my MSI without having to hand-code each individual entry? VS can take the output from a project, and build an MSI from that; I don't see an obvious way to do it in WiX. I've had no problem with WiX for packaging Windows services, since the file counts are relatively low; but my web application contains hundreds of files, and is under constant development, so there must be some way of automating things. Regards, David - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0 library (wixlib) files
WiX 3.0 currently has the ability to read library (.wixlib) files generated by the WiX 2.0 version of the toolset. However, weve recently identified several reasons why wed like to stop maintaining backwards-compatibility with the 2.0 format. The overall goal here is to make the changes necessary so that we never need to touch the wixobj or wixlib file formats ever again. All the proposed changes should make the contents of the wixobj and wixlib files so generic that all future improvements can be made by merely working with the existing concept of unreal tables instead of special 1-off xml and unreal columns. Drawbacks The one obvious drawback of this change is that customers using WiX 2.0 and 3.0 will not be able to share wixlibs from 2.0 to 3.0 as they may have done before. All 2.0 libraries must be converted to the 3.0 format (or re-built in 3.0) to work. For most groups, we anticipate that this will not be a problem since the move to 3.0 should only be done for a new product release and mixing versions of WiX in your build process is currently not advisable (its not a scenario we test very often). From 3.0 onward, however, we should be able to keep a consistent file format for wixobj/wixlib/wixout files. Advantages 1. Remove unreal columns from real tables Currently WiX internally uses a concept of unreal columns to associate additional information with standard MSI tables. For example, to associate a file path with a File row, WiX has a special Source column in the File table which is considered an unreal column. This basically means that wixobj and wixlib files carry the column but the final MSI file does not. The big danger with using this method of persisting additional information about standard tables is that should the MSI team ever decide to add additional columns to the tables, WiX will need to add hacks to ignore its unreal columns since all columns are addressed by their index (not the name of the column). In order to prepare for the possibility of the MSI team adding new columns to existing standard tables, wed like to remove the unreal column concept. This doesnt mean that metadata can no longer be associated with standard tables it just means it needs to be stored in a separate table like a WixFile table with a foreign key matching a File table entry. 2. Prefix wix-specific unreal tables with Wix There are currently several WiX-specific tables used between candle and light which do not actually appear in any MSI files. However, these tables do reside in the same namespace as normal tables that will be put in the MSI file. Some of these tables include: - FeatureGroup supports ComponentGroup authoring concepts - ComponentGroup support ComponentGroup authoring concept - Merge supports merge modules - Actions supports scheduling for standard and custom actions - SuppressAction supports suppression of actions - CustomTables supports custom tables without needing an extension - EnsureTables supports ensuring a table exists in an MSI file - RowData contains row information for CustomTables - UI supports UI elements The danger is that should MSI or any other group decide to use one of these names for a table in their setup package, a collision will occur and WiX will not be able to represent it properly. In order to prepare for this scenario, wed like to preface all WiX-specific table names with Wix similar to how MSI deals with collisions since MSI 2.0 but prefixing all their tables with Msi. This prefix will essentially become a namespace for WiX-specific tables and should not collide with other products. This change will not affect custom action tables like IIsWebSite, SecureObj, XmlFile, etc These must now stay consistent since they ship in MSI files to avoid breaking scenarios in which customers already use these tables. 3. Remove custom xml in wixobj wixlib files Currently WiX passes special information between the compiler and linker in the form of special xml in the wixobj and wixlib files. Over time, we came to recognize that usage of this custom xml was not very extensible and cause a lot of problems whenever a change needed to be made because it basically invalidated the entire wixobj and wixlib file formats. Going forward, we have recognized that the best way to avoid this problem is to persist information between the compiler and linker using unreal tables. This is why WiX 3.0 recently stopped using complexReference elements in the wixobj files and instead switching to unreal WixComplexReference tables. The tables basically allow us to add columns as necessary without breaking backwards-compatibly with previous versions of the wix toolset. This change removing custom xml from the wixobj and wixlib files can be made without sacrificing backwards-compatibility with WiX 2.0 wixlib files. However, Ive called it out here because this change is what prompted us to begin looking at breaking backwards-compatibility. Basically, we found
