Re: [WiX-users] C# Custom Action questions
You might find this an interesting read:
http://blog.deploymentengineering.com/2008/05/deployment-tools-foundation-dtf-custom.html
---
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)"
To: General discussion for Windows Installer XML toolset.
Sent: Fri, March 11, 2011 10:53:29 AM
Subject: Re: [WiX-users] C# Custom Action questions
FYI: The "DLL" is a .NET assembly. The "CA.dll" is a native C++ assembly that
is
responsible for setting up the .NET environment needed to run the .NET "DLL".
As
you found out, you need the bitness of the "CA.dll" to match the target machine.
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: Friday, March 11, 2011 6:40 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] C# Custom Action questions
>
> I am sorry I had inadvertently set the tag to the DLL *not* the
CA.dll
> so with the compile target of the CA specifically set to x86 (*not* Any CPU)
> the CA is called correctly. Thank you.
>
>
> Kevin Burton
> Senior Software Engineer
> BUYSEASONS
> 262-901-2000 Office
> 262-901-2312 Fax
> kev...@buyseasons.com
>
>
> -Original Message-
> From: Michael Osmond [mailto:mosm...@baytech.com.au]
> Sent: Thursday, March 10, 2011 8:49 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: 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 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 th
Re: [WiX-users] msiexec returning before it is done?
Msiexec is not a console application. It is a windows application. When msiexec starts control is immediately passed back to PowerShell. This is the equivalent of using the "start" command in a command prompt. This means that msiexec is still executing when PowerShell executes the next command. To force PowerShell to wait until msiexec completes you should pipe its output to out-null. msiexec /i path\to\setup.msi ... | out-null # next command will only execute after msiexec truly completes 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: Friday, March 11, 2011 3:09 PM > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] msiexec returning before it is done? > > This isn't a WiX question directly but hopefully someone will have some > experience they would be willing to share. > > I am using PowerShell to run msiexec on a remote machine. Right after I zip > up the files that were installed. But PowerShell is too quick because by the > time I get to executing the zip command the files have not been copied. I > don't see any arguments to msiexec that say "wait until you are done". Is > there any indicator that tells me that msiexec is done? > > Kevin Burton > Senior Software Engineer > BUYSEASONS > 262-901-2000 Office > 262-901-2312 Fax > kev...@buyseasons.com > -- > 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
[WiX-users] Error 26201. Error -2147467259: failed to create SQL database
Hello, I am trying to create database and table in SQL Server 2008 using scripts. The script works fine when executed manually in Management studio. But fails with above error "Error 26201. Error -2147467259: failed to create SQL database" when executed from installer. My target machine is Windows XP Professional and database ins SQL Server 2008 R2 Express edition. This same code works on Vista and Windows 7 machines. Following is code from .wxs file Can anyone suggest what am i doing wrong here. Thanks! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Error-26201-Error-2147467259-failed-to-create-SQL-database-tp6163225p6163225.html Sent from the wix-users mailing list archive at Nabble.com. -- 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] Tracker.exe??
Thank you. Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Michael_A [mailto:mcl...@fullarmor.com] Sent: Friday, March 11, 2011 4:50 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Tracker.exe?? Try this Go to VS2010 -> Team Explorer -> Builds -> EDIT BUILD DEFINITION -> PROCESS -> ADVANCED -> MS BUILD ARGUMENTS and add "/p:TrackFileAccess=false" -> then SAVE. Kevin Burton wrote: > > I am getting a warning > > WixUI_Mondo.wxs > WpfComponents.wxs > Product.Generated.wxs > Link: > C:\Program Files\Windows Installer XML v3.5\bin\Light.exe > -cultures:null -ext >"C:\Program Files\Windows Installer XML > v3.5\bin\\WixNetFxExtension.dll" -ex > t "C:\Program Files\Windows Installer XML v3.5\bin\\WixUIExtension.dll" > -ext > "C:\Program Files\Windows Installer XML v3.5\bin\\WixUtilExtension.dll" > -out > > C:\Projects\BuySeasonsIT\Source\Brain\Trunk\BuyseasonsServices\BsiServices\bi > n\Release\BsiServices.msi -pdbout > C:\Projects\BuySeasonsIT\Source\Brain\Trunk > \BuyseasonsServices\BsiServices\bin\Release\BsiServices.wixpdb > obj\Release\Fo > lders.wixobj obj\Release\Product.wixobj > obj\Release\ProductSetup.wixobj obj\R > elease\Properties.wixobj obj\Release\ServiceComponents.wixobj > obj\Release\Wix > UI_Mondo.wixobj obj\Release\WpfComponents.wixobj > obj\Release\Product.Generate > d.wixobj > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > Microsoft (R) Windows Installer Xml Linker version 3.5.2519.0 > Copyright (C) Microsoft Corporation. All rights reserved. > > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > Settings\Temp\ > > I have never seen this before. Any one see errors related to > 'Tracker.exe'? > -- > > 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 > -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Tracker-exe-tp6162943p6163168.html Sent from the wix-users mailing list archive at Nabble.com. -- 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
[WiX-users] msiexec returning before it is done?
This isn't a WiX question directly but hopefully someone will have some experience they would be willing to share. I am using PowerShell to run msiexec on a remote machine. Right after I zip up the files that were installed. But PowerShell is too quick because by the time I get to executing the zip command the files have not been copied. I don't see any arguments to msiexec that say "wait until you are done". Is there any indicator that tells me that msiexec is done? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -- 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] Tracker.exe??
Just turn tracker off. /p:TrackFileAccess=false -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Friday, March 11, 2011 5:53 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Tracker.exe?? I tried linking and it gave me this error on Tracker.exe not finding a response file. I was hoping that someone on this list has seen this error and as a reasonable workaround. The first link had responses like: Sometimes A/V has been known to interfere with build tools. Have you tried exempting the C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp directory from real-time scanning? I don't even know what A/V is an I am certainly not doing any real-time scanning. The second link was a duplicate of the first. The third link was a different format for the first but a duplicate. The fourth link was still another duplicate of the first. The fifth link ended in the conclusion from Microsoft Thanks for reporting the issue. In order to fix the issue, we must first reproduce the issue in our labs. We are unable to reproduce the issue with the steps you provided. After that I stopped reading. I don't have forever to look through all these links. Just an I don't know or haven't seen it would be fine. 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: Friday, March 11, 2011 4:34 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Tracker.exe?? *SIGH* Did you read any of the links that showed up in the search? ... Really, I would expect more from a Senior Software Engineer. I'm not a senior anything... but I know how to search and read. If you can post additional information as to what you learned, what you tried, and how it worked or didn't work, then I'll consider helping again. This has gotten quite ridiculous. 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: Friday, March 11, 2011 2:26 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Tracker.exe?? > > So what have I done wrong that causes this error? > > 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: Friday, March 11, 2011 4:13 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Tracker.exe?? > > http://lmgtfy.com/?q=wix+tracker.exe > > 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: Friday, March 11, 2011 1:33 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: [WiX-users] Tracker.exe?? > > > > I am getting a warning > > > > WixUI_Mondo.wxs > > WpfComponents.wxs > > Product.Generated.wxs > > Link: > > C:\Program Files\Windows Installer XML v3.5\bin\Light.exe > > -cultures:null - ext > >"C:\Program Files\Windows Installer XML > v3.5\bin\\WixNetFxExtension.dll" > > -ex > > t "C:\Program Files\Windows Installer XML > > v3.5\bin\\WixUIExtension.dll" - ext > > "C:\Program Files\Windows Installer XML > > v3.5\bin\\WixUtilExtension.dll" - out > > > > > C:\Projects\BuySeasonsIT\Source\Brain\Trunk\BuyseasonsServices\BsiServ > > i > > ces\bi > > n\Release\BsiServices.msi -pdbout > > C:\Projects\BuySeasonsIT\Source\Brain\Trunk > > \BuyseasonsServices\BsiServices\bin\Release\BsiServices.wixpdb > > obj\Release\Fo > > lders.wixobj obj\Release\Product.wixobj > > obj\Release\ProductSetup.wixobj obj\R > > elease\Properties.wixobj obj\Release\ServiceComponents.wixobj > > obj\Release\Wix > > UI_Mondo.wixobj obj\Release\WpfComponents.wixobj > > obj\Release\Product.Generate > > d.wixobj > > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > > Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > > Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > > Microsoft (R) Windows Installer Xml Linker version 3.5.2519.0 > > Copyright (C) Microsoft Corporation. All rights reserved. > > > > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > > Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local >
Re: [WiX-users] Tracker.exe??
I tried linking and it gave me this error on Tracker.exe not finding a response file. I was hoping that someone on this list has seen this error and as a reasonable workaround. The first link had responses like: Sometimes A/V has been known to interfere with build tools. Have you tried exempting the C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp directory from real-time scanning? I don't even know what A/V is an I am certainly not doing any real-time scanning. The second link was a duplicate of the first. The third link was a different format for the first but a duplicate. The fourth link was still another duplicate of the first. The fifth link ended in the conclusion from Microsoft Thanks for reporting the issue. In order to fix the issue, we must first reproduce the issue in our labs. We are unable to reproduce the issue with the steps you provided. After that I stopped reading. I don't have forever to look through all these links. Just an I don't know or haven't seen it would be fine. 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: Friday, March 11, 2011 4:34 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Tracker.exe?? *SIGH* Did you read any of the links that showed up in the search? ... Really, I would expect more from a Senior Software Engineer. I'm not a senior anything... but I know how to search and read. If you can post additional information as to what you learned, what you tried, and how it worked or didn't work, then I'll consider helping again. This has gotten quite ridiculous. 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: Friday, March 11, 2011 2:26 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Tracker.exe?? > > So what have I done wrong that causes this error? > > 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: Friday, March 11, 2011 4:13 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Tracker.exe?? > > http://lmgtfy.com/?q=wix+tracker.exe > > 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: Friday, March 11, 2011 1:33 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: [WiX-users] Tracker.exe?? > > > > I am getting a warning > > > > WixUI_Mondo.wxs > > WpfComponents.wxs > > Product.Generated.wxs > > Link: > > C:\Program Files\Windows Installer XML v3.5\bin\Light.exe > > -cultures:null - ext > >"C:\Program Files\Windows Installer XML > v3.5\bin\\WixNetFxExtension.dll" > > -ex > > t "C:\Program Files\Windows Installer XML > > v3.5\bin\\WixUIExtension.dll" - ext > > "C:\Program Files\Windows Installer XML > > v3.5\bin\\WixUtilExtension.dll" - out > > > > > C:\Projects\BuySeasonsIT\Source\Brain\Trunk\BuyseasonsServices\BsiServ > > i > > ces\bi > > n\Release\BsiServices.msi -pdbout > > C:\Projects\BuySeasonsIT\Source\Brain\Trunk > > \BuyseasonsServices\BsiServices\bin\Release\BsiServices.wixpdb > > obj\Release\Fo > > lders.wixobj obj\Release\Product.wixobj > > obj\Release\ProductSetup.wixobj obj\R > > elease\Properties.wixobj obj\Release\ServiceComponents.wixobj > > obj\Release\Wix > > UI_Mondo.wixobj obj\Release\WpfComponents.wixobj > > obj\Release\Product.Generate > > d.wixobj > > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > > Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > > Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > > Microsoft (R) Windows Installer Xml Linker version 3.5.2519.0 > > Copyright (C) Microsoft Corporation. All rights reserved. > > > > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > > Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > > Settings\Temp\ > > > > I have never seen this before. Any one see errors related to 'Tracker.exe'? > > > > -- > > > > Colocation vs. Managed Hosting > > A question and answer guide to
Re: [WiX-users] Tracker.exe??
Try this Go to VS2010 -> Team Explorer -> Builds -> EDIT BUILD DEFINITION -> PROCESS -> ADVANCED -> MS BUILD ARGUMENTS and add "/p:TrackFileAccess=false" then SAVE. Kevin Burton wrote: > > I am getting a warning > > WixUI_Mondo.wxs > WpfComponents.wxs > Product.Generated.wxs > Link: > C:\Program Files\Windows Installer XML v3.5\bin\Light.exe -cultures:null > -ext >"C:\Program Files\Windows Installer XML > v3.5\bin\\WixNetFxExtension.dll" -ex > t "C:\Program Files\Windows Installer XML v3.5\bin\\WixUIExtension.dll" > -ext > "C:\Program Files\Windows Installer XML v3.5\bin\\WixUtilExtension.dll" > -out > > C:\Projects\BuySeasonsIT\Source\Brain\Trunk\BuyseasonsServices\BsiServices\bi > n\Release\BsiServices.msi -pdbout > C:\Projects\BuySeasonsIT\Source\Brain\Trunk > \BuyseasonsServices\BsiServices\bin\Release\BsiServices.wixpdb > obj\Release\Fo > lders.wixobj obj\Release\Product.wixobj obj\Release\ProductSetup.wixobj > obj\R > elease\Properties.wixobj obj\Release\ServiceComponents.wixobj > obj\Release\Wix > UI_Mondo.wixobj obj\Release\WpfComponents.wixobj > obj\Release\Product.Generate > d.wixobj > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > Settings\Temp\ > 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > Settings\Temp\ > 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > Microsoft (R) Windows Installer Xml Linker version 3.5.2519.0 > Copyright (C) Microsoft Corporation. All rights reserved. > > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > Settings\Temp\ > 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > Settings\Temp\ > > I have never seen this before. Any one see errors related to > 'Tracker.exe'? > -- > 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 > -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Tracker-exe-tp6162943p6163168.html Sent from the wix-users mailing list archive at Nabble.com. -- 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] Tracker.exe??
*SIGH* Did you read any of the links that showed up in the search? ... Really, I would expect more from a Senior Software Engineer. I'm not a senior anything... but I know how to search and read. If you can post additional information as to what you learned, what you tried, and how it worked or didn't work, then I'll consider helping again. This has gotten quite ridiculous. 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: Friday, March 11, 2011 2:26 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Tracker.exe?? > > So what have I done wrong that causes this error? > > 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: Friday, March 11, 2011 4:13 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Tracker.exe?? > > http://lmgtfy.com/?q=wix+tracker.exe > > 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: Friday, March 11, 2011 1:33 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: [WiX-users] Tracker.exe?? > > > > I am getting a warning > > > > WixUI_Mondo.wxs > > WpfComponents.wxs > > Product.Generated.wxs > > Link: > > C:\Program Files\Windows Installer XML v3.5\bin\Light.exe > > -cultures:null - ext > >"C:\Program Files\Windows Installer XML > v3.5\bin\\WixNetFxExtension.dll" > > -ex > > t "C:\Program Files\Windows Installer XML > > v3.5\bin\\WixUIExtension.dll" - ext > > "C:\Program Files\Windows Installer XML > > v3.5\bin\\WixUtilExtension.dll" - out > > > > > C:\Projects\BuySeasonsIT\Source\Brain\Trunk\BuyseasonsServices\BsiServ > > i > > ces\bi > > n\Release\BsiServices.msi -pdbout > > C:\Projects\BuySeasonsIT\Source\Brain\Trunk > > \BuyseasonsServices\BsiServices\bin\Release\BsiServices.wixpdb > > obj\Release\Fo > > lders.wixobj obj\Release\Product.wixobj > > obj\Release\ProductSetup.wixobj obj\R > > elease\Properties.wixobj obj\Release\ServiceComponents.wixobj > > obj\Release\Wix > > UI_Mondo.wixobj obj\Release\WpfComponents.wixobj > > obj\Release\Product.Generate > > d.wixobj > > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > > Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > > Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > > Microsoft (R) Windows Installer Xml Linker version 3.5.2519.0 > > Copyright (C) Microsoft Corporation. All rights reserved. > > > > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > > Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > > Settings\Temp\ > > > > I have never seen this before. Any one see errors related to 'Tracker.exe'? > > -- > > > > 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 > -- > 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
Re: [WiX-users] Tracker.exe??
So what have I done wrong that causes this error? 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: Friday, March 11, 2011 4:13 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Tracker.exe?? http://lmgtfy.com/?q=wix+tracker.exe 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: Friday, March 11, 2011 1:33 PM > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] Tracker.exe?? > > I am getting a warning > > WixUI_Mondo.wxs > WpfComponents.wxs > Product.Generated.wxs > Link: > C:\Program Files\Windows Installer XML v3.5\bin\Light.exe > -cultures:null - ext >"C:\Program Files\Windows Installer XML v3.5\bin\\WixNetFxExtension.dll" > -ex > t "C:\Program Files\Windows Installer XML > v3.5\bin\\WixUIExtension.dll" - ext > "C:\Program Files\Windows Installer XML > v3.5\bin\\WixUtilExtension.dll" - out > > C:\Projects\BuySeasonsIT\Source\Brain\Trunk\BuyseasonsServices\BsiServ > i > ces\bi > n\Release\BsiServices.msi -pdbout > C:\Projects\BuySeasonsIT\Source\Brain\Trunk > \BuyseasonsServices\BsiServices\bin\Release\BsiServices.wixpdb > obj\Release\Fo > lders.wixobj obj\Release\Product.wixobj > obj\Release\ProductSetup.wixobj obj\R > elease\Properties.wixobj obj\Release\ServiceComponents.wixobj > obj\Release\Wix > UI_Mondo.wixobj obj\Release\WpfComponents.wixobj > obj\Release\Product.Generate > d.wixobj > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > Microsoft (R) Windows Installer Xml Linker version 3.5.2519.0 > Copyright (C) Microsoft Corporation. All rights reserved. > > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > Settings\Temp\ > > I have never seen this before. Any one see errors related to 'Tracker.exe'? > -- > > 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 -- 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] Uninstall Previous Inno Setup Installed App
One thing is that it looks like you're not allowing for the automatic
redirection of various things such as the registry when you run 32-bit things
on a 64-bit system. If your installer is 32-bit and you run it on a 64-bit
system, then references to 'SOFTWARE\Microsoft' will get silently redirected to
'SOFTWARE\Wow6432Node\Microsoft' behind the scenes.
If the old installer was 32 bit and you new installer is 32-bit, you should
just be able to create an installer as if you were targeting a 32-bit system
and it will do the right thing on both 32 and 64 bit - that's the purpose of
the automatic redirection system.
> From: Jammer [mailto:jam...@jammer.biz]
> Sent: Friday, March 11, 2011 8:01 PM
>
> Hi Again,
>
> I've just created a log of my installer and it seems that
> I've got some
> of it work now but the last test just left me with a mangled install
> that won't uninstall :(
>
> According to the log both of these searches found their
> registry values,
> which is confusing since using regedit I can only find the first
> Wow6432Node key:
>
>
> Key='SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uni
> nstall\{413B7644-1F93-4890-BD40-AC540C29935B}_is1'
> Name='UninstallString'>
>
>
>
>
> Key='SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{413B
> 7644-1F93-4890-BD40-AC540C29935B}_is1'
> Name='UninstallString'>
>
>
>
>
> I'm running Win7 64 and my old app is installed into Program
> Files (x86)
> is this why it ran the 32bit CustomAction?
>
>
> Before="InstallFiles">VERSIONNT64
> NOT
> VERSIONNT64
>
>
> MSI (s) (C4:64) [19:37:29:528]: Skipping action:
> ca.RemovePreviousVersion64 (condition is false)
> MSI (s) (C4:64) [19:37:21:422]: Doing action:
> ca.RemovePreviousVersion32
>
> Pretty confused by this to be honest I tried VERSIONNT64 and
> VERSIONNT
> before this but both evaluated false
>
> Is the VERSIONNT64 actually referring to Program Files (x86)
> and not the
> OS version?
>
> Also, I think the InstallFiles is wrong as I've ended up with
> only some
> of the files from the MSI installer actually being installed. Or did
> the time the uninstall execute after some of the MSI files
> had been copied.
>
> Off to fix this utterly mangled install ...
>
> Thanks,
>
> James
>
> --
>
> 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] Tracker.exe??
http://lmgtfy.com/?q=wix+tracker.exe 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: Friday, March 11, 2011 1:33 PM > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] Tracker.exe?? > > I am getting a warning > > WixUI_Mondo.wxs > WpfComponents.wxs > Product.Generated.wxs > Link: > C:\Program Files\Windows Installer XML v3.5\bin\Light.exe -cultures:null - > ext >"C:\Program Files\Windows Installer XML v3.5\bin\\WixNetFxExtension.dll" > -ex > t "C:\Program Files\Windows Installer XML v3.5\bin\\WixUIExtension.dll" - > ext > "C:\Program Files\Windows Installer XML v3.5\bin\\WixUtilExtension.dll" - > out > > C:\Projects\BuySeasonsIT\Source\Brain\Trunk\BuyseasonsServices\BsiServi > ces\bi > n\Release\BsiServices.msi -pdbout > C:\Projects\BuySeasonsIT\Source\Brain\Trunk > \BuyseasonsServices\BsiServices\bin\Release\BsiServices.wixpdb > obj\Release\Fo > lders.wixobj obj\Release\Product.wixobj obj\Release\ProductSetup.wixobj > obj\R > elease\Properties.wixobj obj\Release\ServiceComponents.wixobj > obj\Release\Wix > UI_Mondo.wixobj obj\Release\WpfComponents.wixobj > obj\Release\Product.Generate > d.wixobj > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > Microsoft (R) Windows Installer Xml Linker version 3.5.2519.0 > Copyright (C) Microsoft Corporation. All rights reserved. > > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. > Tracker.exe: Response file C:\Documents and Settings\kevinb\Local > Settings\Temp\ > > I have never seen this before. Any one see errors related to 'Tracker.exe'? > -- > 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
[WiX-users] Tracker.exe??
I am getting a warning WixUI_Mondo.wxs WpfComponents.wxs Product.Generated.wxs Link: C:\Program Files\Windows Installer XML v3.5\bin\Light.exe -cultures:null -ext "C:\Program Files\Windows Installer XML v3.5\bin\\WixNetFxExtension.dll" -ex t "C:\Program Files\Windows Installer XML v3.5\bin\\WixUIExtension.dll" -ext "C:\Program Files\Windows Installer XML v3.5\bin\\WixUtilExtension.dll" -out C:\Projects\BuySeasonsIT\Source\Brain\Trunk\BuyseasonsServices\BsiServices\bi n\Release\BsiServices.msi -pdbout C:\Projects\BuySeasonsIT\Source\Brain\Trunk \BuyseasonsServices\BsiServices\bin\Release\BsiServices.wixpdb obj\Release\Fo lders.wixobj obj\Release\Product.wixobj obj\Release\ProductSetup.wixobj obj\R elease\Properties.wixobj obj\Release\ServiceComponents.wixobj obj\Release\Wix UI_Mondo.wixobj obj\Release\WpfComponents.wixobj obj\Release\Product.Generate d.wixobj Tracker.exe: Response file C:\Documents and Settings\kevinb\Local Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. Tracker.exe: Response file C:\Documents and Settings\kevinb\Local Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. Microsoft (R) Windows Installer Xml Linker version 3.5.2519.0 Copyright (C) Microsoft Corporation. All rights reserved. Tracker.exe: Response file C:\Documents and Settings\kevinb\Local Settings\Temp\ 03b94238f4844598baddb8c2c1a53fc5.rsp not found. Tracker.exe: Response file C:\Documents and Settings\kevinb\Local Settings\Temp\ I have never seen this before. Any one see errors related to 'Tracker.exe'? -- 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
So cross-compile fails (trying to compile x64 on a x86 machine) but running x86 on an x64 platform works and 'Any CPU' fails. At least that has been my experience. 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: Friday, March 11, 2011 2:10 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions I have not tried AnyCPU as that only makes sense if the C++ CA dll is written in C++/CLI. The native C++ CA dll is very likely not written in C++/CLI because we are trying to avoid loading up a .NET assembly to begin with. So... we need to specify an actual platform (x86 or x64). I have not built my project on a 32-bit machine so I don't know if there are any warnings generated but I would not expect to see any errors. My psychic guess is that any warnings generated are trying to tell you that the DLL was cross compiled and will not work on the build machine. Such a warning would make sense and be expected. 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: Friday, March 11, 2011 11:29 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] C# Custom Action questions > > It looks like the only difference is the fact that I am compiling on > an x86 platform. Have you tried 'Any CPU'? When I specify 'Any CPU' > the CA will not run with the afore mentioned errors in the log. > > 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: Friday, March 11, 2011 1:00 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] C# Custom Action questions > > I have a custom action library written in C# with Debug and Release > configurations and only x64 platform. I manually removed the x86 platform. > Here are snippets from the .csproj: > > > Debug > x64 > ... > > > ... > > > ... > > > This builds fine without problems (no warnings and no errors) but I am > building on a x64 machine. I have not built this project on a x86 > machine. The custom action dll also performs flawlessly when used in an > installer. > > The toolset works for me as I would expect it to work. If you are > targeting x64, then you should build x64 custom actions. The project > templates provided by the toolset work pretty good. There's really no > need to write your own build scripts (I have a feeling you might be > writing your own build scripts). > > 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: Friday, March 11, 2011 10:01 AM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] C# Custom Action questions > > > > Actually I had to specifically compile to x86 before it would work > > even though the target machine was x64. If I specifically compiled > > to > > x64 I received a warning on the build machine what I am compiling to > > something different than the current machine but when it came to > > running on the target machine that was actually x64 I ran into > > another error but it didn't work. The takeaway is that no matter > > what the target machine is you have to set x86 when building the > > .NET CA. Any CPU doesn't work and x64 doesn't seem to work either. > > > > 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: Friday, March 11, 2011 10:53 AM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] C# Custom Action questions > > > > FYI: The "DLL" is a .NET assembly. The "CA.dll" is a native C++ > > assembly that is responsible for setting up the .NET environment > > needed to run the .NET "DLL". As you found out, you need the bitness > > of the "CA.dll" to match the target machine. > > > > 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] > > > S
Re: [WiX-users] Uninstall Previous Inno Setup Installed App
Hi Again, I've just created a log of my installer and it seems that I've got some of it work now but the last test just left me with a mangled install that won't uninstall :( According to the log both of these searches found their registry values, which is confusing since using regedit I can only find the first Wow6432Node key: I'm running Win7 64 and my old app is installed into Program Files (x86) is this why it ran the 32bit CustomAction? VERSIONNT64 NOT VERSIONNT64 MSI (s) (C4:64) [19:37:29:528]: Skipping action: ca.RemovePreviousVersion64 (condition is false) MSI (s) (C4:64) [19:37:21:422]: Doing action: ca.RemovePreviousVersion32 Pretty confused by this to be honest I tried VERSIONNT64 and VERSIONNT before this but both evaluated false Is the VERSIONNT64 actually referring to Program Files (x86) and not the OS version? Also, I think the InstallFiles is wrong as I've ended up with only some of the files from the MSI installer actually being installed. Or did the time the uninstall execute after some of the MSI files had been copied. Off to fix this utterly mangled install ... Thanks, James -- 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
It looks like the only difference is the fact that I am compiling on an x86
platform. Have you tried 'Any CPU'? When I specify 'Any CPU' the CA will not
run with the afore mentioned errors in the log.
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: Friday, March 11, 2011 1:00 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I have a custom action library written in C# with Debug and Release
configurations and only x64 platform. I manually removed the x86 platform. Here
are snippets from the .csproj:
Debug
x64
...
...
...
This builds fine without problems (no warnings and no errors) but I am building
on a x64 machine. I have not built this project on a x86 machine. The custom
action dll also performs flawlessly when used in an installer.
The toolset works for me as I would expect it to work. If you are targeting
x64, then you should build x64 custom actions. The project templates provided
by the toolset work pretty good. There's really no need to write your own build
scripts (I have a feeling you might be writing your own build scripts).
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: Friday, March 11, 2011 10:01 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] C# Custom Action questions
>
> Actually I had to specifically compile to x86 before it would work
> even though the target machine was x64. If I specifically compiled to
> x64 I received a warning on the build machine what I am compiling to
> something different than the current machine but when it came to
> running on the target machine that was actually x64 I ran into another
> error but it didn't work. The takeaway is that no matter what the
> target machine is you have to set x86 when building the .NET CA. Any
> CPU doesn't work and x64 doesn't seem to work either.
>
> 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: Friday, March 11, 2011 10:53 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] C# Custom Action questions
>
> FYI: The "DLL" is a .NET assembly. The "CA.dll" is a native C++
> assembly that is responsible for setting up the .NET environment
> needed to run the .NET "DLL". As you found out, you need the bitness
> of the "CA.dll" to match the target machine.
>
> 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: Friday, March 11, 2011 6:40 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] C# Custom Action questions
> >
> > I am sorry I had inadvertently set the tag to the DLL *not*
> > the CA.dll so with the compile target of the CA specifically set to
> > x86 (*not* Any CPU) the CA is called correctly. Thank you.
> >
> >
> > Kevin Burton
> > Senior Software Engineer
> > BUYSEASONS
> > 262-901-2000 Office
> > 262-901-2312 Fax
> > kev...@buyseasons.com
> >
> >
> > -Original Message-
> > From: Michael Osmond [mailto:mosm...@baytech.com.au]
> > Sent: Thursday, March 10, 2011 8:49 PM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: 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 wron
Re: [WiX-users] Uninstall Previous Inno Setup Installed App
Hi All,
I thought I was on the right track with this, but after some testing
it's not working as expected.
I've defined this in my installer:
VERSIONNT64
VERSIONNT
As sean said below he uses QuiteUninstallString but in the registry that
is the "path to the uninstall.exe" with a command of "/SILENT" and
CustomActions need a Property (full path to exe) and an ExeCommand. Can
the exe command be specified with an empty string?
Or am I completely barking up the wrong tree with the whole thing at the
moment?
Thanks,
Jammer
On 10/03/2011 22:23, Sean Farrow wrote:
> 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.
--
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] Uninstall Previous Inno Setup Installed App
I think I've cracked it.
VERSIONNT64
VERSIONNT
On 10/03/2011 22:23, Sean Farrow wrote:
> 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
> 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:
>
>
> Key='SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{413B7644-1F93-4890-BD40-AC540C29935B}_is1'
> Name='UninstallString' Win64='??' />
>
>
>
>
>
>
>
> 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
Actually I had to specifically compile to x86 before it would work even though
the target machine was x64. If I specifically compiled to x64 I received a
warning on the build machine what I am compiling to something different than
the current machine but when it came to running on the target machine that was
actually x64 I ran into another error but it didn't work. The takeaway is that
no matter what the target machine is you have to set x86 when building the .NET
CA. Any CPU doesn't work and x64 doesn't seem to work either.
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: Friday, March 11, 2011 10:53 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
FYI: The "DLL" is a .NET assembly. The "CA.dll" is a native C++ assembly that
is responsible for setting up the .NET environment needed to run the .NET
"DLL". As you found out, you need the bitness of the "CA.dll" to match the
target machine.
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: Friday, March 11, 2011 6:40 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] C# Custom Action questions
>
> I am sorry I had inadvertently set the tag to the DLL *not*
> the CA.dll so with the compile target of the CA specifically set to
> x86 (*not* Any CPU) the CA is called correctly. Thank you.
>
>
> Kevin Burton
> Senior Software Engineer
> BUYSEASONS
> 262-901-2000 Office
> 262-901-2312 Fax
> kev...@buyseasons.com
>
>
> -Original Message-
> From: Michael Osmond [mailto:mosm...@baytech.com.au]
> Sent: Thursday, March 10, 2011 8:49 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: 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 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
> BUYSEA
Re: [WiX-users] Patch install/uninstall timing in regards to access of installed files
Sorry the table I added @ the bottom did not get sent correctly. I reformatted it below. Hi - I would greatly appreciate any help in understanding the timing of when I have access to the original or updated version of files installed during a patch install, uninstall and rollback sequences of both. The Install process seem fairly straight forward. I have availability of the old files before the InstallFiles sequence and the new ones afterwards. However when a rollback occurs I am not sure at what point I have access to the newly installed files and the original files before the patch was applied? Can I schedule something to have access to both the current and previous versions? The Uninstall of the patch seems even a little more confusing since it appears that the previous files are restored before I can get a custom action to run. But once a rollback occurs do I have access to the current or previous versions? The following example is what I am trying to work out. I am installing both SSRS & SQL content on a server and need to handle both the Installation and Un-installation of a patch as well as handling a rollback occurring during either. The Desired Action column shows what I want to happen I just need to know when I have availability to the desired version so I can call the appropriate CA to perform the action. Assuming: Base Install - puts V1 of files on server Patch1 - puts V2 of files on server Install Operation Schedule Desired Action = === Install Patch1 After InstallFiles Run CA to put V2 reports on server Run InstallV2.sql Rollback occurs during Install Patch1 Do I have access to Run CA to put V1 reports on server Both current and prev Run Uninstall V2.sql Versions? Run InstallV1.sql Remove Patch1 ? Run CA to put V1 reports on server Run Uninstall V2.sql Run InstallV1.sql Rollback occurs during Remove Patch1? Run CA to put V2 reports on server Run InstallV2.sql Thanks - Tom -- 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] ComPlus Problem - Was working, now not working
I've got an installer for a utility that includes a COM+ component. The solution was originally created in VS2008 and targetted .NET 3.5. The solution was 'upgraded' to VS2010 and .NET 4.0, and now the installation fails ... Here's a fragment for COM+ component & TLB [this was working fine until the upgrade]: ** Here's a fragment from the installation log file showing the error: ComPlusInstallExecuteCommit: Registering assembly, key: myAssembly MSI (s) (DC!DC) [09:57:53:884]: Closing MSIHANDLE (3073) of type 790531 for thread 3548 MSI (s) (DC!DC) [09:57:58:775]: Creating MSIHANDLE (3074) of type 790531 for thread 3548 ComPlusInstallExecuteCommit: ExceptionInfo: Code='0', Source='System.EnterpriseServices', Description='Failed to load assembly 'c:\program files\myCompany\ourApplication\curVerNum\myAssembly.dll'.', HelpFile='', HelpContext='0' MSI (s) (DC!DC) [09:57:58:791]: Closing MSIHANDLE (3074) of type 790531 for thread 3548 MSI (s) (DC!DC) [09:57:58:791]: Creating MSIHANDLE (3075) of type 790531 for thread 3548 ComPlusInstallExecuteCommit: Error 0x80020009: Failed to invoke RegistrationHelper.InstallAssembly() method MSI (s) (DC!DC) [09:57:58:791]: Closing MSIHANDLE (3075) of type 790531 for thread 3548 MSI (s) (DC!DC) [09:57:58:791]: Creating MSIHANDLE (3076) of type 790531 for thread 3548 ComPlusInstallExecuteCommit: Error 0x80020009: Failed to register .NET assembly MSI (s) (DC!DC) [09:57:58:791]: Closing MSIHANDLE (3076) of type 790531 for thread 3548 MSI (s) (DC!DC) [09:57:58:791]: Creating MSIHANDLE (3077) of type 790531 for thread 3548 ComPlusInstallExecuteCommit: Error 0x80020009: Failed to register assembly, key: myAssembly MSI (s) (DC!DC) [09:57:58:791]: Closing MSIHANDLE (3077) of type 790531 for thread 3548 MSI (s) (DC!DC) [09:57:58:791]: Creating MSIHANDLE (3078) of type 790531 for thread 3548 ComPlusInstallExecuteCommit: Error 0x80020009: Failed to register assemblies ** I'm using WiX v3.5.2519.0 ... and I have seen a similar error has been reported in the WiX bug tracker on SourceForge [registering a TLB] ... but no solution to the problem. Help! Thanks in advance, -dmm -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/ComPlus-Problem-Was-working-now-not-working-tp6162044p6162044.html Sent from the wix-users mailing list archive at Nabble.com. -- 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] ComPlus Problem - Was working, now not working - 2nd Attempt at Posting
I've got an installer for a utility that includes a COM+ component. The solution was originally created in VS2008 and targetted .NET 3.5. The solution was 'upgraded' to VS2010 and .NET 4.0, and now the installation fails ... Here's a fragment for COM+ component & TLB [this was working fine until the upgrade]: ** Here's a fragment from the installation log file showing the error: ComPlusInstallExecuteCommit: Registering assembly, key: myAssembly MSI (s) (DC!DC) [09:57:53:884]: Closing MSIHANDLE (3073) of type 790531 for thread 3548 MSI (s) (DC!DC) [09:57:58:775]: Creating MSIHANDLE (3074) of type 790531 for thread 3548 ComPlusInstallExecuteCommit: ExceptionInfo: Code='0', Source='System.EnterpriseServices', Description='Failed to load assembly 'c:\program files\myCompany\ourApplication\curVerNum\myAssembly.dll'.', HelpFile='', HelpContext='0' MSI (s) (DC!DC) [09:57:58:791]: Closing MSIHANDLE (3074) of type 790531 for thread 3548 MSI (s) (DC!DC) [09:57:58:791]: Creating MSIHANDLE (3075) of type 790531 for thread 3548 ComPlusInstallExecuteCommit: Error 0x80020009: Failed to invoke RegistrationHelper.InstallAssembly() method MSI (s) (DC!DC) [09:57:58:791]: Closing MSIHANDLE (3075) of type 790531 for thread 3548 MSI (s) (DC!DC) [09:57:58:791]: Creating MSIHANDLE (3076) of type 790531 for thread 3548 ComPlusInstallExecuteCommit: Error 0x80020009: Failed to register .NET assembly MSI (s) (DC!DC) [09:57:58:791]: Closing MSIHANDLE (3076) of type 790531 for thread 3548 MSI (s) (DC!DC) [09:57:58:791]: Creating MSIHANDLE (3077) of type 790531 for thread 3548 ComPlusInstallExecuteCommit: Error 0x80020009: Failed to register assembly, key: myAssembly MSI (s) (DC!DC) [09:57:58:791]: Closing MSIHANDLE (3077) of type 790531 for thread 3548 MSI (s) (DC!DC) [09:57:58:791]: Creating MSIHANDLE (3078) of type 790531 for thread 3548 ComPlusInstallExecuteCommit: Error 0x80020009: Failed to register assemblies ** I'm using WiX v3.5.2519.0 ... and I have seen a similar error has been reported in the WiX bug tracker on SourceForge [registering a TLB] ... but no solution to the problem. Help! Thanks in advance, -dmm -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/ComPlus-Problem-Was-working-now-not-working-2nd-Attempt-at-Posting-tp6162048p6162048.html Sent from the wix-users mailing list archive at Nabble.com. -- 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
FYI: The "DLL" is a .NET assembly. The "CA.dll" is a native C++ assembly that
is responsible for setting up the .NET environment needed to run the .NET
"DLL". As you found out, you need the bitness of the "CA.dll" to match the
target machine.
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: Friday, March 11, 2011 6:40 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] C# Custom Action questions
>
> I am sorry I had inadvertently set the tag to the DLL *not* the
> CA.dll
> so with the compile target of the CA specifically set to x86 (*not* Any CPU)
> the CA is called correctly. Thank you.
>
>
> Kevin Burton
> Senior Software Engineer
> BUYSEASONS
> 262-901-2000 Office
> 262-901-2312 Fax
> kev...@buyseasons.com
>
>
> -Original Message-
> From: Michael Osmond [mailto:mosm...@baytech.com.au]
> Sent: Thursday, March 10, 2011 8:49 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: 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 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
>
>
>
> - Ori
[WiX-users] Patch install/uninstall timing in regards to access of installed files
Hi - I would greatly appreciate any help in understanding the timing of when I have access to the original or updated version of files installed during a patch install, uninstall and rollback sequences of both. The Install process seem fairly straight forward. I have availability of the old files before the InstallFiles sequence and the new ones afterwards. However when a rollback occurs I am not sure at what point I have access to the newly installed files and the original files before the patch was applied? Can I schedule something to have access to both the current and previous versions? The Uninstall of the patch seems even a little more confusing since it appears that the previous files are restored before I can get a custom action to run. But once a rollback occurs do I have access to the current or previous versions? The following example is what I am trying to work out. I am installing both SSRS & SQL content on a server and need to handle both the Installation and Un-installation of a patch as well as handling a rollback occurring during either. The Desired Action column shows what I want to happen I just need to know when I have availability to the desired version so I can call the appropriate CA to perform the action. Assuming: Base Install - puts V1 of files on server Patch1 - puts V2 of files on server Install Operation Schedule Desired Action Install Patch1 After InstallFiles Run CA to put V2 reports on server Run InstallV2.sql Rollback occurs during Install Patch1 ? Run CA to put V1 reports on server Run Uninstall V2.sql Run InstallV1.sql Remove Patch1 ? Run CA to put V1 reports on server Run Uninstall V2.sql Run InstallV1.sql Rollback occurs during Remove Patch1 ? Run CA to put V2 reports on server Run InstallV2.sql Thanks - Tom -- 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] Workaround to the missing option to use property values in file names
Hello WiX community, I've got a requirement to change the name of the installed files based on the user input. The initial thought was to use the property values, but it turns out not to be supported. I've also read this: " http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-a-lt-Property-gt-Value-inside-lt-File-Name-gt-td6000865.html"; and it seems the best option is to modify the MSI database before launching the msiexec... However, I'm thinking about the following workaround: - install the file with its original name to somewhere under TempFolder (unique path based on product code) - author a CopyFile element under each of such files and make it create a copy with the desired name (in order to support property values this can only be done with a custom action which populates the DuplicateFile table with necessary temporary rows) I understand that the obvious drawback of this is having a component hidden under temp and not used. I think I can live with this... Any other "features" of such approach? I know I will have to author RemoveFile elements to drop the copied clones. Thanks in advance for any suggestion, -- Yan -- 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] Multilanguage install
Hi I'm having problems with creating an msi that works for different locals.
Below is an extract from the log file
I have created an msi for each language, changing the Language in the
Product element to 1033 and 1040
I can run both the 1033 and 1040 msi on the machine and they display the
correct language
I then created a transform between my 1033 and 1040 and embedded it into the
1033 with a name of 1040
I then set the Languages in the Summary Info to '1033,1040'
I change my regional settings and then try to run the resulting msi and it
fails.
Any ideas what I've missed please?
-
MSI (c) (F4:94) [15:30:26:256]: APPCOMPAT: looking for appcompat database
entry with ProductCode '{15FA6484-DB24-460C-97D5-89CA132144D7}'.
MSI (c) (F4:94) [15:30:26:256]: APPCOMPAT: no matching ProductCode found in
database.
MSI (c) (F4:94) [15:30:26:271]: MSCOREE not loaded loading copy from
system32
MSI (c) (F4:94) [15:30:26:271]: Machine policy value 'TransformsSecure' is 0
MSI (c) (F4:94) [15:30:26:271]: User policy value 'TransformsAtSource' is 0
MSI (c) (F4:94) [15:30:26:271]: Machine policy value 'DisablePatch' is 0
MSI (c) (F4:94) [15:30:26:271]: Machine policy value 'AllowLockdownPatch' is
0
MSI (c) (F4:94) [15:30:26:271]: Machine policy value 'DisableLUAPatching' is
0
MSI (c) (F4:94) [15:30:26:271]: Machine policy value
'DisableFlyWeightPatching' is 0
MSI (c) (F4:94) [15:30:26:271]: Looking for storage transform: 1040
MSI (c) (F4:94) [15:30:26:271]: Validating transform '1040' with validation
bits 0x1
MSI (c) (F4:94) [15:30:26:271]: Note: 1: 2745 2: 1040 3:
C:\DOCUME~1\ADMINI~1\IMPOST~1\Temp\d6082c.msi 4: 1033 5: 1040
MSI (c) (F4:94) [15:30:26:271]: 1: 2745 2: 1040 3:
C:\DOCUME~1\ADMINI~1\IMPOST~1\Temp\d6082c.msi 4: 1033 5: 1040
MSI (c) (F4:94) [15:30:26:271]: Note: 1: 2729
DEBUG: Error 2745: Transform 1040 invalid for package
C:\DOCUME~1\ADMINI~1\IMPOST~1\Temp\d6082c.msi. Expected language 1033, found
language 1040.
1: 2745 2: 1040 3: C:\DOCUME~1\ADMINI~1\IMPOST~1\Temp\d6082c.msi 4: 1033 5:
1040
Errore nell'applicazione dei trasformatori. Verificare che i percorsi dei
trasformatori specificati siano validi.
1040
MSI (c) (F4:94) [15:30:26:271]: Note: 1: 1708
MSI (c) (F4:94) [15:30:26:271]: Note: 1: 2729
MSI (c) (F4:94) [15:30:26:271]: Note: 1: 2729
MSI (c) (F4:94) [15:30:26:271]: Product: Session Insight -- Installation
failed.
--
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] Heat - harvesting COM registry entries for componentswith dependencies
Am I asking this question in the wrong group? After downloading the Wix source and pondering on this a bit further, instead of taking a list of dependent dlls I believe it would be better to take a single/list of fragments containing the harvested data of the dependent component. Jacob -Original Message- From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Sent: Thursday, March 10, 2011 10:17 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Heat - harvesting COM registry entries for componentswith 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 -- 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
I am sorry I had inadvertently set the tag to the DLL *not* the CA.dll
so with the compile target of the CA specifically set to x86 (*not* Any CPU)
the CA is called correctly. Thank you.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Michael Osmond [mailto:mosm...@baytech.com.au]
Sent: Thursday, March 10, 2011 8:49 PM
To: General discussion for Windows Installer XML toolset.
Subject: 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 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)"
To: General discussion for Windows Installer XML toolset.
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 verif
Re: [WiX-users] C# Custom Action questions
Along these same lines I tried building the CA project setting the target as
x64 just to see if this made a difference. I did get a different error message
but it still didn't work:
MSI (s) (60:B0) [08:07:23:200]: Doing action: CA_CheckCredentials
MSI (s) (60:B0) [08:07:23:200]: Note: 1: 2205 2: 3: ActionText
Action ended 8:07:23: InstallInitialize. Return value 1.
MSI (s) (60:4C) [08:07:23:215]: Invoking remote custom action. DLL:
D:\WINDOWS\Installer\MSI463.tmp, Entrypoint: CheckCredentials
MSI (s) (60:80) [08:07:23:215]: Generating random cookie.
MSI (s) (60:80) [08:07:23:231]: Created Custom Action Server with PID 5428
(0x1534).
MSI (s) (60:C0) [08:07:23:278]: Running as a service.
MSI (s) (60:C0) [08:07:23:278]: Hello, I'm your 32bit Impersonated custom
action server.
Action start 8:07:23: CA_CheckCredentials.
SFXCA: Extracting custom action to temporary directory:
D:\WINDOWS\Installer\MSI463.tmp-\
SFXCA: Binding to CLR version v4.0.30319
Calling custom action
BrainCustomActions!BuySeasons.BsiServices.Install.CustomActions.CheckCredentials
Error: could not load custom action class
BuySeasons.BsiServices.Install.CustomActions from assembly: BrainCustomActions
System.BadImageFormatException: Could not load file or assembly
'BrainCustomActions' or one of its dependencies. An attempt was made to load a
program with an incorrect format.
File name: 'BrainCustomActions'
at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String
codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint,
StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean
forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String
codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint,
StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean
forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName
assemblyRef, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean
forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString,
Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection)
at System.AppDomain.Load(String assemblyString)
at
Microsoft.Deployment.WindowsInstaller.CustomActionProxy.GetCustomActionMethod(Session
session, String assemblyName, String className, String methodName)
When I specify x86 as the target I get the familiar error:
MSI (s) (2C:74) [08:24:38:753]: Doing action: CA_CheckCredentials
MSI (s) (2C:74) [08:24:38:753]: Note: 1: 2205 2: 3: ActionText
Action ended 8:24:38: InstallInitialize. Return value 1.
MSI (s) (2C:90) [08:24:38:753]: Invoking remote custom action. DLL:
D:\WINDOWS\Installer\MSI465.tmp, Entrypoint: CheckCredentials
MSI (s) (2C:88) [08:24:38:753]: Generating random cookie.
MSI (s) (2C:88) [08:24:38:768]: Created Custom Action Server with PID 5368
(0x14F8).
MSI (s) (2C:F4) [08:24:38:815]: Running as a service.
MSI (s) (2C:F4) [08:24:38:815]: Hello, I'm your 32bit Impersonated custom
action server.
MSI (s) (2C:74) [08:24:38:878]: Note: 1: 1723 2: CA_CheckCredentials 3:
CheckCredentials 4: D:\WINDOWS\Installer\MSI465.tmp
Action start 8:24:38: CA_CheckCredentials.
MSI (s) (2C:74) [08:24:38:878]: 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\MSI465.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\MSI465.tmp
MSI (s) (2C:74) [08:24:38:878]: Machine policy value 'DisableRollback' is 0
MSI (s) (2C:74) [08:24:38:878]: Note: 1: 1402 2:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts
3: 2
Action ended 8:24:38: CA_CheckCredentials. Return value 3.
MSI (s) (2C:74) [08:24:38:878]: Note: 1: 1402 2:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts
3: 2
MSI (s) (2C:74) [08:24:38:878]: No System Restore sequence number for this
installation.
MSI (s) (2C:74) [08:24:38:878]: Unlocking Server
Action ended 8:24:38: INSTALL. Return value 3.
Property(S): UpgradeCode = {529189FE-FD0E-44FF-8DA6-B4FB5CC7A78B}
Property(S): COMMERCESERVERINSTALLDIR = D:\Program Files (x86)\Microsoft
Commerce Server 2007\
Property(S): NETFRAMEWORK35 = #1
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Michael Osmond [mailto:mosm...@baytech.com.au]
Sent: Thursday, March 10, 2011 8:49 PM
To: General di
Re: [WiX-users] DIFxApp does not properly rollback to the old driverwhen doing a major upgrade
I appear to be looking at the same problem. I was able to reproduce it by hitting 'cancel' near the end of an uninstall and letting it rollback. After that uninstallation failed. Performing a repair fixed things. Did you email the difx team at the email address Quinton suggested, and if so, did you ever hear anything back. Thanks, Rob On 10/12/2010 20:37, James Johnston wrote: > Seeing as how this seems to be a fundamental problem with DIFxApp not > handling all the upgrade possibilities well, I was curious to see how other > products do things and so I ripped apart some MSIs in Orca. I was looking > to see if DIFxApp was set up the same way (CustomAction table). I also > inspected the placement of the RemoveExistingProducts action since after my > previous e-mail I believe that this plays a critical role in whether this > corrupted system state may occur. Since I haven't seen any other indication > or documentation on the Internet (a Google search for RemoveExistingProducts > and DIFxApp reveals little), I thought it would be useful to report my > findings so others can see what some commercial software is doing. My > findings: > > All products using DIFxApp place MsiProcessDrivers and MsiCleanupOnSuccess > actions in the normal places. CustomAction types are always the same. I > identified the program used to compile the MSI by looking at the self-named > custom actions each install tool tends to create (e.g. InstallShield has its > own DLL with tons of custom actions). > > Refer to > http://jpassing.com/2007/06/16/where-to-place-removeexistingproducts-in-a-ma > jor-msi-upgrade/ to better understand the placement of > RemoveExistingProducts action. Examining this table leads me to believe > that placement between InstallInitialize and InstallFinalize is the best > place, since a canceled setup will always leave the old version on the > computer, no matter what. But this doesn't seem to work with DIFxApp due to > its bug, as previously noted. > > My product (with the rollback problem): Compiled with WiX and uses DIFxApp. > RemoveExistingProducts is placed after InstallInitialize. According to the > previous link, a failure at any time (uninstall or reinstall) results in > only the old version remaining: leaving system state exactly as it was > found. Unfortunately, as previously noted, a bug in DIFxApp prevents this > from happening. > > Apple Mobile Device Support (included with iTunes; presumably their iPod > drivers, etc.). Compiled with WiX and uses DIFxApp. RemoveExistingProducts > is placed after InstallFinalize. Probably the DIFxApp bug is not a problem > here, because the new version is installed before the old version is > uninstalled. An error in the new version setup (from DIFx or other source) > would still leave the old version and its drivers untouched. An error in > the old version uninstall would leave the new version& its drivers > untouched. According to the table at the above link, the pitfall is that if > the uninstall fails, then BOTH versions of the product remain installed on > the computer. This seems like a very inconsistent, illogical state to be > in; I can imagine that there could be some issues with a lot of products > (including mine) if this were to happen. (Perhaps an MSI expert can > convince me otherwise? Otherwise, I wonder if Apple's software can get > itself in a bad way if I click Cancel at just the right moment.) > > Microsoft LifeCam (webcam driver). Don't know what compiled this; I didn't > see any obvious indications. It uses DIFxApp. RemoveExistingProducts is > placed after InstallInitialize. It therefore appears to be in a very > similar configuration as with my product, and I believe it would leave the > user's DIFxApp state inconsistent if the upgrade was canceled at just the > right moment. It is interesting to note that the MSI file is wrapped by a > bootstrapper: the MSI itself throws no UI. The bootstrapper does NOT > present the user with a Cancel button. Perhaps this is a reason why? > > Oracle VirtualBox (virtual network drivers). Compiled with WiX and uses > DIFxApp. RemoveExistingProducts is placed between InstallValidate and > InstallInitialize. This seems like the best place to put it. Uninstall > happens first, so there's no possibility of having both versions at the same > time. If the uninstall fails, then the old version remains. If the install > fails, then nothing remains on the computer (i.e. the old version is not > reinstalled). I don't see how this DIFxApp bug would be a problem in this > scenario since the old version isn't reinstalled. > > Western Digital SmartWare (some proprietary driver for external hard drive). > Compiled with Advanced Installer and uses DIFxApp. RemoveExistingProducts > is placed between InstallValidate and InstallInitialize, like with > VirtualBox. > > HP OfficeJet 8500. Compiled with WiX. RemoveExistingProducts is placed > after InstallInitialize so I suspect their
Re: [WiX-users] C# Custom Action questions
It is currently set to 'Any CPU'.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Michael Osmond [mailto:mosm...@baytech.com.au]
Sent: Thursday, March 10, 2011 8:49 PM
To: General discussion for Windows Installer XML toolset.
Subject: 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 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)"
To: General discussion for Windows Installer XML toolset.
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 t
