[WiX-users] WIX 3.5 and Visual Studio 2008 Express
Hello, is there a way to use the WIX version 3.5, which can manage setup projects from/within Visual Studio 2008 Prof. with the Visual C++ 2008 Express Edition? Why is there no support for that free IDE? Will that IDE suported in the future? Thomas -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] multiple entries in add remove programs.
Why are your two upgrade codes different? Are you doing that on purpose? The upgrade code should remain the same for all products that are considered to be in the same upgrade family. by two upgrade codes, I mean the UpgradeCode in your Product tag and the Id in the Upgrade tag. Giora keinan grkei...@gmail.com 12/07/2009 01:39 AM 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] multiple entries in add remove programs. Hello Thanks Sascha, Asker and Neil. I tried your ideas and still have no idea what is the problem I am using only 3 digits version (trying to upgrade 1.0.7 to 1.0.8) following in my upgrade code, maybe you will found what is the problem: ?xml version='1.0' encoding='windows-1252'? ?define Version = 1.0.8 ? Wix xmlns='http://schemas.microsoft.com/wix/2006/wi' Product Name='CapsCake' Id='*' UpgradeCode='2638A59D-5047-4E78-87A6-A665B98FA131' Language='1033' Codepage='1252' Version='$(var.Version)' Manufacturer='Gakay' Package Id='*' Keywords='Installer' Description=CapCake $(var.Version) Updater Comments='CapsCake is a trademark of Gakay.' Manufacturer='Gakay' InstallerVersion='100' Languages='1033' Compressed='yes' SummaryCodepage='1252' / Property Id=INSTALLDIR RegistrySearch Id='CapsCakeRegistry' Type='raw' Root='HKLM' Key='Software\Gakay\CapsCake' Name='InstallDir' / /Property Upgrade Id=474E4E86-1153-4A4D-8ECE-6B1F4D423B24 UpgradeVersion OnlyDetect=yes Property=OLDERVERSIONBEINGUPGRADED Minimum=1.0.0 IncludeMinimum=yes Maximum=$(var.Version) IncludeMaximum=no / UpgradeVersion OnlyDetect=yes Property=NEWERVERSIONDETECTED Minimum=$(var.Version) IncludeMinimum=no / /Upgrade CustomAction Id=AlreadyUpdated Error=[ProductName] is alreadyinstalled. / CustomAction Id=NoDowngrade Error=A later version of [ProductName] is already installed. / Media Id='1' Cabinet='CapsCake.cab' EmbedCab='yes' / !-- Property Id='DiskPrompt' Value=CapCake $(var.Version) Updater [1] / -- Directory Id='TARGETDIR' Name='SourceDir' Directory Id='ProgramFilesFolder' Name='PFiles' Directory Id='INSTALLDIR' Name='.' Component Id='MainExecutable' Guid='*' File Id='CpasCakeEXE' Name='CapsCake.exe' DiskId='1' Source='CapsCake.exe' KeyPath='yes' /File /Component /Directory /Directory Component Id='CapsAppVersion' Guid='*' RegistryValue Id='CapsAppVersionKey' Root='HKLM' Key='Software\Gakay\CapsCake' Name='AppVersion' Type='string' Value='$(var.Version)' Action='write' / /Component /Directory !-- of the first dir -- Feature Id='Complete' Title='CapsCake' Description='The complete package.' Display='hidden' Level='1' ConfigurableDirectory='INSTALLDIR' ComponentRef Id='MainExecutable' / ComponentRef Id='CapsAppVersion' / /Feature InstallExecuteSequence !-- Custom Action='AlreadyUpdated' After='FindRelatedProducts'OLDERVERSIONBEINGUPGRADED/Custom -- Custom Action='NoDowngrade' After='FindRelatedProducts'NEWERVERSIONDETECTED/Custom /InstallExecuteSequence /Product /Wix Thanks Giora Sascha Beaumont wrote: Using Package/@Id=* I'm using the following code - this prevents two versions being installed where only the 4th version number differs. This is primarily to prevent confusion with internal testing, and means that we bump the third version following each public release in order to permit upgrades. We only release major upgrades, so I've got no idea how the code below would perform in a minor upgrade/patch scenario. Upgrade Id=$(var.Property_UpgradeCode) UpgradeVersion OnlyDetect=yes Minimum=$(var.version) Property=NEWERVERSIONDETECTED IncludeMinimum=no / UpgradeVersion OnlyDetect=no Maximum=$(var.version) Property=OLDERVERSIONBEINGUPGRADED IncludeMaximum=no / !-- Detect for changes in 4th field only -- UpgradeVersion Property=ANOTHERBUILDINSTALLED Maximum=$(var.version) Minimum=$(var.version) IncludeMinimum=yes IncludeMaximum=yes OnlyDetect=yes / /Upgrade CustomAction Id=CA_BlockOlderVersionInstall Error=!(loc.LaunchCondition_LaterVersion) / CustomAction Id=CA_BlockAnotherBuildInstall Error=!(loc.LaunchCondition_AnotherBuild) / InstallExecuteSequence Custom Action=CA_BlockOlderVersionInstall After=FindRelatedProducts ![CDATA[NEWERVERSIONDETECTED]] /Custom !-- Prevent installation on 4th version field change only -- Custom Action=CA_BlockAnotherBuildInstall After=FindRelatedProducts
[WiX-users] 32 bit component best practice
Our product has both 32 and 64 bit versions, and we want to allow users to install these side-by-side on a 64 bit machine. The 64 bit version includes a 32 bit component which is identical to the corresponding component of the 32 bit version. How should we choose an installation location for the common 32 bit component? Whilst the 32 bit component isn't huge, it would be nice to share it if the user does install both the 32 and 64 bit versions. I'd also like to avoid, when installing the 64 bit version, two separate prompts for installation locations... Where do you want this application installed? Where do you want the 32 bit component of this application installed? Should I just be dropping the 32 bit component into CommonFilesFolder, perhaps? Thanks for any advice! -- John -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WIX 3.5 and Visual Studio 2008 Express
Thomas Steinbach wrote: is there a way to use the WIX version 3.5, which can manage setup projects from/within Visual Studio 2008 Prof. with the Visual C++ 2008 Express Edition? Why is there no support for that free IDE? Will that IDE suported in the future? No, it won't be supported because Express editions don't have that kind of extensibility enabled. They're free, after all. -- sig://boB http://joyofsetup.com/ -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WIX extension: CreateWixSimpleReferenceRow doesn't work with custom tables?
Hi,
I'm developing WIX extension which creates number of custom tables. One of
them is similar to InstallExecuteSequence, another one is similar to
CustomAction table. Don't ask me why, I just need it ;)
Tables look as follows:
tableDefinition name=MyExecuteSequence
columnDefinition name=Action type=string length=128
primaryKey=yes category=identifier/
columnDefinition name=Condition type=string length=255
nullable=yes /
columnDefinition name=Sequence type=number length=4/
columnDefinition name=Text type=string length=128 nullable=yes
/
columnDefinition name=Flags type=number length=4 nullable=yes
/
/tableDefinition
tableDefinition name=MyCustomAction
columnDefinition name=Key type=string length=128 primaryKey=yes
category=identifier/
columnDefinition name=Module type=string length=128
nullable=no/
columnDefinition name=Condition type=string length=255
nullable=yes/
columnDefinition name=Exe type=string length=255 nullable=no /
columnDefinition name=Install type=string length=128
nullable=yes/
columnDefinition name=Uninstall type=string length=128
nullable=yes/
columnDefinition name=Flags type=number length=4 nullable=yes/
/tableDefinition
Action column in MyExecuteSequence may be one of predefined actions or link
to MyCustomAction table, so I can't set foreign key there - just like in
InstallExecuteSequence. To get some basic validation, in MyExecuteSequence
parsing code I'm trying to create simple reference to MyCustomAction table:
switch (attrib.LocalName)
{
case Action:
if (isCustomAction)
{
action =
extension.Core.GetAttributeIdentifierValue(sourceLineNumbers, attrib);
extension.Core.CreateWixSimpleReferenceRow(sourceLineNumbers,
MyCustomAction, action);
}
else
{
extension.Core.UnexpectedAttribute(sourceLineNumbers, attrib);
}
break;
...
WIX source code:
my:CustomAction Id=custom1 Module=Core Exe=myca.exe
Install=/install Uninstall=/uninstall/
my:ExecuteSequence
my:RunCustomAction Action=custom1 Text=executing custom1
Sequence=1000/
/my:ExecuteSequence
Unfortunately when I try to compile it, I always get
error LGHT0094: Unresolved reference to symbol 'MyCustomAction:custom1' in
section 'Fragment:'.
I checked .wixpdb file and MyCustomAction table is there, with custom1 in
'Key' column which is primary key of this table, so I have no idea what's
wrong.
If I remove creating reference - compilation succeeds, but I have no
validation then.
Any ideas how to make it work?
--
View this message in context:
http://n2.nabble.com/WIX-extension-CreateWixSimpleReferenceRow-doesn-t-work-with-custom-tables-tp4126323p4126323.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Problem with removing registry key containing version info and not removing an assembly while doing a major upgrade
Hi, While creating an installer that should do a major upgrade I firstly faced the problem that the registry key containing a version number (of the previous version) doesn't get removed. In order to make it possible that the installer of the upgrade removes it I changed the GUID of the component containing that registry key. I experienced that the component with the new GUID gets installed only if I schedule RemoveExistingProducts after InstallInitialize. But in order not to remove an assembly from GAC I have to schedule it after InstallFinalize. Can I find some work around for this problem so that I remove the registry key and keep the assembly? Thanks -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with removing registry key containing version info and not removing an assembly while doing a major upgrade
Is the registry value containing the version number the keypath if its component? -Original Message- From: Ana Martic [mailto:t-anm...@microsoft.com] Sent: Monday, December 07, 2009 7:31 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Problem with removing registry key containing version info and not removing an assembly while doing a major upgrade Hi, While creating an installer that should do a major upgrade I firstly faced the problem that the registry key containing a version number (of the previous version) doesn't get removed. In order to make it possible that the installer of the upgrade removes it I changed the GUID of the component containing that registry key. I experienced that the component with the new GUID gets installed only if I schedule RemoveExistingProducts after InstallInitialize. But in order not to remove an assembly from GAC I have to schedule it after InstallFinalize. Can I find some work around for this problem so that I remove the registry key and keep the assembly? Thanks -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] multiple entries in add remove programs.
You have OnlyDetect set to Yes when you detect the older version, that won't cause the upgrade to occur. Phil Wilson -Original Message- From: Giora keinan [mailto:grkei...@gmail.com] Sent: Monday, December 07, 2009 1:35 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] multiple entries in add remove programs. Hello Thanks Sascha, Asker and Neil. I tried your ideas and still have no idea what is the problem I am using only 3 digits version (trying to upgrade 1.0.7 to 1.0.8) following in my upgrade code, maybe you will found what is the problem: ?xml version='1.0' encoding='windows-1252'? ?define Version = 1.0.8 ? Wix xmlns='http://schemas.microsoft.com/wix/2006/wi' Product Name='CapsCake' Id='*' UpgradeCode='2638A59D-5047-4E78-87A6-A665B98FA131' Language='1033' Codepage='1252' Version='$(var.Version)' Manufacturer='Gakay' Package Id='*' Keywords='Installer' Description=CapCake $(var.Version) Updater Comments='CapsCake is a trademark of Gakay.' Manufacturer='Gakay' InstallerVersion='100' Languages='1033' Compressed='yes' SummaryCodepage='1252' / Property Id=INSTALLDIR RegistrySearch Id='CapsCakeRegistry' Type='raw' Root='HKLM' Key='Software\Gakay\CapsCake' Name='InstallDir' / /Property Upgrade Id=474E4E86-1153-4A4D-8ECE-6B1F4D423B24 UpgradeVersion OnlyDetect=yes Property=OLDERVERSIONBEINGUPGRADED Minimum=1.0.0 IncludeMinimum=yes Maximum=$(var.Version) IncludeMaximum=no / UpgradeVersion OnlyDetect=yes Property=NEWERVERSIONDETECTED Minimum=$(var.Version) IncludeMinimum=no / /Upgrade CustomAction Id=AlreadyUpdated Error=[ProductName] is alreadyinstalled. / CustomAction Id=NoDowngrade Error=A later version of [ProductName] is already installed. / Media Id='1' Cabinet='CapsCake.cab' EmbedCab='yes' / !-- Property Id='DiskPrompt' Value=CapCake $(var.Version) Updater [1] / -- Directory Id='TARGETDIR' Name='SourceDir' Directory Id='ProgramFilesFolder' Name='PFiles' Directory Id='INSTALLDIR' Name='.' Component Id='MainExecutable' Guid='*' File Id='CpasCakeEXE' Name='CapsCake.exe' DiskId='1' Source='CapsCake.exe' KeyPath='yes' /File /Component /Directory /Directory Component Id='CapsAppVersion' Guid='*' RegistryValue Id='CapsAppVersionKey' Root='HKLM' Key='Software\Gakay\CapsCake' Name='AppVersion' Type='string' Value='$(var.Version)' Action='write' / /Component /Directory !-- of the first dir -- Feature Id='Complete' Title='CapsCake' Description='The complete package.' Display='hidden' Level='1' ConfigurableDirectory='INSTALLDIR' ComponentRef Id='MainExecutable' / ComponentRef Id='CapsAppVersion' / /Feature InstallExecuteSequence !-- Custom Action='AlreadyUpdated' After='FindRelatedProducts'OLDERVERSIONBEINGUPGRADED/Custom -- Custom Action='NoDowngrade' After='FindRelatedProducts'NEWERVERSIONDETECTED/Custom /InstallExecuteSequence /Product /Wix Thanks Giora Sascha Beaumont wrote: Using Package/@Id=* I'm using the following code - this prevents two versions being installed where only the 4th version number differs. This is primarily to prevent confusion with internal testing, and means that we bump the third version following each public release in order to permit upgrades. We only release major upgrades, so I've got no idea how the code below would perform in a minor upgrade/patch scenario. Upgrade Id=$(var.Property_UpgradeCode) UpgradeVersion OnlyDetect=yes Minimum=$(var.version) Property=NEWERVERSIONDETECTED IncludeMinimum=no / UpgradeVersion OnlyDetect=no Maximum=$(var.version) Property=OLDERVERSIONBEINGUPGRADED IncludeMaximum=no / !-- Detect for changes in 4th field only -- UpgradeVersion Property=ANOTHERBUILDINSTALLED Maximum=$(var.version) Minimum=$(var.version) IncludeMinimum=yes IncludeMaximum=yes OnlyDetect=yes / /Upgrade CustomAction Id=CA_BlockOlderVersionInstall Error=!(loc.LaunchCondition_LaterVersion) / CustomAction Id=CA_BlockAnotherBuildInstall Error=!(loc.LaunchCondition_AnotherBuild) / InstallExecuteSequence Custom Action=CA_BlockOlderVersionInstall After=FindRelatedProducts ![CDATA[NEWERVERSIONDETECTED]] /Custom !-- Prevent installation on 4th version field change only -- Custom Action=CA_BlockAnotherBuildInstall After=FindRelatedProducts ![CDATA[ANOTHERBUILDINSTALLED]] /Custom /InstallExecuteSequence On Mon, Dec 7, 2009 at 5:54 PM, Asker Brodersen asker.broder...@esri-sgroup.se wrote: Giora, do your versions differ by more than the fourth digit? I have found that if you install
Re: [WiX-users] multiple entries in add remove programs.
Goira, your Product/@UpgradeCode doesn't match Upgrade/@Id that is why you get the duplicate. Take a look at my sample again you will see I use ?define UpgradeCode to stop this happening. Neil -Original Message- From: Giora keinan [mailto:grkei...@gmail.com] Sent: 07 December 2009 09:35 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] multiple entries in add remove programs. Hello Thanks Sascha, Asker and Neil. I tried your ideas and still have no idea what is the problem I am using only 3 digits version (trying to upgrade 1.0.7 to 1.0.8) following in my upgrade code, maybe you will found what is the problem: ?xml version='1.0' encoding='windows-1252'? ?define Version = 1.0.8 ? Wix xmlns='http://schemas.microsoft.com/wix/2006/wi' Product Name='CapsCake' Id='*' UpgradeCode='2638A59D-5047-4E78-87A6-A665B98FA131' Language='1033' Codepage='1252' Version='$(var.Version)' Manufacturer='Gakay' Package Id='*' Keywords='Installer' Description=CapCake $(var.Version) Updater Comments='CapsCake is a trademark of Gakay.' Manufacturer='Gakay' InstallerVersion='100' Languages='1033' Compressed='yes' SummaryCodepage='1252' / Property Id=INSTALLDIR RegistrySearch Id='CapsCakeRegistry' Type='raw' Root='HKLM' Key='Software\Gakay\CapsCake' Name='InstallDir' / /Property Upgrade Id=474E4E86-1153-4A4D-8ECE-6B1F4D423B24 UpgradeVersion OnlyDetect=yes Property=OLDERVERSIONBEINGUPGRADED Minimum=1.0.0 IncludeMinimum=yes Maximum=$(var.Version) IncludeMaximum=no / UpgradeVersion OnlyDetect=yes Property=NEWERVERSIONDETECTED Minimum=$(var.Version) IncludeMinimum=no / /Upgrade CustomAction Id=AlreadyUpdated Error=[ProductName] is alreadyinstalled. / CustomAction Id=NoDowngrade Error=A later version of [ProductName] is already installed. / Media Id='1' Cabinet='CapsCake.cab' EmbedCab='yes' / !-- Property Id='DiskPrompt' Value=CapCake $(var.Version) Updater [1] / -- Directory Id='TARGETDIR' Name='SourceDir' Directory Id='ProgramFilesFolder' Name='PFiles' Directory Id='INSTALLDIR' Name='.' Component Id='MainExecutable' Guid='*' File Id='CpasCakeEXE' Name='CapsCake.exe' DiskId='1' Source='CapsCake.exe' KeyPath='yes' /File /Component /Directory /Directory Component Id='CapsAppVersion' Guid='*' RegistryValue Id='CapsAppVersionKey' Root='HKLM' Key='Software\Gakay\CapsCake' Name='AppVersion' Type='string' Value='$(var.Version)' Action='write' / /Component /Directory !-- of the first dir -- Feature Id='Complete' Title='CapsCake' Description='The complete package.' Display='hidden' Level='1' ConfigurableDirectory='INSTALLDIR' ComponentRef Id='MainExecutable' / ComponentRef Id='CapsAppVersion' / /Feature InstallExecuteSequence !-- Custom Action='AlreadyUpdated' After='FindRelatedProducts'OLDERVERSIONBEINGUPGRADED/Custom -- Custom Action='NoDowngrade' After='FindRelatedProducts'NEWERVERSIONDETECTED/Custom /InstallExecuteSequence /Product /Wix Thanks Giora Sascha Beaumont wrote: Using Package/@Id=* I'm using the following code - this prevents two versions being installed where only the 4th version number differs. This is primarily to prevent confusion with internal testing, and means that we bump the third version following each public release in order to permit upgrades. We only release major upgrades, so I've got no idea how the code below would perform in a minor upgrade/patch scenario. Upgrade Id=$(var.Property_UpgradeCode) UpgradeVersion OnlyDetect=yes Minimum=$(var.version) Property=NEWERVERSIONDETECTED IncludeMinimum=no / UpgradeVersion OnlyDetect=no Maximum=$(var.version) Property=OLDERVERSIONBEINGUPGRADED IncludeMaximum=no / !-- Detect for changes in 4th field only -- UpgradeVersion Property=ANOTHERBUILDINSTALLED Maximum=$(var.version) Minimum=$(var.version) IncludeMinimum=yes IncludeMaximum=yes OnlyDetect=yes / /Upgrade CustomAction Id=CA_BlockOlderVersionInstall Error=!(loc.LaunchCondition_LaterVersion) / CustomAction Id=CA_BlockAnotherBuildInstall Error=!(loc.LaunchCondition_AnotherBuild) / InstallExecuteSequence Custom Action=CA_BlockOlderVersionInstall After=FindRelatedProducts ![CDATA[NEWERVERSIONDETECTED]] /Custom !-- Prevent installation on 4th version field change only -- Custom Action=CA_BlockAnotherBuildInstall After=FindRelatedProducts ![CDATA[ANOTHERBUILDINSTALLED]] /Custom /InstallExecuteSequence On Mon, Dec 7, 2009 at 5:54 PM, Asker Brodersen asker.broder...@esri-sgroup.se wrote: Giora, do your versions differ by
Re: [WiX-users] How Do I Verify Group Membership?
If you have special security needs, the best approach is to create a user or group with exactly the permissions that you need and have your code run as that user or as a member of that group. When you uninstall your application you remove the created user/group. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/ Legalize Adulthood! http://legalizeadulthood.wordpress.com -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] SqlString is Name a keyword?
All:
I'm using SqlString to affect changes to the database during
installation. Here is a snippet from the wxs file:
sql:SqlString Id=InsertCabinetScript ExecuteOnInstall=yes
Sequence=6
SQL=IF NOT EXISTS (
SELECT * FROM Cabinet WHERE [Name] = '[SQLSERVERDATABASENAME]'
)
INSERT INTO Cabinet ([Name], StorageProvider)
VALUES ('[SQLSERVERDATABASENAME]','[STORAGEPROVIDERCONFIG]' ) /
I'm getting the following exception during install:
Error -2147217900: failed to execute SQL string, error
Detail: Line 4: Incorrect syntax near ','., SQL key:
InsertCabinetScript SQL string: IF NOT EXISTS (
SELECT * FROM Cabinet WHERE = 'installTest'
)
INSERT INTO Cabinet (, StorageProvider)...
As you can see the error message includes the first bit of the script
and Name is being replaced with an empty string in the two places it
shows up. I have tried Name and [Name] in the script with the same
results for each.
Any help on this is greatly appreciated.
Regards,
Steve Braswell
Informa Software
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] SqlString is Name a keyword?
Hi Steve,
I guess, SQL attribute is a Formatted string. Try to escape [ and ]:
[\[]
And
[\]]
Alex
-Original Message-
From: Steve Braswell [mailto:sbrasw...@informasoftware.com]
Sent: Monday, December 07, 2009 1:12 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] SqlString is Name a keyword?
All:
I'm using SqlString to affect changes to the database during
installation. Here is a snippet from the wxs file:
sql:SqlString Id=InsertCabinetScript ExecuteOnInstall=yes
Sequence=6
SQL=IF NOT EXISTS (
SELECT * FROM Cabinet WHERE [Name] = '[SQLSERVERDATABASENAME]'
)
INSERT INTO Cabinet ([Name], StorageProvider)
VALUES ('[SQLSERVERDATABASENAME]','[STORAGEPROVIDERCONFIG]' ) /
I'm getting the following exception during install:
Error -2147217900: failed to execute SQL string, error
Detail: Line 4: Incorrect syntax near ','., SQL key:
InsertCabinetScript SQL string: IF NOT EXISTS (
SELECT * FROM Cabinet WHERE = 'installTest'
)
INSERT INTO Cabinet (, StorageProvider)...
As you can see the error message includes the first bit of the script
and Name is being replaced with an empty string in the two places it
shows up. I have tried Name and [Name] in the script with the same
results for each.
Any help on this is greatly appreciated.
Regards,
Steve Braswell
Informa Software
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Instance transforms with the msi
Hi, I am using instance transforms (msts) to install multiple instances of my base product (msi) on the same machine. Everything works except for one issue: I use an instance identifier property [INSTANCEPROP] that gets set toInstance1, Instance 2,...etc for each instance. I use this property to write registry keys for each instance. For example - HKLM\Software\ESRI\[INSTANCEPROP] is written via the registry table (One record in the registry table to linked to one component). When multiple instances are installed, this key could be repeated multiple times, but they would all be in their own hive HKLM\Software\ESRI\ Instance1 HKLM\Software\ESRI\ Instance2 HKLM\Software\ESRI\ Instance3 Etc Scenario: The base setup and an instance 1 is installed, I uninstall the instance 1. I find that HKLM\Software\ESRI\Instance1 is still left behind on the machine after instance 1 is uninstalled. Is this because the component that includes this registry key is still in the installed state with the base setup? What would be the best way to ensure that the HKLM\Software\ESRI\Instance1 get removed when instance 1 is uninstalled? Should I make multiple components in the msi each with unique conditions for each transform? Or create a custom action that deletes the registry entry for each transform? Thanks! Uma Harano -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Instance transforms with the msi
Are you using the same component GUID for each of these keys? You can't do that... It's breaking the component rules and all kinds of bad things happen when you break the component rules. Each distinct component keypath (the 'main' entry in a component) MUST have a unique component GUID. Each distinct component GUID can only be installed in one place on a given machine (you can't try to install the same GUID to two different keypaths). Kelly Uma Harano uhar...@esri.com 12/07/2009 02:47 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 [WiX-users] Instance transforms with the msi Hi, I am using instance transforms (msts) to install multiple instances of my base product (msi) on the same machine. Everything works except for one issue: I use an instance identifier property [INSTANCEPROP] that gets set toInstance1, Instance 2,...etc for each instance. I use this property to write registry keys for each instance. For example - HKLM\Software\ESRI\[INSTANCEPROP] is written via the registry table (One record in the registry table to linked to one component). When multiple instances are installed, this key could be repeated multiple times, but they would all be in their own hive HKLM\Software\ESRI\ Instance1 HKLM\Software\ESRI\ Instance2 HKLM\Software\ESRI\ Instance3 Etc Scenario: The base setup and an instance 1 is installed, I uninstall the instance 1. I find that HKLM\Software\ESRI\Instance1 is still left behind on the machine after instance 1 is uninstalled. Is this because the component that includes this registry key is still in the installed state with the base setup? What would be the best way to ensure that the HKLM\Software\ESRI\Instance1 get removed when instance 1 is uninstalled? Should I make multiple components in the msi each with unique conditions for each transform? Or create a custom action that deletes the registry entry for each transform? Thanks! Uma Harano -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ 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 disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Unless indicated to the contrary: it does not constitute professional advice or opinions upon which reliance may be made by the addressee or any other party, and it should be considered to be a work in progress. Unless otherwise noted in this email or its attachments, this communication does not form a Statement of Actuarial Opinion under American Academy of Actuaries guidelines. ** -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Instance transforms with the msi
Each instance has a unique Product Code. Also, I was following the guidelines from the Windows installer SDK (On how to author instance transforms). How do I install the same set of files for multiple instances using transforms? Please advise! Uma- Here is the windows installer sdk topic on this: Authoring Multiple Instances with Instance Transforms To install multiple instances of a product from one Windows(r) Installer package, you need to author a base installation package for the product and an instance transform for each instance to be installed in addition to the base instance. Use the following guidelines when authoring your base package and transforms: *Your setup application can check for the presence of the installer running on a version of the Microsoft(r)Windows Server 2003 family, Windows XP SP1, Windows 2000 SP4 and the Windows Installer 3.0 redistributable. Any of these installer versions (or later) are required to install multiple instances from a single package using a product code-changing transform. * Each instance must have a unique product code and instance identifier. You may define a property in the base package, the value of which can be set to the instance identifier. * To keep the files of each instance isolated, the base package should install files into a directory location that depends on the instance identifier. * To keep the nonfile data of each instance isolated, the base package should collect nonfile data into sets of components for each instance. The appropriate components should then be installed based on conditional statements that depend on the instance identifier. * Author an instance transform for each instance being installed in addition to the base instance. The base package may install its own instance. * The instance transform must change the product code and identifier for each instance. * It is recommended that the product transform also change the product name so that the instance is readily distinguished in Add/Remove Programs through Control Panel. * If the instance transform installs files, they should be installed in a directory that depends on the instance identifier. * All nonfile data, such as registry keys, should include the instance name in their path to prevent collisions. This can be accomplished by using the property whose value is the instance identifier in the path as shown by the following example of a Registry Table. -Original Message- From: kelly.le...@milliman.com [mailto:kelly.le...@milliman.com] Sent: Monday, December 07, 2009 2:52 PM To: General discussion for Windows Installer XML toolset. Cc: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Instance transforms with the msi Are you using the same component GUID for each of these keys? You can't do that... It's breaking the component rules and all kinds of bad things happen when you break the component rules. Each distinct component keypath (the 'main' entry in a component) MUST have a unique component GUID. Each distinct component GUID can only be installed in one place on a given machine (you can't try to install the same GUID to two different keypaths). Kelly Uma Harano uhar...@esri.com 12/07/2009 02:47 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 [WiX-users] Instance transforms with the msi Hi, I am using instance transforms (msts) to install multiple instances of my base product (msi) on the same machine. Everything works except for one issue: I use an instance identifier property [INSTANCEPROP] that gets set toInstance1, Instance 2,...etc for each instance. I use this property to write registry keys for each instance. For example - HKLM\Software\ESRI\[INSTANCEPROP] is written via the registry table (One record in the registry table to linked to one component). When multiple instances are installed, this key could be repeated multiple times, but they would all be in their own hive HKLM\Software\ESRI\ Instance1 HKLM\Software\ESRI\ Instance2 HKLM\Software\ESRI\ Instance3 Etc Scenario: The base setup and an instance 1 is installed, I uninstall the instance 1. I find that HKLM\Software\ESRI\Instance1 is still left behind on the machine after instance 1 is uninstalled. Is this because the component that includes this registry key is still in the installed state with the base setup? What would be the best way to ensure that the HKLM\Software\ESRI\Instance1 get removed when instance 1 is uninstalled? Should I make multiple components in the msi each with unique conditions for each transform? Or create a custom action that deletes the registry entry for each transform? Thanks! Uma Harano -- Return on Information: Google Enterprise
Re: [WiX-users] Instance transforms with the msi
I wasn't asking about ProductCode. I'm asking about the component GUID for the registry key you're referring to. You need to assign different GUIDs for all components that could be installed in two locations by the two different instances. If you want to install the same files in two places, you're going to have to modify all the component GUIDs for the files, if I understand the process correctly. I'm not an expert on using instance transforms to install multiple instances, but it seems like no matter what you do, you can't break the component rules. Otherwise, it won't install the files to the new locations, since it will think they are already installed (based on the component ID and its installed state). Kelly Uma Harano uhar...@esri.com 12/07/2009 03:24 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] Instance transforms with the msi Each instance has a unique Product Code. Also, I was following the guidelines from the Windows installer SDK (On how to author instance transforms). How do I install the same set of files for multiple instances using transforms? Please advise! Uma- Here is the windows installer sdk topic on this: Authoring Multiple Instances with Instance Transforms To install multiple instances of a product from one Windows(r) Installer package, you need to author a base installation package for the product and an instance transform for each instance to be installed in addition to the base instance. Use the following guidelines when authoring your base package and transforms: *Your setup application can check for the presence of the installer running on a version of the Microsoft(r)Windows Server 2003 family, Windows XP SP1, Windows 2000 SP4 and the Windows Installer 3.0 redistributable. Any of these installer versions (or later) are required to install multiple instances from a single package using a product code-changing transform. * Each instance must have a unique product code and instance identifier. You may define a property in the base package, the value of which can be set to the instance identifier. * To keep the files of each instance isolated, the base package should install files into a directory location that depends on the instance identifier. * To keep the nonfile data of each instance isolated, the base package should collect nonfile data into sets of components for each instance. The appropriate components should then be installed based on conditional statements that depend on the instance identifier. * Author an instance transform for each instance being installed in addition to the base instance. The base package may install its own instance. * The instance transform must change the product code and identifier for each instance. * It is recommended that the product transform also change the product name so that the instance is readily distinguished in Add/Remove Programs through Control Panel. * If the instance transform installs files, they should be installed in a directory that depends on the instance identifier. * All nonfile data, such as registry keys, should include the instance name in their path to prevent collisions. This can be accomplished by using the property whose value is the instance identifier in the path as shown by the following example of a Registry Table. -Original Message- From: kelly.le...@milliman.com [mailto:kelly.le...@milliman.com] Sent: Monday, December 07, 2009 2:52 PM To: General discussion for Windows Installer XML toolset. Cc: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Instance transforms with the msi Are you using the same component GUID for each of these keys? You can't do that... It's breaking the component rules and all kinds of bad things happen when you break the component rules. Each distinct component keypath (the 'main' entry in a component) MUST have a unique component GUID. Each distinct component GUID can only be installed in one place on a given machine (you can't try to install the same GUID to two different keypaths). Kelly Uma Harano uhar...@esri.com 12/07/2009 02:47 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 [WiX-users] Instance transforms with the msi Hi, I am using instance transforms (msts) to install multiple instances of my base product (msi) on the same machine. Everything works except for one issue: I use an instance identifier property [INSTANCEPROP] that gets set toInstance1, Instance 2,...etc for each instance. I use this property to write registry keys for each instance. For example - HKLM\Software\ESRI\[INSTANCEPROP] is
[WiX-users] Two Custom Action entry points in one C++ Dll and WcaLog failure
At one point I was thinking that I have too many C++ Custom Action Dlls and started using existing Dlls. That is, I added a new entry point for a new CA in a Dll that already hosted code for existing CA. That appears to work just fine except for one issue: WcaLog() doesn't work - nothing gets output in a log! I don't know if the fact that I have 2 CA and 2 entry points in this DLL is relevant, but this is the only case where WcaLog doesn't work. I am using calls like: ::WcaLog(LOGMSG_STANDARD, Install folder %S created., Path); so there is hardly anything mysterious here that can fail when many similar calls in many other CA Dlls work. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Instance transforms with the msi
Hi If you are using MSI Instances and installing to different locations, you don't need different component GUIDs for each component in each installed instance and the reference counting seems to work okay. I will be honest and say I don't know how it works under the hood, but it does work.The installer is able to work out where things are. I do however use a registry key for each instance to keep the path where I installed that instance too, which comes in handy on major upgrades. Also have found it usefull to record the product ID of the instance in the registry as well. Michael From: kelly.le...@milliman.com [kelly.le...@milliman.com] Sent: Tuesday, 8 December 2009 9:32 AM To: General discussion for Windows Installer XML toolset. Cc: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Instance transforms with the msi I wasn't asking about ProductCode. I'm asking about the component GUID for the registry key you're referring to. You need to assign different GUIDs for all components that could be installed in two locations by the two different instances. If you want to install the same files in two places, you're going to have to modify all the component GUIDs for the files, if I understand the process correctly. I'm not an expert on using instance transforms to install multiple instances, but it seems like no matter what you do, you can't break the component rules. Otherwise, it won't install the files to the new locations, since it will think they are already installed (based on the component ID and its installed state). Kelly Uma Harano uhar...@esri.com 12/07/2009 03:24 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] Instance transforms with the msi Each instance has a unique Product Code. Also, I was following the guidelines from the Windows installer SDK (On how to author instance transforms). How do I install the same set of files for multiple instances using transforms? Please advise! Uma- Here is the windows installer sdk topic on this: Authoring Multiple Instances with Instance Transforms To install multiple instances of a product from one Windows(r) Installer package, you need to author a base installation package for the product and an instance transform for each instance to be installed in addition to the base instance. Use the following guidelines when authoring your base package and transforms: *Your setup application can check for the presence of the installer running on a version of the Microsoft(r)Windows Server 2003 family, Windows XP SP1, Windows 2000 SP4 and the Windows Installer 3.0 redistributable. Any of these installer versions (or later) are required to install multiple instances from a single package using a product code-changing transform. * Each instance must have a unique product code and instance identifier. You may define a property in the base package, the value of which can be set to the instance identifier. * To keep the files of each instance isolated, the base package should install files into a directory location that depends on the instance identifier. * To keep the nonfile data of each instance isolated, the base package should collect nonfile data into sets of components for each instance. The appropriate components should then be installed based on conditional statements that depend on the instance identifier. * Author an instance transform for each instance being installed in addition to the base instance. The base package may install its own instance. * The instance transform must change the product code and identifier for each instance. * It is recommended that the product transform also change the product name so that the instance is readily distinguished in Add/Remove Programs through Control Panel. * If the instance transform installs files, they should be installed in a directory that depends on the instance identifier. * All nonfile data, such as registry keys, should include the instance name in their path to prevent collisions. This can be accomplished by using the property whose value is the instance identifier in the path as shown by the following example of a Registry Table. -Original Message- From: kelly.le...@milliman.com [mailto:kelly.le...@milliman.com] Sent: Monday, December 07, 2009 2:52 PM To: General discussion for Windows Installer XML toolset. Cc: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Instance transforms with the msi Are you using the same component GUID for each of these keys? You can't do that... It's breaking the component rules and all kinds of bad things happen when you break the component rules. Each distinct component keypath (the 'main' entry in a component) MUST have a unique component GUID.
Re: [WiX-users] How Do I Verify Group Membership?
In general I don't have permission nor ability to create the domain accounts/groups with the required permissions on our target environments. Requirements/restrictions can get in the way sometimes. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Richard [mailto:legal...@xmission.com] Sent: Monday, December 07, 2009 10:08 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How Do I Verify Group Membership? If you have special security needs, the best approach is to create a user or group with exactly the permissions that you need and have your code run as that user or as a member of that group. When you uninstall your application you remove the created user/group. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://legalizeadulthood.wordpress.com/the-direct3d-graphics- pipeline/ Legalize Adulthood! http://legalizeadulthood.wordpress.com --- --- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Quiet Execution Custom Action - run a temporary executable
Hi All, I have an executable which has to be launched as a custom action. It is a temporary one, I have to run and delete it after that. When I add it as a Binary and Custom action it works. Binary Id=SetConfigExe SourceFile=$(var.SetConfig.TargetDir)SetConfig.exe / CustomAction Id=RunSetConfig PAR1=[SOMEPAR1] / Now I want to execute it silently, I added an action to set RunSetConfig property and another CAQuietExec custom action to execute. CustomAction Id=RunSetConfig BinaryKey=WixCA DllEntry=CAQuietExec Execute=deferred Return=check Impersonate=no/ From the log file I see that exe name and parameters are assigned properly but with no path to the exe and installer seems cannot find that exe. Any way to point the action on a binary? I don't want to include that exe as a component. Thanks, Vladimir -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] table contains an action '' -- how to find it ??? (Light warning 1055)
Light is giving this warning: Console.wxs(142) : warning LGHT1055 : The table contains an action '' which cannot be merged from the merge module 'CDF.msm'. How can I find which action is colliding? Light omits the name, and there's no obvious culprit in CDF.msm (which is built elsewhere, and not from WiX source) nor in Console.wxs The Console.wxs source was converted by dark.exe (original source was Wise) and contains no custom actions itself, but does pull in a number of other merge modules with numerous custom actions. We're using Wix 3.0.5419.0. The full text warning is Console.wxs(142) : warning LGHT1055 : The table contains an action '' which cannot be merged from the merge module 'CDF.msm'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. If this is a standard action, it is likely colliding due to a difference in the condition for the action in the database and merge module. If this is a custom action, it should only be declared in the database or one merge module. thanks -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Instance transforms with the msi
See if this can be of any help for you: http://ysdevlog.blogspot.com/2008/12/multiple-instance-installations-and .html It works for me. -- Yan -Original Message- From: Uma Harano [mailto:uhar...@esri.com] Sent: Tuesday, December 08, 2009 01:24 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Instance transforms with the msi Each instance has a unique Product Code. Also, I was following the guidelines from the Windows installer SDK (On how to author instance transforms). How do I install the same set of files for multiple instances using transforms? Please advise! Uma- Here is the windows installer sdk topic on this: Authoring Multiple Instances with Instance Transforms To install multiple instances of a product from one Windows(r) Installer package, you need to author a base installation package for the product and an instance transform for each instance to be installed in addition to the base instance. Use the following guidelines when authoring your base package and transforms: *Your setup application can check for the presence of the installer running on a version of the Microsoft(r)Windows Server 2003 family, Windows XP SP1, Windows 2000 SP4 and the Windows Installer 3.0 redistributable. Any of these installer versions (or later) are required to install multiple instances from a single package using a product code-changing transform. * Each instance must have a unique product code and instance identifier. You may define a property in the base package, the value of which can be set to the instance identifier. * To keep the files of each instance isolated, the base package should install files into a directory location that depends on the instance identifier. * To keep the nonfile data of each instance isolated, the base package should collect nonfile data into sets of components for each instance. The appropriate components should then be installed based on conditional statements that depend on the instance identifier. * Author an instance transform for each instance being installed in addition to the base instance. The base package may install its own instance. * The instance transform must change the product code and identifier for each instance. * It is recommended that the product transform also change the product name so that the instance is readily distinguished in Add/Remove Programs through Control Panel. * If the instance transform installs files, they should be installed in a directory that depends on the instance identifier. * All nonfile data, such as registry keys, should include the instance name in their path to prevent collisions. This can be accomplished by using the property whose value is the instance identifier in the path as shown by the following example of a Registry Table. -Original Message- From: kelly.le...@milliman.com [mailto:kelly.le...@milliman.com] Sent: Monday, December 07, 2009 2:52 PM To: General discussion for Windows Installer XML toolset. Cc: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Instance transforms with the msi Are you using the same component GUID for each of these keys? You can't do that... It's breaking the component rules and all kinds of bad things happen when you break the component rules. Each distinct component keypath (the 'main' entry in a component) MUST have a unique component GUID. Each distinct component GUID can only be installed in one place on a given machine (you can't try to install the same GUID to two different keypaths). Kelly Uma Harano uhar...@esri.com 12/07/2009 02:47 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 [WiX-users] Instance transforms with the msi Hi, I am using instance transforms (msts) to install multiple instances of my base product (msi) on the same machine. Everything works except for one issue: I use an instance identifier property [INSTANCEPROP] that gets set toInstance1, Instance 2,...etc for each instance. I use this property to write registry keys for each instance. For example - HKLM\Software\ESRI\[INSTANCEPROP] is written via the registry table (One record in the registry table to linked to one component). When multiple instances are installed, this key could be repeated multiple times, but they would all be in their own hive HKLM\Software\ESRI\ Instance1 HKLM\Software\ESRI\ Instance2 HKLM\Software\ESRI\ Instance3 Etc Scenario: The base setup and an instance 1 is installed, I uninstall the instance 1. I find that HKLM\Software\ESRI\Instance1 is still left behind on the machine after instance 1 is uninstalled. Is this because the component that includes this registry key is still in the installed state with the base setup? What would be the best way to ensure that the HKLM\Software\ESRI\Instance1 get removed
