[WiX-users] question on volumecostList control
I have used volumecostList control in wix. When the control comes its full of exclamation marks. The image is attached. http://n2.nabble.com/file/n2191299/Untitled.jpg Untitled.jpg -- View this message in context: http://n2.nabble.com/question-on-volumecostList-control-tp2191299p2191299.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] question on volumecostList control
I am using wix 2.0. I tried building with different wix versions and ended up with the same problem. Can anyone please help me out? skarthik_psg wrote: I have used volumecostList control in wix. When the control comes its full of exclamation marks. The image is attached. http://n2.nabble.com/file/n2191299/Untitled.jpg Untitled.jpg -- View this message in context: http://n2.nabble.com/question-on-volumecostList-control-tp2191299p2191305.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question on selective patching
Thanks for the information. I have an application with more than 1000 files. Even though the next version can have changes in several files, I want to build patches for selected 2 or 3 files. Since number of files to ignore is more I am not sure we can use the solution of explicitly list files to ignore in the UpgradedFilesToIgnore table. Is there any other option in WiX 2.0? Thanks, Suraj -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Wednesday, January 21, 2009 12:51 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question on selective patching Sudhakaran, Suraj wrote: I am using WiX2.0. I have a requirement of patching selected components in a new version. AFAIK, patching process will include all the modified files from the old and new installer and include them in the patch. Is there a way to select what all will be included here rather than all the modified files from old to new? In WiX v3, the patching mechanism supports explicit resource references. In WiX v2, you're using PatchCreation packages, so you're limited to what MsiMsp gives you. I believe it includes all changed resources, but you can explicitly list files to ignore in the UpgradedFilesToIgnore table. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Build wixlib with localization
After setting culture for project that is using my library everything works fine. Maybe anyone know how to build library with default localization set up. -Original Message- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: Wednesday, January 21, 2009 1:02 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Build wixlib with localization In the case that is working, you are specifying the default culture to light.exe. In the case that is not working you are not. That's probably the problem. -Original Message- From: Jeremy Lew [mailto:j...@liquidmachines.com] Sent: Tuesday, January 20, 2009 13:39 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Build wixlib with localization I think I'm seeing the same thing. Seems to happen only in Debug configuration. The build machine is a 64 bit system with AMD64 Wix installed. Here are the command lines, first the failing configuration then the working configuration. Sorry for the length, this is best viewed without wordwrap. The localization symbols it is complaining about are in LqmiWixLib.wixlib, which is being referenced as a Votive project reference from the main install project. * FAILING VERSION (Debug|x64) *** 22 C:\Program Files (x86)\Windows Installer XML v3\bin\candle.exe -dDebug -dDevEnvDir=C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\\ -dSolutionDir=C:\Proj\falcon\lqmi\ues\server\cs.net\phoenix\ -dSolutionExt=.sln -dSolutionFileName=phoenix.sln -dSolutionName=phoenix -dSolutionPath=C:\Proj\falcon\lqmi\ues\server\cs.net\phoenix\phoenix.sln -dConfiguration=Debug -dOutDir=..\..\..\..\..\..\..\buildout2\Setup\Debug\x64\ -dPlatform=x64 -dProjectDir=C:\Proj\falcon\lqmi\ues\server\cs.net\phoenix\installer\Ser verSetup\ -dProjectExt=.wixproj -dProjectFileName=LMDC_Server_Setup.wixproj -dProjectName=LMDC_Server_Setup -dProjectPath=C:\Proj\falcon\lqmi\ues\server\cs.net\phoenix\installer\Se rverSetup\LMDC_Server_Setup.wixproj -dTargetDir=C:\Proj\falcon\buildout2\Setup\Debug\x64\ -dTargetExt=.msi -dTargetFileName=LiquidMachines-DocumentControl.msi -dTargetName=LiquidMachines-DocumentControl -dTargetPath=C:\Proj\falcon\buildout2\Setup\Debug\x64\LiquidMachines-Doc umentControl.msi -dLqmiWixLib.Configuration=Debug -dLqmiWixLib.FullConfiguration=Debug|x64 -dLqmiWixLib.Platform=x64 -dLqmiWixLib.ProjectDir=C:\Proj\falcon\lqmi\wix\LqmiWixLib\ --snip-- 22 C:\Program Files (x86)\Windows Installer XML v3\bin\Light.exe -dWixUILicenseRtf=LicenseAgreement.rtf -out C:\Proj\falcon\buildout2\Setup\Debug\x64\LiquidMachines-DocumentControl. msi -pdbout C:\Proj\falcon\buildout2\Setup\Debug\x64\LiquidMachines-DocumentControl. wixpdb -sice:ICE47 -sice:ICE03 -sice:ICE82 -sice:ICE83 -ext WixUtilExtension -ext WixUIExtension -ext WixNetFxExtension -ext WixIISExtension obj\x64\Debug\AdminUIApp.wixobj obj\x64\Debug\AdminUIAppGroup.wixobj obj\x64\Debug\CRTMergeModule.wixobj obj\x64\Debug\KeyService.wixobj obj\x64\Debug\KeyServiceGroup.wixobj obj\x64\Debug\ServicesApp.wixobj obj\x64\Debug\ServicesAppGroup.wixobj obj\x64\Debug\KeyServiceMain.wixobj obj\x64\Debug\OpenSSLMain.wixobj obj\x64\Debug\Product.wixobj obj\x64\Debug\LMDC_Server_Installer_UI.wixobj obj\x64\Debug\LMDC_SqlScripts.wixobj C:\Proj\falcon\lqmi\wix\LqmiWixLib\bin\x64\Debug\LqmiWixLib.wixlib 22C:\Proj\falcon\lqmi\wix\LqmiWixLib\ServiceUserDlg.wxs(14,0): error LGHT0102: The localization variable !(loc.LqmiWixLib_ServiceUserDlgDescription) is unknown. Please ensure the variable is defined. 22C:\Proj\falcon\lqmi\wix\LqmiWixLib\ServiceUserDlg.wxs(15,0): error LGHT0102: The localization variable !(loc.LqmiWixLib_ServiceUserDlgTitleText) is unknown. Please ensure the variable is defined. 22C:\Proj\falcon\lqmi\wix\LqmiWixLib\ServiceUserDlg.wxs(19,0): error LGHT0102: The localization variable !(loc.LqmiWixLib_ServiceUserDlgUserNameLabel) is unknown. Please ensure the variable is defined. 22C:\Proj\falcon\lqmi\wix\LqmiWixLib\ServiceUserDlg.wxs(21,0): error LGHT0102: The localization variable !(loc.LqmiWixLib_ServiceUserDlgPasswordLabel) is unknown. Please ensure the variable is defined. 22C:\Proj\falcon\lqmi\wix\LqmiWixLib\ServiceUserDlg.wxs(23,0): error LGHT0102: The localization variable !(loc.LqmiWixLib_ServiceUserDlgConfirmPasswordLabel) is unknown. Please ensure the variable is defined. 22C:\Proj\falcon\lqmi\wix\LqmiWixLib\ServiceUserDlg.wxs(8,0): error LGHT0102: The localization variable !(loc.LqmiWixLib_ServiceUserDlg_Title) is unknown. Please ensure the variable is defined. 22C:\Proj\falcon\lqmi\wix\LqmiWixLib\PasswordNotMatchDlg.wxs(6,0): error LGHT0102: The localization variable !(loc.LqmiWixLib_PasswordNotMatchDlgConfirmText) is unknown. Please ensure the variable is defined. 22C:\Proj\falcon\lqmi\wix\LqmiWixLib\PasswordNotMatchDlg.wxs(9,0): error LGHT0102: The localization variable
Re: [WiX-users] Not able to install votive
Wix 2.x is too old for using with VS 2008. In order to do that you need to use Wix 3 On Wed, Jan 21, 2009 at 12:20 PM, Murtaza Chowdhury murta...@microsoft.com wrote: When I try to install Votive 2.0.5805.0 on Visual Studio 2008, I get the following error message : WIX Toolset Visual Studio Package requires the Standard, Professional, or Team editions of Visual Studio; Express editions are not supported. I have the Team edition and not the express edition but somehow votive thinks that the other way. Has anybody come across this problem. What is the resolution ? Any pointers will be highly appreciated. Regards, Murtaza Chowdhury -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] condition on a feature, greater than or equal
Oh darn, well it seems that I maybe able to use the version number of one of the files these chaps install, so maybe it won't be so bad after all, Thanks Rob. Simon - Message: 5 Date: Tue, 20 Jan 2009 10:38:10 -0800 From: Rob Mensching rob.mensch...@microsoft.com Subject: Re: [WiX-users] condition on a feature, greater than or equal to To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Message-ID: de33023b477fe44eaa71983f5279f6ce50fc4f5...@na-exmsg-c102.redmond.corp.m icrosoft.com Content-Type: text/plain; charset=us-ascii Yep, what you're seeing is known. The Windows Installer will convert Property values to numbers for you when doing comparisons... but only if the data provide is all digits. The # in front of DWORDs from RegSearch is maddening for this reason. Bob has a design laying around somewhere for completely replacing AppSearch with a data driven CustomAction that is more powerful and more useful but that's not in development anywhere. So, you need to do something to tweak the DWORD into a number (sadly, I think that means CustomAction). -Original Message- From: Simon Topley [mailto:simon.top...@wallingfordsoftware.com] Sent: Tuesday, January 20, 2009 08:27 To: wix-users@lists.sourceforge.net Subject: [WiX-users] condition on a feature, greater than or equal to Hello all, its' been a very long time since I checked in here. I've joyfully had an issue with our installers of late that should be simple to solve... only I can't solve it. The situation is this, our clients install many versions of our software new and old and run them concurrently. We also ship third party drivers for our dongles, so users have to have a valid license to use our software. Now the most recent update of this third party install has raised a weird issue that we haven't seen before. When someone installs an older version of our software alongside the newest version the older driver mangles the newer one as I assume it is still attempting to install it. I get the version number for this third party software from the registry using a property, as raw - its' a DWORD in the registry. Now I'm hoping I can just done some simple comparison like this (on the feature) Condition Level=0DRIVERVERSION = 7/Condition Sadly this doesn't work as the version number has a hash in it as I got it as raw, and I think it maybe comparing it as a string anyway. I'm not sure I can even use a greater than or equal too in a condition like this anyway. I'm dying here please help! 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 is strictly prohibited. Wallingford Software is not liable for unauthorised disclosures nor for subsequent actions or omissions in reliance upon them. Registered in the UK, company no: 02288719 Wallingford Software Limited, Howbery Park, Wallingford, Oxfordshire, OX10 8BA -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Message: 6 Date: Tue, 20 Jan 2009 10:48:21 -0800 (PST) From: Improvize1 improvi...@yahoo.com Subject: [WiX-users] ScheduleReboot and Post-install Bootstrapper To: wix-users wix-users@lists.sourceforge.net Message-ID: 82447.77519...@web12.mail.gq1.yahoo.com Content-Type: text/plain; charset=us-ascii Hi, Our installer is packed with a post-install bootstrapper that runs installs some additional software if it is not already present on the target machine. (That is, it may or may not run.) The main setup also has a ScheduleReboot action before InstallFinalize. We are running into a problem where the reboot and bootstrapper dialogs appear at the same time. Any suggestions for how to remedy this? Thanks! -- Message: 7 Date: Tue, 20 Jan 2009 13:52:59 -0500 From: Alicia Holloway ahollo...@sounddes.com Subject: [WiX-users] How to add an Operating System specific shortcut To: wix-users@lists.sourceforge.net Message-ID: ca2eea2e0901201052h47371402je7942e7a48648...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi, I have a Wix project in which I am trying to add a shortcut to a command prompt which calls a batch file as a command line argument. With the code I have so far (see below), I can get it to work on Windows XP only, because the environment variable it's
[WiX-users] Not able to install votive
When I try to install Votive 2.0.5805.0 on Visual Studio 2008, I get the following error message : WIX Toolset Visual Studio Package requires the Standard, Professional, or Team editions of Visual Studio; Express editions are not supported. I have the Team edition and not the express edition but somehow votive thinks that the other way. Has anybody come across this problem. What is the resolution ? Any pointers will be highly appreciated. Regards, Murtaza Chowdhury -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] CustomAction accessing CustomTable
Hello all, Can I do anything to clearify the issue. Is it not supposed to work? I am using WIX 3.0.4805.0, developing using Visual Studio 2008 with Votive Thank you! Jesper jballe wrote: Hello all, I am writing my first complex setup using wix and managed custom actions using c#. During the setup the user enters some settings. I have created an immediate customaction which saves those settings as rows in a CustomTable when the user clicks next. When I debug this customaction it seems to me that the records are successfully saved. I have scheduled an immediate customaction after InstallFiles which should read this customtable and schedule customactions as deferred, callback, commit with the data from this customtable as CustomData using the CustomData class. However, when this immediate custom action executes it retrieves no rows from the custom table. I save the records using InsertTemporary as I cannot use Insert and have read that this should not be possible during the installation process. -- View this message in context: http://n2.nabble.com/CustomAction-accessing-CustomTable-tp2181353p2191781.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WiX custom dialogs insight.
We are currently developing a new product and would like to use WiX to create our installer, but we still have some doubts about WiX usage. The version of WiX in question is v3. The problem is our installer does not make use only of WiX dialog sets (WixUI_Mondo, WixUI_InstallDir and so on), but it has some custom dialogs like 'Select SQl Server dialog', 'Inform user and password' and others that is not present on these sets. We also need to write values in the registry and install and lauch a service. This seems like a common scenario, but we couldn't find the right way to these things, and the scarse WiX documentation on the internet wasn't helping much. We were able to make a Wix installer that is launching a Wizard (that we made in Windows Forms) during the WiX installation process, this Wizard has the custom dialogs that we need. But after collecting some more info, we realized that the WiX dialogs order can be modified and it's possible to create new dialogs only using the WiX syntax and Custom Actions. What would be the right way to do this? 1) Create our custom dialogs using WiX syntax and integrate them with the WiX dialogs sets, if it's really possible to create any type of dialog using only this. 2) Create our custom dialogs in a separate project using Windows Forms, WPF or whatever and launch this during or after the installation process. Much like what is being made with our currently installer. 3) Other option...? Thank you for your help. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX custom dialogs insight.
You can check these links http://dizzymonkeydesign.com/blog/misc/adding-and-customizing-dlgs-in-wix-3/ http://blog.wharton.com.au/2007/06/windows-installer-xml-wix-30-snippets.html http://www.wixwiki.com/index.php?title=Main_Page http://www.tramontana.co.hu/wix/index.php The last link would be the first to understand about Wix. I read all of them to get a feel of Wix even though I do get stuck sometimes and people in this mailing list do help a lot. Hope this helps. Arun Perregattur -Original Message- From: Tezuka Kunimitsu [mailto:osu...@gmail.com] Sent: Wednesday, January 21, 2009 8:31 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] WiX custom dialogs insight. We are currently developing a new product and would like to use WiX to create our installer, but we still have some doubts about WiX usage. The version of WiX in question is v3. The problem is our installer does not make use only of WiX dialog sets (WixUI_Mondo, WixUI_InstallDir and so on), but it has some custom dialogs like 'Select SQl Server dialog', 'Inform user and password' and others that is not present on these sets. We also need to write values in the registry and install and lauch a service. This seems like a common scenario, but we couldn't find the right way to these things, and the scarse WiX documentation on the internet wasn't helping much. We were able to make a Wix installer that is launching a Wizard (that we made in Windows Forms) during the WiX installation process, this Wizard has the custom dialogs that we need. But after collecting some more info, we realized that the WiX dialogs order can be modified and it's possible to create new dialogs only using the WiX syntax and Custom Actions. What would be the right way to do this? 1) Create our custom dialogs using WiX syntax and integrate them with the WiX dialogs sets, if it's really possible to create any type of dialog using only this. 2) Create our custom dialogs in a separate project using Windows Forms, WPF or whatever and launch this during or after the installation process. Much like what is being made with our currently installer. 3) Other option...? Thank you for your help. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] RadioButtons and Feature
Thanks, that was the problem. CData is case sensitive and i had CData instead of CDATA after changing, it worked. Arun Perregattur -Original Message- From: Peter Björkman [mailto:peter.bjork...@aptus.se] Sent: Wednesday, January 21, 2009 1:57 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] RadioButtons and Feature Hi I can't see anything wrong on that row but on the next row and some other places you have written CData instead of CDATA... Perhaps you can skip CDATA and write just INSTALLTYPE=ServerFeature instead of ![CData[NOT (INSTALLTYPE=ServerFeature)]]. I use CDATA as I sometimes use not equal to in my conditions. -Original Message- From: Arun Perregatturv [mailto:aperregatt...@napcosecurity.com] Sent: den 20 januari 2009 20:29 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] RadioButtons and Feature I get an error 'Error 1 Expecting '![CDATA['. ' Here's my code Dialog Id=InstallDlg Width=370 Height=270 Title=!(loc.SetupTypeDlg_Title) NoMinimize=yes Control Id=Next Type=PushButton X=236 Y=243 Width=56 Height=17 Default=yes Text=!(loc.WixUINext) Publish Event=AddLocal Value=ServerFeature![CDATA[(INSTALLTYPE =ServerFeature)]]/Publish getting the error here.. Publish Event=Remove Value=ServerFeature![CData[NOT (INSTALLTYPE=ServerFeature)]]/Publish Publish Event=AddLocal Value=WorkstationFeature![CData[ (INSTALLTYPE=WorkstationFeature)]]/Publish Publish Event=Remove Value=WorkstationFeature![CData[NOT (INSTALLTYPE=WorkstationFeature)]]/Publish /Control Control Id=Back Type=PushButton X=180 Y=243 Width=56 Height=17 Text=!(loc.WixUIBack) / Control Id=Cancel Type=PushButton X=304 Y=243 Width=56 Height=17 Cancel=yes Text=!(loc.WixUICancel) Publish Event=SpawnDialog Value=CancelDlg1/Publish /Control Control Id=Description Type=Text X=25 Y=23 Width=280 Height=15 Transparent=yes NoPrefix=yes Text=!(loc.SetupTypeDlgDescription) / Control Id=Title Type=Text X=15 Y=6 Width=200 Height=15 Transparent=yes NoPrefix=yes Text=!(loc.SetupTypeDlgTitle) / Control Id=BannerBitmap Type=Bitmap X=0 Y=0 Width=370 Height=44 TabSkip=no Text=!(loc.SetupTypeDlgBannerBitmap) / Control Id=BannerLine Type=Line X=0 Y=44 Width=370 Height=0 / Control Id=BottomLine Type=Line X=0 Y=234 Width=370 Height=0 / Control Id=CreateDB Type=CheckBox Text=Create Database Property=CREATEDB CheckBoxValue=1 X=52 Y=139 Width=150 Height=30 / Control Id=RadioButtonGroupID Type=RadioButtonGroup X=49 Y=64 Width=188 Height=68 Property=INSTALLTYPE Text=This is My Group RadioButtonGroup Property=INSTALLTYPE RadioButton Value=ServerFeature X=0 Y=0 Width=100 Height=10 Text=Server / RadioButton Value=WorkstationFeature X=0 Y=45 Width=100 Height=10 Text=Workstation / /RadioButtonGroup /Control /Dialog Please let me know what I am missing here. Thanks, Arun Perregattur -Original Message- From: Peter Björkman [mailto:peter.bjork...@aptus.se] Sent: Tuesday, January 20, 2009 1:45 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] RadioButtons and Feature Hi Here is my solution to this. I don't know if there is something easier or better. The radiobuttongroup controls some property RadioButtonGroup Property=PROPERTY RadioButton Text=Feature1 Value=Feature1 X=5 Y=0 Width=140 Height=15 / RadioButton Text=Feature2 Value=Feature2 X=5 Y=20 Width=140 Height=15 / /RadioButtonGroup When the user presses the Next-button I publish events to add/remove the features Control Id=Next Type=PushButton X=236 Y=243 Width=56 Height=17 Default=yes Text=!(loc.WixUINext) Publish Event=AddLocal Value=Feature1![CDATA[(PROPERTY = Feature1)]]/Publish Publish Event=Remove Value=Feature1![CDATA[NOT (PROPERTY = Feature1)]]/Publish Publish Event=AddLocal Value=Feature2![CDATA[(PROPERTY = Feature2)]]/Publish Publish Event=Remove Value=Feature2![CDATA[NOT (PROPERTY = Feature2)]]/Publish Publish Event=NewDialog Value=NextDlg1/Publish /Control Where the value in the publish-element equals the feature names. //Peter Björkman -Original Message- From: Arun Perregatturv [mailto:aperregatt...@napcosecurity.com] Sent: den 19 januari 2009 18:08 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] RadioButtons and Feature I am confused on how to set a feature to a Radiobutton selection. I have 4 Features 1. Feature1 2. Feature2 3. Feature3 4. Feature4 I copied WixUI_Mondo and modified to include my custom Dialog which has 4 radiobuttons and one checkbox. Now, I
Re: [WiX-users] candle.exe and light.exe source code
From here http://sourceforge.net/project/showfiles.php?group_id=105970package_id=16 Arun Perregattur -Original Message- From: sam desilva [mailto:sam.desilv...@gmail.com] Sent: Wednesday, January 21, 2009 1:22 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] candle.exe and light.exe source code where i can get source code of light.exe and candle.exe -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Prevent reboot.
Hi, I have created some WiX based installers for some services and a web application I am working on at work. We use the installers as part of our test rigs, so we patch our test changes, build the new version and install it. Since this whole process is automated if the MSI determines it needs to reboot, it will. Previously when I installed the services it would cause a reboot, I assume due to file locks even though the installer would stop the service. My resolution was to stop the service before performing the upgrade, this seems to have solved that issue, although it seems unnecessary. I am now getting the same problem with the Web Application. It automatically deploys a new test build 2 times during the day, once in early morning before anyone is here and once at lunch. The morning build runs fine (I would guess this is because no ones use the application for hours so IIS has released its file locks) but the afternoon builds during lunch forces a reboot most of the time (I would guess because IIS has file locks due to recent activity), which is not only annoying because its rebooting the server, but also the server hosts other software (such as virtual servers) taking that down. I have tried stopping IIS before it begins the install but it still causes a reboot most of the time. Is there a switch that could solve this or some way to make windows locking more sane or something? I am just stumped. Thanks in advance, Adam. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX custom dialogs insight.
Hi! Here's a page demonstrating how to customize the installation flow. http://www.wixwiki.com/index.php?title=WixUI_Custom http://www.wixwiki.com/index.php?title=WixUI_Custom you should choose the UI sequence that fits your installer the most, get it's stock sequence, copy and paste, then is just a matter of programming your dialog, and plugging it on the sequence. it's somewhat cumbersome for a first timer, but fairly easy to program. joe -- View this message in context: http://n2.nabble.com/WiX-custom-dialogs-insight.-tp2192149p2192338.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] question about DTF Session object
Hi All, I have an install in which I have written custom actions using C# and DTF. One of my custom actions that I have written is scheduled to execute after RemoveFolders during uninstall only. It is not working as expected, and when I debug into my custom action I find that the Session object does not have values for most of the properties from my install. Additionally the database is not accessible. Is there anyone who can give me more information about when the properties and database from the session will still be available? Thanks, Amy Amy Rosewater SPECTRUM Human Resource Systems Corporation 707 17th Street Suite 3800 Denver CO, 80202 303.592.3403 arosewa...@spectrumhr.com -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Create database by attaching mdf and ldf file
Hi everyone I have been trying to create a database by attaching a pair of mdf/ldf files. I can't get it to work properly so I hope someone has an easy solution for this. I have been using a SqlString element with a call to sp_attach_db but I am getting problems. First I used the mdf file as keypath for the component but as I don't want any data to be destroyed at uninstall the component for the mdf and ldf files must be permanent and never be overwritten. Then I got the problem that the database was not attached if the files already existed on the machine. What I want to do is At Install: Copy mdf and ldf files but not overwrite existing files. Attach the database. At uninstall Detach the database. At major upgrade. Do nothing. Any Ideas? Can the SqlDatabase element with SqlFileSpec and SqlLogFileSpec be used in some way to attach a pair of mdf/ldf files? Best regards Peter Björkman Component Id=DatabaseAttachment Guid= Sql:SqlString SqlDb=MasterDB Id=AttachScript ContinueOnError=no ExecuteOnInstall=yes SQL=sp_attach_db @dbname=N'[DATABASE_NAME]', @filename1=N'[INSTALLDIR]Database\MultiAccess.mdf', @filename2=N'[INSTALLDIR]Database\MultiAccess.ldf' Sequence=1 / Sql:SqlString SqlDb=MasterDB Id=DetachScript ContinueOnError=yes ExecuteOnUninstall=yes SQL= exec sp_detach_db @dbname='[DATABASE_NAME]', @skipchecks='true'; Sequence=1 / /Component -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Log File name
So it looks like I can set logging to verbose in WiX with this property: Property Id=LOGVERBOSE1/Property Is there a way in WiX to set the default logfile name, and have it be created in the same folder as the .msi? Thanks. - Phil -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] question about DTF Session object
That's because your problematic custom action is deferred. If you mark it as immediate, you'll be able to access the Database property and read the properties. In deferred actions you are supposed to use special CustomActionData property to read the data from. -- Yan -Original Message- From: Amy Rosewater [mailto:arosewa...@spectrumhr.com] Sent: Wednesday, January 21, 2009 5:28 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] question about DTF Session object Hi All, I have an install in which I have written custom actions using C# and DTF. One of my custom actions that I have written is scheduled to execute after RemoveFolders during uninstall only. It is not working as expected, and when I debug into my custom action I find that the Session object does not have values for most of the properties from my install. Additionally the database is not accessible. Is there anyone who can give me more information about when the properties and database from the session will still be available? Thanks, Amy Amy Rosewater SPECTRUM Human Resource Systems Corporation 707 17th Street Suite 3800 Denver CO, 80202 303.592.3403 arosewa...@spectrumhr.com -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] question about DTF Session object
Hi Yan, Thanks for the reply. I do actually want the custom action to execute deferred...that was intentional. However, your information the the CustomActionData property is helpful. Thanks, A -Original Message- From: Yan Sklyarenko [mailto:y...@sitecore.net] Sent: Wednesday, January 21, 2009 8:51 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] question about DTF Session object That's because your problematic custom action is deferred. If you mark it as immediate, you'll be able to access the Database property and read the properties. In deferred actions you are supposed to use special CustomActionData property to read the data from. -- Yan -Original Message- From: Amy Rosewater [mailto:arosewa...@spectrumhr.com] Sent: Wednesday, January 21, 2009 5:28 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] question about DTF Session object Hi All, I have an install in which I have written custom actions using C# and DTF. One of my custom actions that I have written is scheduled to execute after RemoveFolders during uninstall only. It is not working as expected, and when I debug into my custom action I find that the Session object does not have values for most of the properties from my install. Additionally the database is not accessible. Is there anyone who can give me more information about when the properties and database from the session will still be available? Thanks, Amy Amy Rosewater SPECTRUM Human Resource Systems Corporation 707 17th Street Suite 3800 Denver CO, 80202 303.592.3403 arosewa...@spectrumhr.com -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Create database by attaching mdf and ldf file
I have recently managed to implement something similar for my installation. You can find the whole story here: http://ysdevlog.blogspot.com/2009/01/attach-detach-database-during.html Also this mail archive contains a number of relative examples, for instance, in this thread: http://n2.nabble.com/Attach-a-database-td712370.html#a712373 Hope this helps. -- Yan -Original Message- From: Peter Björkman [mailto:peter.bjork...@aptus.se] Sent: Wednesday, January 21, 2009 5:48 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Create database by attaching mdf and ldf file Hi everyone I have been trying to create a database by attaching a pair of mdf/ldf files. I can't get it to work properly so I hope someone has an easy solution for this. I have been using a SqlString element with a call to sp_attach_db but I am getting problems. First I used the mdf file as keypath for the component but as I don't want any data to be destroyed at uninstall the component for the mdf and ldf files must be permanent and never be overwritten. Then I got the problem that the database was not attached if the files already existed on the machine. What I want to do is At Install: Copy mdf and ldf files but not overwrite existing files. Attach the database. At uninstall Detach the database. At major upgrade. Do nothing. Any Ideas? Can the SqlDatabase element with SqlFileSpec and SqlLogFileSpec be used in some way to attach a pair of mdf/ldf files? Best regards Peter Björkman Component Id=DatabaseAttachment Guid= Sql:SqlString SqlDb=MasterDB Id=AttachScript ContinueOnError=no ExecuteOnInstall=yes SQL=sp_attach_db @dbname=N'[DATABASE_NAME]', @filename1=N'[INSTALLDIR]Database\MultiAccess.mdf', @filename2=N'[INSTALLDIR]Database\MultiAccess.ldf' Sequence=1 / Sql:SqlString SqlDb=MasterDB Id=DetachScript ContinueOnError=yes ExecuteOnUninstall=yes SQL= exec sp_detach_db @dbname='[DATABASE_NAME]', @skipchecks='true'; Sequence=1 / /Component -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Log File name
This property enables verbose logging in WiX custom actions. It writes extra entries to the MSI log. See /src/ca/wcautil/wcalog.cpp in the WiX sources for more details. Take a look at MSI logging options running this command: msiexec /help So, in order to have very verbose log for WiX-based installation run it with the following command-line: msiexec /i YourPackage.msi LOGVERBOSE=1 /l*v install.log This works for me. Hope this helps. -- Yan -Original Message- From: phillip_sid...@dellteam.com [mailto:phillip_sid...@dellteam.com] Sent: Wednesday, January 21, 2009 5:51 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Log File name So it looks like I can set logging to verbose in WiX with this property: Property Id=LOGVERBOSE1/Property Is there a way in WiX to set the default logfile name, and have it be created in the same folder as the .msi? Thanks. - Phil -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Log File name
So I have this working from the command line already. What I want to do is duplicate the effect of LOGVERBOSE=1 /l*v MyPackage.log without having to provide it on the command line. Essentially I want the package to default to verbose logging to file in the same dir as the MSI with the name I define in WiX (hopefully). - Phil -Original Message- From: Yan Sklyarenko [mailto:y...@sitecore.net] Sent: Wednesday, January 21, 2009 10:13 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Log File name This property enables verbose logging in WiX custom actions. It writes extra entries to the MSI log. See /src/ca/wcautil/wcalog.cpp in the WiX sources for more details. Take a look at MSI logging options running this command: msiexec /help So, in order to have very verbose log for WiX-based installation run it with the following command-line: msiexec /i YourPackage.msi LOGVERBOSE=1 /l*v install.log This works for me. Hope this helps. -- Yan -Original Message- From: phillip_sid...@dellteam.com [mailto:phillip_sid...@dellteam.com] Sent: Wednesday, January 21, 2009 5:51 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Log File name So it looks like I can set logging to verbose in WiX with this property: Property Id=LOGVERBOSE1/Property Is there a way in WiX to set the default logfile name, and have it be created in the same folder as the .msi? Thanks. - Phil -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] InstallExecuteSequence in a fragment?
Trying to be tidy, I pulled out the CustomAction declarations relating to a particular aspect of my install into its own .wxs file. I have Fragment CustomAction... CustomAction... CustomAction... InstallSequence [...sequence the custom actions declared above] /InstallSequence Fragment Problem is, the InstallSequence seems to be ignored. I'm guessing that this is because it's not referenced in the Product element, which lives in a different file. How can cause InstallSequences defined in fragments to be merged into the one in the Product? Is the only way to use a .wxi include instead of a Fragment? Why then is Fragment a valid parent for InstallSequence? Thanks, Jeremy -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] InstallExecuteSequence in a fragment?
Hey Jeremy, In order to include code inside a fragment you must reference something. From the below snippet you provided you could reference a single CustomAction using CustomActionRefhttp://wix.sourceforge.net/manual-wix3/wix_xsd_customactionref.htm/. This will link in the rest of the fragment. Thanks, Brian Rogers Intelligence removes complexity. - Me http://icumove.spaces.live.com On Wed, Jan 21, 2009 at 8:32 AM, Jeremy Lew j...@liquidmachines.com wrote: Trying to be tidy, I pulled out the CustomAction declarations relating to a particular aspect of my install into its own .wxs file. I have Fragment CustomAction... CustomAction... CustomAction... InstallSequence [...sequence the custom actions declared above] /InstallSequence Fragment Problem is, the InstallSequence seems to be ignored. I'm guessing that this is because it's not referenced in the Product element, which lives in a different file. How can cause InstallSequences defined in fragments to be merged into the one in the Product? Is the only way to use a .wxi include instead of a Fragment? Why then is Fragment a valid parent for InstallSequence? Thanks, Jeremy -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question on selective patching
Sudhakaran, Suraj wrote: Even though the next version can have changes in several files, I want to build patches for selected 2 or 3 files. Since number of files to ignore is more I am not sure we can use the solution of explicitly list files to ignore in the UpgradedFilesToIgnore table. The only shortcut available with the old patch tools is to use the wildcarding available in the FTK column. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] InstallExecuteSequence in a fragment?
Jeremy Lew wrote: Problem is, the InstallSequence seems to be ignored. I'm guessing that this is because it's not referenced in the Product element, which lives in a different file. How can cause InstallSequences defined in fragments to be merged into the one in the Product? Is the only way to use a .wxi include instead of a Fragment? Why then is Fragment a valid parent for InstallSequence? CustomActionRef -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Log File name
phillip_sid...@dellteam.com wrote: So I have this working from the command line already. What I want to do is duplicate the effect of LOGVERBOSE=1 /l*v MyPackage.log without having to provide it on the command line. On MSI 4.0 and later, you can use the MsiLogging and MsiLogFileLocation properties. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Build wixlib with localization
Alexandr Naumuk wrote: After setting culture for project that is using my library everything works fine. Maybe anyone know how to build library with default localization set up. Wixlibs are collections of WiX objects; they don't have the concept of default localization set. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] InstallExecuteSequence in a fragment?
Got it (thanks Brian too). Is that a general rule, if you reference something in a fragment, the entire fragment is linked? -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Wednesday, January 21, 2009 11:42 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] InstallExecuteSequence in a fragment? Jeremy Lew wrote: Problem is, the InstallSequence seems to be ignored. I'm guessing that this is because it's not referenced in the Product element, which lives in a different file. How can cause InstallSequences defined in fragments to be merged into the one in the Product? Is the only way to use a .wxi include instead of a Fragment? Why then is Fragment a valid parent for InstallSequence? CustomActionRef -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] InstallExecuteSequence in a fragment?
Yes, that is the general rule. It works well if you are building wixlib files and only want to include what you NEED not everything that is there. Brian Rogers Intelligence removes complexity. - Me http://icumove.spaces.live.com On Wed, Jan 21, 2009 at 8:58 AM, Jeremy Lew j...@liquidmachines.com wrote: Got it (thanks Brian too). Is that a general rule, if you reference something in a fragment, the entire fragment is linked? -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Wednesday, January 21, 2009 11:42 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] InstallExecuteSequence in a fragment? Jeremy Lew wrote: Problem is, the InstallSequence seems to be ignored. I'm guessing that this is because it's not referenced in the Product element, which lives in a different file. How can cause InstallSequences defined in fragments to be merged into the one in the Product? Is the only way to use a .wxi include instead of a Fragment? Why then is Fragment a valid parent for InstallSequence? CustomActionRef -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Setting Environment Variable
I also saw this behaviour. It would be nice to know why. Rob Improvize1 wrote: I am setting system environment variable on a Windows Server 2003 system using the WiX Environment element like so: Environment Id=SetMyAppDir Action=set Name=MYAPPDIR Value=[INSTALLLOCATION] System=yes / I can verify in control panel - system after the installer runs that the it was successfully defined, but when I open a new console window the variable is not defined there. If I edit it in the control panel then open another console window, it is defined there. The opposite case is also true: after uninstalling and verifying that in the control panel that the environment variable has been removed, subsequent console windows still see it. So it seems something is not getting updated in the system cache. Is there some other action that can be taken in the installer to fix this (short of scheduling a reboot)? WiX 3.0.4130.0. Thanks. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] question on volumecostList control
skarthik_psg wrote: I am using wix 2.0. I tried building with different wix versions and ended up with the same problem. Can anyone please help me out? You're missing rows in the UIText table. See src\ext\UIExtension\wixlib\Common.wxs for how WixUI does it. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing a service wich is also a COM server
1. Looking at the fairly standard set of .Net and VB COM files I would
say these:
{62C8FE65-4EBB-45e7-B440-6E39B2CDBF29} - .NET Category
{40FC6ED5-2438-11CF-A3DB-080036F12502} - Automation Objects
{40FC6ED4-2438-11CF-A3DB-080036F12502} - Controls/Control
These seems to be quite common on VB COM components but aren't in
HKCR\Component Categories on my PC:
{0DE86A52-2BAA-11CF-A229-00AA003D7352} -
{0DE86A53-2BAA-11CF-A229-00AA003D7352}
{0DE86A57-2BAA-11CF-A229-00AA003D7352}
2. If you register a .Net COM assembly it adds a key under
InprocServer32 of the assembly version number with a duplicate of the
values at the InprocServer32 level - another reason for fixed assembly
versions :-)
3. We I guess it depends. These are used by all .Net COM assemblies:
HKCR\CLSID\{guid}\InprocServer32 Name=Class
HKCR\CLSID\{guid}\InprocServer32 Name=Assembly
HKCR\CLSID\{guid}\InprocServer32 Name=RuntimeVersion
HKCR\CLSID\{guid}\InprocServer32 Name=CodeBase
These are common in VB controls:
HKCR\CLSID\{guid}\MiscStatus
HKCR\CLSID\{guid}\ToolBoxBitmap32
I am not sure about these:
HKCR\TypeLib\{guid}\3.0 Name=PrimaryInteropAssemblyName
HKCR\Interface\{guid}\Forward
Neil
-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com]
Sent: 21 January 2009 06:53
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Installing a service wich is also a COM server
1. there is already support for the two most common Implemented
Categories. Do you know others that need support?
2. What is InprocServer32\1.2.3.4?
3. Does anybody actually use that other stuff?
-Original Message-
From: Neil Sleightholm [mailto:n...@x2systems.com]
Sent: Tuesday, January 20, 2009 22:28
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Installing a service wich is also a COM server
Like which ones?
Implemented Categories:
HKCR\CLSID\{guid1}\Implemented Categories\{guid2}
Any entries for assemblies:
CLSID\{guid}\InprocServer32\1.2.3.4
These are generated from Heat I have to admit I don't know what they
are!
HKCR\Component Categories\{guid1}
HKCR\Record\{guid1}\1.2.3.4
This is from Heat and I am not sure why it couldn't be a Typelib
HKCR\TypeLib\{guid1}\1.0
These are probably more obscure:
HKCR\CLSID\{guid}\InprocServer32 Name=Class
HKCR\CLSID\{guid}\InprocServer32 Name=Assembly
HKCR\CLSID\{guid}\InprocServer32 Name=RuntimeVersion
HKCR\CLSID\{guid}\InprocServer32 Name=CodeBase
HKCR\TypeLib\{guid}\3.0 Name=PrimaryInteropAssemblyName
HKCR\Interface\{guid}\Forward
HKCR\CLSID\{guid}\MiscStatus
HKCR\CLSID\{guid}\ToolBoxBitmap32
Neil
-Original Message-
From: Rob Mensching [mailto:rob.mensch...@microsoft.com]
Sent: 20 January 2009 17:36
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Installing a service wich is also a COM server
Like which ones?
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX custom dialogs insight.
There is some information on customising the standard dialogs here: http://neilsleightholm.blogspot.com/2008/08/customised-uis-for-wix.html. I use WiXEdit to create the dialogs: http://wixedit.sourceforge.net/. It is a bit clunky but quicker than doing it by hand. Neil -Original Message- From: Tezuka Kunimitsu [mailto:osu...@gmail.com] Sent: 21 January 2009 13:31 To: wix-users@lists.sourceforge.net Subject: [WiX-users] WiX custom dialogs insight. We are currently developing a new product and would like to use WiX to create our installer, but we still have some doubts about WiX usage. The version of WiX in question is v3. The problem is our installer does not make use only of WiX dialog sets (WixUI_Mondo, WixUI_InstallDir and so on), but it has some custom dialogs like 'Select SQl Server dialog', 'Inform user and password' and others that is not present on these sets. We also need to write values in the registry and install and lauch a service. This seems like a common scenario, but we couldn't find the right way to these things, and the scarse WiX documentation on the internet wasn't helping much. We were able to make a Wix installer that is launching a Wizard (that we made in Windows Forms) during the WiX installation process, this Wizard has the custom dialogs that we need. But after collecting some more info, we realized that the WiX dialogs order can be modified and it's possible to create new dialogs only using the WiX syntax and Custom Actions. What would be the right way to do this? 1) Create our custom dialogs using WiX syntax and integrate them with the WiX dialogs sets, if it's really possible to create any type of dialog using only this. 2) Create our custom dialogs in a separate project using Windows Forms, WPF or whatever and launch this during or after the installation process. Much like what is being made with our currently installer. 3) Other option...? Thank you for your help. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX custom dialogs insight.
I would like to thank you all for the help and links. They will certainly help us a lot. :) On Wed, Jan 21, 2009 at 3:35 PM, Neil Sleightholm n...@x2systems.comwrote: There is some information on customising the standard dialogs here: http://neilsleightholm.blogspot.com/2008/08/customised-uis-for-wix.html. I use WiXEdit to create the dialogs: http://wixedit.sourceforge.net/. It is a bit clunky but quicker than doing it by hand. Neil -Original Message- From: Tezuka Kunimitsu [mailto:osu...@gmail.com] Sent: 21 January 2009 13:31 To: wix-users@lists.sourceforge.net Subject: [WiX-users] WiX custom dialogs insight. We are currently developing a new product and would like to use WiX to create our installer, but we still have some doubts about WiX usage. The version of WiX in question is v3. The problem is our installer does not make use only of WiX dialog sets (WixUI_Mondo, WixUI_InstallDir and so on), but it has some custom dialogs like 'Select SQl Server dialog', 'Inform user and password' and others that is not present on these sets. We also need to write values in the registry and install and lauch a service. This seems like a common scenario, but we couldn't find the right way to these things, and the scarse WiX documentation on the internet wasn't helping much. We were able to make a Wix installer that is launching a Wizard (that we made in Windows Forms) during the WiX installation process, this Wizard has the custom dialogs that we need. But after collecting some more info, we realized that the WiX dialogs order can be modified and it's possible to create new dialogs only using the WiX syntax and Custom Actions. What would be the right way to do this? 1) Create our custom dialogs using WiX syntax and integrate them with the WiX dialogs sets, if it's really possible to create any type of dialog using only this. 2) Create our custom dialogs in a separate project using Windows Forms, WPF or whatever and launch this during or after the installation process. Much like what is being made with our currently installer. 3) Other option...? Thank you for your help. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] question about DTF Session object
Is the CustomAction deferred? If so, there are a lot of restrictions on deferred CustomActions. The MSI SDK details this. -Original Message- From: Amy Rosewater [mailto:arosewa...@spectrumhr.com] Sent: Wednesday, January 21, 2009 07:28 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] question about DTF Session object Hi All, I have an install in which I have written custom actions using C# and DTF. One of my custom actions that I have written is scheduled to execute after RemoveFolders during uninstall only. It is not working as expected, and when I debug into my custom action I find that the Session object does not have values for most of the properties from my install. Additionally the database is not accessible. Is there anyone who can give me more information about when the properties and database from the session will still be available? Thanks, Amy Amy Rosewater SPECTRUM Human Resource Systems Corporation 707 17th Street Suite 3800 Denver CO, 80202 303.592.3403 arosewa...@spectrumhr.com -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Prevent reboot.
MSI verbose log file should point out the file being locked. Then you just need to figure out how to get the thing to be unlocked. That's how Windows works. It's perfectly sane, just not always very convenient. smile/ -Original Message- From: Adam Burton [mailto:adz...@googlemail.com] Sent: Wednesday, January 21, 2009 06:00 To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Prevent reboot. Hi, I have created some WiX based installers for some services and a web application I am working on at work. We use the installers as part of our test rigs, so we patch our test changes, build the new version and install it. Since this whole process is automated if the MSI determines it needs to reboot, it will. Previously when I installed the services it would cause a reboot, I assume due to file locks even though the installer would stop the service. My resolution was to stop the service before performing the upgrade, this seems to have solved that issue, although it seems unnecessary. I am now getting the same problem with the Web Application. It automatically deploys a new test build 2 times during the day, once in early morning before anyone is here and once at lunch. The morning build runs fine (I would guess this is because no ones use the application for hours so IIS has released its file locks) but the afternoon builds during lunch forces a reboot most of the time (I would guess because IIS has file locks due to recent activity), which is not only annoying because its rebooting the server, but also the server hosts other software (such as virtual servers) taking that down. I have tried stopping IIS before it begins the install but it still causes a reboot most of the time. Is there a switch that could solve this or some way to make windows locking more sane or something? I am just stumped. Thanks in advance, Adam. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] CustomAction accessing CustomTable
Sorry, no extra data for you. It seems like it should work. -Original Message- From: jballe [mailto:j...@visionpeople.dk] Sent: Wednesday, January 21, 2009 03:42 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] CustomAction accessing CustomTable Hello all, Can I do anything to clearify the issue. Is it not supposed to work? I am using WIX 3.0.4805.0, developing using Visual Studio 2008 with Votive Thank you! Jesper jballe wrote: Hello all, I am writing my first complex setup using wix and managed custom actions using c#. During the setup the user enters some settings. I have created an immediate customaction which saves those settings as rows in a CustomTable when the user clicks next. When I debug this customaction it seems to me that the records are successfully saved. I have scheduled an immediate customaction after InstallFiles which should read this customtable and schedule customactions as deferred, callback, commit with the data from this customtable as CustomData using the CustomData class. However, when this immediate custom action executes it retrieves no rows from the custom table. I save the records using InsertTemporary as I cannot use Insert and have read that this should not be possible during the installation process. -- View this message in context: http://n2.nabble.com/CustomAction-accessing-CustomTable-tp2181353p2191781.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] MsiGetProperty and MsiSetProperty in C#.
Hi, Can anyone help me know if MsiGetProperty and MsiSetProperty are available to use in C#? if yes! little guidance on how to use would help. I have used these in C++ before, just wondering if possible in c#. In C++: uRetVal = MsiSetProperty(hInstall,LOCAL_TIMEZONE,(LPCWSTR)retstr.ToPointer()); Thanks Sachin -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Editing MSI properties in WiX 3.0.
Hi, I am working on adding prerequisite check dialog to the MSI, I have a List View, where the List Items are all the software need to be checked. My questions is how to dynamically change add/remove or change the icon of, List Items on pass or failure of the prerequisite check. In more easy words - what's the best way to add prerequisite check dialog box using WiX 3.0? Any help would be greatly appreciated. I know in WiX 2.0, we had to use C++ code to edit the property of the MSI (using MsiGetProperty, MsiSetProperty, MsiCreateRecord and other functions) after performing the checks and then add/remove list items as needed. Just wondering if there is any easy way of doing so in WiX 3.0. If not possible directly through WiX, is there a way to handle this in c#? Thanks Sachin -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Editing MSI properties in WiX 3.0.
1. WiX provides no such dialog built in today. 2. DTF is a C# layer around the MSI APIs. -Original Message- From: Sachin Dubey (Tata Consultancy Services) [mailto:v-sad...@microsoft.com] Sent: Wednesday, January 21, 2009 10:16 To: General discussion for Windows Installer XML toolset. Cc: Pete Maroun Subject: [WiX-users] Editing MSI properties in WiX 3.0. Hi, I am working on adding prerequisite check dialog to the MSI, I have a List View, where the List Items are all the software need to be checked. My questions is how to dynamically change add/remove or change the icon of, List Items on pass or failure of the prerequisite check. In more easy words - what's the best way to add prerequisite check dialog box using WiX 3.0? Any help would be greatly appreciated. I know in WiX 2.0, we had to use C++ code to edit the property of the MSI (using MsiGetProperty, MsiSetProperty, MsiCreateRecord and other functions) after performing the checks and then add/remove list items as needed. Just wondering if there is any easy way of doing so in WiX 3.0. If not possible directly through WiX, is there a way to handle this in c#? Thanks Sachin -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] how to read appsettings values within wix
Hi, I have a requirement to build an installer the does the following: 1 - the installer should read an appsettings value from a pre existing web.config on the target machine. 2 - This value should then be used to edit a web.config file before writing it, as a new file to the target directory (different than the directory where the first web.config resides) I can get step 2 done easily with the Util:XmlFile, but I don't have a way to extract the value, as described in step 1. I can imagine an XmlSearch or an AppSettingsSearch tag would be a nice way to solve this. Is there such an animal? If not, how difficult would it be to write one? Thanks, Mordecai Netik LLC - Incorporated with limited liability in the State of Delaware, USA Head Office: 40 Fulton Street, 11th Floor, New York, NY 10038, USA London Branch registered in England Wales with Company No FC025482 and Branch No BR007789 London Branch Office: Broken Wharf House, 2 Broken Wharf, High Timber Street, London EC4V 3DT, United Kingdom. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] InstallExecuteSequence in a fragment?
I posted a bug on this, but I got it classified as invalid, since you can use CustomActionRef; as Bob wrote. What I did was to include an empty ComponentGroup in the fragment, and a reference to the component group from Product.wxs, this way I don't need to set a CustomActionRef for every custom action. Kind of: Product Feature ComponentGroupRef Id='CAGroup' / /Feature /Product Fragment ComponentGroup Id='CAGroup' / !--ALL Custom Actions go here -- /Fragment -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Wednesday, January 21, 2009 6:42 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] InstallExecuteSequence in a fragment? Jeremy Lew wrote: Problem is, the InstallSequence seems to be ignored. I'm guessing that this is because it's not referenced in the Product element, which lives in a different file. How can cause InstallSequences defined in fragments to be merged into the one in the Product? Is the only way to use a .wxi include instead of a Fragment? Why then is Fragment a valid parent for InstallSequence? CustomActionRef -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] InstallExecuteSequence in a fragment?
Eitan Behar wrote: What I did was to include an empty ComponentGroup in the fragment, and a reference to the component group from Product.wxs, this way I don't need to set a CustomActionRef for every custom action. You don't need a CustomActionRef for every custom action, just one for the fragment. WiX links in whole fragments, so any one reference brings in the whole thing. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Editing MSI properties in WiX 3.0.
Sachin Dubey (Tata Consultancy Services) wrote: Would be great if you can point me to any web reading on DTF, where I can found the details of available APIs and there uses that can help be achieve my gaols. Every build of WiX includes DTF help file shortcuts on the Start menu. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] InstallExecuteSequence in a fragment?
Also, if you write your CustomActions to be data driven, you usually end up with something else more natural that brings them in. -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Wednesday, January 21, 2009 11:15 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] InstallExecuteSequence in a fragment? Eitan Behar wrote: What I did was to include an empty ComponentGroup in the fragment, and a reference to the component group from Product.wxs, this way I don't need to set a CustomActionRef for every custom action. You don't need a CustomActionRef for every custom action, just one for the fragment. WiX links in whole fragments, so any one reference brings in the whole thing. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] InstallExecuteSequence in a fragment?
Mmm, I was not aware of that, probably I didn't read the whole response to the bug resolution 8^) Well, in any case, when working with several Wixers, I prefer linking to a dummy element and not to a real custom action, since that way I give 100% flexibility to the wix fragment owner. But, well, this is just a matter of taste. -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Wednesday, January 21, 2009 9:15 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] InstallExecuteSequence in a fragment? Eitan Behar wrote: What I did was to include an empty ComponentGroup in the fragment, and a reference to the component group from Product.wxs, this way I don't need to set a CustomActionRef for every custom action. You don't need a CustomActionRef for every custom action, just one for the fragment. WiX links in whole fragments, so any one reference brings in the whole thing. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Prevent reboot.
I don't know about that. I can understand why it gets the locks etc, but its the releasing that seems to mess up for me, or behave in a manor I would not except. For example the services I install ... why are files still locked when the msi stops the service ... the service is the only thing that will use those file ... I can't see why I should need to stop the service for the msi before hand. Same with the IIS files, IIS is stopped, it should release those DLLs that are only accessed by IIS (they live in the website 'bin' directory, surely once IIS is stopped it has no use for them and should release them). I have just always assumed that it is a separate service/process/thread that releases the locks and its just too slow off the mark for the MSI. If that is the case though then you'd think there'd be stuff in Windows Installer that would take that into account so I'd at least only be rebooting every so often rather than a majority of the time. Also its not uncommon for me to delete a directory and the directory wont go away. With some inspection using stuff like process explorer it appears System has a lock on it (presumably for shi**z and giggles), soon as you kill the handle the directory goes. While the lock idea is sane, Windows implementation doesn't seem to work for me, therefore in its current state it's not sane for me :-). Before anyone thinks I am Windows bashing this is just one of the gripes I have with Windows, I have plenty of gripes with other OS's too. Although I have to say on the plus side I am yet to encounter the issue in Vista, but that being said I don't tend to delete directories often or install already running services in Vista so maybe I've just not trodden the path :-). Regardless I must be doing something else wrong because even if I got the file's name from the log file I still wouldn't know where to start. Anything that is supposed to use the files, in the case of IIS, is shut down and for the services it is shut down by Windows installer which I would think is smart enough to handle a situation like shutting down the service correctly so any files locked only by it will be released sometimes preventing the requirement of a reboot. On Wednesday 21 January 2009 18:03:05 Rob Mensching wrote: MSI verbose log file should point out the file being locked. Then you just need to figure out how to get the thing to be unlocked. That's how Windows works. It's perfectly sane, just not always very convenient. smile/ -Original Message- From: Adam Burton [mailto:adz...@googlemail.com] Sent: Wednesday, January 21, 2009 06:00 To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Prevent reboot. Hi, I have created some WiX based installers for some services and a web application I am working on at work. We use the installers as part of our test rigs, so we patch our test changes, build the new version and install it. Since this whole process is automated if the MSI determines it needs to reboot, it will. Previously when I installed the services it would cause a reboot, I assume due to file locks even though the installer would stop the service. My resolution was to stop the service before performing the upgrade, this seems to have solved that issue, although it seems unnecessary. I am now getting the same problem with the Web Application. It automatically deploys a new test build 2 times during the day, once in early morning before anyone is here and once at lunch. The morning build runs fine (I would guess this is because no ones use the application for hours so IIS has released its file locks) but the afternoon builds during lunch forces a reboot most of the time (I would guess because IIS has file locks due to recent activity), which is not only annoying because its rebooting the server, but also the server hosts other software (such as virtual servers) taking that down. I have tried stopping IIS before it begins the install but it still causes a reboot most of the time. Is there a switch that could solve this or some way to make windows locking more sane or something? I am just stumped. Thanks in advance, Adam. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] how to read appsettings values within wix
Rob, Thanks For your prompt response. The code that you mention having to write (read data, set properties...) what form does it take? (I can write it in c#) but what should I be building? An wix extension? Is there any tutorials on the subject? Thanks, Mordecai -Original Message- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: Wednesday, January 21, 2009 1:30 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] how to read appsettings values within wix Doesn't exist today (unfortunately)... probably not too hard since you don't have to modify machine state. Just read data, set properties... let XmlConfig do all the heavy lifting (aka: install/uninstall/rollback/etc.). -Original Message- From: Mordecai Zibkoff [mailto:mzibk...@netik.com] Sent: Wednesday, January 21, 2009 10:28 To: wix-users@lists.sourceforge.net Subject: [WiX-users] how to read appsettings values within wix Hi, I have a requirement to build an installer the does the following: 1 - the installer should read an appsettings value from a pre existing web.config on the target machine. 2 - This value should then be used to edit a web.config file before writing it, as a new file to the target directory (different than the directory where the first web.config resides) I can get step 2 done easily with the Util:XmlFile, but I don't have a way to extract the value, as described in step 1. I can imagine an XmlSearch or an AppSettingsSearch tag would be a nice way to solve this. Is there such an animal? If not, how difficult would it be to write one? Thanks, Mordecai Netik LLC - Incorporated with limited liability in the State of Delaware, USA Head Office: 40 Fulton Street, 11th Floor, New York, NY 10038, USA London Branch registered in England Wales with Company No FC025482 and Branch No BR007789 London Branch Office: Broken Wharf House, 2 Broken Wharf, High Timber Street, London EC4V 3DT, United Kingdom. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Prevent reboot.
Adam, I suspect there is something more going on here. We have been following a test deployment process like yours for several years for a suite of large web applications, and the only time we have file lock issues is if someone is actively testing (hitting the pages) when the upgrade occurs. Michael -Original Message- From: Adam Burton [mailto:adz...@googlemail.com] Sent: Thursday, 22 January 2009 5:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Prevent reboot. I don't know about that. I can understand why it gets the locks etc, but its the releasing that seems to mess up for me, or behave in a manor I would not except. For example the services I install ... why are files still locked when the msi stops the service ... the service is the only thing that will use those file ... I can't see why I should need to stop the service for the msi before hand. Same with the IIS files, IIS is stopped, it should release those DLLs that are only accessed by IIS (they live in the website 'bin' directory, surely once IIS is stopped it has no use for them and should release them). I have just always assumed that it is a separate service/process/thread that releases the locks and its just too slow off the mark for the MSI. If that is the case though then you'd think there'd be stuff in Windows Installer that would take that into account so I'd at least only be rebooting every so often rather than a majority of the time. Also its not uncommon for me to delete a directory and the directory wont go away. With some inspection using stuff like process explorer it appears System has a lock on it (presumably for shi**z and giggles), soon as you kill the handle the directory goes. While the lock idea is sane, Windows implementation doesn't seem to work for me, therefore in its current state it's not sane for me :-). Before anyone thinks I am Windows bashing this is just one of the gripes I have with Windows, I have plenty of gripes with other OS's too. Although I have to say on the plus side I am yet to encounter the issue in Vista, but that being said I don't tend to delete directories often or install already running services in Vista so maybe I've just not trodden the path :-). Regardless I must be doing something else wrong because even if I got the file's name from the log file I still wouldn't know where to start. Anything that is supposed to use the files, in the case of IIS, is shut down and for the services it is shut down by Windows installer which I would think is smart enough to handle a situation like shutting down the service correctly so any files locked only by it will be released sometimes preventing the requirement of a reboot. On Wednesday 21 January 2009 18:03:05 Rob Mensching wrote: MSI verbose log file should point out the file being locked. Then you just need to figure out how to get the thing to be unlocked. That's how Windows works. It's perfectly sane, just not always very convenient. smile/ -Original Message- From: Adam Burton [mailto:adz...@googlemail.com] Sent: Wednesday, January 21, 2009 06:00 To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Prevent reboot. Hi, I have created some WiX based installers for some services and a web application I am working on at work. We use the installers as part of our test rigs, so we patch our test changes, build the new version and install it. Since this whole process is automated if the MSI determines it needs to reboot, it will. Previously when I installed the services it would cause a reboot, I assume due to file locks even though the installer would stop the service. My resolution was to stop the service before performing the upgrade, this seems to have solved that issue, although it seems unnecessary. I am now getting the same problem with the Web Application. It automatically deploys a new test build 2 times during the day, once in early morning before anyone is here and once at lunch. The morning build runs fine (I would guess this is because no ones use the application for hours so IIS has released its file locks) but the afternoon builds during lunch forces a reboot most of the time (I would guess because IIS has file locks due to recent activity), which is not only annoying because its rebooting the server, but also the server hosts other software (such as virtual servers) taking that down. I have tried stopping IIS before it begins the install but it still causes a reboot most of the time. Is there a switch that could solve this or some way to make windows locking more sane or something? I am just stumped. Thanks in advance, Adam. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing
Re: [WiX-users] Prevent reboot.
Michael, Well yea that will be sorta the case. Some people will probably be in the middle of using the site (if the poor souls are sad enough or getting close to dead line to feel the need to work during lunch :-) ), not had chance to tell it to send out a warning email yet ... although they should know by now when it is going to happen, when suddenly the process stops IIS and copies the MSI to a place accessible by the server then installs it (the MSI is about 30MB for the website, with our poor network at this time we are talking several (10-20) seconds before its copied and started the install which I feel is enough time for IIS to release the locks on any dlls). At least with the services I can understand Windows Installer maybe being too quick to start installing before we its let the service settle (althought like i said I would think its smarter than that) but the website I am a bit stumped with. Adam On Wednesday 21 January 2009 22:10:55 Michael Osmond wrote: Adam, I suspect there is something more going on here. We have been following a test deployment process like yours for several years for a suite of large web applications, and the only time we have file lock issues is if someone is actively testing (hitting the pages) when the upgrade occurs. Michael -Original Message- From: Adam Burton [mailto:adz...@googlemail.com] Sent: Thursday, 22 January 2009 5:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Prevent reboot. I don't know about that. I can understand why it gets the locks etc, but its the releasing that seems to mess up for me, or behave in a manor I would not except. For example the services I install ... why are files still locked when the msi stops the service ... the service is the only thing that will use those file ... I can't see why I should need to stop the service for the msi before hand. Same with the IIS files, IIS is stopped, it should release those DLLs that are only accessed by IIS (they live in the website 'bin' directory, surely once IIS is stopped it has no use for them and should release them). I have just always assumed that it is a separate service/process/thread that releases the locks and its just too slow off the mark for the MSI. If that is the case though then you'd think there'd be stuff in Windows Installer that would take that into account so I'd at least only be rebooting every so often rather than a majority of the time. Also its not uncommon for me to delete a directory and the directory wont go away. With some inspection using stuff like process explorer it appears System has a lock on it (presumably for shi**z and giggles), soon as you kill the handle the directory goes. While the lock idea is sane, Windows implementation doesn't seem to work for me, therefore in its current state it's not sane for me :-). Before anyone thinks I am Windows bashing this is just one of the gripes I have with Windows, I have plenty of gripes with other OS's too. Although I have to say on the plus side I am yet to encounter the issue in Vista, but that being said I don't tend to delete directories often or install already running services in Vista so maybe I've just not trodden the path :-). Regardless I must be doing something else wrong because even if I got the file's name from the log file I still wouldn't know where to start. Anything that is supposed to use the files, in the case of IIS, is shut down and for the services it is shut down by Windows installer which I would think is smart enough to handle a situation like shutting down the service correctly so any files locked only by it will be released sometimes preventing the requirement of a reboot. On Wednesday 21 January 2009 18:03:05 Rob Mensching wrote: MSI verbose log file should point out the file being locked. Then you just need to figure out how to get the thing to be unlocked. That's how Windows works. It's perfectly sane, just not always very convenient. smile/ -Original Message- From: Adam Burton [mailto:adz...@googlemail.com] Sent: Wednesday, January 21, 2009 06:00 To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Prevent reboot. Hi, I have created some WiX based installers for some services and a web application I am working on at work. We use the installers as part of our test rigs, so we patch our test changes, build the new version and install it. Since this whole process is automated if the MSI determines it needs to reboot, it will. Previously when I installed the services it would cause a reboot, I assume due to file locks even though the installer would stop the service. My resolution was to stop the service before performing the upgrade, this seems to have solved that issue, although it seems unnecessary. I am now getting the same problem with the Web Application. It automatically deploys
Re: [WiX-users] Prevent reboot.
Adam, I agree (and our experience bears it out), IIS reset should kill off any thing that the web app is doing (actually we rarely even need to do that. Unless is some of the web application code is in COM+, that can have a life of its own. Michael -Original Message- From: Adam Burton [mailto:adz...@googlemail.com] Sent: Thursday, 22 January 2009 8:28 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Prevent reboot. Michael, Well yea that will be sorta the case. Some people will probably be in the middle of using the site (if the poor souls are sad enough or getting close to dead line to feel the need to work during lunch :-) ), not had chance to tell it to send out a warning email yet ... although they should know by now when it is going to happen, when suddenly the process stops IIS and copies the MSI to a place accessible by the server then installs it (the MSI is about 30MB for the website, with our poor network at this time we are talking several (10-20) seconds before its copied and started the install which I feel is enough time for IIS to release the locks on any dlls). At least with the services I can understand Windows Installer maybe being too quick to start installing before we its let the service settle (althought like i said I would think its smarter than that) but the website I am a bit stumped with. Adam On Wednesday 21 January 2009 22:10:55 Michael Osmond wrote: Adam, I suspect there is something more going on here. We have been following a test deployment process like yours for several years for a suite of large web applications, and the only time we have file lock issues is if someone is actively testing (hitting the pages) when the upgrade occurs. Michael -Original Message- From: Adam Burton [mailto:adz...@googlemail.com] Sent: Thursday, 22 January 2009 5:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Prevent reboot. I don't know about that. I can understand why it gets the locks etc, but its the releasing that seems to mess up for me, or behave in a manor I would not except. For example the services I install ... why are files still locked when the msi stops the service ... the service is the only thing that will use those file ... I can't see why I should need to stop the service for the msi before hand. Same with the IIS files, IIS is stopped, it should release those DLLs that are only accessed by IIS (they live in the website 'bin' directory, surely once IIS is stopped it has no use for them and should release them). I have just always assumed that it is a separate service/process/thread that releases the locks and its just too slow off the mark for the MSI. If that is the case though then you'd think there'd be stuff in Windows Installer that would take that into account so I'd at least only be rebooting every so often rather than a majority of the time. Also its not uncommon for me to delete a directory and the directory wont go away. With some inspection using stuff like process explorer it appears System has a lock on it (presumably for shi**z and giggles), soon as you kill the handle the directory goes. While the lock idea is sane, Windows implementation doesn't seem to work for me, therefore in its current state it's not sane for me :-). Before anyone thinks I am Windows bashing this is just one of the gripes I have with Windows, I have plenty of gripes with other OS's too. Although I have to say on the plus side I am yet to encounter the issue in Vista, but that being said I don't tend to delete directories often or install already running services in Vista so maybe I've just not trodden the path :-). Regardless I must be doing something else wrong because even if I got the file's name from the log file I still wouldn't know where to start. Anything that is supposed to use the files, in the case of IIS, is shut down and for the services it is shut down by Windows installer which I would think is smart enough to handle a situation like shutting down the service correctly so any files locked only by it will be released sometimes preventing the requirement of a reboot. On Wednesday 21 January 2009 18:03:05 Rob Mensching wrote: MSI verbose log file should point out the file being locked. Then you just need to figure out how to get the thing to be unlocked. That's how Windows works. It's perfectly sane, just not always very convenient. smile/ -Original Message- From: Adam Burton [mailto:adz...@googlemail.com] Sent: Wednesday, January 21, 2009 06:00 To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Prevent reboot. Hi, I have created some WiX based installers for some services and a web application I am working on at work. We use the installers as part of our test rigs, so we patch our test changes, build the new version and install it. Since
Re: [WiX-users] Not able to install votive
It's been a while since I've touched Votive 2 code so my memory may be hazy, but I don't think Votive 2 is supported under VS 2008. It's designed for VS 2003/2005. If you want to use VS 2008, I recommend upgrading to Votive 3. Even if Votive 2 works under VS 2008, there has been so much added to Votive 3 (bug fixes and features) that it's definitely worth your while trying it out. Justin -Original Message- From: Murtaza Chowdhury [mailto:murta...@microsoft.com] Sent: Wednesday, January 21, 2009 2:21 AM To: wix-users@lists.sourceforge.net Cc: Mayank Chhajed Subject: [WiX-users] Not able to install votive When I try to install Votive 2.0.5805.0 on Visual Studio 2008, I get the following error message : WIX Toolset Visual Studio Package requires the Standard, Professional, or Team editions of Visual Studio; Express editions are not supported. I have the Team edition and not the express edition but somehow votive thinks that the other way. Has anybody come across this problem. What is the resolution ? Any pointers will be highly appreciated. Regards, Murtaza Chowdhury -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Prevent reboot.
We have a large web site, too. With many services running beside IIS. Any time we get locks I take a verbose log and search for in use and it always tells me the process that has the file in use and I can make some correction to take care of it. Never been a problem that could be handled so far. -Original Message- From: Adam Burton [mailto:adz...@googlemail.com] Sent: Wednesday, January 21, 2009 2:28 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Prevent reboot. Michael, Well yea that will be sorta the case. Some people will probably be in the middle of using the site (if the poor souls are sad enough or getting close to dead line to feel the need to work during lunch :-) ), not had chance to tell it to send out a warning email yet ... although they should know by now when it is going to happen, when suddenly the process stops IIS and copies the MSI to a place accessible by the server then installs it (the MSI is about 30MB for the website, with our poor network at this time we are talking several (10-20) seconds before its copied and started the install which I feel is enough time for IIS to release the locks on any dlls). At least with the services I can understand Windows Installer maybe being too quick to start installing before we its let the service settle (althought like i said I would think its smarter than that) but the website I am a bit stumped with. Adam On Wednesday 21 January 2009 22:10:55 Michael Osmond wrote: Adam, I suspect there is something more going on here. We have been following a test deployment process like yours for several years for a suite of large web applications, and the only time we have file lock issues is if someone is actively testing (hitting the pages) when the upgrade occurs. Michael -Original Message- From: Adam Burton [mailto:adz...@googlemail.com] Sent: Thursday, 22 January 2009 5:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Prevent reboot. I don't know about that. I can understand why it gets the locks etc, but its the releasing that seems to mess up for me, or behave in a manor I would not except. For example the services I install ... why are files still locked when the msi stops the service ... the service is the only thing that will use those file ... I can't see why I should need to stop the service for the msi before hand. Same with the IIS files, IIS is stopped, it should release those DLLs that are only accessed by IIS (they live in the website 'bin' directory, surely once IIS is stopped it has no use for them and should release them). I have just always assumed that it is a separate service/process/thread that releases the locks and its just too slow off the mark for the MSI. If that is the case though then you'd think there'd be stuff in Windows Installer that would take that into account so I'd at least only be rebooting every so often rather than a majority of the time. Also its not uncommon for me to delete a directory and the directory wont go away. With some inspection using stuff like process explorer it appears System has a lock on it (presumably for shi**z and giggles), soon as you kill the handle the directory goes. While the lock idea is sane, Windows implementation doesn't seem to work for me, therefore in its current state it's not sane for me :-). Before anyone thinks I am Windows bashing this is just one of the gripes I have with Windows, I have plenty of gripes with other OS's too. Although I have to say on the plus side I am yet to encounter the issue in Vista, but that being said I don't tend to delete directories often or install already running services in Vista so maybe I've just not trodden the path :-). Regardless I must be doing something else wrong because even if I got the file's name from the log file I still wouldn't know where to start. Anything that is supposed to use the files, in the case of IIS, is shut down and for the services it is shut down by Windows installer which I would think is smart enough to handle a situation like shutting down the service correctly so any files locked only by it will be released sometimes preventing the requirement of a reboot. On Wednesday 21 January 2009 18:03:05 Rob Mensching wrote: MSI verbose log file should point out the file being locked. Then you just need to figure out how to get the thing to be unlocked. That's how Windows works. It's perfectly sane, just not always very convenient. smile/ -Original Message- From: Adam Burton [mailto:adz...@googlemail.com] Sent: Wednesday, January 21, 2009 06:00 To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Prevent reboot. Hi, I have created some WiX based installers for some services and a web application I am working on at work. We use the installers as part of our test rigs, so we patch our test changes, build the new version and
[WiX-users] Setting the output name with a variable
I've asked this before but haven't gotten a solid answer, so I'll try one more time. I need to be able to incorporate a modified form of the package version into the .msi name. What would be ideal would be the ability to reference the !(bind.fileVersion.MyPackageEXE) as part of the output name, something like: DeluxeInstaller_!(bind.fileVersion.MyPackageEXE).msi I've had no luck shooting in the dark with different forms of the variable. Setting the OutputName field to include either a $() variable or a !() bind variable doesn't work, and the bind variable seems to no longer be in scope at the post-build-event stage (where I could simply write a line of DOS that renames the file. Is the only option to me at this point truly to write a separate stand-alone application that will have to go get the version information from the binaries itself and do a rename? That seems incredibly lame, since all the information I need is available during the wix processing, but I just don't seem to be able to get at it. I REALLY don't want to have to make an ugly hack just to add the version number into the filename. Please don't tell me that that is the only way. -- Regards, cf -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Prevent reboot.
::Rolls eyes and bows head:: oh I really hate COM it's always being difficult with me lol. I hadn't thought about the COM stuff, we run it as a server process so I bet that's still chilling out somewhere in the processes. I bet that when I run a verbose log tomorrow it will confirm that. Unfortunately as if COM didn't have enough of a life of its own the code we have in VB6 isn't really well maintained in terms of keeping binary compatibility etc so we don't keep the same GUIDs for components and so on, therefore my control of the COM isn't exactly ... clean. I suppose I may need to write a script that searches for our COM applications by name and performs a shutdown after stopping IIS, shouldn't be too hard. Although I guess it depends when the MSI performs its checks for file locks whether this is a cause of the problem. As (again ... unfortunately) I am forced to run a custom VBS script that registers the COM components (although I have to say due to the lack of proper maintaining of our COM components binary compatibility etc its made using WiX easier to use our custom scripts than the COMPlus extension, solve evil with evil I guess) and at the start of the install I run another VBS script that removes our COM applications before performing any file operation. At the moment though I am at home so I can't remember where I put the custom action in the sequence, but I would presume it would be before the lock checks (I am guessing they are done as it looks at each individual file on the fly not checks each file for locks then removes it or whatever) so removing the COM application should stop COM from locking its DLLs. Regardless I see 2 options, IIS is doing something funky with its file locks or I need to remove my COM applications earlier to prevent MSI bumping into COMs file locks. I guess I'll have to see tomorrow :-) ... pending I get the time. Thanks for your help so far. Adam On Wednesday 21 January 2009 22:59:01 Michael Osmond wrote: Adam, I agree (and our experience bears it out), IIS reset should kill off any thing that the web app is doing (actually we rarely even need to do that. Unless is some of the web application code is in COM+, that can have a life of its own. Michael -Original Message- From: Adam Burton [mailto:adz...@googlemail.com] Sent: Thursday, 22 January 2009 8:28 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Prevent reboot. Michael, Well yea that will be sorta the case. Some people will probably be in the middle of using the site (if the poor souls are sad enough or getting close to dead line to feel the need to work during lunch :-) ), not had chance to tell it to send out a warning email yet ... although they should know by now when it is going to happen, when suddenly the process stops IIS and copies the MSI to a place accessible by the server then installs it (the MSI is about 30MB for the website, with our poor network at this time we are talking several (10-20) seconds before its copied and started the install which I feel is enough time for IIS to release the locks on any dlls). At least with the services I can understand Windows Installer maybe being too quick to start installing before we its let the service settle (althought like i said I would think its smarter than that) but the website I am a bit stumped with. Adam On Wednesday 21 January 2009 22:10:55 Michael Osmond wrote: Adam, I suspect there is something more going on here. We have been following a test deployment process like yours for several years for a suite of large web applications, and the only time we have file lock issues is if someone is actively testing (hitting the pages) when the upgrade occurs. Michael -Original Message- From: Adam Burton [mailto:adz...@googlemail.com] Sent: Thursday, 22 January 2009 5:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Prevent reboot. I don't know about that. I can understand why it gets the locks etc, but its the releasing that seems to mess up for me, or behave in a manor I would not except. For example the services I install ... why are files still locked when the msi stops the service ... the service is the only thing that will use those file ... I can't see why I should need to stop the service for the msi before hand. Same with the IIS files, IIS is stopped, it should release those DLLs that are only accessed by IIS (they live in the website 'bin' directory, surely once IIS is stopped it has no use for them and should release them). I have just always assumed that it is a separate service/process/thread that releases the locks and its just too slow off the mark for the MSI. If that is the case though then you'd think there'd be stuff in Windows Installer that would take that into account so I'd at least only be rebooting every
Re: [WiX-users] Setting the output name with a variable
You need to separate the WiX toolset from MSBuild in your mind. Treat the WiX toolset the way you would treat csc.exe or vbc.exe or (actually more like) cl.exe/link.exe. Anything written in the language being compiled is completely contained within the compilation process. MSBuild (or NAnt or make.exe or whatever you want to use) is driving the outputs from those tools in a coordinated manner. You need some MSBuild syntax to set the property you want. I'm not an MSBuild guru so I'm not much more help than that. Sorry. -Original Message- From: Colin Fox [mailto:greenene...@gmail.com] Sent: Wednesday, January 21, 2009 15:52 To: wix-users Subject: [WiX-users] Setting the output name with a variable I've asked this before but haven't gotten a solid answer, so I'll try one more time. I need to be able to incorporate a modified form of the package version into the .msi name. What would be ideal would be the ability to reference the !(bind.fileVersion.MyPackageEXE) as part of the output name, something like: DeluxeInstaller_!(bind.fileVersion.MyPackageEXE).msi I've had no luck shooting in the dark with different forms of the variable. Setting the OutputName field to include either a $() variable or a !() bind variable doesn't work, and the bind variable seems to no longer be in scope at the post-build-event stage (where I could simply write a line of DOS that renames the file. Is the only option to me at this point truly to write a separate stand-alone application that will have to go get the version information from the binaries itself and do a rename? That seems incredibly lame, since all the information I need is available during the wix processing, but I just don't seem to be able to get at it. I REALLY don't want to have to make an ugly hack just to add the version number into the filename. Please don't tell me that that is the only way. -- Regards, cf -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Prevent reboot.
Well another poster pointed out COM which I forgot (/wishfully forgot :-) ) existed. Due to how we develop our COM, and some might say the stubbornness not to change it (which I can sorta understand, it works so why change it), I am having to manage the COM via custom actions, so if a COM application is active during lock checks then that's probably locking the DLLs. Since I think COM by default doesn't unload a component (or application, one of them I am sure) from active memory till its not been used for 2 or 3 minute the VB6 COM DLLs are going to be locked. Unfortunately I can't confirm this till I am back in work so, we'll soon see ... I say soon we are talking 10 hours minimum, but that's soon in the grand scheme of things :-P. Cheers, Adam On Wednesday 21 January 2009 23:18:56 Chad Petersen wrote: We have a large web site, too. With many services running beside IIS. Any time we get locks I take a verbose log and search for in use and it always tells me the process that has the file in use and I can make some correction to take care of it. Never been a problem that could be handled so far. -Original Message- From: Adam Burton [mailto:adz...@googlemail.com] Sent: Wednesday, January 21, 2009 2:28 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Prevent reboot. Michael, Well yea that will be sorta the case. Some people will probably be in the middle of using the site (if the poor souls are sad enough or getting close to dead line to feel the need to work during lunch :-) ), not had chance to tell it to send out a warning email yet ... although they should know by now when it is going to happen, when suddenly the process stops IIS and copies the MSI to a place accessible by the server then installs it (the MSI is about 30MB for the website, with our poor network at this time we are talking several (10-20) seconds before its copied and started the install which I feel is enough time for IIS to release the locks on any dlls). At least with the services I can understand Windows Installer maybe being too quick to start installing before we its let the service settle (althought like i said I would think its smarter than that) but the website I am a bit stumped with. Adam On Wednesday 21 January 2009 22:10:55 Michael Osmond wrote: Adam, I suspect there is something more going on here. We have been following a test deployment process like yours for several years for a suite of large web applications, and the only time we have file lock issues is if someone is actively testing (hitting the pages) when the upgrade occurs. Michael -Original Message- From: Adam Burton [mailto:adz...@googlemail.com] Sent: Thursday, 22 January 2009 5:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Prevent reboot. I don't know about that. I can understand why it gets the locks etc, but its the releasing that seems to mess up for me, or behave in a manor I would not except. For example the services I install ... why are files still locked when the msi stops the service ... the service is the only thing that will use those file ... I can't see why I should need to stop the service for the msi before hand. Same with the IIS files, IIS is stopped, it should release those DLLs that are only accessed by IIS (they live in the website 'bin' directory, surely once IIS is stopped it has no use for them and should release them). I have just always assumed that it is a separate service/process/thread that releases the locks and its just too slow off the mark for the MSI. If that is the case though then you'd think there'd be stuff in Windows Installer that would take that into account so I'd at least only be rebooting every so often rather than a majority of the time. Also its not uncommon for me to delete a directory and the directory wont go away. With some inspection using stuff like process explorer it appears System has a lock on it (presumably for shi**z and giggles), soon as you kill the handle the directory goes. While the lock idea is sane, Windows implementation doesn't seem to work for me, therefore in its current state it's not sane for me :-). Before anyone thinks I am Windows bashing this is just one of the gripes I have with Windows, I have plenty of gripes with other OS's too. Although I have to say on the plus side I am yet to encounter the issue in Vista, but that being said I don't tend to delete directories often or install already running services in Vista so maybe I've just not trodden the path :-). Regardless I must be doing something else wrong because even if I got the file's name from the log file I still wouldn't know where to start. Anything that is supposed to use the files, in the case of IIS, is shut down and for the services it is shut down by Windows installer which I
Re: [WiX-users] Setting the output name with a variable
If we're building with Visual Studio (or devenv.exe) are we still using msbuild under the hood? On Wed, Jan 21, 2009 at 3:57 PM, Rob Mensching rob.mensch...@microsoft.comwrote: You need to separate the WiX toolset from MSBuild in your mind. Treat the WiX toolset the way you would treat csc.exe or vbc.exe or (actually more like) cl.exe/link.exe. Anything written in the language being compiled is completely contained within the compilation process. MSBuild (or NAnt or make.exe or whatever you want to use) is driving the outputs from those tools in a coordinated manner. You need some MSBuild syntax to set the property you want. I'm not an MSBuild guru so I'm not much more help than that. Sorry. -Original Message- From: Colin Fox [mailto:greenene...@gmail.com] Sent: Wednesday, January 21, 2009 15:52 To: wix-users Subject: [WiX-users] Setting the output name with a variable I've asked this before but haven't gotten a solid answer, so I'll try one more time. I need to be able to incorporate a modified form of the package version into the .msi name. What would be ideal would be the ability to reference the !(bind.fileVersion.MyPackageEXE) as part of the output name, something like: DeluxeInstaller_!(bind.fileVersion.MyPackageEXE).msi I've had no luck shooting in the dark with different forms of the variable. Setting the OutputName field to include either a $() variable or a !() bind variable doesn't work, and the bind variable seems to no longer be in scope at the post-build-event stage (where I could simply write a line of DOS that renames the file. Is the only option to me at this point truly to write a separate stand-alone application that will have to go get the version information from the binaries itself and do a rename? That seems incredibly lame, since all the information I need is available during the wix processing, but I just don't seem to be able to get at it. I REALLY don't want to have to make an ugly hack just to add the version number into the filename. Please don't tell me that that is the only way. -- Regards, cf -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Regards, cf -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Setting the output name with a variable
Colin, When you say setting the 'OutputName' field do you mean through the UI or through manually editing the project file. Theoretically, you should be able to edit this in the project file and it will work (using the '$(xxx)' syntax), but the VS IDE doesn't let you do so through its own UI. However, there isn't a $(xxx) (environment or MSBuild variable) that I'm aware of that will get you the property you want. You may need an MSBuild extension or something for this. We've abandoned building WiX projects via the IDE and doing so via the MSBuild targets that are provided with WiX in favor of our own build script. There, you have all the power of MSBuild at your disposal and none of the assumptions made during the WiX development or the VS2005 development in your way. It works good for us, except that you lose the pleasantness of being able to build directly from VS, but I can't say I've really missed that much on our installers anyway, since our installers are of monster size (not like Office or anything, but they take a good 15-30 minutes to build) so I can't say I really want to hang my IDE for that long anyway :) Kelly Colin Fox greenene...@gmail.com 2009-01-21 04:10 PM Please respond to General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net To General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net cc Subject Re: [WiX-users] Setting the output name with a variable If we're building with Visual Studio (or devenv.exe) are we still using msbuild under the hood? On Wed, Jan 21, 2009 at 3:57 PM, Rob Mensching rob.mensch...@microsoft.comwrote: You need to separate the WiX toolset from MSBuild in your mind. Treat the WiX toolset the way you would treat csc.exe or vbc.exe or (actually more like) cl.exe/link.exe. Anything written in the language being compiled is completely contained within the compilation process. MSBuild (or NAnt or make.exe or whatever you want to use) is driving the outputs from those tools in a coordinated manner. You need some MSBuild syntax to set the property you want. I'm not an MSBuild guru so I'm not much more help than that. Sorry. -Original Message- From: Colin Fox [mailto:greenene...@gmail.com] Sent: Wednesday, January 21, 2009 15:52 To: wix-users Subject: [WiX-users] Setting the output name with a variable I've asked this before but haven't gotten a solid answer, so I'll try one more time. I need to be able to incorporate a modified form of the package version into the .msi name. What would be ideal would be the ability to reference the !(bind.fileVersion.MyPackageEXE) as part of the output name, something like: DeluxeInstaller_!(bind.fileVersion.MyPackageEXE).msi I've had no luck shooting in the dark with different forms of the variable. Setting the OutputName field to include either a $() variable or a !() bind variable doesn't work, and the bind variable seems to no longer be in scope at the post-build-event stage (where I could simply write a line of DOS that renames the file. Is the only option to me at this point truly to write a separate stand-alone application that will have to go get the version information from the binaries itself and do a rename? That seems incredibly lame, since all the information I need is available during the wix processing, but I just don't seem to be able to get at it. I REALLY don't want to have to make an ugly hack just to add the version number into the filename. Please don't tell me that that is the only way. -- Regards, cf -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Regards, cf -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ** This communication is intended solely for the addressee and is confidential. If you are not the intended recipient, any
Re: [WiX-users] Prevent reboot.
Adam, Good luck!! Michael -Original Message- From: Adam Burton [mailto:adz...@googlemail.com] Sent: Thursday, 22 January 2009 9:53 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Prevent reboot. ::Rolls eyes and bows head:: oh I really hate COM it's always being difficult with me lol. I hadn't thought about the COM stuff, we run it as a server process so I bet that's still chilling out somewhere in the processes. I bet that when I run a verbose log tomorrow it will confirm that. Unfortunately as if COM didn't have enough of a life of its own the code we have in VB6 isn't really well maintained in terms of keeping binary compatibility etc so we don't keep the same GUIDs for components and so on, therefore my control of the COM isn't exactly ... clean. I suppose I may need to write a script that searches for our COM applications by name and performs a shutdown after stopping IIS, shouldn't be too hard. Although I guess it depends when the MSI performs its checks for file locks whether this is a cause of the problem. As (again ... unfortunately) I am forced to run a custom VBS script that registers the COM components (although I have to say due to the lack of proper maintaining of our COM components binary compatibility etc its made using WiX easier to use our custom scripts than the COMPlus extension, solve evil with evil I guess) and at the start of the install I run another VBS script that removes our COM applications before performing any file operation. At the moment though I am at home so I can't remember where I put the custom action in the sequence, but I would presume it would be before the lock checks (I am guessing they are done as it looks at each individual file on the fly not checks each file for locks then removes it or whatever) so removing the COM application should stop COM from locking its DLLs. Regardless I see 2 options, IIS is doing something funky with its file locks or I need to remove my COM applications earlier to prevent MSI bumping into COMs file locks. I guess I'll have to see tomorrow :-) ... pending I get the time. Thanks for your help so far. Adam On Wednesday 21 January 2009 22:59:01 Michael Osmond wrote: Adam, I agree (and our experience bears it out), IIS reset should kill off any thing that the web app is doing (actually we rarely even need to do that. Unless is some of the web application code is in COM+, that can have a life of its own. Michael -Original Message- From: Adam Burton [mailto:adz...@googlemail.com] Sent: Thursday, 22 January 2009 8:28 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Prevent reboot. Michael, Well yea that will be sorta the case. Some people will probably be in the middle of using the site (if the poor souls are sad enough or getting close to dead line to feel the need to work during lunch :-) ), not had chance to tell it to send out a warning email yet ... although they should know by now when it is going to happen, when suddenly the process stops IIS and copies the MSI to a place accessible by the server then installs it (the MSI is about 30MB for the website, with our poor network at this time we are talking several (10-20) seconds before its copied and started the install which I feel is enough time for IIS to release the locks on any dlls). At least with the services I can understand Windows Installer maybe being too quick to start installing before we its let the service settle (althought like i said I would think its smarter than that) but the website I am a bit stumped with. Adam On Wednesday 21 January 2009 22:10:55 Michael Osmond wrote: Adam, I suspect there is something more going on here. We have been following a test deployment process like yours for several years for a suite of large web applications, and the only time we have file lock issues is if someone is actively testing (hitting the pages) when the upgrade occurs. Michael -Original Message- From: Adam Burton [mailto:adz...@googlemail.com] Sent: Thursday, 22 January 2009 5:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Prevent reboot. I don't know about that. I can understand why it gets the locks etc, but its the releasing that seems to mess up for me, or behave in a manor I would not except. For example the services I install ... why are files still locked when the msi stops the service ... the service is the only thing that will use those file ... I can't see why I should need to stop the service for the msi before hand. Same with the IIS files, IIS is stopped, it should release those DLLs that are only accessed by IIS (they live in the website 'bin' directory, surely once IIS is stopped it has no use for them and should release them). I have just always assumed that it is a separate service/process/thread that
Re: [WiX-users] how to read appsettings values within wix
You'd need to build a CustomAction. A Class 2 CustomAction: http://robmensching.com/blog/posts/2007/8/10/Zataoca-Classes-of-Custom-Actions. I personally always recommend building CustomActions with the fewest dependencies, so C/C++ statically linked to C runtime. That's what all the WiX CustomActions do. An extension would just provide syntactic sugar for authoring the data for the CustomAction. It isn't necessary to get the job done. -Original Message- From: Mordecai Zibkoff [mailto:mzibk...@netik.com] Sent: Wednesday, January 21, 2009 12:15 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] how to read appsettings values within wix Rob, Thanks For your prompt response. The code that you mention having to write (read data, set properties...) what form does it take? (I can write it in c#) but what should I be building? An wix extension? Is there any tutorials on the subject? Thanks, Mordecai -Original Message- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: Wednesday, January 21, 2009 1:30 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] how to read appsettings values within wix Doesn't exist today (unfortunately)... probably not too hard since you don't have to modify machine state. Just read data, set properties... let XmlConfig do all the heavy lifting (aka: install/uninstall/rollback/etc.). -Original Message- From: Mordecai Zibkoff [mailto:mzibk...@netik.com] Sent: Wednesday, January 21, 2009 10:28 To: wix-users@lists.sourceforge.net Subject: [WiX-users] how to read appsettings values within wix Hi, I have a requirement to build an installer the does the following: 1 - the installer should read an appsettings value from a pre existing web.config on the target machine. 2 - This value should then be used to edit a web.config file before writing it, as a new file to the target directory (different than the directory where the first web.config resides) I can get step 2 done easily with the Util:XmlFile, but I don't have a way to extract the value, as described in step 1. I can imagine an XmlSearch or an AppSettingsSearch tag would be a nice way to solve this. Is there such an animal? If not, how difficult would it be to write one? Thanks, Mordecai Netik LLC - Incorporated with limited liability in the State of Delaware, USA Head Office: 40 Fulton Street, 11th Floor, New York, NY 10038, USA London Branch registered in England Wales with Company No FC025482 and Branch No BR007789 London Branch Office: Broken Wharf House, 2 Broken Wharf, High Timber Street, London EC4V 3DT, United Kingdom. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Setting the output name with a variable
VS2008? Yes. VS2005? No, I think that was make.exe... but I'm not an expert on the VS build systems. I find modifying build systems in VS to be painful since there are so many tiny boxes to type data in and a weird split between debug and release. shrug/ -Original Message- From: Colin Fox [mailto:greenene...@gmail.com] Sent: Wednesday, January 21, 2009 16:06 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Setting the output name with a variable If we're building with Visual Studio (or devenv.exe) are we still using msbuild under the hood? On Wed, Jan 21, 2009 at 3:57 PM, Rob Mensching rob.mensch...@microsoft.comwrote: You need to separate the WiX toolset from MSBuild in your mind. Treat the WiX toolset the way you would treat csc.exe or vbc.exe or (actually more like) cl.exe/link.exe. Anything written in the language being compiled is completely contained within the compilation process. MSBuild (or NAnt or make.exe or whatever you want to use) is driving the outputs from those tools in a coordinated manner. You need some MSBuild syntax to set the property you want. I'm not an MSBuild guru so I'm not much more help than that. Sorry. -Original Message- From: Colin Fox [mailto:greenene...@gmail.com] Sent: Wednesday, January 21, 2009 15:52 To: wix-users Subject: [WiX-users] Setting the output name with a variable I've asked this before but haven't gotten a solid answer, so I'll try one more time. I need to be able to incorporate a modified form of the package version into the .msi name. What would be ideal would be the ability to reference the !(bind.fileVersion.MyPackageEXE) as part of the output name, something like: DeluxeInstaller_!(bind.fileVersion.MyPackageEXE).msi I've had no luck shooting in the dark with different forms of the variable. Setting the OutputName field to include either a $() variable or a !() bind variable doesn't work, and the bind variable seems to no longer be in scope at the post-build-event stage (where I could simply write a line of DOS that renames the file. Is the only option to me at this point truly to write a separate stand-alone application that will have to go get the version information from the binaries itself and do a rename? That seems incredibly lame, since all the information I need is available during the wix processing, but I just don't seem to be able to get at it. I REALLY don't want to have to make an ugly hack just to add the version number into the filename. Please don't tell me that that is the only way. -- Regards, cf -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Regards, cf -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Application pool identity is stuffed up on product upgrade - IIS7.0
I am using Wix to create an application pool with an identity of a custom account. When I do a major upgrade the application pool identity is stuffed up although it should remain unchanged. The result is that the application pool is stopped and I get Service Unavailable message when I try to access the website that uses this application pool. The only way to solve it is to manually set the identity of the application pool after the upgrade is completed. I have no idea why it happens - the identity of the application pool shouldn't change. The only way to prevent the installer from setting the application pool identity on product upgrade is to disable the ConfigureIIs action on product upgrade, but the side effect is that the web site isn't removed on uninstall. This is the Wix code that creates the website and the application pool: Component Id=CreateWebSite Guid=CBAF81F1-E6D2-430e-A5FC-08DCCC4FC8D7 CreateFolder / iis:WebSite Id='KeyManagement' AutoStart='yes' Directory='Web.Ui' Description='Key Management Facility' iis:WebAddress Id='AllUnasigned' Port='80'/ iis:WebApplication Id='WMISystemMonitorWebservices' Name='KMfWebAPPName' WebAppPool='ClientApplicationPool' / /iis:WebSite /Component Component Id='ClientApplicationPoolComponent' Guid='012C66B6-B308-4883-BE18-C99E0E90B476' KeyPath='yes' UninstallWhenSuperseded='yes' iis:WebAppPool Id='ClientApplicationPool' Name='Tait Key Management Facility' Identity='other' User='KmfWebUI' / /Component /DirectoryRef === This email, including any attachments, is only for the intended addressee. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If the receiver is not the intended addressee, please accept our apologies, notify us by return, delete all copies and perform no other act on the email. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission. === -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Application pool identity is stuffed up on productupgrade - IIS7.0
Joe, How is the Uninstall of the old product version scheduled in the upgrade. My guess is that your update is uninstalling and then installing the web pool and when it reinstalls it, it no longer has the identity to use. Michael -Original Message- From: Joe Osman [mailto:joe.os...@tait.co.nz] Sent: Thursday, 22 January 2009 11:27 AM To: General discussion for Windows Installer XMLtoolset. Subject: [WiX-users] Application pool identity is stuffed up on productupgrade - IIS7.0 I am using Wix to create an application pool with an identity of a custom account. When I do a major upgrade the application pool identity is stuffed up although it should remain unchanged. The result is that the application pool is stopped and I get Service Unavailable message when I try to access the website that uses this application pool. The only way to solve it is to manually set the identity of the application pool after the upgrade is completed. I have no idea why it happens - the identity of the application pool shouldn't change. The only way to prevent the installer from setting the application pool identity on product upgrade is to disable the ConfigureIIs action on product upgrade, but the side effect is that the web site isn't removed on uninstall. This is the Wix code that creates the website and the application pool: Component Id=CreateWebSite Guid=CBAF81F1-E6D2-430e-A5FC-08DCCC4FC8D7 CreateFolder / iis:WebSite Id='KeyManagement' AutoStart='yes' Directory='Web.Ui' Description='Key Management Facility' iis:WebAddress Id='AllUnasigned' Port='80'/ iis:WebApplication Id='WMISystemMonitorWebservices' Name='KMfWebAPPName' WebAppPool='ClientApplicationPool' / /iis:WebSite /Component Component Id='ClientApplicationPoolComponent' Guid='012C66B6-B308-4883-BE18-C99E0E90B476' KeyPath='yes' UninstallWhenSuperseded='yes' iis:WebAppPool Id='ClientApplicationPool' Name='Tait Key Management Facility' Identity='other' User='KmfWebUI' / /Component /DirectoryRef === This email, including any attachments, is only for the intended addressee. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If the receiver is not the intended addressee, please accept our apologies, notify us by return, delete all copies and perform no other act on the email. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission. === -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Application pool identity is stuffed up on product upgrade - IIS7.0
What version of the WiX toolset are you using? -Original Message- From: Joe Osman [mailto:joe.os...@tait.co.nz] Sent: Wednesday, January 21, 2009 17:27 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Application pool identity is stuffed up on product upgrade - IIS7.0 I am using Wix to create an application pool with an identity of a custom account. When I do a major upgrade the application pool identity is stuffed up although it should remain unchanged. The result is that the application pool is stopped and I get Service Unavailable message when I try to access the website that uses this application pool. The only way to solve it is to manually set the identity of the application pool after the upgrade is completed. I have no idea why it happens - the identity of the application pool shouldn't change. The only way to prevent the installer from setting the application pool identity on product upgrade is to disable the ConfigureIIs action on product upgrade, but the side effect is that the web site isn't removed on uninstall. This is the Wix code that creates the website and the application pool: Component Id=CreateWebSite Guid=CBAF81F1-E6D2-430e-A5FC-08DCCC4FC8D7 CreateFolder / iis:WebSite Id='KeyManagement' AutoStart='yes' Directory='Web.Ui' Description='Key Management Facility' iis:WebAddress Id='AllUnasigned' Port='80'/ iis:WebApplication Id='WMISystemMonitorWebservices' Name='KMfWebAPPName' WebAppPool='ClientApplicationPool' / /iis:WebSite /Component Component Id='ClientApplicationPoolComponent' Guid='012C66B6-B308-4883-BE18-C99E0E90B476' KeyPath='yes' UninstallWhenSuperseded='yes' iis:WebAppPool Id='ClientApplicationPool' Name='Tait Key Management Facility' Identity='other' User='KmfWebUI' / /Component /DirectoryRef === This email, including any attachments, is only for the intended addressee. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If the receiver is not the intended addressee, please accept our apologies, notify us by return, delete all copies and perform no other act on the email. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission. === -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] DISABLEROLLBACK not working
Has anyone seen this symtom before? Here is the scenario: I am trouble shooting a failing install. In the debug process, I run the install with DISABLEROLLBACK=1. When the failure happens, it is suppose to NOT rollback. That way, I can figure out what isn't right. This has worked before. For some reason, I am seeing this method not work on some machines. When I attempt this process, the install is always rolling back. And ideas? Thanks, John -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Application pool identity is stuffed uponproductupgrade - IIS7.0
I am using WIX 3.0.4617.0 The upgrade doesn't remove the identity. The application pool uses a logon which cannot be removed by uninstalling the application. I specifically set the logon to be RemoveOnUninstall=no, hence I am sure that the logon (identity) exists when reinstalling the application pool. When I manually set the identity using the IIS Manager I can see that the correct identity is set, but nevertheless I need to set it again in order to start the application pool. Thank you for your help Joe Michael Osmond wrote: Joe, How is the Uninstall of the old product version scheduled in the upgrade. My guess is that your update is uninstalling and then installing the web pool and when it reinstalls it, it no longer has the identity to use. Michael -Original Message- From: Joe Osman [mailto:joe.os...@tait.co.nz] Sent: Thursday, 22 January 2009 11:27 AM To: General discussion for Windows Installer XMLtoolset. Subject: [WiX-users] Application pool identity is stuffed up on productupgrade - IIS7.0 I am using Wix to create an application pool with an identity of a custom account. When I do a major upgrade the application pool identity is stuffed up although it should remain unchanged. The result is that the application pool is stopped and I get Service Unavailable message when I try to access the website that uses this application pool. The only way to solve it is to manually set the identity of the application pool after the upgrade is completed. I have no idea why it happens - the identity of the application pool shouldn't change. The only way to prevent the installer from setting the application pool identity on product upgrade is to disable the ConfigureIIs action on product upgrade, but the side effect is that the web site isn't removed on uninstall. This is the Wix code that creates the website and the application pool: Component Id=CreateWebSite Guid=CBAF81F1-E6D2-430e-A5FC-08DCCC4FC8D7 CreateFolder / iis:WebSite Id='KeyManagement' AutoStart='yes' Directory='Web.Ui' Description='Key Management Facility' iis:WebAddress Id='AllUnasigned' Port='80'/ iis:WebApplication Id='WMISystemMonitorWebservices' Name='KMfWebAPPName' WebAppPool='ClientApplicationPool' / /iis:WebSite /Component Component Id='ClientApplicationPoolComponent' Guid='012C66B6-B308-4883-BE18-C99E0E90B476' KeyPath='yes' UninstallWhenSuperseded='yes' iis:WebAppPool Id='ClientApplicationPool' Name='Tait Key Management Facility' Identity='other' User='KmfWebUI' / /Component /DirectoryRef === This email, including any attachments, is only for the intended addressee. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If the receiver is not the intended addressee, please accept our apologies, notify us by return, delete all copies and perform no other act on the email. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission. === -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users === This email, including any attachments, is only for the intended addressee. It is subject to copyright, is confidential and may be the subject of legal or other privilege, none of which is waived or lost by reason of this transmission. If the receiver is not the intended addressee, please accept our apologies, notify us by return, delete all copies and perform no other act on the email. Unfortunately, we cannot warrant that the email has not been altered or corrupted during transmission. ===
Re: [WiX-users] Editing MSI properties in WiX 3.0.
Sachin Dubey (Tata Consultancy Services) wrote: I am trying to update the listview table- Can you please point me what's wrong with this: Microsoft.Deployment.WindowsInstaller.View view = null; view = session.Database.OpenView(UPDATE `ListView` SET `Binary` = 'Success' WHERE `Property` ='PREREQ_CHECK_STATUS' AND `Order` = 1); The column is named Binary_ not Binary. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Setting the output name with a variable
On Thu, Jan 22, 2009 at 2:56 AM, Rob Mensching rob.mensch...@microsoft.com wrote: VS2008? Yes. VS2005? No, I think that was make.exe... but I'm not an expert on the VS build systems. I find modifying build systems in VS to be painful since there are so many tiny boxes to type data in and a weird split between debug and release. shrug/ MSBuild was in first appeared in VS 2005 FWIW, if you know what you are doing, there is an option in VS to unload project and for an unloaded project there is an option to Edit projectname.csproj that lets you edit away as xml. For certain things, I find this faster/easier/less painful. -Original Message- From: Colin Fox [mailto:greenene...@gmail.com] Sent: Wednesday, January 21, 2009 16:06 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Setting the output name with a variable If we're building with Visual Studio (or devenv.exe) are we still using msbuild under the hood? On Wed, Jan 21, 2009 at 3:57 PM, Rob Mensching rob.mensch...@microsoft.comwrote: You need to separate the WiX toolset from MSBuild in your mind. Treat the WiX toolset the way you would treat csc.exe or vbc.exe or (actually more like) cl.exe/link.exe. Anything written in the language being compiled is completely contained within the compilation process. MSBuild (or NAnt or make.exe or whatever you want to use) is driving the outputs from those tools in a coordinated manner. You need some MSBuild syntax to set the property you want. I'm not an MSBuild guru so I'm not much more help than that. Sorry. -Original Message- From: Colin Fox [mailto:greenene...@gmail.com] Sent: Wednesday, January 21, 2009 15:52 To: wix-users Subject: [WiX-users] Setting the output name with a variable I've asked this before but haven't gotten a solid answer, so I'll try one more time. I need to be able to incorporate a modified form of the package version into the .msi name. What would be ideal would be the ability to reference the !(bind.fileVersion.MyPackageEXE) as part of the output name, something like: DeluxeInstaller_!(bind.fileVersion.MyPackageEXE).msi I've had no luck shooting in the dark with different forms of the variable. Setting the OutputName field to include either a $() variable or a !() bind variable doesn't work, and the bind variable seems to no longer be in scope at the post-build-event stage (where I could simply write a line of DOS that renames the file. Is the only option to me at this point truly to write a separate stand-alone application that will have to go get the version information from the binaries itself and do a rename? That seems incredibly lame, since all the information I need is available during the wix processing, but I just don't seem to be able to get at it. I REALLY don't want to have to make an ugly hack just to add the version number into the filename. Please don't tell me that that is the only way. -- Regards, cf -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Regards, cf -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 3.0.4805.0: Internal MSBuild Errors
John H. Bergman (XPedient Technologies) wrote: I am having a problem with the 3.0.4805.0 release. On one of my machines, I am getting build errors that are related to WiX. If I load my solution, with the series of MergeModules and Installs, I get the output (included below). Somebody already reported this bug as https://sourceforge.net/tracker2/?func=detailaid=2491406group_id=105970atid=642714. Please update to the latest weekly release from http://wix.sourceforge.net/releases/ to help narrow down the cause. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] question on volumecostList control
skarthik_psg wrote: Thanks for the reply but i am not using WixUI I wasn't suggesting you use it, I was suggesting you could get the UIText strings you need from it. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX 3.0.4805.0: Internal MSBuild Errors
I have already upgraded to the latest release (4917). -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Thursday, January 22, 2009 12:26 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX 3.0.4805.0: Internal MSBuild Errors John H. Bergman (XPedient Technologies) wrote: I am having a problem with the 3.0.4805.0 release. On one of my machines, I am getting build errors that are related to WiX. If I load my solution, with the series of MergeModules and Installs, I get the output (included below). Somebody already reported this bug as https://sourceforge.net/tracker2/?func=detailaid=2491406group_id=105970atid=642714. Please update to the latest weekly release from http://wix.sourceforge.net/releases/ to help narrow down the cause. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
