[WiX-users] Patching Merge module
Hi All, I am building WIX MSI that has integrated Merge Module. Now I am creating patches for this MSI. I know that I can specify ComponentRef's in my patch.wxs file but is there any way to provide patch for the integrated Merge Module? Thank You all in advance. Regards, AK. DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] custom actions after reboot
Thanks,
I'll take a look at bootstrapping.
http://msdn.microsoft.com/en-us/library/aa367553.aspx gave me the
impression that after the forecereboot, the installer would be
relaunched and I could then perform the queue set up, hence trying to
perform the MSMQ stuff before installing any files.
-Original Message-
From: David Watson [mailto:dwat...@sdl.com]
Sent: 09 March 2011 17:20
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] custom actions after reboot
Put a launch condition in that cancels your installation if msmq is not
installed.
If you really need to install msmq for your user use a bootstrapper that
installs it before your msi is called.
-Original Message-
From: Matthew Slane [mailto:matthew.sl...@thetrainline.com]
Sent: 09 March 2011 16:58
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] custom actions after reboot
Hi,
I'm getting a bit frustrated with constantly rebooting to try and get
this working.
If MSMQ is installed the queue gets created. If MSMQ isn't installed,
it gets installed and throws the following message before forcing the
reboot:
The installer has encountered an unexpected error installing this
package. This may indicate a problem with the package. The Error code
is 28101.
I'm using an wsx file based on the tutorial at
www.tramontana.co.hu/wix/lesson1.php
I need to force the reboot and then install the msmqueues component if
MSMQ gets installed.
?xml version='1.0' encoding='windows-1252'?
Wix xmlns='http://schemas.microsoft.com/wix/2006/wi'
xmlns:pca=http://schemas.microsoft.com/wix/MsmqExtension;
xmlns:util=http://schemas.microsoft.com/wix/UtilExtension;
Product Name='Foobar 1.0' Id='{D657286E-E865-43e3-B6F3-F37A0AC032BB}'
UpgradeCode='{F4FD13DB-B92B-4e4d-A6F6-35DFCA877DC2}'
Language='1033' Codepage='1252' Version='1.0.0' Manufacturer='Acme
Ltd.'
Package Id='*' Keywords='Installer' Description=Acme's Foobar 1.0
Installer
Comments='Foobar is a registered trademark of Acme Ltd.'
Manufacturer='Acme Ltd.'
InstallerVersion='100' Languages='1033' Compressed='yes'
SummaryCodepage='1252' /
Media Id='1' Cabinet='App.cab' EmbedCab='yes' /
util:User Domain='.' Name='Administrator' Id='myuser'/
Directory Id='TARGETDIR' Name='SourceDir'
Directory Id='ProgramFilesFolder' Name='PFiles'
Directory Id='INSTALLDIR' Name='Acme'
Component Id='doc1'
Guid='{18E8D982-4958-492b-AAAC-CD9AABF4E0B9}'
File Id='d1' Name='1stdoc.txt' DiskId='1'
Source='1stdoc.txt' KeyPath='yes'/
/Component
Component Id='msmqueues'
Guid='{95B2735A-6014-4e16-AD23-70F1BF6A844E}' KeyPath='yes'
pca:MessageQueue Id='testqueue' Label='testqueue'
Transactional='yes'
PathName='.\Private$\testqueue'
pca:MessageQueuePermission Id='distqueupermission'
ReceiveMessage='yes' User='myuser'/
/pca:MessageQueue
/Component
/Directory
/Directory
/Directory
Property Id=msmqcontainer Value='dism.exe /online
/Enable-Feature /FeatureName:MSMQ-Container /norestart'/
Property Id=msmqserver Value='dism.exe /online /Enable-Feature
/FeatureName:MSMQ-Server /norestart'/
Property Id=msmqmulticast Value='dism.exe /online
/Enable-Feature /FeatureName:MSMQ-Multicast /norestart'/
CustomAction Id=msmqcontainer
BinaryKey=WixCA
DllEntry=CAQuietExec
Execute=deferred
Return='check'
/
CustomAction Id=msmqserver
BinaryKey=WixCA
DllEntry=CAQuietExec
Execute='deferred'
Return='check'/
CustomAction Id=msmqmulticast
BinaryKey=WixCA
DllEntry=CAQuietExec
Execute='deferred'
Return='check'/
Feature Id='Complete' Level='1'
Feature Id='one' Level='1'
ComponentRef Id='doc1'/
/Feature
Feature Id='MSMQqueues' Level='1'
ComponentRef Id='msmqueues'/ComponentRef
Condition Level='0'NOT MSMQAVAILABLE/Condition
/Feature
/Feature
Property Id='MSMQAVAILABLE'
RegistrySearch Id=MSMQIsInstalled
Root=HKLM
Key=System\CurrentControlSet\Services\MSMQ
Name=ImagePath
Type=raw /
/Property
InstallExecuteSequence
Custom Action=msmqcontainer After=InstallFiles NOT
MSMQAVAILABLE/Custom
Custom Action=msmqserver After=msmqcontainer NOT
MSMQAVAILABLE/Custom
Custom Action=msmqmulticast After=msmqserver NOT
MSMQAVAILABLE/Custom
ForceReboot After='msmqmulticast'
NOT MSMQAVAILABLE
/ForceReboot
/InstallExecuteSequence
/Product
/Wix
-Original Message-
From: Matthew Slane [mailto:matthew.sl...@thetrainline.com]
Sent: 04 March 2011 10:22
To:
Re: [WiX-users] INSTALLLOCATION wrong value during uninstall (has the default value, not the used one)
Thank you guys for all your help! MeCoco On 3/9/2011 4:19 PM, David Watson wrote: If you have a directory element with no @Name it just makes the @Id an alias of the containing element. So your code makes any files targeted to MyApp.Binaries go in the same location as INSTALLDIR. -Original Message- From: MeCoco [mailto:vcotirl...@hotmail.com] Sent: 09 March 2011 15:03 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] INSTALLLOCATION wrong value during uninstall (has the default value, not the used one) Hi Michael, Thanks again for the explanation. Could you also tell me please what are the following lines of code actually do?: DirectoryRef Id=INSTALLDIR Directory Id=MyApp.Binaries / /DirectoryRef Thanks! MeCoco On 3/9/2011 3:08 PM, Michael Urman wrote: That doesn't look like it creates a component whose Directory is INSTALLDIR. It may put the component's file in the same directory, but since custom actions could override this, it doesn't count. What you need is the Directory_ column of the Component table to say INSTALLDIR instead of MyApp.Binaries, for at least one installed component. On Wed, Mar 9, 2011 at 02:29, MeCocovcotirl...@hotmail.com wrote: Hi Michael, Thanks for your answer. Is the following code not enough to preserve the INSTALLDIR directory? Fragment DirectoryRef Id=INSTALLDIR Directory Id=MyApp.Binaries / /DirectoryRef /Fragment Fragment Component Id=MyApp.Binaries.app.config Directory=MyApp.Binaries Guid=MY-GUID File Id=MyApp.Binaries.app.config Source=MyApp.app.config / /Component /Fragment As the file MyApp.app.config ends up going into the INSTALLLOCATION directory? I am not even sure what the: Fragment DirectoryRef Id=INSTALLDIR Directory Id=MyApp.Binaries / /DirectoryRef /Fragment is doing as the: Directory Id=MyApp.Binaries / doesn't have any Name parameter, so it looks like redefining MyApp.Binaries to be the INSTALLDIR value. Am I assuming correct? Thanks, MeCoco On 3/8/2011 3:07 PM, Michael Urman wrote: Directories are only automatically preserved when there is a component that installs to it. So make sure at least one component installs to INSTALLDIR. On Tue, Mar 8, 2011 at 03:31, MeCocovcotirl...@hotmail.com wrote: Hi all, I tried to create a small sample to reproduce the problem I'm having, and after a lot of tries I managed to reproduce it. The problem is described extensivly in my previous email, but a summary would be: if the user, when installing, changes the default directory (eg: from C:\Program Files\... to Z:\Program Files\...), then on uninstall (only real uninstall, not updates) one can see in the verbose log file that the INSTALLDIR property is set wrong to the default value (eg: C:\Program Files\...) and not to the folder where the user really installed the product (eg: Z:\Program Files\...) HOW to reproduce the problem: 1) If in the code I have the following: Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=INSTALLDIR Name=$(var.InstallDirectoryName) Component Id=MyDoc.txt Guid=6817A42D-30E7-464C-99DC-8FDBED6D70C6 File Id=MyDoc.txt Source=MyDoc.txt KeyPath=yes Checksum=yes / /Component Directory Id=Modules Name=Modules Component Id=MyLogo.txt Guid=68C1561C-85F8-4E2F-81F4-41DDDBE35DDB File Id=MyLogo.txt Source=MyLogo.txt KeyPath=yes Checksum=yes / /Component /Directory /Directory /Directory /Directory !-- application features -- Feature Id=Application Title=$(var.ProductName) Application Level=1 Absent=disallow ComponentRef Id=MyLogo.txt / ComponentRef Id=MyDoc.txt / /Feature I get everything correct, meaning I have in the log file the following: MSI (s) (08:24) [10:13:46:801]: PROPERTY CHANGE: Adding INSTALLDIR property. Its value is 'Z:\Program Files\MyTestInstallDirectory'. MSI (s) (08:24) [10:13:46:801]: PROPERTY CHANGE: Adding Modules property. Its value is 'Z:\Program Files\MyTestInstallDirectory\Modules'. 2) BUT, if in the code the MyDoc.txt component is missing, the INSTALLDIR property is wrong. So, for the code: Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=INSTALLDIR Name=$(var.InstallDirectoryName) Directory Id=Modules Name=Modules Component Id=MyLogo.txt Guid=68C1561C-85F8-4E2F-81F4-41DDDBE35DDB File Id=MyLogo.txt Source=MyLogo.txt KeyPath=yes Checksum=yes / /Component /Directory /Directory /Directory /Directory !-- application features -- Feature Id=Application Title=$(var.ProductName) Application Level=1 Absent=disallow ComponentRef Id=MyLogo.txt / /Feature In the log file I can see: MSI (s) (08:B0) [10:16:49:444]: PROPERTY CHANGE: Adding INSTALLDIR property. Its value is 'C:\Program Files\MyTestInstallDirectory\'. MSI (s) (08:B0) [10:16:49:444]: PROPERTY CHANGE: Modifying Modules property. Its current value is 'Z:\Program Files\MyTestInstallDirectory\Modules'. Its new
Re: [WiX-users] Patching Merge module
You patch the MSI, not the merge module, so you need to use the Component Ids as they appear in the MSI. Open your release MSI in something like Orca or InstEd and you can look up the component Ids as they appear after merging. Include those in your patch.wxs. -Original Message- From: Arun Kumar [mailto:arun_jku...@persistent.co.in] Sent: 10 March 2011 09:20 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Patching Merge module Hi All, I am building WIX MSI that has integrated Merge Module. Now I am creating patches for this MSI. I know that I can specify ComponentRef's in my patch.wxs file but is there any way to provide patch for the integrated Merge Module? Thank You all in advance. Regards, AK. DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Ltd. does not accept any liability for virus infected mails. - - Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Custom Action questions
How does the custom action indicate that the credentials are incorrect? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com] Sent: Wednesday, March 09, 2011 11:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You shouldn't return failure if the credentials are incorrect, if you do so you will get this error. been there, done that... On Mar 10, 2011 6:34 AM, Kevin Burton kev...@buyseasons.com wrote: I read that. Which of the four rules is this violating? I made the warning go away by making the C# CA 'immediate' thus I don't have to have another custom action to remember the property. So I have CustomAction Id=CA_CheckCredentials Return=check Execute=immediate BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And the schedule InstallExecuteSequence Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence But in the verbose log I get: MSI (s) (B8:9C) [22:04:26:415]: Note: 1: 1723 2: CA_CheckCredentials 3: CheckCredentials 4: D:\WINDOWS\Installer\MSI410.tmp Action start 22:04:26: CA_CheckCredentials. MSI (s) (B8:9C) [22:04:26:415]: Product: Bsi WebServices -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp The error says that the DLL cannot be run. Why? I believe I have followed the instructions for writing a managed CA to the tee (though there seems to be some disagreement between the online tutorial http://www.tramontana.co.hu/wix/ and this book). -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, March 09, 2011 5:26 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions ICE63 - http://msdn.microsoft.com/en-us/library/aa369008.aspx Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Wednesday, March 09, 2011 2:15 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions I think I have solved this problem. The CA was scheduled in the InstallExecuteSequence and was marked as 'deferred' so I created the following 'Custom Data'. CustomAction Id=SetProperty Property=CA_CheckCredentials Value=[SERVICEUSER],[SERVICEPASSWORD] / CustomAction Id=CA_CheckCredentials Return=check Execute=deferred BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And scheduled it like (I am trying to follow the instructions on page 133 of 'WiX: A Developer's Guide to Windows Installer XML' by Nick Ramirez) InstallExecuteSequence Custom Action=SetProperty Before=CA_CheckCredentials / Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence Now I get the ICE warning: warning LGHT1076: ICE63: Some action falls between InstallInitialize and RemoveExistingProducts. Is this a bad warning? I don't completely understand why this scheduling is bad. I would like to know that the credentials are bad *before* the existing products are removed. If I look at the .msi generated with Orca I see that in the InstallExecuteSequence table InstallInitialize 1500 SetProperty 1501 CA_CheckCredentials 1502 RemoveExistingProducts 1503 This seems like a valid sequence to me but I am obviously missing something as the warning is there for a purpose. -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Wednesday, March 09, 2011 3:30 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions If I had to guess you calling this CA as a ControlEvent off a Dialog / Control in your UI sequence. Am I correct? If so, it's a known issue that Msi lacks the ability to process messages in this scenario. The workaround is to set a dummy property to see a PROPERTY CHANGED message in the log file where the value is the data you are trying to log. Chris --- Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves
Re: [WiX-users] C# Custom Action questions
This error occurs when the credentials are correct. I don't get the message that the CA is being called (the first line in the code) so I don't think the CA is even being called. Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com] Sent: Wednesday, March 09, 2011 11:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You shouldn't return failure if the credentials are incorrect, if you do so you will get this error. been there, done that... On Mar 10, 2011 6:34 AM, Kevin Burton kev...@buyseasons.com wrote: I read that. Which of the four rules is this violating? I made the warning go away by making the C# CA 'immediate' thus I don't have to have another custom action to remember the property. So I have CustomAction Id=CA_CheckCredentials Return=check Execute=immediate BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And the schedule InstallExecuteSequence Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence But in the verbose log I get: MSI (s) (B8:9C) [22:04:26:415]: Note: 1: 1723 2: CA_CheckCredentials 3: CheckCredentials 4: D:\WINDOWS\Installer\MSI410.tmp Action start 22:04:26: CA_CheckCredentials. MSI (s) (B8:9C) [22:04:26:415]: Product: Bsi WebServices -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp The error says that the DLL cannot be run. Why? I believe I have followed the instructions for writing a managed CA to the tee (though there seems to be some disagreement between the online tutorial http://www.tramontana.co.hu/wix/ and this book). -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, March 09, 2011 5:26 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions ICE63 - http://msdn.microsoft.com/en-us/library/aa369008.aspx Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Wednesday, March 09, 2011 2:15 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions I think I have solved this problem. The CA was scheduled in the InstallExecuteSequence and was marked as 'deferred' so I created the following 'Custom Data'. CustomAction Id=SetProperty Property=CA_CheckCredentials Value=[SERVICEUSER],[SERVICEPASSWORD] / CustomAction Id=CA_CheckCredentials Return=check Execute=deferred BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And scheduled it like (I am trying to follow the instructions on page 133 of 'WiX: A Developer's Guide to Windows Installer XML' by Nick Ramirez) InstallExecuteSequence Custom Action=SetProperty Before=CA_CheckCredentials / Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence Now I get the ICE warning: warning LGHT1076: ICE63: Some action falls between InstallInitialize and RemoveExistingProducts. Is this a bad warning? I don't completely understand why this scheduling is bad. I would like to know that the credentials are bad *before* the existing products are removed. If I look at the .msi generated with Orca I see that in the InstallExecuteSequence table InstallInitialize 1500 SetProperty 1501 CA_CheckCredentials 1502 RemoveExistingProducts 1503 This seems like a valid sequence to me but I am obviously missing something as the warning is there for a purpose. -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Wednesday, March 09, 2011 3:30 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions If I had to guess you calling this CA as a ControlEvent off a Dialog / Control in your UI sequence. Am I correct? If so, it's a known issue that Msi lacks the ability to process messages in this scenario. The workaround is to set a dummy property to see a PROPERTY CHANGED message in the log file where the value is the data you are trying to log. Chris --- Christopher Painter, Author of
Re: [WiX-users] INSTALLLOCATION wrong value during uninstall (has the default value, not the used one)
And yes, just to be clear, once I added a component under the INSTALLDIR (not one of it's alias) the INSTALLDIR was also correctly preserved for uninstall. Thx, MeCoco On 3/10/2011 10:39 AM, MeCoco wrote: Thank you guys for all your help! MeCoco On 3/9/2011 4:19 PM, David Watson wrote: If you have a directory element with no @Name it just makes the @Id an alias of the containing element. So your code makes any files targeted to MyApp.Binaries go in the same location as INSTALLDIR. -Original Message- From: MeCoco [mailto:vcotirl...@hotmail.com] Sent: 09 March 2011 15:03 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] INSTALLLOCATION wrong value during uninstall (has the default value, not the used one) Hi Michael, Thanks again for the explanation. Could you also tell me please what are the following lines of code actually do?: DirectoryRef Id=INSTALLDIR Directory Id=MyApp.Binaries / /DirectoryRef Thanks! MeCoco On 3/9/2011 3:08 PM, Michael Urman wrote: That doesn't look like it creates a component whose Directory is INSTALLDIR. It may put the component's file in the same directory, but since custom actions could override this, it doesn't count. What you need is the Directory_ column of the Component table to say INSTALLDIR instead of MyApp.Binaries, for at least one installed component. On Wed, Mar 9, 2011 at 02:29, MeCocovcotirl...@hotmail.comwrote: Hi Michael, Thanks for your answer. Is the following code not enough to preserve the INSTALLDIR directory? Fragment DirectoryRef Id=INSTALLDIR Directory Id=MyApp.Binaries / /DirectoryRef /Fragment Fragment Component Id=MyApp.Binaries.app.config Directory=MyApp.Binaries Guid=MY-GUID File Id=MyApp.Binaries.app.config Source=MyApp.app.config / /Component /Fragment As the file MyApp.app.config ends up going into the INSTALLLOCATION directory? I am not even sure what the: Fragment DirectoryRef Id=INSTALLDIR Directory Id=MyApp.Binaries / /DirectoryRef /Fragment is doing as the: Directory Id=MyApp.Binaries / doesn't have any Name parameter, so it looks like redefining MyApp.Binaries to be the INSTALLDIR value. Am I assuming correct? Thanks, MeCoco On 3/8/2011 3:07 PM, Michael Urman wrote: Directories are only automatically preserved when there is a component that installs to it. So make sure at least one component installs to INSTALLDIR. On Tue, Mar 8, 2011 at 03:31, MeCocovcotirl...@hotmail.com wrote: Hi all, I tried to create a small sample to reproduce the problem I'm having, and after a lot of tries I managed to reproduce it. The problem is described extensivly in my previous email, but a summary would be: if the user, when installing, changes the default directory (eg: from C:\Program Files\... to Z:\Program Files\...), then on uninstall (only real uninstall, not updates) one can see in the verbose log file that the INSTALLDIR property is set wrong to the default value (eg: C:\Program Files\...) and not to the folder where the user really installed the product (eg: Z:\Program Files\...) HOW to reproduce the problem: 1) If in the code I have the following: Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=INSTALLDIR Name=$(var.InstallDirectoryName) Component Id=MyDoc.txt Guid=6817A42D-30E7-464C-99DC-8FDBED6D70C6 File Id=MyDoc.txt Source=MyDoc.txt KeyPath=yes Checksum=yes / /Component Directory Id=Modules Name=Modules Component Id=MyLogo.txt Guid=68C1561C-85F8-4E2F-81F4-41DDDBE35DDB File Id=MyLogo.txt Source=MyLogo.txt KeyPath=yes Checksum=yes / /Component /Directory /Directory /Directory /Directory !-- application features -- Feature Id=Application Title=$(var.ProductName) Application Level=1 Absent=disallow ComponentRef Id=MyLogo.txt / ComponentRef Id=MyDoc.txt / /Feature I get everything correct, meaning I have in the log file the following: MSI (s) (08:24) [10:13:46:801]: PROPERTY CHANGE: Adding INSTALLDIR property. Its value is 'Z:\Program Files\MyTestInstallDirectory'. MSI (s) (08:24) [10:13:46:801]: PROPERTY CHANGE: Adding Modules property. Its value is 'Z:\Program Files\MyTestInstallDirectory\Modules'. 2) BUT, if in the code the MyDoc.txt component is missing, the INSTALLDIR property is wrong. So, for the code: Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=INSTALLDIR Name=$(var.InstallDirectoryName) Directory Id=Modules Name=Modules Component Id=MyLogo.txt Guid=68C1561C-85F8-4E2F-81F4-41DDDBE35DDB File Id=MyLogo.txt Source=MyLogo.txt KeyPath=yes Checksum=yes / /Component /Directory /Directory /Directory /Directory !-- application features -- Feature Id=Application Title=$(var.ProductName) Application Level=1 Absent=disallow ComponentRef Id=MyLogo.txt / /Feature In the log file I can see: MSI (s) (08:B0) [10:16:49:444]: PROPERTY CHANGE: Adding INSTALLDIR property. Its
[WiX-users] Adding registry entries for other users or non-existant users
Hi all, When our installation installs for ALLUSERS we put registry entries into HKEY_LOCAL_MACHINE, and when the application starts on each user account we copy the settings from there to HKEY_CURRENT_USER. This is handy because it will work for all existing users on the machine, as well as for user accounts that do not exist yet. However, we also install a keyboard layout which needs keys in HKEY_CURRENT_USER as the user logs in, before the user can access the layout, and before our application can be run. Is there some way we can create registry entries for all existing users on the system AND any new users? Thanks, John. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Heat - harvesting COM registry entries for components with dependencies
Does anyone have a fix or workaround for registering COM components that are dependent upon other type libraries being registered? Due to the way heat is harvesting (via registry redirection) the changes, the other components will not be available. About the only thing I can think of is to add an option to heat to add a list of dependent modules as a parameter to heat. Then in the code we would need to preload all those dependents, load our file to harvest, register the dependents and our harvest file, and then unregister our dependents. This should result in a close to pure image of what our module changed (assuming the dependent modules do clean up everything they add). Thoughts? Jacob -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Custom Action questions
You'll want to set a property that can be checked in a condition. 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: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 6:05 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions How does the custom action indicate that the credentials are incorrect? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com] Sent: Wednesday, March 09, 2011 11:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You shouldn't return failure if the credentials are incorrect, if you do so you will get this error. been there, done that... On Mar 10, 2011 6:34 AM, Kevin Burton kev...@buyseasons.com wrote: I read that. Which of the four rules is this violating? I made the warning go away by making the C# CA 'immediate' thus I don't have to have another custom action to remember the property. So I have CustomAction Id=CA_CheckCredentials Return=check Execute=immediate BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And the schedule InstallExecuteSequence Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence But in the verbose log I get: MSI (s) (B8:9C) [22:04:26:415]: Note: 1: 1723 2: CA_CheckCredentials 3: CheckCredentials 4: D:\WINDOWS\Installer\MSI410.tmp Action start 22:04:26: CA_CheckCredentials. MSI (s) (B8:9C) [22:04:26:415]: Product: Bsi WebServices -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp The error says that the DLL cannot be run. Why? I believe I have followed the instructions for writing a managed CA to the tee (though there seems to be some disagreement between the online tutorial http://www.tramontana.co.hu/wix/ and this book). -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, March 09, 2011 5:26 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions ICE63 - http://msdn.microsoft.com/en-us/library/aa369008.aspx Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Wednesday, March 09, 2011 2:15 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions I think I have solved this problem. The CA was scheduled in the InstallExecuteSequence and was marked as 'deferred' so I created the following 'Custom Data'. CustomAction Id=SetProperty Property=CA_CheckCredentials Value=[SERVICEUSER],[SERVICEPASSWORD] / CustomAction Id=CA_CheckCredentials Return=check Execute=deferred BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And scheduled it like (I am trying to follow the instructions on page 133 of 'WiX: A Developer's Guide to Windows Installer XML' by Nick Ramirez) InstallExecuteSequence Custom Action=SetProperty Before=CA_CheckCredentials / Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence Now I get the ICE warning: warning LGHT1076: ICE63: Some action falls between InstallInitialize and RemoveExistingProducts. Is this a bad warning? I don't completely understand why this scheduling is bad. I would like to know that the credentials are bad *before* the existing products are removed. If I look at the .msi generated with Orca I see that in the InstallExecuteSequence table InstallInitialize 1500 SetProperty 1501 CA_CheckCredentials 1502 RemoveExistingProducts 1503 This seems like a valid sequence to me but I am obviously missing something as the warning is there for a purpose. -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Wednesday, March 09, 2011 3:30 PM To: General
Re: [WiX-users] C# Custom Action questions
So CA's always return Success. What are the other return values used for? Thank you. For the tip. The problem that I am having now is that it doesn't appear that the CA is getting called. I look in the log and see the message indicated earlier in this thread indicating that the DLL could not be run. Any idea for this? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Thursday, March 10, 2011 12:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You'll want to set a property that can be checked in a condition. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 6:05 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions How does the custom action indicate that the credentials are incorrect? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com] Sent: Wednesday, March 09, 2011 11:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You shouldn't return failure if the credentials are incorrect, if you do so you will get this error. been there, done that... On Mar 10, 2011 6:34 AM, Kevin Burton kev...@buyseasons.com wrote: I read that. Which of the four rules is this violating? I made the warning go away by making the C# CA 'immediate' thus I don't have to have another custom action to remember the property. So I have CustomAction Id=CA_CheckCredentials Return=check Execute=immediate BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And the schedule InstallExecuteSequence Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence But in the verbose log I get: MSI (s) (B8:9C) [22:04:26:415]: Note: 1: 1723 2: CA_CheckCredentials 3: CheckCredentials 4: D:\WINDOWS\Installer\MSI410.tmp Action start 22:04:26: CA_CheckCredentials. MSI (s) (B8:9C) [22:04:26:415]: Product: Bsi WebServices -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp The error says that the DLL cannot be run. Why? I believe I have followed the instructions for writing a managed CA to the tee (though there seems to be some disagreement between the online tutorial http://www.tramontana.co.hu/wix/ and this book). -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, March 09, 2011 5:26 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions ICE63 - http://msdn.microsoft.com/en-us/library/aa369008.aspx Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Wednesday, March 09, 2011 2:15 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions I think I have solved this problem. The CA was scheduled in the InstallExecuteSequence and was marked as 'deferred' so I created the following 'Custom Data'. CustomAction Id=SetProperty Property=CA_CheckCredentials Value=[SERVICEUSER],[SERVICEPASSWORD] / CustomAction Id=CA_CheckCredentials Return=check Execute=deferred BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And scheduled it like (I am trying to follow the instructions on page 133 of 'WiX: A Developer's Guide to Windows Installer XML' by Nick Ramirez) InstallExecuteSequence Custom Action=SetProperty Before=CA_CheckCredentials / Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence Now I get the ICE warning: warning LGHT1076: ICE63: Some action falls between
Re: [WiX-users] C# Custom Action questions
In cases where you checking things like credentials you want the actions to return success so that the install does not fail. As it was said, you set a property if the call succeeded and check if the property is set. You use the other return values in those cases where you want the install to fail and not continue such as when updating configuration files or updating anything that the application requires to function. The basic rule of thumb is when in the UI sequence always have actions return success and set properties use in conditional statements. When the action is called in the Execute sequence and it is critical to the success of the product always have the action return success or failure so that the install can fail and rollback when needed. Mat Skildum -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions So CA's always return Success. What are the other return values used for? Thank you. For the tip. The problem that I am having now is that it doesn't appear that the CA is getting called. I look in the log and see the message indicated earlier in this thread indicating that the DLL could not be run. Any idea for this? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Thursday, March 10, 2011 12:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You'll want to set a property that can be checked in a condition. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 6:05 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions How does the custom action indicate that the credentials are incorrect? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com] Sent: Wednesday, March 09, 2011 11:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You shouldn't return failure if the credentials are incorrect, if you do so you will get this error. been there, done that... On Mar 10, 2011 6:34 AM, Kevin Burton kev...@buyseasons.com wrote: I read that. Which of the four rules is this violating? I made the warning go away by making the C# CA 'immediate' thus I don't have to have another custom action to remember the property. So I have CustomAction Id=CA_CheckCredentials Return=check Execute=immediate BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And the schedule InstallExecuteSequence Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence But in the verbose log I get: MSI (s) (B8:9C) [22:04:26:415]: Note: 1: 1723 2: CA_CheckCredentials 3: CheckCredentials 4: D:\WINDOWS\Installer\MSI410.tmp Action start 22:04:26: CA_CheckCredentials. MSI (s) (B8:9C) [22:04:26:415]: Product: Bsi WebServices -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp The error says that the DLL cannot be run. Why? I believe I have followed the instructions for writing a managed CA to the tee (though there seems to be some disagreement between the online tutorial http://www.tramontana.co.hu/wix/ and this book). -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, March 09, 2011 5:26 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions ICE63 - http://msdn.microsoft.com/en-us/library/aa369008.aspx Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton
Re: [WiX-users] Adding registry entries for other users or non-existant users
This should work if you have the entries created with default values in HKCU where the component keypath is the registry item. This is mentioned in the Registry Table MSDN docs where it talks about HKCU and the installer writes the necessary entries when there are multiple users on the same computer. The repair mechanism is what causes the registry entries to be written for every user because it's a keypath item that's missing. You'd also need to have a triggering mechanism like a non-advertised shortcut to cause the repair, and repairs percolate up from component to feature, so it might take some re-arranging of your components/features. Phil Wilson -Original Message- From: John Daintree [mailto:jo...@dyalog.com] Sent: Thursday, March 10, 2011 7:40 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Adding registry entries for other users or non-existant users Hi all, When our installation installs for ALLUSERS we put registry entries into HKEY_LOCAL_MACHINE, and when the application starts on each user account we copy the settings from there to HKEY_CURRENT_USER. This is handy because it will work for all existing users on the machine, as well as for user accounts that do not exist yet. However, we also install a keyboard layout which needs keys in HKEY_CURRENT_USER as the user logs in, before the user can access the layout, and before our application can be run. Is there some way we can create registry entries for all existing users on the system AND any new users? Thanks, John. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77nav_id=80prev_id=77. You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail recept...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Custom Action questions
But I want the install to fail. If it continues with the wrong credentials it will try to start services with the wrong credentials. Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Skildum, Mathew [mailto:mathew.skil...@aspect.com] Sent: Thursday, March 10, 2011 12:32 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions In cases where you checking things like credentials you want the actions to return success so that the install does not fail. As it was said, you set a property if the call succeeded and check if the property is set. You use the other return values in those cases where you want the install to fail and not continue such as when updating configuration files or updating anything that the application requires to function. The basic rule of thumb is when in the UI sequence always have actions return success and set properties use in conditional statements. When the action is called in the Execute sequence and it is critical to the success of the product always have the action return success or failure so that the install can fail and rollback when needed. Mat Skildum -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions So CA's always return Success. What are the other return values used for? Thank you. For the tip. The problem that I am having now is that it doesn't appear that the CA is getting called. I look in the log and see the message indicated earlier in this thread indicating that the DLL could not be run. Any idea for this? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Thursday, March 10, 2011 12:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You'll want to set a property that can be checked in a condition. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 6:05 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions How does the custom action indicate that the credentials are incorrect? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com] Sent: Wednesday, March 09, 2011 11:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You shouldn't return failure if the credentials are incorrect, if you do so you will get this error. been there, done that... On Mar 10, 2011 6:34 AM, Kevin Burton kev...@buyseasons.com wrote: I read that. Which of the four rules is this violating? I made the warning go away by making the C# CA 'immediate' thus I don't have to have another custom action to remember the property. So I have CustomAction Id=CA_CheckCredentials Return=check Execute=immediate BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And the schedule InstallExecuteSequence Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence But in the verbose log I get: MSI (s) (B8:9C) [22:04:26:415]: Note: 1: 1723 2: CA_CheckCredentials 3: CheckCredentials 4: D:\WINDOWS\Installer\MSI410.tmp Action start 22:04:26: CA_CheckCredentials. MSI (s) (B8:9C) [22:04:26:415]: Product: Bsi WebServices -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp The error says that the DLL cannot be run. Why? I believe I have followed the instructions for writing a managed CA to the tee (though there seems to be some disagreement between the online tutorial http://www.tramontana.co.hu/wix/ and this book). -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, March 09,
Re: [WiX-users] C# Custom Action questions
This is where you use the property that the action set. You do not allow the user off of the dialog until they enter credentials that work and the property is set to the value you expect. This way it is up to the installer to exit the install if they do not have the needed information, but you give them all the chances they need to get it right. Mat Skildum -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:38 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions But I want the install to fail. If it continues with the wrong credentials it will try to start services with the wrong credentials. Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Skildum, Mathew [mailto:mathew.skil...@aspect.com] Sent: Thursday, March 10, 2011 12:32 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions In cases where you checking things like credentials you want the actions to return success so that the install does not fail. As it was said, you set a property if the call succeeded and check if the property is set. You use the other return values in those cases where you want the install to fail and not continue such as when updating configuration files or updating anything that the application requires to function. The basic rule of thumb is when in the UI sequence always have actions return success and set properties use in conditional statements. When the action is called in the Execute sequence and it is critical to the success of the product always have the action return success or failure so that the install can fail and rollback when needed. Mat Skildum -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions So CA's always return Success. What are the other return values used for? Thank you. For the tip. The problem that I am having now is that it doesn't appear that the CA is getting called. I look in the log and see the message indicated earlier in this thread indicating that the DLL could not be run. Any idea for this? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Thursday, March 10, 2011 12:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You'll want to set a property that can be checked in a condition. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 6:05 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions How does the custom action indicate that the credentials are incorrect? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com] Sent: Wednesday, March 09, 2011 11:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You shouldn't return failure if the credentials are incorrect, if you do so you will get this error. been there, done that... On Mar 10, 2011 6:34 AM, Kevin Burton kev...@buyseasons.com wrote: I read that. Which of the four rules is this violating? I made the warning go away by making the C# CA 'immediate' thus I don't have to have another custom action to remember the property. So I have CustomAction Id=CA_CheckCredentials Return=check Execute=immediate BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And the schedule InstallExecuteSequence Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence But in the verbose log I get: MSI (s) (B8:9C) [22:04:26:415]: Note: 1: 1723 2: CA_CheckCredentials 3: CheckCredentials 4: D:\WINDOWS\Installer\MSI410.tmp Action start 22:04:26: CA_CheckCredentials. MSI (s) (B8:9C) [22:04:26:415]: Product: Bsi WebServices -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp Error 1723. There is a problem with this Windows Installer package. A
Re: [WiX-users] C# Custom Action questions
and Kevin, are you sure that attempting to validate will not be treated as a logon failure and put you back to square one? User account validation schemes are often nothing more than an attempt to log on with the supplied credentials. That might be what Context.ValidateCredentials does - I don't know enough about AD and AdsOpenObject() to know if that's what happens. Reflector seems to indicate that's the underlying Win32 call. Phil Wilson -Original Message- From: Skildum, Mathew [mailto:mathew.skil...@aspect.com] Sent: Thursday, March 10, 2011 10:49 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions This is where you use the property that the action set. You do not allow the user off of the dialog until they enter credentials that work and the property is set to the value you expect. This way it is up to the installer to exit the install if they do not have the needed information, but you give them all the chances they need to get it right. Mat Skildum -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:38 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions But I want the install to fail. If it continues with the wrong credentials it will try to start services with the wrong credentials. Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Skildum, Mathew [mailto:mathew.skil...@aspect.com] Sent: Thursday, March 10, 2011 12:32 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions In cases where you checking things like credentials you want the actions to return success so that the install does not fail. As it was said, you set a property if the call succeeded and check if the property is set. You use the other return values in those cases where you want the install to fail and not continue such as when updating configuration files or updating anything that the application requires to function. The basic rule of thumb is when in the UI sequence always have actions return success and set properties use in conditional statements. When the action is called in the Execute sequence and it is critical to the success of the product always have the action return success or failure so that the install can fail and rollback when needed. Mat Skildum -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions So CA's always return Success. What are the other return values used for? Thank you. For the tip. The problem that I am having now is that it doesn't appear that the CA is getting called. I look in the log and see the message indicated earlier in this thread indicating that the DLL could not be run. Any idea for this? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Thursday, March 10, 2011 12:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You'll want to set a property that can be checked in a condition. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 6:05 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions How does the custom action indicate that the credentials are incorrect? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com] Sent: Wednesday, March 09, 2011 11:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You shouldn't return failure if the credentials are incorrect, if you do so you will get this error. been there, done that... On Mar 10, 2011 6:34 AM, Kevin Burton kev...@buyseasons.com wrote: I read that. Which of the four rules is this violating? I made the warning go away by making the C# CA 'immediate' thus I don't have to have another custom action to remember the property. So I have CustomAction Id=CA_CheckCredentials Return=check Execute=immediate BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And the schedule InstallExecuteSequence Custom
Re: [WiX-users] C# Custom Action questions
I am not sure what you mean by square one? Are you saying that the checking of credentials that are invalid will throw an exception that is not caught? First I have to solve the problem that I don't think the CA is being called as evidenced by the snippet of log I posted earlier. Unless the log entry will be suppressed by an exception. But the entry on the log indicates that the DLL could not be run so I don't think I am even getting to that point. Also I get the same error (DLL could not be run) whether I supply the correct credentials or incorrect ones. Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Thursday, March 10, 2011 1:55 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions and Kevin, are you sure that attempting to validate will not be treated as a logon failure and put you back to square one? User account validation schemes are often nothing more than an attempt to log on with the supplied credentials. That might be what Context.ValidateCredentials does - I don't know enough about AD and AdsOpenObject() to know if that's what happens. Reflector seems to indicate that's the underlying Win32 call. Phil Wilson -Original Message- From: Skildum, Mathew [mailto:mathew.skil...@aspect.com] Sent: Thursday, March 10, 2011 10:49 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions This is where you use the property that the action set. You do not allow the user off of the dialog until they enter credentials that work and the property is set to the value you expect. This way it is up to the installer to exit the install if they do not have the needed information, but you give them all the chances they need to get it right. Mat Skildum -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:38 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions But I want the install to fail. If it continues with the wrong credentials it will try to start services with the wrong credentials. Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Skildum, Mathew [mailto:mathew.skil...@aspect.com] Sent: Thursday, March 10, 2011 12:32 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions In cases where you checking things like credentials you want the actions to return success so that the install does not fail. As it was said, you set a property if the call succeeded and check if the property is set. You use the other return values in those cases where you want the install to fail and not continue such as when updating configuration files or updating anything that the application requires to function. The basic rule of thumb is when in the UI sequence always have actions return success and set properties use in conditional statements. When the action is called in the Execute sequence and it is critical to the success of the product always have the action return success or failure so that the install can fail and rollback when needed. Mat Skildum -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions So CA's always return Success. What are the other return values used for? Thank you. For the tip. The problem that I am having now is that it doesn't appear that the CA is getting called. I look in the log and see the message indicated earlier in this thread indicating that the DLL could not be run. Any idea for this? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Thursday, March 10, 2011 12:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You'll want to set a property that can be checked in a condition. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 6:05 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions How does the custom action indicate that the credentials are incorrect? Kevin Burton Senior Software Engineer BUYSEASONS
[WiX-users] Uninstall Previous Inno Setup Installed App
Hi All,
I've just rewritten my installer using WiX 3.5. However, before I
distribute the new MSI I'm dotting all the i and crossing the t's this
time! The problem is that I need to make sure the previous .exe setup
is removed before installing the new msi version.
So, i've been looking at various ways to locate the unins000.exe file
(UninstallString) and execute it. If possible I'd like to search the
registry and use the info in there but I can't think of a way to use the
RegistrySearch element and be sure it's found, if there.
When I look at my dev machine registry the key would look like this:
SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{413B7644-1F93-4890-BD40-AC540C29935B}_is1
How would this work on a 32bit XP machine for instance? What key value
can I possibly use to catch all flavours of OS? I've seen the Win64
property but I can only find my keys in one place on my dev machine so
if I said no to this it wouldn't find it on my dev box ... confused!
All the script I have for this at the moment is:
Property Id='UNINSTALL_EXE'
RegistrySearch Id='LocateUninstallExe' Type='file' Root='HKLM'
Key='SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{413B7644-1F93-4890-BD40-AC540C29935B}_is1'
Name='UninstallString' Win64='??' /
/Property
Property Id='UNINSTALL_CMD' Value='/SILENT'/
InstallExecuteSequence
Custom Action=ca.RemovePreviousVersion Before=InstallInitialize /
/InstallExecuteSequence
CustomAction Id=ca.RemovePreviousVersion Property=UNINSTALL_EXE
ExeCommand=UNINSTALL_CMD /
Any pointers on this would be much appreciated.
Thanks,
Jammer
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Votive and Visual Studio Question
A short follow up. I had assumed this wouldn't work due to past knowledge of the Visual Studio Express AddOn debate. However a PM from Microsoft emailed me and it prompted me to just try it out on a VM. I grabed the TFC install ( which uses the VS 2008 Shell in Integrated Mode ) and sure enough WiX installed into it without any issues. Well, one issue, but that's to be expected. The WiX Custom Action project types ( C++, C#, VB.Net ) aren't available because those languages aren't available. My own tool IsWiX ( CodePlex ) also registered with VS without any issues. Really cool stuff. These three tools together make a pretty interesting IDE for authoring installers. What can I say, I love MSBuild and Votive. Chris - Original Message From: Christopher Painter chr...@deploymentengineering.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, March 9, 2011 10:42:30 AM Subject: Votive and Visual Studio Question I've been doing a lot of work with collaboration and TFS lately and I've been wondering something. Team Foundation Server Client ( aka TFC aka Team Explorer ) has an installer that gives you a stock Visual Studio IDE / Shell and installs the Team Explorer AddIn. This allows non-developer personas to access the Team System ( work items / source control / builds / reports and so on ) Is it possible to piggy back off of this and use WiX / Votive? I ask because in my collaboration / setup democratization excercises I sometimes come across contributors who are not developers. These tend to be content producers, tech writers, and so on. I want to try to leverage the Votive story with these people also. --- Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Custom Action questions
This is nothing to do with exceptions. I'm telling you that the act of verifying credentials is a flavor of logon, and that a failure to verify may be treated in exactly the same way as when your service tries to log on with invalid credentials. In other words you can write a bunch of code that tries to verify an account and the result is that the account gets locked out, or you can just go back to what you were doing before and have the service logon failure cause account lockout. I'm saying that this is what you may end up with, so all your code gives you very little advantage, if any at all. You should run your custom action in a program and use an invalid password. Try it a dozen times and see if the account gets locked out. Phil Wilson -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:27 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions I am not sure what you mean by square one? Are you saying that the checking of credentials that are invalid will throw an exception that is not caught? First I have to solve the problem that I don't think the CA is being called as evidenced by the snippet of log I posted earlier. Unless the log entry will be suppressed by an exception. But the entry on the log indicates that the DLL could not be run so I don't think I am even getting to that point. Also I get the same error (DLL could not be run) whether I supply the correct credentials or incorrect ones. Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Thursday, March 10, 2011 1:55 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions and Kevin, are you sure that attempting to validate will not be treated as a logon failure and put you back to square one? User account validation schemes are often nothing more than an attempt to log on with the supplied credentials. That might be what Context.ValidateCredentials does - I don't know enough about AD and AdsOpenObject() to know if that's what happens. Reflector seems to indicate that's the underlying Win32 call. Phil Wilson -Original Message- From: Skildum, Mathew [mailto:mathew.skil...@aspect.com] Sent: Thursday, March 10, 2011 10:49 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions This is where you use the property that the action set. You do not allow the user off of the dialog until they enter credentials that work and the property is set to the value you expect. This way it is up to the installer to exit the install if they do not have the needed information, but you give them all the chances they need to get it right. Mat Skildum -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:38 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions But I want the install to fail. If it continues with the wrong credentials it will try to start services with the wrong credentials. Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Skildum, Mathew [mailto:mathew.skil...@aspect.com] Sent: Thursday, March 10, 2011 12:32 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions In cases where you checking things like credentials you want the actions to return success so that the install does not fail. As it was said, you set a property if the call succeeded and check if the property is set. You use the other return values in those cases where you want the install to fail and not continue such as when updating configuration files or updating anything that the application requires to function. The basic rule of thumb is when in the UI sequence always have actions return success and set properties use in conditional statements. When the action is called in the Execute sequence and it is critical to the success of the product always have the action return success or failure so that the install can fail and rollback when needed. Mat Skildum -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions So CA's always return Success. What are the other return values used for? Thank you. For the tip. The problem that I am having now is that it doesn't appear that the CA is getting called. I look in the log and see the message indicated earlier in this thread indicating that the DLL could not be run. Any
Re: [WiX-users] C# Custom Action questions
I can check the credentials with invalid credentials and then I am able to
check the credentials using valid credentials. No lock out. Here is the code:
private static bool CheckCredentials(string userName, string password)
{
bool valid = false;
using(PrincipalContext context = new
PrincipalContext(ContextType.Domain, ASGARD))
{
valid = context.ValidateCredentials(userName, password);
}
return valid;
}
static void Main(string[] args)
{
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, invalid)));
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, valid)));
}
And the output is:
Credentials are False
Credentials are True
Now my biggest problem is that the CA is not getting called.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Thursday, March 10, 2011 3:10 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
This is nothing to do with exceptions. I'm telling you that the act of
verifying credentials is a flavor of logon, and that a failure to verify may
be treated in exactly the same way as when your service tries to log on with
invalid credentials. In other words you can write a bunch of code that tries to
verify an account and the result is that the account gets locked out, or you
can just go back to what you were doing before and have the service logon
failure cause account lockout. I'm saying that this is what you may end up
with, so all your code gives you very little advantage, if any at all.
You should run your custom action in a program and use an invalid password. Try
it a dozen times and see if the account gets locked out.
Phil Wilson
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 12:27 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I am not sure what you mean by square one? Are you saying that the checking
of credentials that are invalid will throw an exception that is not caught?
First I have to solve the problem that I don't think the CA is being called as
evidenced by the snippet of log I posted earlier. Unless the log entry will be
suppressed by an exception. But the entry on the log indicates that the DLL
could not be run so I don't think I am even getting to that point. Also I get
the same error (DLL could not be run) whether I supply the correct credentials
or incorrect ones.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Thursday, March 10, 2011 1:55 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
and Kevin, are you sure that attempting to validate will not be
treated as a logon failure and put you back to square one? User account
validation schemes are often nothing more than an attempt to log on with the
supplied credentials. That might be what Context.ValidateCredentials does - I
don't know enough about AD and AdsOpenObject() to know if that's what happens.
Reflector seems to indicate that's the underlying Win32 call.
Phil Wilson
-Original Message-
From: Skildum, Mathew [mailto:mathew.skil...@aspect.com]
Sent: Thursday, March 10, 2011 10:49 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
This is where you use the property that the action set. You do not allow the
user off of the dialog until they enter credentials that work and the property
is set to the value you expect. This way it is up to the installer to exit the
install if they do not have the needed information, but you give them all the
chances they need to get it right.
Mat Skildum
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 12:38 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
But I want the install to fail. If it continues with the wrong credentials it
will try to start services with the wrong credentials.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Skildum, Mathew [mailto:mathew.skil...@aspect.com]
Sent: Thursday, March 10, 2011 12:32 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
In cases where you checking things like credentials you want the actions to
return success
Re: [WiX-users] C# Custom Action questions
Phil and I both mentioned the potential problem. Run your code for invalid
credentials more than once. Try it about 4-12 times (as suggested by Phil). The
flow for the custom action is the following:
User enters credentials in dialog.
Dialog asks custom action to validate.
Dialog checks validation result property letting the user know if the password
was valid or invalid.
Suppose that a user incorrect enters invalid credentials enough times... At my
work you only get 3 tries! On the third validation the account is locked out
and the fourth and future attempts all fail regardless of whether the
credentials were valid or not.
Running it once is not enough to verify that this is not the case.
Now, to address the CA running to begin with... Check that the CA is getting
compiled with the correct bitness as required by the target platform. In other
words, are you compiling a 64-bit CA and trying to call it on a 32-bit machine
or vice versa?
If you can post a minimal reproduction (wix source, CA source, etc) of the CA
running problem I can try to reproduce it on my end.
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: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 1:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I can check the credentials with invalid credentials and then I am able to
check the credentials using valid credentials. No lock out. Here is the code:
private static bool CheckCredentials(string userName, string password)
{
bool valid = false;
using(PrincipalContext context = new
PrincipalContext(ContextType.Domain, ASGARD))
{
valid = context.ValidateCredentials(userName, password);
}
return valid;
}
static void Main(string[] args)
{
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, invalid)));
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, valid)));
}
And the output is:
Credentials are False
Credentials are True
Now my biggest problem is that the CA is not getting called.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Thursday, March 10, 2011 3:10 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
This is nothing to do with exceptions. I'm telling you that the act of
verifying
credentials is a flavor of logon, and that a failure to verify may be
treated in
exactly the same way as when your service tries to log on with invalid
credentials. In other words you can write a bunch of code that tries to verify
an account and the result is that the account gets locked out, or you can just
go back to what you were doing before and have the service logon failure
cause account lockout. I'm saying that this is what you may end up with, so
all
your code gives you very little advantage, if any at all.
You should run your custom action in a program and use an invalid password.
Try it a dozen times and see if the account gets locked out.
Phil Wilson
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 12:27 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I am not sure what you mean by square one? Are you saying that the
checking of credentials that are invalid will throw an exception that is not
caught?
First I have to solve the problem that I don't think the CA is being called as
evidenced by the snippet of log I posted earlier. Unless the log entry will be
suppressed by an exception. But the entry on the log indicates that the DLL
could not be run so I don't think I am even getting to that point. Also I get
the
same error (DLL could not be run) whether I supply the correct credentials or
incorrect ones.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Thursday, March 10, 2011 1:55 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
and Kevin, are you sure that attempting to validate will not be
treated
as a logon failure and put you back to square one? User account validation
schemes are often nothing more than an attempt to log on with the supplied
credentials. That might be what
Re: [WiX-users] C# Custom Action questions
The same is true here running the validation with invalid credentials 3 or more
times locks the account out. So the user will not get that many tries I will
fail the installation after the first invalid entry. But this is to avoid the
situation where installing and starting the service just once causes the
account to be locked out if invalid credentials are entered.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
Sent: Thursday, March 10, 2011 4:11 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
Phil and I both mentioned the potential problem. Run your code for invalid
credentials more than once. Try it about 4-12 times (as suggested by Phil). The
flow for the custom action is the following:
User enters credentials in dialog.
Dialog asks custom action to validate.
Dialog checks validation result property letting the user know if the password
was valid or invalid.
Suppose that a user incorrect enters invalid credentials enough times... At my
work you only get 3 tries! On the third validation the account is locked out
and the fourth and future attempts all fail regardless of whether the
credentials were valid or not.
Running it once is not enough to verify that this is not the case.
Now, to address the CA running to begin with... Check that the CA is getting
compiled with the correct bitness as required by the target platform. In other
words, are you compiling a 64-bit CA and trying to call it on a 32-bit machine
or vice versa?
If you can post a minimal reproduction (wix source, CA source, etc) of the CA
running problem I can try to reproduce it on my end.
Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
P Please consider the environment before printing this e-mail
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 1:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I can check the credentials with invalid credentials and then I am
able to check the credentials using valid credentials. No lock out. Here is
the code:
private static bool CheckCredentials(string userName, string password)
{
bool valid = false;
using(PrincipalContext context = new
PrincipalContext(ContextType.Domain, ASGARD))
{
valid = context.ValidateCredentials(userName, password);
}
return valid;
}
static void Main(string[] args)
{
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, invalid)));
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, valid)));
}
And the output is:
Credentials are False
Credentials are True
Now my biggest problem is that the CA is not getting called.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Thursday, March 10, 2011 3:10 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
This is nothing to do with exceptions. I'm telling you that the act of
verifying credentials is a flavor of logon, and that a failure to
verify may be treated in exactly the same way as when your service
tries to log on with invalid credentials. In other words you can write
a bunch of code that tries to verify an account and the result is that
the account gets locked out, or you can just go back to what you were
doing before and have the service logon failure cause account lockout.
I'm saying that this is what you may end up with, so all your code gives you
very little advantage, if any at all.
You should run your custom action in a program and use an invalid password.
Try it a dozen times and see if the account gets locked out.
Phil Wilson
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 12:27 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I am not sure what you mean by square one? Are you saying that the
checking of credentials that are invalid will throw an exception that
is not caught?
First I have to solve the problem that I don't think the CA is being
called as evidenced by the snippet of log I posted earlier. Unless the
log entry will be suppressed by an exception. But the entry on the log
indicates that the DLL could not be run so I don't think I am even
getting to that point. Also I get the
Re: [WiX-users] C# Custom Action questions
The CA is compile on a 32 bit machine and installed on a 64 bit machine. Is
that a problem? Will not WoW take care of that? It does for the other
assemblies.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
Sent: Thursday, March 10, 2011 4:11 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
Phil and I both mentioned the potential problem. Run your code for invalid
credentials more than once. Try it about 4-12 times (as suggested by Phil). The
flow for the custom action is the following:
User enters credentials in dialog.
Dialog asks custom action to validate.
Dialog checks validation result property letting the user know if the password
was valid or invalid.
Suppose that a user incorrect enters invalid credentials enough times... At my
work you only get 3 tries! On the third validation the account is locked out
and the fourth and future attempts all fail regardless of whether the
credentials were valid or not.
Running it once is not enough to verify that this is not the case.
Now, to address the CA running to begin with... Check that the CA is getting
compiled with the correct bitness as required by the target platform. In other
words, are you compiling a 64-bit CA and trying to call it on a 32-bit machine
or vice versa?
If you can post a minimal reproduction (wix source, CA source, etc) of the CA
running problem I can try to reproduce it on my end.
Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
P Please consider the environment before printing this e-mail
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 1:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I can check the credentials with invalid credentials and then I am
able to check the credentials using valid credentials. No lock out. Here is
the code:
private static bool CheckCredentials(string userName, string password)
{
bool valid = false;
using(PrincipalContext context = new
PrincipalContext(ContextType.Domain, ASGARD))
{
valid = context.ValidateCredentials(userName, password);
}
return valid;
}
static void Main(string[] args)
{
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, invalid)));
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, valid)));
}
And the output is:
Credentials are False
Credentials are True
Now my biggest problem is that the CA is not getting called.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Thursday, March 10, 2011 3:10 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
This is nothing to do with exceptions. I'm telling you that the act of
verifying credentials is a flavor of logon, and that a failure to
verify may be treated in exactly the same way as when your service
tries to log on with invalid credentials. In other words you can write
a bunch of code that tries to verify an account and the result is that
the account gets locked out, or you can just go back to what you were
doing before and have the service logon failure cause account lockout.
I'm saying that this is what you may end up with, so all your code gives you
very little advantage, if any at all.
You should run your custom action in a program and use an invalid password.
Try it a dozen times and see if the account gets locked out.
Phil Wilson
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 12:27 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I am not sure what you mean by square one? Are you saying that the
checking of credentials that are invalid will throw an exception that
is not caught?
First I have to solve the problem that I don't think the CA is being
called as evidenced by the snippet of log I posted earlier. Unless the
log entry will be suppressed by an exception. But the entry on the log
indicates that the DLL could not be run so I don't think I am even
getting to that point. Also I get the same error (DLL could not be
run) whether I supply the correct credentials or incorrect ones.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
Re: [WiX-users] Uninstall Previous Inno Setup Installed App
Hi:
On a 32-bit version of windows, your key would look like:
SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{413B7644-1F93-4890-BD40-AC540C29935B}_is1
I don't tend to use SilentUninstallString in these situations as this stil
shows user interface--at least the cancel button if I remember correctly and it
may even give the user the option to uninstall! I'd rather use
QuietUninstallString as this shows nothing.
To get these two custom actions to work you need to search the registry based
on a condition--I'd use VERSIONNT64/VERSIONNT.
Then have two custom actions in your InstallExecute sequence, one that executes
if your running 32-bit windows and the other if your running 64-bit.
Looking at the old code I ran the uninstall just before InstallFiles.
If you need any further help let me know but hopefully this should be enough to
get you going!
Cheers
Sean.
-Original Message-
From: Jammer [mailto:jam...@jammer.biz]
Sent: 10 March 2011 20:43
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Uninstall Previous Inno Setup Installed App
Hi All,
I've just rewritten my installer using WiX 3.5. However, before I
distribute the new MSI I'm dotting all the i and crossing the t's this
time! The problem is that I need to make sure the previous .exe setup
is removed before installing the new msi version.
So, i've been looking at various ways to locate the unins000.exe file
(UninstallString) and execute it. If possible I'd like to search the
registry and use the info in there but I can't think of a way to use the
RegistrySearch element and be sure it's found, if there.
When I look at my dev machine registry the key would look like this:
SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{413B7644-1F93-4890-BD40-AC540C29935B}_is1
How would this work on a 32bit XP machine for instance? What key value
can I possibly use to catch all flavours of OS? I've seen the Win64
property but I can only find my keys in one place on my dev machine so
if I said no to this it wouldn't find it on my dev box ... confused!
All the script I have for this at the moment is:
Property Id='UNINSTALL_EXE'
RegistrySearch Id='LocateUninstallExe' Type='file' Root='HKLM'
Key='SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{413B7644-1F93-4890-BD40-AC540C29935B}_is1'
Name='UninstallString' Win64='??' /
/Property
Property Id='UNINSTALL_CMD' Value='/SILENT'/
InstallExecuteSequence
Custom Action=ca.RemovePreviousVersion Before=InstallInitialize /
/InstallExecuteSequence
CustomAction Id=ca.RemovePreviousVersion Property=UNINSTALL_EXE
ExeCommand=UNINSTALL_CMD /
Any pointers on this would be much appreciated.
Thanks,
Jammer
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Custom Action questions
When I was at Continental Airlines we had an application that I had to
distribute where the service used a service account. For reasons never
determined ( aka damn service account ) something out there would periodically
lock the account and group policy would have it unlocked 10 minutes later.
One of the worst dependencies I ever had to take. It wasn't fun.
---
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves
attention? E-Mail Me
- Original Message
From: Castro, Edwin G. (Hillsboro) edwin.cas...@fiserv.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Thu, March 10, 2011 4:11:13 PM
Subject: Re: [WiX-users] C# Custom Action questions
Phil and I both mentioned the potential problem. Run your code for invalid
credentials more than once. Try it about 4-12 times (as suggested by Phil). The
flow for the custom action is the following:
User enters credentials in dialog.
Dialog asks custom action to validate.
Dialog checks validation result property letting the user know if the password
was valid or invalid.
Suppose that a user incorrect enters invalid credentials enough times... At my
work you only get 3 tries! On the third validation the account is locked out
and
the fourth and future attempts all fail regardless of whether the credentials
were valid or not.
Running it once is not enough to verify that this is not the case.
Now, to address the CA running to begin with... Check that the CA is getting
compiled with the correct bitness as required by the target platform. In other
words, are you compiling a 64-bit CA and trying to call it on a 32-bit machine
or vice versa?
If you can post a minimal reproduction (wix source, CA source, etc) of the CA
running problem I can try to reproduce it on my end.
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: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 1:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I can check the credentials with invalid credentials and then I am able to
check the credentials using valid credentials. No lock out. Here is the code:
private static bool CheckCredentials(string userName, string password)
{
bool valid = false;
using(PrincipalContext context = new
PrincipalContext(ContextType.Domain, ASGARD))
{
valid = context.ValidateCredentials(userName, password);
}
return valid;
}
static void Main(string[] args)
{
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, invalid)));
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, valid)));
}
And the output is:
Credentials are False
Credentials are True
Now my biggest problem is that the CA is not getting called.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Thursday, March 10, 2011 3:10 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
This is nothing to do with exceptions. I'm telling you that the act of
verifying
credentials is a flavor of logon, and that a failure to verify may be
treated
in
exactly the same way as when your service tries to log on with invalid
credentials. In other words you can write a bunch of code that tries to verify
an account and the result is that the account gets locked out, or you can just
go back to what you were doing before and have the service logon failure
cause account lockout. I'm saying that this is what you may end up with, so
all
your code gives you very little advantage, if any at all.
You should run your custom action in a program and use an invalid password.
Try it a dozen times and see if the account gets locked out.
Phil Wilson
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 12:27 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I am not sure what you mean by square one? Are you saying that the
checking of credentials that are invalid will throw an exception that is not
caught?
First I have to solve the problem that I don't think the CA is being called as
evidenced by the snippet of log I posted earlier. Unless the log entry will be
suppressed by an exception. But the entry on the log indicates that the DLL
could not be run so I don't
Re: [WiX-users] C# Custom Action questions
Hi Kevin
I think your error that it can't find the CA is in the call
private static bool CheckCredentials
Should be something like:
[CustomAction]
public static ActionResult CheckCredentials(Session session)
The class it is a member of also needs to be public.
Note you need to get the credentials out of properties.
Michael
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Friday, 11 March 2011 8:41 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I hear you. Where I work there is already considerable skepticism on the
installation package and anything that goes wrong is blamed on the installation
so when the installation locks the account (because of bad credentials) there
is a call to not use any deployment and go to copy deployment because of
similar mysteries. If I can avoid the account lockout with a CA that would
sweep the problem under the rug at least for now.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: Thursday, March 10, 2011 4:24 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
When I was at Continental Airlines we had an application that I had to
distribute where the service used a service account. For reasons never
determined ( aka damn service account ) something out there would periodically
lock the account and group policy would have it unlocked 10 minutes later.
One of the worst dependencies I ever had to take. It wasn't fun.
---
Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know
a secret or read a really good thread that deserves attention? E-Mail Me
- Original Message
From: Castro, Edwin G. (Hillsboro) edwin.cas...@fiserv.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Thu, March 10, 2011 4:11:13 PM
Subject: Re: [WiX-users] C# Custom Action questions
Phil and I both mentioned the potential problem. Run your code for invalid
credentials more than once. Try it about 4-12 times (as suggested by Phil). The
flow for the custom action is the following:
User enters credentials in dialog.
Dialog asks custom action to validate.
Dialog checks validation result property letting the user know if the password
was valid or invalid.
Suppose that a user incorrect enters invalid credentials enough times... At my
work you only get 3 tries! On the third validation the account is locked out and
the fourth and future attempts all fail regardless of whether the credentials
were valid or not.
Running it once is not enough to verify that this is not the case.
Now, to address the CA running to begin with... Check that the CA is getting
compiled with the correct bitness as required by the target platform. In other
words, are you compiling a 64-bit CA and trying to call it on a 32-bit machine
or vice versa?
If you can post a minimal reproduction (wix source, CA source, etc) of the CA
running problem I can try to reproduce it on my end.
Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
P Please consider the environment before printing this e-mail
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 1:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I can check the credentials with invalid credentials and then I am able to
check the credentials using valid credentials. No lock out. Here is the code:
private static bool CheckCredentials(string userName, string password)
{
bool valid = false;
using(PrincipalContext context = new
PrincipalContext(ContextType.Domain, ASGARD))
{
valid = context.ValidateCredentials(userName, password);
}
return valid;
}
static void Main(string[] args)
{
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, invalid)));
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, valid)));
}
And the output is:
Credentials are False
Credentials are True
Now my biggest problem is that the CA is not getting called.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Thursday, March 10, 2011 3:10 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
This is nothing to do with exceptions. I'm telling you that the
Re: [WiX-users] C# Custom Action questions
Thank you Michael,
I tried
public class CustomActions
{
private static int checkCount = 1;
[CustomAction]
public static ActionResult CheckCredentials(Session session)
{
With the same error in the log file. It seems more related to the assembly than
the scope of the method. The error indicates that the DLL could not be run. I
don't think the process has even gotten to the point of looking for the member.
Something is wrong with the DLL that is produced by the custom action project
that is integrated with Visual Studio.
I think the issue that the .msi is compiled and built (and the CA project) in a
32 bit environment and the .msi is installing to a 64-bit environment may be
more of the problem. Although I am not sure how to tackle it if this is indeed
the problem. So the binary element that makes the DLL part of the .msi maybe
needs to know about the bited-ness: of the source and target. All of this is
just supposition as I am a relative beginner with WiX.
-Original Message-
From: Michael Osmond [mailto:mosm...@baytech.com.au]
Sent: Thursday, March 10, 2011 5:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
Hi Kevin
I think your error that it can't find the CA is in the call
private static bool CheckCredentials
Should be something like:
[CustomAction]
public static ActionResult CheckCredentials(Session session)
The class it is a member of also needs to be public.
Note you need to get the credentials out of properties.
Michael
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Friday, 11 March 2011 8:41 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I hear you. Where I work there is already considerable skepticism on the
installation package and anything that goes wrong is blamed on the installation
so when the installation locks the account (because of bad credentials) there
is a call to not use any deployment and go to copy deployment because of
similar mysteries. If I can avoid the account lockout with a CA that would
sweep the problem under the rug at least for now.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: Thursday, March 10, 2011 4:24 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
When I was at Continental Airlines we had an application that I had to
distribute where the service used a service account. For reasons never
determined ( aka damn service account ) something out there would periodically
lock the account and group policy would have it unlocked 10 minutes later.
One of the worst dependencies I ever had to take. It wasn't fun.
---
Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know
a secret or read a really good thread that deserves attention? E-Mail Me
- Original Message
From: Castro, Edwin G. (Hillsboro) edwin.cas...@fiserv.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Thu, March 10, 2011 4:11:13 PM
Subject: Re: [WiX-users] C# Custom Action questions
Phil and I both mentioned the potential problem. Run your code for invalid
credentials more than once. Try it about 4-12 times (as suggested by Phil). The
flow for the custom action is the following:
User enters credentials in dialog.
Dialog asks custom action to validate.
Dialog checks validation result property letting the user know if the password
was valid or invalid.
Suppose that a user incorrect enters invalid credentials enough times... At my
work you only get 3 tries! On the third validation the account is locked out
and the fourth and future attempts all fail regardless of whether the
credentials were valid or not.
Running it once is not enough to verify that this is not the case.
Now, to address the CA running to begin with... Check that the CA is getting
compiled with the correct bitness as required by the target platform. In other
words, are you compiling a 64-bit CA and trying to call it on a 32-bit machine
or vice versa?
If you can post a minimal reproduction (wix source, CA source, etc) of the CA
running problem I can try to reproduce it on my end.
Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
P Please consider the environment before printing this e-mail
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 1:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I can check the credentials with invalid
Re: [WiX-users] C# Custom Action questions
I think I hit something like that. Try building the CA with AnyCPU as the
platform rather than 32/64
I have got that error when I forgot the public on the class, though
Regards
Michael
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Friday, 11 March 2011 12:05 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
Thank you Michael,
I tried
public class CustomActions
{
private static int checkCount = 1;
[CustomAction]
public static ActionResult CheckCredentials(Session session)
{
With the same error in the log file. It seems more related to the assembly than
the scope of the method. The error indicates that the DLL could not be run. I
don't think the process has even gotten to the point of looking for the member.
Something is wrong with the DLL that is produced by the custom action project
that is integrated with Visual Studio.
I think the issue that the .msi is compiled and built (and the CA project) in a
32 bit environment and the .msi is installing to a 64-bit environment may be
more of the problem. Although I am not sure how to tackle it if this is indeed
the problem. So the binary element that makes the DLL part of the .msi maybe
needs to know about the bited-ness: of the source and target. All of this is
just supposition as I am a relative beginner with WiX.
-Original Message-
From: Michael Osmond [mailto:mosm...@baytech.com.au]
Sent: Thursday, March 10, 2011 5:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
Hi Kevin
I think your error that it can't find the CA is in the call
private static bool CheckCredentials
Should be something like:
[CustomAction]
public static ActionResult CheckCredentials(Session session)
The class it is a member of also needs to be public.
Note you need to get the credentials out of properties.
Michael
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Friday, 11 March 2011 8:41 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I hear you. Where I work there is already considerable skepticism on the
installation package and anything that goes wrong is blamed on the installation
so when the installation locks the account (because of bad credentials) there
is a call to not use any deployment and go to copy deployment because of
similar mysteries. If I can avoid the account lockout with a CA that would
sweep the problem under the rug at least for now.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: Thursday, March 10, 2011 4:24 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
When I was at Continental Airlines we had an application that I had to
distribute where the service used a service account. For reasons never
determined ( aka damn service account ) something out there would periodically
lock the account and group policy would have it unlocked 10 minutes later.
One of the worst dependencies I ever had to take. It wasn't fun.
---
Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know
a secret or read a really good thread that deserves attention? E-Mail Me
- Original Message
From: Castro, Edwin G. (Hillsboro) edwin.cas...@fiserv.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Thu, March 10, 2011 4:11:13 PM
Subject: Re: [WiX-users] C# Custom Action questions
Phil and I both mentioned the potential problem. Run your code for invalid
credentials more than once. Try it about 4-12 times (as suggested by Phil). The
flow for the custom action is the following:
User enters credentials in dialog.
Dialog asks custom action to validate.
Dialog checks validation result property letting the user know if the password
was valid or invalid.
Suppose that a user incorrect enters invalid credentials enough times... At my
work you only get 3 tries! On the third validation the account is locked out
and the fourth and future attempts all fail regardless of whether the
credentials were valid or not.
Running it once is not enough to verify that this is not the case.
Now, to address the CA running to begin with... Check that the CA is getting
compiled with the correct bitness as required by the target platform. In other
words, are you compiling a 64-bit CA and trying to call it on a 32-bit machine
or vice versa?
If you can post a minimal reproduction (wix source, CA source, etc) of the CA
running problem I can try to reproduce it on my end.
Edwin G. Castro
Software Developer - Staff
Electronic Banking
[WiX-users] Is it possible to have two root directories in WIX
I need to deploy files in both C and D drives. For example File A goes to drive C and File B goes to drive D. I know that Wix allows you to have only one root directory. Is there any way I can accomplish this? I know that one solution is to set C as the root directory in the Wix Xml and deploy files that go to C directory through the Wix Xml. The files that have to deployed to D directory then have to be deployed through a custom action. However I want to avoid using Custom Actions and want to deploy files to both (C and D drives) using the same Wix Xml. Pramod DSilva Software Engineer Philips Healthcare The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
