Re: [WiX-users] MSI install log
Or you can set the registry as per http://support.microsoft.com/kb/223300 but this will affect all msi installs but can be useful during dev or on site diagnostics -Original Message- From: Blair [mailto:os...@live.com] Sent: 12 August 2010 22:37 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] MSI install log If you are using MSI 4.0 or later, you can add the MsiLogging property to the Property table. http://msdn.microsoft.com/library/aa370322.aspx -Original Message- From: Sohail Somani [mailto:soh...@taggedtype.net] Sent: Thursday, August 12, 2010 10:48 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] MSI install log Thanks. So I guess there is no command in Windows Installer to generate a log file? On 10-08-12 11:15 AM, Michael Clark wrote: See http://support.microsoft.com/kb/223300 -Original Message- From: Sohail Somani [mailto:soh...@taggedtype.net] Sent: Thursday, August 12, 2010 9:55 AM To:wix-users@lists.sourceforge.net Subject: [WiX-users] MSI install log This is probably a MSI question more than a WiX question but here goes: is it possible with WiX to always generate an install log without requesting it on the command-line? Thanks! -- Sohail Somani -- iBlog : http://uint32t.blogspot.com iTweet: http://twitter.com/somanisoftware iCode : http://bitbucket.org/cheez -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users IDOX group email privacy confidentiality notice: The information contained in this email message is intended only for the person or persons to whom it is addressed. Such information is confidential and privileged and no mistake in transmission is intended to waive or compromise such privilege. If you have received it in error, please destroy it and notify us on 0870 333 7101. If you do not receive complete and legible copies, please telephone us immediately. Any opinions expressed herein including attachments are those of the author only. IDOX group does not accept responsibility for the accuracy or completeness of the information provided or for any changes to this email, however made, after it was sent. Please note that it is your responsibility to scan this message for viruses. Registered Address: IDOX plc, 2nd Floor, 160 Queen Victoria Street, London EC4V 4BF Registered Numbers: IDOX Software Ltd - 2933889 in England and Wales TFPL Ltd - 1946440 in England and Wales IDOX Information Solutions Ltd - 06706798 in England and Wales Vat Registration Number: GB 766 8008 04 Please consider the environment before printing this email. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Error: MSB4067
Hi, I'm having a problem building an install package. The build proj and log are attached. I'm using: VS2010 WIX 3.5 \Microsoft.NET\Framework\v3.5\MSBuild.exe On a 64-bit Windows XP system. Error: MSB4067 (see log) Can anybody help me with this error? Thanks regards, Matt ?xml version=1.0? Project DefaultTargets=SetProperties;BuildAll xmlns=http://schemas.microsoft.com/developer/msbuild/2003; PropertyGroup !-- General properties -- CompanyNameGroup/CompanyName ProductNameRevit Menus/ProductName CopyrightCopyright (c) 2010/Copyright !-- Set paths -- MSBuildCommunityTasksPath$(MSBuildProjectDirectory)\Externals\MSBuildCommunityTasks\Build/MSBuildCommunityTasksPath WixToolPath$(MSBuildProjectDirectory)\Externals\wix3.5-binaries/WixToolPath /PropertyGroup !-- Collection of AssemblyInfo.cs files to generate -- ItemGroup AssemblyInfoFile Include=Item Value..\WSPR.ClassLibrary\Properties\AssemblyInfo.cs/Value /AssemblyInfoFile AssemblyInfoFile Include=Item Value..\WSPR.Links\Properties\AssemblyInfo.cs/Value /AssemblyInfoFile AssemblyInfoFile Include=Item Value..\WSPR.MenuUI\Properties\AssemblyInfo.cs/Value /AssemblyInfoFile AssemblyInfoFile Include=Item Value..\WSPR.Plotting\Properties\AssemblyInfo.cs/Value /AssemblyInfoFile AssemblyInfoFile Include=Item Value..\WSPR.VisibilityTools\Properties\AssemblyInfo.cs/Value /AssemblyInfoFile /ItemGroup !-- We use the AssemblyInfo task from MSBuildCommunityTasks (http://msbuildtasks.tigris.org/) -- Import Project=$(MSBuildCommunityTasksPath)\MSBuild.Community.Tasks.Targets / Import Project=C:\Program Files (x86)\MSBuild\ExtensionPack\MSBuild.ExtensionPack.tasks/ Target Name=BuildAll Message Text=Building version: $(Version)/ CallTarget Targets=GenerateAssemblyInfoForEachFile / CallTarget Targets=RebuildSolution / /Target Target Name=GenerateAssemblyInfoForEachFile Inputs=@AssemblyInfoFile Outputs=@null !-- Generate AssemblyInfo files specified in ItemGroup @AssemblyInfoFile -- AssemblyInfo CodeLanguage=CS OutputFile=%(AssemblyInfoFile.Value) AssemblyCompany=$(CompanyName) AssemblyProduct=$(ProductName) AssemblyCopyright=$(Copyright) ComVisible=false CLSCompliant=true AssemblyVersion=$(Version) AssemblyFileVersion=$(Version) / /Target Target Name=RebuildSolution PropertyGroup !--ConfigurationDebug/Configuration-- ConfigurationRelease/Configuration /PropertyGroup AssemblyInfoFile Include=Item Value..\WSPR.ClassLibrary\Properties\AssemblyInfo.cs/Value /AssemblyInfoFile AssemblyInfoFile Include=Item Value..\WSPR.Links\Properties\AssemblyInfo.cs/Value /AssemblyInfoFile AssemblyInfoFile Include=Item Value..\WSPR.MenuUI\Properties\AssemblyInfo.cs/Value /AssemblyInfoFile AssemblyInfoFile Include=Item Value..\WSPR.Plotting\Properties\AssemblyInfo.cs/Value /AssemblyInfoFile AssemblyInfoFile Include=Item Value..\WSPR.VisibilityTools\Properties\AssemblyInfo.cs/Value /AssemblyInfoFile !-- Build Any CPU versions of .NET projects -- MSBuild Targets=Rebuild Projects=..\WSPR.ClassLibrary\WSPR.ClassLibrary.vbproj Properties=Configuration=$(Configuration) / MSBuild Targets=Rebuild Projects=..\WSPR.Links\WSPR.Links.vbproj Properties=Configuration=$(Configuration) / MSBuild Targets=Rebuild Projects=..\WSPR.MenuUI\WSPR.MenuUI.vbproj Properties=Configuration=$(Configuration) / MSBuild Targets=Rebuild Projects=..\WSPR.Plotting\WSPR.Plotting.vbproj Properties=Configuration=$(Configuration) / MSBuild Targets=Rebuild Projects=..\WSPR.VisibilityTools\WSPR.VisibilityTools.vbproj Properties=Configuration=$(Configuration) / !-- Build 32-bit version of setup -- MSBuild Targets=Rebuild Projects=Setup\Setup.wixproj Properties=Configuration=$(Configuration);Platform=x86;CompanyName=$(CompanyName);ProductName=$(ProductName);Version=$(Version);WixToolPath=$(WixToolPath) / !-- Properties=Configuration=$(Configuration);Platform=AnyCPU;CompanyName=$(CompanyName);ProductName=$(ProductName);Version=$(Version);WixToolPath=$(WixToolPath) / -- Copy SourceFiles=Setup\bin\$(Configuration)\WSP_Revit_Custom_Setup.msi
Re: [WiX-users] Meaning of Light's -sacl?
The only time I have seen is in a locked down corporate environment when I only have Modify rights to a share. Neil Neil Sleightholm X2 Systems Limited n...@x2systems.com mailto:n...@x2systems.com From: Nick Ramirez [mailto:nickra...@hotmail.com] Sent: Thu 12/08/2010 21:30 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Meaning of Light's -sacl? Thanks Neil. I've been trying out different scenarios with sending the output of my MSI build to a network share and viewing the permissions of the MSI. But I must be missing something. Do you have an example of the permissions problem? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Meaning-of-Light-s-sacl-tp5416423p5417732.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Gracefully handling Internal Extension Errors
Hey all, For custom a Preprocessor or Compiler Extensions, what is the proper process/mechanism to gracefully handle internal errors. For example, if the GetVariableValue throws a NullReferenceException, or the Compiler extension ctor throws an exception, how should the exception be caught and reported so it shows up as something useful. Unhandled exceptions, when building inside Visual Studio, cause VS to do it's 'internal error would you like to report to Microsoft' flow. - Ed Unum Application Services In pleasant South Carolina -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Disallowing uninstallation of component since another client exists
Hello
I'm don't know how to continue an existing discussion, that's why I started a
new one (feel free to point me out the procedure if any). The discussion I
refer to is WiX MSI not removing REG entries during removal, from 15 November
2007.
Problem :
1. I install my product
2. I uninstall my product
3. Files are still here, reg keys too, and msi log states that Disallowing
uninstallation of component: {COMPONENT-GUID} since another client exists
Question :
As it seems to be the rule, my product GUID is auto-generated to force major
update (using a simple msi file).
Do I have to auto-generate my components GUID as well, in order to avoid the
problem described above ?
Thanks for any enlightenment
thomas
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Dialog execution order
Thanks Blair - That fixed it... it would be cool if your sentence explaining the problem was easily found or otherwise available in the doc...I was scratching my head for a long time over this. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dialog-execution-order-tp5417778p5420321.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Disallowing uninstallation of component since another client exists
No. You need to find the other product using your same component guid(s) and
remove that application as well (it may be a broken old version of your own
product that could not be removed).
-Original Message-
From: PLEYBER Thomas [mailto:thomas.pley...@alyotech.fr]
Sent: Friday, August 13, 2010 7:08 AM
To: 'wix-users@lists.sourceforge.net'
Subject: [WiX-users] Disallowing uninstallation of component since another
client exists
Hello
I'm don't know how to continue an existing discussion, that's why I started
a new one (feel free to point me out the procedure if any). The discussion I
refer to is WiX MSI not removing REG entries during removal, from 15
November 2007.
Problem :
1. I install my product
2. I uninstall my product
3. Files are still here, reg keys too, and msi log states that Disallowing
uninstallation of component: {COMPONENT-GUID} since another client exists
Question :
As it seems to be the rule, my product GUID is auto-generated to force major
update (using a simple msi file).
Do I have to auto-generate my components GUID as well, in order to avoid the
problem described above ?
Thanks for any enlightenment
thomas
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Gracefully handling Internal Extension Errors
Throw a WixException is one way (requires creating/obtaining a WixErrorEventArgs object which can be generated by compiling a file similar to the messages.xml files in the wix toolset). Some of the exceptions you mention have wix-ready exceptions already (see the src\wix\exceptions directory). -Original Message- From: Maillet, Ed [mailto:email...@unum.com] Sent: Friday, August 13, 2010 6:00 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Gracefully handling Internal Extension Errors Hey all, For custom a Preprocessor or Compiler Extensions, what is the proper process/mechanism to gracefully handle internal errors. For example, if the GetVariableValue throws a NullReferenceException, or the Compiler extension ctor throws an exception, how should the exception be caught and reported so it shows up as something useful. Unhandled exceptions, when building inside Visual Studio, cause VS to do it's 'internal error would you like to report to Microsoft' flow. - Ed Unum Application Services In pleasant South Carolina -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Error: MSB4067
Your project showed up, your log did not. Are you using the 32-bit or the 64-bit msbuild.exe? -Original Message- From: Taylor, Matthew [mailto:matthew.tay...@wspgroup.com] Sent: Friday, August 13, 2010 4:38 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Error: MSB4067 Hi, I'm having a problem building an install package. The build proj and log are attached. I'm using: VS2010 WIX 3.5 \Microsoft.NET\Framework\v3.5\MSBuild.exe On a 64-bit Windows XP system. Error: MSB4067 (see log) Can anybody help me with this error? Thanks regards, Matt -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] DTF managed custom action with supportedRuntime=v4.0
2.0-targeted applications do not activate with .NET 4.0 by default -- that was a deliberate compatibility policy decision made by.NET 4.0, for better or worse. You'll need to add useLegacyV2RuntimeActivationPolicy=true attribute to the startup element in your CustomAction.config. For more information, see http://msdn.microsoft.com/en-us/library/bbx34a2h.aspx -Original Message- From: Sam Strasser [mailto:sam.stras...@microsoft.com] Sent: Thursday, August 12, 2010 5:45 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] DTF managed custom action with supportedRuntime=v4.0 I am running my setup on a machine with .NET 4 but not .NET 3.5. The setup is running a managed custom action created using DTF, but the custom action is not run. Instead, I get this error: SFXCA: Extracting custom action to temporary directory: C:\Windows\Installer\MSI7DA3.tmp-\ SFXCA: Failed to get requested CLR info. Error code 0x80131700 SFXCA: Ensure that the proper version of the .NET Framework is installed, or that there is a matching supportedRuntime element in CustomAction.config. I have what I think is the right setup in my .config file: supportedRuntime version=v2.0.50727/ supportedRuntime version=v4.0/ Is this scenario supported? What am I doing wrong? Thanks in advance, Sam -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Passing properties to merge modules
While that works perfectly, it wasn't what I was after, but interesting nonetheless, so thanks. In the end after a further day of head-scratching I realised that I didn't fully understand what was going on in the merge process and was expecting too much. Revisting an example I realised that I needed a custom action to set the property. Here're the relevant bits: MSM: Property Id=FOO Value=default/ Configuration Name='fooProperty' Format='Text' DefaultValue='[FOO]'/ Substitution Table='CustomAction' Row='setFoo' Column='Target' Value='[=fooProperty]'/ CustomAction Id='setFoo' Property='FOO' Value='[FOO]'/ InstallExecuteSequence Custom Action='setFoo' Before=LaunchConditions1/Custom /InstallExecuteSequence MSI: Property Id=FOO Value=hello!/ Directory Id=TARGETDIR Name=SourceDir Merge Id=MyMergeModule SourceFile=MyMergeModule.msm DiskId=1 Language=1033 ConfigurationData Name='fooProperty' Value='[FOO]'/ /Merge /Directory And that's it. I was using FOO in the MSM to update an XML file to demonstrate that it was being set to hello!, which it was. A nice end to the week :~) Ryszard On 12 August 2010 19:29, bpackard bill.pack...@kepware.com wrote: Not certain that this is exactly what you are looking for, if you are actually attempting to update the directory table (based on the MY_DIRECTORY property listed), then this may help. !-- This block replaces the parent directory (in the Directory table) of SMHelp directory entry. This allows the user defined Start Menu property to be used for the shortcuts. -- Configuration Name=SHORTCUTFOLDER Format=Key Type=Identifier DefaultValue=SHORTCUTFOLDER Description=Start Menu Path DisplayName=Start Menu Folder/ Substitution Table=Directory Column=Directory_Parent Row=SMHelp Value=[=SHORTCUTFOLDER]/ Directory Id=TARGETDIR Name=SourceDir Directory Id=SMHelp Name=Help Documentation ShortName=HELPDOC / ... The property SHORTCUTFOLDER is generated in the MSI and becomes the parent directory of the SMHelp directory that exists in the merge module. You'll also need an entry in the directory table of the MSI project for the SHORTCUTFOLDER directory, as the actual path is generated it doesn't really matter where in the hierarchy it is. Directory Id=SHORTCUTFOLDER Name=ProgramMenuFolder/ When the module is merged into the MSI the parent of the SMHelp directory will become SHORTCUTFOLDER. bill packard -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Passing-properties-to-merge-modules-tp5417112p5417343.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] creating a 64b CustomAction
I see that the C# custom action I created references Microsoft.Dwployment.WindowsInstaller. Is there a 64b version of this? Or more generally, how do I make a 64b custom action dll? A -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] creating a 64b CustomAction
I set the Platform target to Any CPU and the problem went away. A On Fri, Aug 13, 2010 at 2:02 PM, Andrew Hammond andrew.george.hamm...@gmail.com wrote: I see that the C# custom action I created references Microsoft.Dwployment.WindowsInstaller. Is there a 64b version of this? Or more generally, how do I make a 64b custom action dll? A -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] setting INSTALLDIR using a CustomAction
I have the following CustomAction and would like to it to set the INSTALLDIR property used in the WXS that calls it. I seem to be trying to set the property incorrectly. session[INSTALLDIR] = Some Location What is the correct way to set properties from within a CustomAction? A -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Best way to copy (or reference) install files stored outside of MSI file.
Hello, this is my first post so apologies if this question has been answered before. (If so, please point me to the answer.) What's the best way to copy files on the distribution media (install CD) that are stored separately from the MSI file? That is, they're not embedded within the MSI payload but stored separately in another folder on the install disc. It seems like the MoveFiles element should do the trick but from the WiX documentation I don't see how to specify files on the source media. (Or even how to use the element at all.) If MoveFiles isn't the answer, then my next supposition would be to use a custom action that calls the Win32 CopyFile function within a DLL. I could resort to a program or a batch file called from the ShellExecute action or even have a batch file that installs the MSI and then copies the files, but I'd definitely like to avoid batch files. Perhaps there's yet another, better way. An example would be greatly appreciated. Thanks, Phil -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Best way to copy (or reference) install files stored outside of MSI file.
Does this help: http://blogs.technet.com/b/alexshev/archive/2008/04/04/from-msi-to-wix-part- 16-installable-items-handling-installation-media.aspx -Original Message- From: Philip Garofalo [mailto:ph...@vavatini.com] Sent: Friday, August 13, 2010 6:55 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Best way to copy (or reference) install files stored outside of MSI file. Hello, this is my first post so apologies if this question has been answered before. (If so, please point me to the answer.) What's the best way to copy files on the distribution media (install CD) that are stored separately from the MSI file? That is, they're not embedded within the MSI payload but stored separately in another folder on the install disc. It seems like the MoveFiles element should do the trick but from the WiX documentation I don't see how to specify files on the source media. (Or even how to use the element at all.) If MoveFiles isn't the answer, then my next supposition would be to use a custom action that calls the Win32 CopyFile function within a DLL. I could resort to a program or a batch file called from the ShellExecute action or even have a batch file that installs the MSI and then copies the files, but I'd definitely like to avoid batch files. Perhaps there's yet another, better way. An example would be greatly appreciated. Thanks, Phil -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] setting INSTALLDIR using a CustomAction
Ok, that works for setting INSTALLDIR, however it appears to be getting set after the files have alread installed. I have the following in my wxs, but it doesn't seem to be causing the CA to happen before it actually installs files. Binary Id=CustomAction.dll SourceFile= $(var.CustomAction.TargetDir)$(var.CustomAction.TargetName).CA.dll / CustomAction Id=SetMirInstallDir BinaryKey=CustomAction.dll DllEntry= SetMirInstallDir Execute=immediate/ InstallExecuteSequence Custom Action=SetMirInstallDir Before=InstallFiles / /InstallExecuteSequence I'll try a couple of other Before targets, but if anyone has done this before it'd be a big help. A On Fri, Aug 13, 2010 at 6:23 PM, Andrew Hammond andrew.george.hamm...@gmail.com wrote: I have the following CustomAction and would like to it to set the INSTALLDIR property used in the WXS that calls it. I seem to be trying to set the property incorrectly. session[INSTALLDIR] = Some Location What is the correct way to set properties from within a CustomAction? A -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
