[WiX-users] Launch Checkbox
Hi All,I'm trying to add a checkbox to the Finish dialog which will let me launch an application conditionallyI've tried adding a checkbox like so:Control Id=Launch Type=CheckBox Width=100 Height=17 X=135 Y=80 Property=LAUNCHCONFIGURATIONCHECKED And then having Property Id='LAUNCHCONFIGURATIONCHECKED' Value ='1'/ InstallUISequence Custom Action="" After=ExecuteAction ![CDATA[LAUNCHCONFIGURATIONCHECKED]] /Custom /InstallUISequence CustomAction Id=LaunchConfig FileKey=MyConfig.exe ExeCommand= Return=asyncNoWait/ But it doesn't seem to work...I'm sure many people have done this in the past... Please help!?!Thanks,-- Shmarya--- [EMAIL PROTECTED] - http://shmarya.netNUnit 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] Question: Migrating Existing Installer to WindowsInstaller
Based on the information provided below, youll likely want to look into using the WixIIsExtension, WixSQLExtension, and WixUtilExtension (for some additional service configuration and xml manipulation custom actions). Youll need to decide to use either WiX 2.0 or 3.0. Were currently only encouraging adoption of 3.0 for groups shipping in 2007 or later. This is because 3.0 is under active development and youll avoid the intermediate bugs and schema changes associated with that if you stick with 2.0. If you use WiX 3.0, youll get some help with creating the initial installation by using a tool called heat.exe. It can create WiX authoring from type libraries, self-reg dlls, directories, web sites (partial support no app pools yet), and assembly RegistrationServices. A tool in WiX 2.0 performs similar functions its called tallow.exe. It does not support type libraries or web sites (it was the predecessor to heat). There has been a bit of a debate raging here lately about the Installer classes. WiX and MSI actually have no formal interaction with the installer classes and the WiX team advises against using them because they do not provide a complete rollback experience in the case of installation failures. Full disclosure however: there are some people that prefer them because they are easy, but youll often find that going the easy route in setup is a bit more dangerous (as is the case here). Ideally we need to add some additional logic to heat.exe to convert Installer operations into simple Registry and File operations since that is the most robust and declarative installation method possible with MSI. Your plan for the upgrade sounds good. You would likely need some sort of executable bootstrapper to save off the config settings, perform the uninstall, and install the new MSI file. Derek From: Rick Glos [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 10:41 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: 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
[WiX-users] shortcut and validation error
I have a shortcut componentin my setup package that fails ICE validation because it doesn't "use a registry key under HKCU as its KeyPath". I have the ALLUSERS property set to 1. This will set the ProgramMenuFolder to the "All Users" profile. Why does itstill need to have a registry key under HKCU as its KeyPath? What do I need to do other then creating a registry key that won't be used? Thanks, -- Leo - 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] Device scan before install
Hi Chesong, Is there a way to supress the New Hardware Wizard when CM_Reenumerate_DevNode is called? None of the parameters can do it. I guess I have to ask this question in a forum; The Wizard appears in XP, but not in Server 2003. Best regards, Calin Chesong Lee wrote: Refer to How To Force Reenumeration of a Device Tree From an Application http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q259697 if you want to go for your own custom action. CM_Reenumerate_DevNode: http://msdn.microsoft.com/library/en-us/DevInst_r/hh/DevInst_r/cfgmgrfn_9ed0f83c-4b63-425f-b80b-9be5d69bb43a.xml.asp?frame=true Just one more thing. I have seen most of the custom (non-DIFx) device driver packages are run as immediate actions or external programs. Those actions should be a deferred custom action and preferably with no impersonation - which *can* be run in Local System Context. The former is the requirement for custom actions which changes the system. The latter allows normal users to install the package if privileged installation is allowed by the group policy. Regards, Chesong Lee -Original Message- From: Calin Iaru [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 4:42 AM To: Chesong Lee; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Device scan before install Hi Chesong, thanks for the link. From the FAQ: Does the message cautioning that the hardware is unplugged at the end of the install actually scan for Hardware IDs? Or does this message just assume that the hardware isn't plugged in because a software first install has just completed? DIFxApp checks to determine whether or not the hardware is connected. Not much to handle here. I think I will opt for a custom action. The logs generated by MSIEXEC after the Device Manager detected the hardware as Other Device show an extra call: DIFXAPP: INFO: ENTER UpdateDriverForPlugAndPlayDevices... MSI (s) (74!D0) [14:17:28:906]: Closing MSIHANDLE (128) of type 790531 for thread 1488 MSI (s) (74!D0) [14:17:33:703]: Creating MSIHANDLE (129) of type 790531 for thread 1488 DIFXAPP: SUCCESS:RETURN UpdateDriverForPlugAndPlayDevices. Maybe I can find the exact SetupAPI function which does a Hardware Scan before installing - the obvious candidate is the function above, but I need more info. Other driver installers like the Intel Ethernet Controller scan before installing - it uses InstallShield though. Best regards, Calin Chesong Lee wrote: Take a look at DIFx (http://www.microsoft.com/whdc/driver/install/DIFxFAQ.mspx) if it can help you. Otherwise, you may have to create your own custom actions to force such actions using SetupDi APIs. Consult devcon samples in DDK as a reference. Regards, Chesong Lee -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Calin Iaru Sent: Thursday, July 27, 2006 1:37 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Device scan before install Hi List, given the scenario below, I would like to know how to force a device scan before installing a driver: Device Manager shows Other Device detected The drivers are installed The drivers are uninstalled The device entry disappears from Device Manager, but there is no Other Device section Install the drivers again A prompt message appears saying Please attach your device to this computer any time after the installation has finished Device Manager does not show any entry for the device So the problem is that install/uninstall/install driver will not detect the device on the second install. Best regards, Calin - 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] Should WiX add support for installingWindowsinstrumentation features?
John Vottero wrote: This is mostly tool for developer to get the cmdlet working. Release setup should set the registry keys explicitly. See, it's not just WiX crazies!g It just sets series of registry keys. We need to document the keys which vendors need to set for registering snapins. I will open a bug for this. Will the PowerShell team create a WiX extension? There is no plan for V1. OK, that's good news. -- 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 see. How about just putting the component into Feature1 so that it will run when Feature1 is installed locally? Derek From: Scott Sam [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 5:12 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: 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
Re: [WiX-users] Device scan before install
Refer to How To Force Reenumeration of a Device Tree From an Application http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q259697 if you want to go for your own custom action. CM_Reenumerate_DevNode: http://msdn.microsoft.com/library/en-us/DevInst_r/hh/DevInst_r/cfgmgrfn_9ed0f83c-4b63-425f-b80b-9be5d69bb43a.xml.asp?frame=true Just one more thing. I have seen most of the custom (non-DIFx) device driver packages are run as immediate actions or external programs. Those actions should be a deferred custom action and preferably with no impersonation - which *can* be run in Local System Context. The former is the requirement for custom actions which changes the system. The latter allows normal users to install the package if privileged installation is allowed by the group policy. Regards, Chesong Lee -Original Message- From: Calin Iaru [mailto:[EMAIL PROTECTED] Sent: Friday, July 28, 2006 4:42 AM To: Chesong Lee; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Device scan before install Hi Chesong, thanks for the link. From the FAQ: Does the message cautioning that the hardware is unplugged at the end of the install actually scan for Hardware IDs? Or does this message just assume that the hardware isn't plugged in because a software first install has just completed? DIFxApp checks to determine whether or not the hardware is connected. Not much to handle here. I think I will opt for a custom action. The logs generated by MSIEXEC after the Device Manager detected the hardware as Other Device show an extra call: DIFXAPP: INFO: ENTER UpdateDriverForPlugAndPlayDevices... MSI (s) (74!D0) [14:17:28:906]: Closing MSIHANDLE (128) of type 790531 for thread 1488 MSI (s) (74!D0) [14:17:33:703]: Creating MSIHANDLE (129) of type 790531 for thread 1488 DIFXAPP: SUCCESS:RETURN UpdateDriverForPlugAndPlayDevices. Maybe I can find the exact SetupAPI function which does a Hardware Scan before installing - the obvious candidate is the function above, but I need more info. Other driver installers like the Intel Ethernet Controller scan before installing - it uses InstallShield though. Best regards, Calin Chesong Lee wrote: Take a look at DIFx (http://www.microsoft.com/whdc/driver/install/DIFxFAQ.mspx) if it can help you. Otherwise, you may have to create your own custom actions to force such actions using SetupDi APIs. Consult devcon samples in DDK as a reference. Regards, Chesong Lee -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Calin Iaru Sent: Thursday, July 27, 2006 1:37 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Device scan before install Hi List, given the scenario below, I would like to know how to force a device scan before installing a driver: Device Manager shows Other Device detected The drivers are installed The drivers are uninstalled The device entry disappears from Device Manager, but there is no Other Device section Install the drivers again A prompt message appears saying Please attach your device to this computer any time after the installation has finished Device Manager does not show any entry for the device So the problem is that install/uninstall/install driver will not detect the device on the second install. Best regards, Calin - 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] Should WiX add support for installingWindowsinstrumentation features?
John Vottero wrote: Are you saying that it's impossible to create a good Installer based Installer class? No. That's fine with me, who do I start with? I just need some direction from Microsoft. Right now, I have the PowerShell team saying use these Installer based classes to install your Cmdlets but the Windows Installer/WiX people are saying Yuck, don't use that crap!. What am I supposed to do? Ask the PowerShell team to do the right thing for their customers and their customers's customers. Worst case, they should document what the installer classes do so anyone can do it, regardless of tool. Better yet, they can provide merge modules, .wixlibs, or WiX extensions for strongly-typed authoring. Best of all, they can work with the WiX team to ship them in the box. Some teams already do some of it, but it's driven by customer demand. If they don't hear from customers that it's an issue, they're going to (logically) do the simplest thing. -- 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] Controls with Conditions
Michael Cline wrote: Is there any way to update the property with every key press? No. Unfortunately, MSI only updates properties on focus change. -- 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
[WiX-users] Create folder in DRVSTORE
Hi List, is there any possibility to create a folder inside the system DRVSTORE? When installing a driver, some files may reside in different folders and the inf file needs them from different locations. The problem occurs when the installer copies these files to the DRVSTORE and the directory structure is not preserved. Consequently, a message pops up asking the user to browse for that particular file. There are workarounds, like modifying the inf, which can be used to fix it. Best regards, Calin - 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] Website Creation Error
On Tue, 25 Jul 2006 08:27:37 -0700, Derek Cicerone wrote: Hello, This is a bit beyond my knowledge of the IIS custom actions. The quickest way to find a solution is likely going to be debugging the custom action yourself to see whats going wrong. I have plenty of bandwidth, that's not the problem but can we ask for not repeating humongous e-mails over and over again (this last one amounted to 243k in a single message), pretty please? Logs and other files should go into attachments rather than the message itself and not repeated with every turn of the thread. I know that it's mostly Outlook to blame with its questionable and rather foolish original message attached at the end behavior but we should be able to overcome this somehow... :-))) Bye, Gábor --- DEÁK JAHN, Gábor -- Budapest, Hungary E-mail: [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] ProgramMenuFolder and validation error
When defining a component with "ProgramMenuFolder" as the directory path for a menu item, an ICE38validation error occur indicating that the component installs to user profile and that it must use a reg key under HKCU as its KeyPaths. Since I have the property ALLUSERS=1 set doesn't this indicate that the package installs per machine and not per user? So, why do I still get this validation error? Is this an installer validation bug? Thanks, -- Leo - 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 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
Re: [WiX-users] Fwd: LGHT1055 InstallUISequence warning
I backed out of this a couple of months back because I was having difficulties... Let me see if I can find it in my source-control... otherwise I can try and reproduce...On 7/26/06, Rob Mensching [EMAIL PROTECTED] wrote: I know that I had trouble with Component referenceing because you can't reference a single component from multiple features... at least, I couldn't get it to work... [DerekC] You should absolutely be able to reference a single component from multiple features using multiple ComponentRef elements under each feature. In WiX 3.0, it's also possible to create groups of components to be included under a feature by using the ComponentGroup element (this brings you extremely close to what you'd get with a merge module). [Shmarya] I know that I had difficulty with this... kept getting errors about components being referenced from more than one feature... perhaps it was a bug which is now fixed? [RobMen] What was the error message exactly? My guess is that you needed to mark one of the ComponentRef elements as Primary="yes" so that all the advertised goo gets associated with the correct Feature. -- Shmarya---[EMAIL PROTECTED] - http://shmarya.netNUnit 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] [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. Thanks John -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 - 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] Long path name to COM server
Hello, all! I have following situation: when I use Class element to install Class for my COM server, I use Server attribute to set path to my COM server in registry (under InProcServer32 key). I use unadvertised mode (i. e. Advertise=no) for Class element. The problem is that WIX writes this in registry table to the Value column in Registry table in following manner: [!comserver.dll] where comserver.dll is the Id of my COM server in File table. When installation finishes, path to my COM server is in short form. But I want to get it in long form. I know that if WIX will write it to Registry table in [#comserver.dll] form, then I will get long path after installation. Is it possible somehow to do this? Thank you in advance. - 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] Question: Migrating Existing Installer to Windows Installer
Rick Glos wrote: 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? MSI has support for automatically upgrading other MSI installations to later versions. You won't be able to use that with your custom installer but you can fake it. For example, use RegistrySearch or FileSearch to locate old installations, then provide UI that prompts them to uninstall first. -- 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] Should WiX add support for installingWindowsinstrumentation features?
This is good, except for the part about not creating an Extension. smile/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Vottero Sent: Wednesday, July 26, 2006 5:32 AM To: Bob Arnson Cc: wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: [WiX-users] Should WiX add support for installingWindowsinstrumentation features? Bob Arnson wrote: John Vottero wrote: Are you saying that it's impossible to create a good Installer based Installer class? No. That's fine with me, who do I start with? I just need some direction from Microsoft. Right now, I have the PowerShell team saying use these Installer based classes to install your Cmdlets but the Windows Installer/WiX people are saying Yuck, don't use that crap!. What am I supposed to do? Ask the PowerShell team to do the right thing for their customers and their customers's customers. Worst case, they should document what the installer classes do so anyone can do it, regardless of tool. Better yet, they can provide merge modules, .wixlibs, or WiX extensions for strongly-typed authoring. Best of all, they can work with the WiX team to ship them in the box. Some teams already do some of it, but it's driven by customer demand. If they don't hear from customers that it's an issue, they're going to (logically) do the simplest thing. I posted this exchange and a number of questions on the PowerShell newsgroup and here's the response: Posting on behalf of the feature developer. Does the PowerShell team feel that PSSnapin is suitable for professional Cmdlet installers? Or, is it intended to be a tool for developers to use to quickly get a Cmdlet working? This is mostly tool for developer to get the cmdlet working. Release setup should set the registry keys explicitly. Does the PSSnapin do anything other than creating registry entries? No. Will the inner workings of PSSnapin be documented? It just sets series of registry keys. We need to document the keys which vendors need to set for registering snapins. I will open a bug for this. Will the PowerShell team create a WiX extension? There is no plan for V1. - 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
Sorry about that everyone. These messages where posted two days ago when we were having problems with mail server at work. Hope not too many more come across. I dont want anyone thinking I'm flooding the mailing list. Thanks John On 7/26/06, John Hidey [EMAIL PROTECTED] 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 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 -Take Surveys. Earn Cash. Influence the Future of ITJoin 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.nethttps://lists.sourceforge.net/lists/listinfo/wix-users -- 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] Question: Migrating Existing Installer to WindowsInstaller
I used a similar approach to deal with migration of an app that was originally built with non-MSI WISE and then did the same basic thing again when my first MSI version was (mistakenly) installed per-user instead of per-machine. AppSearch for traces of the old stuff and LaunchCondition that prevents install until the old stuff is gone. Sad (especially the per-user goof!), but basically functional. Joe K. - Original Message - From: Rob Hamflett [EMAIL PROTECTED] To: wix-users@lists.sourceforge.net Sent: Friday, July 28, 2006 3:24 AM Subject: Re: [WiX-users] Question: Migrating Existing Installer to WindowsInstaller 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 - 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] ISAPI Filter installation hangs IIS
James Carter wrote: [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. The WiX extensions now support localization, which means you have to specify the culture for the localizable strings. Pass -cultures:en-us to use English strings. -- 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] GAC and call Custom Action
John Hidey wrote: 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? Or they just use standard MSI support for registration. Calling GAC'd assemblies isn't really feasible. -- 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] Launch Checkbox
Shmarya Rubenstein wrote: InstallUISequence Custom Action=LaunchConfig After=ExecuteAction ![CDATA[LAUNCHCONFIGURATIONCHECKED]] /Custom /InstallUISequence After MSI has processed the ExecuteAction action, it stops following the sequence in InstallUISequence. Instead, it uses only the negative sequence numbers to show success or failure. Instead, publish a DoAction control event from the Finish/Close button on the success dialog. -- 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] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0library (wixlib) files
If there are utilities to bring a pure WiX 2 code base up to a pure WiX 3 code base then breaking compatibility is fine by me. We do not intend to mix the two. The utilities would eliminate costly manual conversion time and provide a quick way for the entire WiX 2 code library to be converted. So we could keep our existing WiX 2 library (just in case :)) then put upa parallel WiX 3 library and just make the switch wholesale and if WiX 3 floats in production then the WiX 2 library can be deprecated ... Note however we won't address the switch to WiX 3 until it becomes production ready. So on that note ... to help encourage the use of (and thus bug fixing of) WiX 3 to get it ready for production the conversion utilities need to convert from WiX 2 to WiX 3 and (to save our butts if WiX 3 doesn't get it done) convert from WiX 3 to WiX 2. You will need to weigh the cost of conversion versus backwards compatibility ... I'm clueless on just how would you automate a conversion. Dave WilliamsonClear Sky Software704.568.5544 sales704.554.6300 support704.943.0585 fax[EMAIL PROTECTED]www.clearskysoftware.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek CiceroneSent: Wednesday, July 26, 2006 6:50 PMTo: wix-users@lists.sourceforge.netSubject: [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
Re: [WiX-users] Question about repeat installation of the same MSI
As you've discovered, when you install a product a cached MSI file is created, and maintenance activities use this cached MSI file. It's the ProductCode guid that indicates that the product is already installed on the system, and when a product is already installed MSI goes into maintenance mode. It's this maintenance mode that you're encountering because the guid is already installed, and the fact that it uses a cached MSI file is pretty much just an implementation detail. It seems to me that your best choice is to make every version of your product a major upgrade. If there is a prior version of your product it will be silently uninstalled. Whether there is an older version or not, every install will be an install of a new product. Phil Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter G. Sakhno Sent: Wednesday, July 26, 2006 2:22 AM To: wix-users@lists.sourceforge.net Subject: [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 - 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
I am using the Enterprise Library in this way as well. I decided to install the assembly into the GAC, also install the assembly to somewhere on the file system and finally install a batch file which is executed via a custom action after InstallFinalize that runs installutil I know its not a particular elegant solution but its what I have right now From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hidey Sent: 27 July 2006 18:04 To: John Vottero; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] GAC and call Custom Action This was not my decision. This is how the Microsoft enterprise library 2.0 does it. We have signed the msentlib 2.0 and are putting in the gac and want to get all the instrumentation installed for it also with the installer. From: John Vottero [mailto:[EMAIL PROTECTED] Sent: Thursday, July 27, 2006 1:03 PM To: John Hidey; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] GAC and call Custom Action I don't think it's a good idea to put Installer classes in the same assembly that they're installing for. This is one of the reasons. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Hidey Sent: Wednesday, July 26, 2006 1:51 PM To: wix-users@lists.sourceforge.net Subject: [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] Long path name to COM server
The very latest WiX 3.0 release fixes this, enjoy! :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrey T Sent: Friday, July 28, 2006 4:47 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Long path name to COM server Hello, all! I have following situation: when I use Classelement to install Class for my COM server, I use Server attribute to set path to my COM server in registry (under InProcServer32 key). I use unadvertised mode (i. e. Advertise=no) for Classelement. The problem is that WIX writes this in registry table to the Value column in Registry table in following manner: [!comserver.dll] where comserver.dll is the Id of my COM server in File table. When installation finishes, path to my COM server is in short form. But I want to get it in long form. I know that if WIX will write it to Registry table in [#comserver.dll] form, then I will get long path after installation. Is it possible somehow to do this? Thank you in advance. - 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] ProgramMenuFolder and validation error
This question has been coming up often. Note that ALLUSERS is completely uppercase so a user can change your installation to be per-user via the command line or several other methods. This means that you need the HKCU key to ensure proper repair operation (since a shortcut is not a valid keypath). Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of dangle123 ... Sent: Tuesday, July 25, 2006 3:36 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] ProgramMenuFolder and validation error When defining a component with ProgramMenuFolder as the directory path for a menu item, an ICE38validation error occur indicating that the component installs to user profile and that it must use a reg key under HKCU as its KeyPaths. Since I have the property ALLUSERS=1 set doesn't this indicate that the package installs per machine and not per user? So, why do I still get this validation error? Is this an installer validation bug? Thanks, -- Leo - 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
We already have a tool to convert from WiX 2.0 to WiX 3.0. Its called wixcop. I assume you were referring to converting the source code itself (not the wixlib files) since just having the libraries without source is a bit dangerous. We do not have a tool to convert from WiX 3.0 back down to 2.0. Once the time comes to ask everyone to switch from 2.0 to 3.0, the core tools should be extremely stable, and the decision to move to 3.0 should only be one way. It would be very painful to go from 2 - 3 and back to 2 since there are some concepts in 3.0 that will not translate back down to 2.0 sources (like not having short file names). The reason I assert that 3.0 core tools will be very stable by the time 3.0 is labeled stable is because Ive always set out to stabilize the core tools well ahead of the toolset as a whole. In fact, the WiX 2.0 custom actions still arent locked down whereas the core tools have been for almost a year. Thank you for this feedback, its good to see that no groups are intending to mix 2.0 and 3.0 in their organization so far. However, after much discussion over the issue, I think the hope is that WiX 3.0 will be the last time we touch the wixobj, wixlib, and wixout file formats. Were trying to make them generic enough that anything further can be supported via a new table instead of modifying the format itself. Derek From: Dave Williamson [mailto:[EMAIL PROTECTED] Sent: Saturday, July 29, 2006 5:47 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] rfc: break WiX 3.0 backwards-compatibility with WiX 2.0library (wixlib) files If there are utilities to bring a pure WiX 2 code base up to a pure WiX 3 code base then breaking compatibility is fine by me. We do not intend to mix the two. The utilities would eliminate costly manual conversion time and provide a quick way for the entire WiX 2 code library to be converted. So we could keep our existing WiX 2 library (just in case :)) then put upa parallel WiX 3 library and just make the switch wholesale and if WiX 3 floats in production then the WiX 2 library can be deprecated ... Note however we won't address the switch to WiX 3 until it becomes production ready. So on that note ... to help encourage the use of (and thus bug fixing of) WiX 3 to get it ready for production the conversion utilities need to convert from WiX 2 to WiX 3 and (to save our butts if WiX 3 doesn't get it done) convert from WiX 3 to WiX 2. You will need to weigh the cost of conversion versus backwards compatibility ... I'm clueless on just how would you automate a conversion. Dave Williamson Clear Sky Software 704.568.5544 sales 704.554.6300 support 704.943.0585 fax [EMAIL PROTECTED] www.clearskysoftware.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Cicerone Sent: Wednesday, July 26, 2006 6:50 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
Re: [WiX-users] SelfRegCost on windows 2003 Server
Title: SelfRegCost on windows 2003 Server Its probably a missing dependency. It might be easier to stop using self reg by running tallow (wix v2) or heat (v3) against the self-reg dll to collect its registry keys. J Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Topley Sent: Thursday, July 27, 2006 3:24 AM To: 'wix-users@lists.sourceforge.net' Subject: [WiX-users] SelfRegCost on windows 2003 Server Greetings all, I'm not sure if this is a bug with WIX, or if the problem is this end. We have a load of self registering dll's, I know, don't start. These babies work fine when installed on XP, the registry entries all appear fine etc. etc. When I run the same installer on 2003 server standard edition the installer fails with a failed to register blah blah blah.dll error. Our old Installshield versions manage to self register on 2003 fine... Any offers? Cheers ta, Simon. The information contained in this e-mail is likely to be confidential and may be legally privileged. It is intended only for the addressee. If you have received this message in error please notify the sender immediately at the above address. The disclosure, copying or distribution of this message or its contents without the prior approval of Wallingford Software Ltd. is strictly prohibited. Wallingford Software Ltd. is not liable for unauthorised disclosures nor for subsequent actions or omissions in reliance upon them. - 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] ISAPI Filter installation hangs IIS
To resolve the localization issue: I think youll need to pass cultures:en-us to light to load the English resources for the extension. This change was just made in the last release. Please note that the custom action code in WiX 3.0 is identical to what can be found in 2.0. We still havent locked down on 2.0 and forked 3.0 for the custom actions (everything else has forked). Derek From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carter Sent: Friday, July 28, 2006 10:46 AM To: wix-users@lists.sourceforge.net Subject: [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
