Re: [WiX-users] C# Managed Custom Actions in WiX 3.0
The best practice is not to use C# managed custom actions at all. If you search an archive of this list here: http://www.nabble.com/wix-users-f4470.html, you'll see plenty of reasons why this is stated. This is not a limitation of WiX, but rather a requirement imposed upon all of us by using Windows Installer. You need to write your custom actions preferably in C++, script custom actions are also supported, but no C# without using hacks to make it work. Dana On Thu, Feb 21, 2008 at 2:47 AM, si [EMAIL PROTECTED] wrote: Greetings, Does anyone have any good links as to best practice and guidance for implementing C# managed custom actions in Wix 3.0? In particular, XmlFile and XmlConfig are slowly driving us crazy. Part of the frustration is knowing how easy it is in C#, part of it is the large amount of grunt work you have to do in WiX, especially manipulating existing xml. So we're looking for other options to ensure that all our developers will embrace WiX, as most of it is awesome. Thanks in advance. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Vista, C Root, Hello world, Windows 3.1
Thanks bob, we have opted to warn the user that installing to the programfile folder will mean they may have issues with writing. I'd do something better but our release deadline is speeding towards us and we will be deploying our tutorial data in a different way for the next release anyway. Simon (See you all again in 6 months) -Original Message- From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: 19 February 2008 16:20 To: Simon Topley Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Vista, C Root, Hello world, Windows 3.1 Simon Topley wrote: the issue. I have attempted to suggest sensible places we may want to put our files, application data folder for example (if I could find a common one that all users could use). Even the desktop. Sadly everyone apart from me is rather keen on using the root of the C drive, or windows drive. Bad idea for the same reason. If the goal is to write to a directory that all users can share, delete, overwrite regardless of other users, you can use CommonAppDataFolder and use PermissionEx to give all users permissions. -- sig://boB http://joyofsetup.com/ 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Need a custom action with UAC elevated privileges before InstallInitialize
Brian Rogers wrote: Please don't mistake the fact that I like using Windows Installer as a tool, I just think it needs to become more robust at this point. I'm pretty sure nobody's arguing against that. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Managed Custom Actions in WiX 3.0
si wrote: In particular, XmlFile and XmlConfig are slowly driving us crazy. Part of the frustration is knowing how easy it is in C#, part of it is the large amount of grunt work you have to do in WiX, especially manipulating existing xml. How would C# make it easier to support uninstall, repair, rollback, upgrades, and patching? What are some examples of grunt work? -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Vista, C Root, Hello world, Windows 3.1
Simon Topley wrote: That does raise a question of how I detect if the user has changed the output path. I thought about adding a property to the browse folder click but it is possible a user will browse but not change the output directory. It's not a major problem if we tell them all the time it just would be nicer if it only warned them if they haven't changed the path. I wouldn't, simply because then you're in the game of keeping a list of potential writable-v-not directories. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Vista, C Root, Hello world, Windows 3.1
Good point. Thanks again Bob. -Original Message- From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: 21 February 2008 15:47 To: Simon Topley Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Vista, C Root, Hello world, Windows 3.1 Simon Topley wrote: That does raise a question of how I detect if the user has changed the output path. I thought about adding a property to the browse folder click but it is possible a user will browse but not change the output directory. It's not a major problem if we tell them all the time it just would be nicer if it only warned them if they haven't changed the path. I wouldn't, simply because then you're in the game of keeping a list of potential writable-v-not directories. -- sig://boB http://joyofsetup.com/ 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Localization with WiX3
Thanks you! I was confused by the fact that I was only getting errors with German, Spanish and Dutch because I thought those translations were complete. By adding these missing String items to my own 1031.wxl file I was able to build an MSI. The February 15, 2008 version of the WiX source requires these additions for a WixUI_InstallDir build (true for Spanish and Dutch as well): ?xml version=1.0? WixLocalization xmlns=http://schemas.microsoft.com/wix/2006/localization; Codepage=1252 Culture=de-DE String Id=InvalidDirDlg_Title Overridable=yes[ProductName] Setup/String String Id=InvalidDirDlgIcon Overridable=yesWixUI_Ico_Info/String String Id=InvalidDirDlgIconTooltip Overridable=yesInformation icon/String String Id=InvalidDirDlgText Overridable=yesInstallation directory must be on a local hard drive./String String Id=MaintenanceTypeDlgRemoveDisabledText Overridable=yes[ProductName] kann nicht entfernt werden./String String Id=MaintenanceTypeDlgRepairDisabledText Overridable=yes[ProductName] kann nicht repariert werden./String String Id=UITextNewFolder Overridable=yesOrdner|Neuer Ordner/String /WixLocalization -- View this message in context: http://www.nabble.com/Localization-with-WiX3-tp15489213p15614709.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to change the order of InstallSqlData custom action?
Hello, We are trying to change the order of our actions and don't have any success so far. By default InstallFiles has a sequence number of 4000 and InstallSqlData gets the number 4001. We need to run our custom action between these 2 action. We tried to explicitly include InstallSqlData in the InstallExecuteSequence and give it a different sequence number but it didn't work. What is the way to do that? Thank you, Yancho - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Coniguring Vista HTTP Namespace reservations in WIX
I'm guessing I'm not the only one who will be needing to make HTTP namespace reservations to allow my application to accept incoming HTTP calls on Vista, so in case it is of use to anyone else, I've written up some steps to do this: http://damianblog.com/2008/02/21/configuring-http-namespace-reservations-on-vista-using-wix/ I actually coded up a custom action initially, only to then discover a much simpler way of doing it. I am new to WIX, so any constructive comment is most welcome. Damian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Help with ICE38 and KeyPath installing to a folder on the Desktop
I can't connect to Rob's Blog archive for some reason and he's Out of the office right now. I'm running into this same error and need to resolve this ASAP. Does anyone have the text? Thanks, Dan From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Wednesday, January 23, 2008 9:54 PM To: Paul McLaughlin Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Help with ICE38 and KeyPath installing to a folder on the Desktop Paul McLaughlin wrote: test.wxs(18) : error LGHT0204 : ICE38: Component idTestProgram installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file. I tried learning what KeyPath means, but I can't find anything that really talks about it in the WiX help file. Many topics refer to it, but I can't find what ICE38 is and why I need a registry key, and I still don't know what a KeyPath means. WiX doesn't do much on documenting MSI concepts; for those, you want/need the MSI SDK. KeyPath is a column in the Component table: http://msdn2.microsoft.com/en-us/library/aa368007(VS.85).aspx. See http://robmensching.com/blog/archive/2007/04/27/How-to-create-an-uninstall-shortcut-and-pass-all-the.aspx for the oddities of ICEs and resources installed into the user profile. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Not detecting correct version of aspnet_regiis.exe
Property Id=ASPNETREGPATH RegistrySearch Id=FRAMEWORKBASEPATH Root=HKLM Key=SOFTWARE\Microsoft\.NETFramework Name=InstallRoot Type=raw DirectorySearch Id=FindAspRegExe Path=[FRAMEWORKBASEPATH] Depth=1 FileSearch Id=FindAspNetReg Name=aspnet_regiis.exe MinVersion=2.0.50727.42/ /DirectorySearch /RegistrySearch /Property Here's what I'm using, it appears to work OK: Property Id='ASPNETREGPATH' RegistrySearch Id='FindFrameworkDir' Root='HKLM' Key='SOFTWARE\Microsoft\.NETFramework' Name='InstallRoot' Type='directory' Win64='$(var.SEARCH.WIN64.REG)' DirectorySearch Id='FindAspNetRegDir' Depth='1' FileSearch Id='FindAspNetRegFile' Name='aspnet_regiis.exe' MinVersion='2.0.50727'/ /DirectorySearch /RegistrySearch /Property - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] INstall SQL Database
I am trying to create a SQL database as a separate component. I know that it is probably something simple maybe you could take a look at the attached and point me in the right direction. Basically I want to install the SQL Data and Log files in a sub directory to the Main application folder. Attached is my wxs. The error that I get is: The Directory/Component pair must be listed in the CreateFolders table Eric Latendresse Optimum Solutions, Inc. (615) 369-6097 office (615) 329-4448 fax [EMAIL PROTECTED] www.optimum-solutions.com http://www.optimum-solutions.com/ Payroll ∙ HR ∙ Time Attendance Made Simple. SuiteSetup.wxs Description: SuiteSetup.wxs - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] INstall SQL Database
Hi Eric, Add CreateFolder around sql:SqlDatabase. sql:SqlDatabase is a custom action and Windows Installer will not create an empty folder unless it will be forced to do so with explicit CreateFolder: Directory Id=”SuiteDatabaseFolder” Component iD=”SuiteDatabaseComponent” … CreateFolder sql:SqlDatabase … / /CreateFolder /Component /Directory Alex From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Latendresse Sent: Thursday, February 21, 2008 2:11 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] INstall SQL Database I am trying to create a SQL database as a separate component. I know that it is probably something simple maybe you could take a look at the attached and point me in the right direction. Basically I want to install the SQL Data and Log files in a sub directory to the Main application folder. Attached is my wxs. The error that I get is: “The Directory/Component pair must be listed in the CreateFolders table” Eric Latendresse Optimum Solutions, Inc. (615) 369-6097 office (615) 329-4448 fax [EMAIL PROTECTED] www.optimum-solutions.comhttp://www.optimum-solutions.com/ Payroll ∙ HR ∙ Time Attendance Made Simple. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Feature Tree - Redundant Options ?
I have a simple feature tree with a couple of features, where each of these features have no sub-features. Code fragment currently looks like this: Feature Id=Feature1 ConfigurableDirectory=FEATURE1DIR Display=collapse Level=1 Title=Feature1 AllowAdvertise=no Absent=allow TypicalDefault=install This give the user gets three options to select from: 1. Will be Installed on local hard drive 2. Entire Feature will be installed on local hard drive 3. Entire Feature will be unavailable. But since these features has no subfeatures, option 1 and 2 are redundant. Is there any way to show just Options (1 and 3) or (2 and 3)? I played with the attributes on the Feature element, but I can't figure it out. Maybe it is not possible? Thanks in advance. Tom - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] INstall SQL Database
Thanks for your reply, but now I get the error: error CNDL0005 : The CreateFolder element contains an unexpected child element 'sql:SqlDatabase’ Eric From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Shevchuk Sent: Thursday, February 21, 2008 4:29 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] INstall SQL Database Hi Eric, Add CreateFolder around sql:SqlDatabase. sql:SqlDatabase is a custom action and Windows Installer will not create an empty folder unless it will be forced to do so with explicit CreateFolder: Directory Id=”SuiteDatabaseFolder” Component iD=”SuiteDatabaseComponent” … CreateFolder sql:SqlDatabase … / /CreateFolder /Component /Directory Alex From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Latendresse Sent: Thursday, February 21, 2008 2:11 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] INstall SQL Database I am trying to create a SQL database as a separate component. I know that it is probably something simple maybe you could take a look at the attached and point me in the right direction. Basically I want to install the SQL Data and Log files in a sub directory to the Main application folder. Attached is my wxs. The error that I get is: “The Directory/Component pair must be listed in the CreateFolders table” Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] INstall SQL Database
Try this: Directory Id=”SuiteDatabaseFolder” Component iD=”SuiteDatabaseComponent” … CreateFolder / sql:SqlDatabase … / /Component /Directory From: Eric Latendresse [mailto:[EMAIL PROTECTED] Sent: Thursday, February 21, 2008 2:47 PM To: Alexander Shevchuk; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] INstall SQL Database Thanks for your reply, but now I get the error: error CNDL0005 : The CreateFolder element contains an unexpected child element 'sql:SqlDatabase’ Eric From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alexander Shevchuk Sent: Thursday, February 21, 2008 4:29 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] INstall SQL Database Hi Eric, Add CreateFolder around sql:SqlDatabase. sql:SqlDatabase is a custom action and Windows Installer will not create an empty folder unless it will be forced to do so with explicit CreateFolder: Directory Id=”SuiteDatabaseFolder” Component iD=”SuiteDatabaseComponent” … CreateFolder sql:SqlDatabase … / /CreateFolder /Component /Directory Alex From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Latendresse Sent: Thursday, February 21, 2008 2:11 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] INstall SQL Database I am trying to create a SQL database as a separate component. I know that it is probably something simple maybe you could take a look at the attached and point me in the right direction. Basically I want to install the SQL Data and Log files in a sub directory to the Main application folder. Attached is my wxs. The error that I get is: “The Directory/Component pair must be listed in the CreateFolders table” Eric - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Vista, C Root, Hello world, Windows 3.1
For some reason a lot of developers are having trouble with understanding UAC. UAC isn't just the prompt, it's a bunch of features designed to ensure only those things that need to run with high privilege do so, that other programs can't interfere with the high-privileged programs, and some additional features to try to help work around the changes for legacy programs. The best thing to do for any new code is not to be considered a legacy program. To do this, your programs - all of them - need a manifest describing their privilege requirements. The way to do this is described at http://msdn2.microsoft.com/en-us/library/bb756929.aspx. 99.9% of programs should be marked 'asInvoker', the remaining 0.1% which are actually used to administer your system marked as 'requireAdministrator', and anything that would require 'highestAvailable' should be split into a regular program that can run with normal privileges and a small bit that must run with administrative privileges, to configure those settings. You could, of course, simply set 'requireAdministrator' on everything and annoy your users every time they run the program with a UAC prompt. But it's against the spirit of trying to get everything running with the lowest privileges possible, so that if a remote code execution bug (at worst) is found and exploited, it can only trash the user's profile, not the whole system. Windows NT has always had a security system, it's just that most people didn't use it because it was too much bother, largely because applications expected to be able to write anywhere and failed in unusual ways if they couldn't. I used to use Windows XP as a standard user - I still do at work - and it can be a lot of pain. Vista UAC makes it much easier to run with low privileges most of the time and only invoke higher privileges when you need them. You're definitely on the right lines with moving files that all users need to write to the Common Application Files folder, but you should question whether all users on the same machine really need to write to the same file or registry key. There really is no harm in having separate configurations for each user, and it may surprise users if a setting changes because a different user changed it. You could get into really odd scenarios with Fast User Switching or Terminal Services, if settings can change under a running copy of the program. Modifying a file written by Windows Installer can have a surprising effect - it may not be overwritten when you install an upgrade, depending on when you schedule RemoveExistingProducts (I think). Modifying a key can be similar - there is no versioning involved, registry key updates always overwrite. I would recommend treating whatever is installed as immutable except by the next version of the installer. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Topley Sent: 19 February 2008 15:51 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Vista, C Root, Hello world, Windows 3.1 Where do I begin... First off I suppose I should say hello, it's been ages since I posted as our lovingly tailored installers have been carefree for sometime now. Here is my problem... Vista. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Help with ICE38 and KeyPath installing to a folder on the Desktop
Google cached it: http://209.85.173.104/search?q=cache:9Hg8CQyYJXkJ:robmensching.com/blog/arch ive/2007/04/27/How-to-create-an-uninstall-shortcut-and-pass-all-the.aspx+How +to+create+an+uninstall+shortcut+and+pass+all+the http://209.85.173.104/search?q=cache:9Hg8CQyYJXkJ:robmensching.com/blog/arc hive/2007/04/27/How-to-create-an-uninstall-shortcut-and-pass-all-the.aspx+Ho w+to+create+an+uninstall+shortcut+and+pass+all+thehl=enct=clnkcd=1gl=us hl=enct=clnkcd=1gl=us -Paul From: Dan Hoeger [mailto:[EMAIL PROTECTED] Sent: Thursday, February 21, 2008 12:41 PM To: Bob Arnson; Paul McLaughlin Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Help with ICE38 and KeyPath installing to a folder on the Desktop I can't connect to Rob's Blog archive for some reason and he's Out of the office right now. I'm running into this same error and need to resolve this ASAP. Does anyone have the text? Thanks, Dan From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Wednesday, January 23, 2008 9:54 PM To: Paul McLaughlin Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Help with ICE38 and KeyPath installing to a folder on the Desktop Paul McLaughlin wrote: test.wxs(18) : error LGHT0204 : ICE38: Component idTestProgram installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file. I tried learning what KeyPath means, but I can't find anything that really talks about it in the WiX help file. Many topics refer to it, but I can't find what ICE38 is and why I need a registry key, and I still don't know what a KeyPath means. WiX doesn't do much on documenting MSI concepts; for those, you want/need the MSI SDK. KeyPath is a column in the Component table: http://msdn2.microsoft.com/en-us/library/aa368007(VS.85).aspx. See http://robmensching.com/blog/archive/2007/04/27/How-to-create-an-uninstall-s hortcut-and-pass-all-the.aspx for the oddities of ICEs and resources installed into the user profile. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Failing gracefully from ServiceControl?
I've got several services I'm trying to install. If I add Start='install' to the ServiceControl element then it will try to start them, but it will almost always fail with a 1920 error. I'm pretty sure this is because some of the services are dependent on side-by-side assemblies that are being installed at the same time and so won't be available until the install actually finishes. However is there a way to make it so that it will attempt to start the services but _not_ force a rollback if it fails? There are at least some circumstances where the assemblies might already have been installed by another package and it would be nice to at least make the attempt. There doesn't seem to be any Vital attribute for the ServiceControl element that I can set to no. There is a Vital for ServiceInstall, but I can't set that to no even if it would fix the above problem, because it _is_ vital that they at least install properly, even if they don't start right away, and the same goes for ErrorControl in the ServiceInstall element as well I think. As an added bonus, if the above can be done is there also a way to do the service start step silently? We're expecting it to fail most of the time so there's no need to pop up an error message about it if it does. Thanks! And here's the code I've got in case it matters: ServiceInstall Id=SystemServiceInstall DisplayName=$(loc.IDS_SERVER) $(var.MAJORVER).$(var.MINORVER) Description=$(loc.IDS_SERVER_SERVICE) $(var.MAJORVER).$(var.MINORVER) Name=ServerService ErrorControl=normal Start=auto Type=ownProcess Vital=yes ServiceDependency Id =HTTP / /ServiceInstall ServiceControl Id=SystemServiceControl Name=ServerService Start=install Stop=uninstall Remove=uninstall / - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Light... could spare me some time!
I build packages with two media components:
Package InstallerVersion=300 Compressed=yes /
Media Id=1 Cabinet=files.cab EmbedCab=yes /
Media Id=2 Layout=.\files /
And here is a sample Component/File couplet that I use:
Component Id=file.fil DiskId=2 Guid={*}
File Id= file.fil Name= file.fil Compressed=no Checksum=yes
KeyPath=yes Source=C:\Original Path\file.fil /
/Component
The problem is that when building the project, the FIL files are put in the
right folder (root\files), however Windows Installer looks for them inside
the root folder and not the files subfolder, which is rather frustrating:
Ive been trying to hack around with it but no luck came out. Hopefully you
can show me the light.
Also, another annoyance: FIL files amount for a few gigabytes, and it seems
that light tries to copy them to my files subfolder each time I compile,
even though no changes have been made to these files! Is there a way to
restrain light from copying them every time to save compilation time?
Thanks a bunch.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Managed Custom Actions in WiX 3.0
Hi Bob, I don't want to get into a religious argument over this, and Dana, yes I have read about the potential problems, I'm just looking for avenues to explore to get our development team on the right path. We use C# for almost everything else, so it's natural for us to want to use this language if at all possible, especially since Votive works so well in Visual Studio. How would C# make it easier to support uninstall, repair, rollback, upgrades, and patching? I'm not a WiX or windows installer expert, but for what we want to do with the managed actions; uninstall and rollback would be probably treated the same i.e. leave everything as it was, likewise for upgrades and patches. Not sure about repair. I was actually talking more about leveraging our existing tools for debugging (e.g. log4net) as well as the tools that ship with .NET i.e. the Base Class Libraries. What are some examples of grunt work? Sure. One example is our companies custom security and data extensions for Microsoft Reporting Services. Because this is an existing product, we can't just overwrite the xml configuration files that exist with our own versions. To take the RSSrvPolicy.config as an example, I have nearly 1,000 lines of XmlConfig code in the wxs file related to just 22 xml elements! This is one of six configuration files we have to modify. To be fair it's the largest but they all take time to develop and more importantly, because the idiosyncrasies of XmlConfig are difficult to develop and debug. Even Microsoft's own developers have problems with this: http://blogs.msdn.com/gisenberg/archive/2007/10/09/wix-v3-and-xmlconfig-xmlfile-troubleshooting.aspx What I'd like is something as simple as the XmlPoke and XmlPeek tasks that are found in NAnt. We'd also like an XmlBulkAdd action i.e. adding well-formed elements and attributes instead of having to treat each element value or attribute invidually. With those actions I could get my wxs file mentioned above down to less than 100 lines, making it easier to develop, understand, test and maintain. We'd also write an XmlTidy action - a few lines of C# thanks to the BCL - so that the xml files are left in a clean state after being touched, as anyone who has spent time with XmlFile and XmlConfig knows, they get messy quickly. Yes, no problem for a parser, but a pain for humans. If it's true that a Microsoft supported WiX variant will be in the next version of Visual Studio, expect a lot more of these sort of requests from other .NET developers in the not-to-distant future :) cheers si -- It's a wild world that we live in, you step to the vibe like a new found religion, take your position, compile your vision, futurism, algorithm has risen up!pfm - the western - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] defining one property before another
I know there has to be a trick to this but... How do you ensure that one property is defined before another property is defined? I have a property that reads a value from the registry And a second property that defines a directory based on the registry property I want to make sure the reg property is defined before defining the directory property or else my directory will point to the wrong place. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] defining one property before another
I am assuming you're using custom action Type 51 to set the second property's value. Just schedule it after the AppSearch standard action. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Don Tasanasanta (Volt) Sent: Thursday, February 21, 2008 4:54 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] defining one property before another I know there has to be a trick to this but... How do you ensure that one property is defined before another property is defined? I have a property that reads a value from the registry And a second property that defines a directory based on the registry property I want to make sure the reg property is defined before defining the directory property or else my directory will point to the wrong place. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Managed Custom Actions in WiX 3.0
I read earlier that someone said that the MSI team issued a `requirement` to not use managed code. Also to say it's a best practice to not use managed code is a stretch of the truth also. The future of Windows development is managed code and I've found very successful ways to incorporate it into my installs. Anyone who tells me otherwise simply isn't thinking outside of the box or just likes the torture of writing raw C++ Win32 code. si [EMAIL PROTECTED] wrote: Hi Bob, I don't want to get into a religious argument over this, and Dana, yes I have read about the potential problems, I'm just looking for avenues to explore to get our development team on the right path. We use C# for almost everything else, so it's natural for us to want to use this language if at all possible, especially since Votive works so well in Visual Studio. How would C# make it easier to support uninstall, repair, rollback, upgrades, and patching? I'm not a WiX or windows installer expert, but for what we want to do with the managed actions; uninstall and rollback would be probably treated the same i.e. leave everything as it was, likewise for upgrades and patches. Not sure about repair. I was actually talking more about leveraging our existing tools for debugging (e.g. log4net) as well as the tools that ship with .NET i.e. the Base Class Libraries. What are some examples of grunt work? Sure. One example is our companies custom security and data extensions for Microsoft Reporting Services. Because this is an existing product, we can't just overwrite the xml configuration files that exist with our own versions. To take the RSSrvPolicy.config as an example, I have nearly 1,000 lines of XmlConfig code in the wxs file related to just 22 xml elements! This is one of six configuration files we have to modify. To be fair it's the largest but they all take time to develop and more importantly, because the idiosyncrasies of XmlConfig are difficult to develop and debug. Even Microsoft's own developers have problems with this: http://blogs.msdn.com/gisenberg/archive/2007/10/09/wix-v3-and-xmlconfig-xmlfile-troubleshooting.aspx What I'd like is something as simple as the XmlPoke and XmlPeek tasks that are found in NAnt. We'd also like an XmlBulkAdd action i.e. adding well-formed elements and attributes instead of having to treat each element value or attribute invidually. With those actions I could get my wxs file mentioned above down to less than 100 lines, making it easier to develop, understand, test and maintain. We'd also write an XmlTidy action - a few lines of C# thanks to the BCL - so that the xml files are left in a clean state after being touched, as anyone who has spent time with XmlFile and XmlConfig knows, they get messy quickly. Yes, no problem for a parser, but a pain for humans. If it's true that a Microsoft supported WiX variant will be in the next version of Visual Studio, expect a lot more of these sort of requests from other .NET developers in the not-to-distant future :) cheers si -- It's a wild world that we live in, you step to the vibe like a new found religion, take your position, compile your vision, futurism, algorithm has risen up! pfm - the western - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] defining one property before another
Looking at the install log (msiexec /lvx install.log /i installer.msi) is a good starting point for working things like this out, you can easily see which actions fire when and what task(s) each action is performing, so with that in mind an install log will show that searches (registry or directory) are triggered during the AppSearch action, therefore... Property Id=PROPERTY1 RegistrySearch Id=RegSearchExample ... / /Property CustomAction Id=SetProperty2 Property=PROPERTY2 Value=[PROPERTY1] Execute=immediate Return=check/ InstallUISequence Custom Action=SetProperty2 After=AppSearch/ /InstallUISequence InstallExecuteSequence Custom Action=SetProperty2 After=AppSearch/ /InstallExecuteSequence ... should do the trick. Don Tasanasanta (Volt) wrote: I know there has to be a trick to this but... How do you ensure that one property is defined before another property is defined? I have a property that reads a value from the registry And a second property that defines a directory based on the registry property I want to make sure the reg property is defined before defining the directory property or else my directory will point to the wrong place. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://www.nabble.com/defining-one-property-before-another-tp15625171p15625458.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] FW: Conditional Custom Actions
Hi I'm totally new to MSI and WIX, and I want the MSI to run an executable (.EXE file) during the installation process, but not when the application is being uninstalled. So I used a custom action, and put it inside InstallExecuteSequence, but I don't know what should I do to prevent it from running during uninstall. This is the general format of my WXS file. Wix Product Directory Component Id=Cmp1 File Id=SomeFile /Component /Directory Binary Id=MyExecutable / Feature Id=Ftr ComponentRef Id=Cmp1 / /Feature CustomAction Id=DoAction BinaryKey=MyExecutable ExecCommand=-CommandParams / InstallExecuteSequence Custom Action DoAction Sequence=1 / /InstallExecuteSequence /Product /Wix - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Failing gracefully from ServiceControl?
I haven't been using windows installer/wix very long so am a little confused, from what I can see the default behaviour of the install sequence is to process all files before attempting to start any services, therefore if your product includes dependent assemblies they will already have processed before the StartServices action, in fact starting services is close to the last action in the install sequence, of course you can always move it further back. If you're installing several services are you sure you don't have any inter-service dependencies you're not taking care of? You can always check if the dependencies are already installed and skip trying to start the service if they are not, but like I said, if your product is installing those assemblies anyhow it shouldn't be an issue. Geoff Finger-2 wrote: I've got several services I'm trying to install. If I add Start='install' to the ServiceControl element then it will try to start them, but it will almost always fail with a 1920 error. I'm pretty sure this is because some of the services are dependent on side-by-side assemblies that are being installed at the same time and so won't be available until the install actually finishes. However is there a way to make it so that it will attempt to start the services but _not_ force a rollback if it fails? There are at least some circumstances where the assemblies might already have been installed by another package and it would be nice to at least make the attempt. There doesn't seem to be any Vital attribute for the ServiceControl element that I can set to no. There is a Vital for ServiceInstall, but I can't set that to no even if it would fix the above problem, because it _is_ vital that they at least install properly, even if they don't start right away, and the same goes for ErrorControl in the ServiceInstall element as well I think. As an added bonus, if the above can be done is there also a way to do the service start step silently? We're expecting it to fail most of the time so there's no need to pop up an error message about it if it does. Thanks! And here's the code I've got in case it matters: ServiceInstall Id=SystemServiceInstall DisplayName=$(loc.IDS_SERVER) $(var.MAJORVER).$(var.MINORVER) Description=$(loc.IDS_SERVER_SERVICE) $(var.MAJORVER).$(var.MINORVER) Name=ServerService ErrorControl=normal Start=auto Type=ownProcess Vital=yes ServiceDependency Id =HTTP / /ServiceInstall ServiceControl Id=SystemServiceControl Name=ServerService Start=install Stop=uninstall Remove=uninstall / - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://www.nabble.com/Failing-gracefully-from-ServiceControl--tp15624384p15626152.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] FW: Conditional Custom Actions
What about maintenance mode? If you want to run it on install only, add condition to your custom action: InstallExecuteSequence Custom Action...Not Installed/Custom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sina Hakami Sent: Thursday, February 21, 2008 5:55 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] FW: Conditional Custom Actions Hi I'm totally new to MSI and WIX, and I want the MSI to run an executable (.EXE file) during the installation process, but not when the application is being uninstalled. So I used a custom action, and put it inside InstallExecuteSequence, but I don't know what should I do to prevent it from running during uninstall. This is the general format of my WXS file. Wix Product Directory Component Id=Cmp1 File Id=SomeFile /Component /Directory Binary Id=MyExecutable / Feature Id=Ftr ComponentRef Id=Cmp1 / /Feature CustomAction Id=DoAction BinaryKey=MyExecutable ExecCommand=-CommandParams / InstallExecuteSequence Custom Action DoAction Sequence=1 / /InstallExecuteSequence /Product /Wix - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Managed Custom Actions in WiX 3.0
In article [EMAIL PROTECTED], si [EMAIL PROTECTED] writes: What I'd like is something as simple as the XmlPoke and XmlPeek tasks that are found in NAnt. [...] We'd also like an XmlBulkAdd action i.e. adding well-formed elements and attributes instead of having to treat each element value or attribute invidually. With those actions I could get my wxs file mentioned above down to less than 100 lines, making it easier to develop, understand, test and maintain. We'd also write an XmlTidy action [...] These all seem like very reasonable feature requests for WiX as an extension/adjunct to the existing XmlConfig actions. I'm assuming that the XmlTidy action is only because when WiX edits an XML file, it does unwanted things to the whitespace in the XML file? I'd treat that more as a bug to XmlConfig/XmlFile. What about this: would you be happy with a tool that took two XML files, a before and after version, and processed the differences to generate the appropriate XmlConfig/XmlFile nodes? That could be part of your build process so that ongoing iterative changes could be incorporated automatically. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Managed Custom Actions in WiX 3.0
Hi Richard, These all seem like very reasonable feature requests for WiX as an extension/adjunct to the existing XmlConfig actions. Agreed. We'd prefer not have to code this ourselves and worry about custom actions. I'm assuming that the XmlTidy action is only because when WiX edits an XML file, it does unwanted things to the whitespace in the XML file? Correct. On installs it can create elements without adding a CRLF to the parent element. On uninstalls it doesn't remove CRLF from deleted elements. So I end up using Visual Studio Format Document command (Ctrl+E, D) quite often when testing. This fixes the first problem (for testing, not for deployment) but not the later. I'd treat that more as a bug to XmlConfig/XmlFile. Agreed, although I posted to this list recently about this - subject heading Xml Beautifier - and it didn't elicit much response so I didn't bother filing an issue. Perhaps it was poorly written. What about this: would you be happy with a tool that took two XML files, a before and after version, and processed the differences to generate the appropriate XmlConfig/XmlFile nodes? Yes, that's an excellent idea! The before file wouldn't have to be the whole configuration file, just the elements and attributes needed for the xpath queries. That could be part of your build process so that ongoing iterative changes could be incorporated automatically. Sounds good, and thanks for your input. Shall I go ahead and create a feature request for this tool? cheers si - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Name of the msi with in the install file
Hello: And where does OriginalDatabase property gets set (As in after/before which event). Thanks, Vishnu -- View this message in context: http://www.nabble.com/Name-of-the-msi-with-in-the-install-file-tp15583249p15627797.html Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Setting Estimated Size and Version
I was wondering if it was possible to set the size and version that shows up for a given program in ARP when I set ARPSYSTEMCOMPONENT to 1. For size, it seems like setting ARPSIZE or EstimatedSize has no effect. I'm also unsure how to set the Version. Does anybody have an idea? Thanks! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Registry permissions messed up after installing package
Hi, I'm authoring an installer package that need to register a couple of DLLs in the registry (traditionally done by regsvr32). I used heat.exe to generate the snip After installing the package: Administrator (Full control - not inherited) (the user, not the group) System (Full control - not inherited) Administrators (Full control - not inherited) RESTRICTED (Read - not inherited) Ok, I figured this one out. It's not a WiX issue, but this is how Windows installer does it when you install a package that is Just for me as opposed to Everyone. I assume it is OK, it just looked very strange to me. By adding the ALLUSERS property and setting the value to 2 (meaning install and make available to everyone) it works as expected. The thing is that I had no UI so I completely forgot about that setting. Regards, Arild - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Registry permissions messed up after installing package
Hi, I'm authoring an installer package that need to register a couple of DLLs in the registry (traditionally done by regsvr32). I used heat.exe to generate the snip After installing the package: Administrator (Full control - not inherited) (the user, not the group) System (Full control - not inherited) Administrators (Full control - not inherited) RESTRICTED (Read - not inherited) Ok, I figured this one out. It's not a WiX issue, but this is how Windows installer does it when you install a package that is Just for me as opposed to Everyone. I assume it is OK, it just looked very strange to me. By adding the ALLUSERS property and setting the value to 2 (meaning install and make available to everyone) it works as expected. The thing is that I had no UI so I completely forgot about that setting. And some additional info in case others are wondering how this works. ALLUSERS should be set to 1 to enforce per-machine installation. The value 2 will attempt a per-machine installation and revert to per-user if the installing user does not have the privileges to perform per-machine installation (except on Vista where it will fail instead of revert if the installing user fails to provide proper credentials to the UAC). And regarding the registry and permissions, when doing a per-user installation the registry keys are written to HKCU\Software\Classes and the HKCR key reflects the merged version from HKLM\Software\Classes and HKCU\Software\Classes. That's why the permissions looked strange, but they were of course only for _my_ user and not for everyone. Arild - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
