Re: [WiX-users] C# Custom Action questions
On 3/11/2011 9:27 AM, Kevin Burton wrote: 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: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) This error is because you are trying to load the x64 assembly into an x86 runtime environment. Note the line immediately before your custom action is called: Hello, I'm your 32bit Impersonated custom action server. That's coming from MSI and is telling you that MSI's running in 32-bit mode already. Remember, the MSI itself is already targeting a specific architecture, as specified by the Platform attribute on your Package tag. Your MSI is a 32-bit MSI, so everything it loads needs to be 32-bit as well. Ideally you should be building two separate packages, one for each arch. By setting up your Solution build configurations properly this is pretty simple, and will build a 64-bit MSI with a 64-bit CA project, and 32-bit MSI with a 32-bit CA project. The key here is that WiX defines a Platform variable that matches the platform for the currently building configuration, so you would do things like: Package ... Platform=$(var.Platform) / For more details on the MSI side of things, see: http://blogs.msdn.com/b/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx -- 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 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 binary element that makes the DLL part of the .msi maybe
needs to know about the bited-ness: of the source and target. All of this is
just supposition as I am a relative beginner with WiX.
-Original Message-
From: Michael Osmond [mailto:mosm...@baytech.com.au]
Sent: Thursday, March 10, 2011 5:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
Hi Kevin
I think your error that it can't find the CA is in the call
private static bool CheckCredentials
Should be something like:
[CustomAction]
public static ActionResult CheckCredentials(Session session)
The class it is a member of also needs to be public.
Note you need to get the credentials out of properties.
Michael
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Friday, 11 March 2011 8:41 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I hear you. Where I work there is already considerable skepticism on the
installation package and anything that goes wrong is blamed on the installation
so when the installation locks the account (because of bad credentials) there
is a call to not use any deployment and go to copy deployment because of
similar mysteries. If I can avoid the account lockout with a CA that would
sweep the problem under the rug at least for now.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: Thursday, March 10, 2011 4:24 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
When I was at Continental Airlines we had an application that I had to
distribute where the service used a service account. For reasons never
determined ( aka damn service account ) something out there would periodically
lock the account and group policy would have it unlocked 10 minutes later.
One of the worst dependencies I ever had to take. It wasn't fun.
---
Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know
a secret or read a really good thread that deserves attention? E-Mail Me
- Original Message
From: Castro, Edwin G. (Hillsboro) edwin.cas...@fiserv.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Thu, March 10, 2011 4:11:13 PM
Subject: Re: [WiX-users] C# Custom Action questions
Phil and I both mentioned the potential problem. Run your code for invalid
credentials more than once. Try it about 4-12 times (as suggested by Phil). The
flow for the custom action is the following:
User enters credentials in dialog.
Dialog asks custom action to validate.
Dialog checks validation result property letting the user know if the password
was valid or invalid.
Suppose that a user incorrect enters invalid credentials enough times... At my
work you only get 3 tries! On the third validation the account is locked out
and the fourth and future attempts all fail regardless of whether the
credentials were valid or not.
Running it once is not enough to verify that this is not the case.
Now, to address the CA running to begin with... Check that the CA
Re: [WiX-users] C# Custom Action questions
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 binary element that makes the DLL part of the .msi maybe
needs to know about the bited-ness: of the source and target. All of this is
just supposition as I am a relative beginner with WiX.
-Original Message-
From: Michael Osmond [mailto:mosm...@baytech.com.au]
Sent: Thursday, March 10, 2011 5:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
Hi Kevin
I think your error that it can't find the CA is in the call
private static bool CheckCredentials
Should be something like:
[CustomAction]
public static ActionResult CheckCredentials(Session session)
The class it is a member of also needs to be public.
Note you need to get the credentials out of properties.
Michael
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Friday, 11 March 2011 8:41 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I hear you. Where I work there is already considerable skepticism on the
installation package and anything that goes wrong is blamed on the installation
so when the installation locks the account (because of bad credentials) there
is a call to not use any deployment and go to copy deployment because of
similar mysteries. If I can avoid the account lockout with a CA that would
sweep the problem under the rug at least for now.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: Thursday, March 10, 2011 4:24 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
When I was at Continental Airlines we had an application that I had to
distribute where the service used a service account. For reasons never
determined ( aka damn service account ) something out there would periodically
lock the account and group policy would have it unlocked 10 minutes later.
One of the worst dependencies I ever had to take. It wasn't fun.
---
Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know
a secret or read a really good thread that deserves attention? E-Mail Me
- Original Message
From: Castro, Edwin G. (Hillsboro) edwin.cas...@fiserv.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Thu, March 10, 2011 4:11:13 PM
Subject: Re: [WiX-users] C# Custom Action questions
Phil and I both mentioned the potential problem. Run your code for invalid
credentials more than once. Try it about 4-12 times (as suggested by Phil). The
flow for the custom action is the following:
User enters credentials in dialog.
Dialog asks custom action to validate.
Dialog checks validation result property letting the user know if the password
was valid or invalid.
Suppose that a user incorrect enters invalid credentials enough times... At my
work you only get 3 tries! On the third validation the account is locked out
and the fourth and future attempts all fail regardless of whether the
credentials were valid or not.
Running it once is not enough to verify that this is not the case.
Now, to address the CA running to begin with... Check that the CA is getting
compiled with the correct bitness as required by the target platform. In other
words, are you compiling a 64-bit CA and trying to call it on a 32-bit machine
or vice versa?
If you can post a minimal reproduction (wix source, CA source, etc) of the CA
running problem I can
Re: [WiX-users] C# Custom Action questions
I am sorry I had inadvertently set the binary 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 binary element that makes the DLL part of the .msi maybe
needs to know about the bited-ness: of the source and target. All of this is
just supposition as I am a relative beginner with WiX.
-Original Message-
From: Michael Osmond [mailto:mosm...@baytech.com.au]
Sent: Thursday, March 10, 2011 5:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
Hi Kevin
I think your error that it can't find the CA is in the call
private static bool CheckCredentials
Should be something like:
[CustomAction]
public static ActionResult CheckCredentials(Session session)
The class it is a member of also needs to be public.
Note you need to get the credentials out of properties.
Michael
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Friday, 11 March 2011 8:41 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I hear you. Where I work there is already considerable skepticism on the
installation package and anything that goes wrong is blamed on the installation
so when the installation locks the account (because of bad credentials) there
is a call to not use any deployment and go to copy deployment because of
similar mysteries. If I can avoid the account lockout with a CA that would
sweep the problem under the rug at least for now.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: Thursday, March 10, 2011 4:24 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
When I was at Continental Airlines we had an application that I had to
distribute where the service used a service account. For reasons never
determined ( aka damn service account ) something out there would periodically
lock the account and group policy would have it unlocked 10 minutes later.
One of the worst dependencies I ever had to take. It wasn't fun.
---
Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know
a secret or read a really good thread that deserves attention? E-Mail Me
- Original Message
From: Castro, Edwin G. (Hillsboro) edwin.cas...@fiserv.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Thu, March 10, 2011 4:11:13 PM
Subject: Re: [WiX-users] C# Custom Action questions
Phil and I both mentioned the potential problem. Run your code for invalid
credentials more than once. Try it about 4-12 times (as suggested by Phil). The
flow for the custom action is the following:
User enters credentials in dialog.
Dialog asks custom action to validate.
Dialog checks validation result property letting the user know if the password
was valid or invalid.
Suppose that a user incorrect enters invalid credentials enough times... At my
work you only get 3 tries! On the third validation the account is locked out
and the fourth and future attempts all fail regardless of whether
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 binary 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 binary element that makes the DLL part of the .msi
maybe needs to know about the bited-ness: of the source and target. All of
this is just supposition as I am a relative beginner with WiX.
-Original Message-
From: Michael Osmond [mailto:mosm...@baytech.com.au]
Sent: Thursday, March 10, 2011 5:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
Hi Kevin
I think your error that it can't find the CA is in the call
private static bool CheckCredentials
Should be something like:
[CustomAction]
public static ActionResult CheckCredentials(Session session)
The class it is a member of also needs to be public.
Note you need to get the credentials out of properties.
Michael
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Friday, 11 March 2011 8:41 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I hear you. Where I work there is already considerable skepticism on the
installation package and anything that goes wrong is blamed on the
installation so when the installation locks the account (because of bad
credentials) there is a call to not use any deployment and go to copy
deployment because of similar mysteries. If I can avoid the account lockout
with a CA that would sweep the problem under the rug at least for now.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: Thursday, March 10, 2011 4:24 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
When I was at Continental Airlines we had an application that I had to
distribute where the service used a service account. For reasons never
determined ( aka damn service account ) something out there would
periodically lock the account and group policy would have it unlocked 10
minutes later.
One of the worst dependencies I ever had to take. It wasn't fun.
---
Christopher Painter, Author of Deployment Engineering Blog Have a hot tip,
know a secret or read a really good thread that deserves attention? E-Mail
Me
- Original Message
From: Castro, Edwin G. (Hillsboro) edwin.cas...@fiserv.com
To: General discussion for Windows Installer XML toolset
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 binary 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 binary element that makes the DLL
part of the .msi maybe needs to know about the bited-ness: of the
source and target. All of this is just supposition as I am a relative
beginner with WiX.
-Original Message-
From: Michael Osmond [mailto:mosm...@baytech.com.au]
Sent: Thursday, March 10, 2011 5:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
Hi Kevin
I think your error that it can't find the CA is in the call
private static bool CheckCredentials
Should be something like:
[CustomAction]
public static ActionResult CheckCredentials(Session session)
The class it is a member of also needs to be public.
Note you need to get the credentials out of properties.
Michael
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Friday, 11 March 2011 8:41 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I hear you. Where I work there is already considerable skepticism on
the installation package and anything that goes wrong is blamed on the
installation so when the installation locks the account (because of
bad
credentials) there is a call to not use any deployment and go to copy
deployment because of similar mysteries. If I can avoid the account
lockout with a CA that would sweep the problem under the rug at least for now.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From
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:
PropertyGroup
Configuration Condition= '$(Configuration)' == '' Debug/Configuration
Platform Condition= '$(Platform)' == '' x64/Platform
...
/PropertyGroup
PropertyGroup Condition= '$(Configuration)|$(Platform)' == 'Debug|x64'
...
/PropertyGroup
PropertyGroup Condition= '$(Configuration)|$(Platform)' == 'Release|x64'
...
/PropertyGroup
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 binary 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
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: PropertyGroup Configuration Condition= '$(Configuration)' == '' Debug/Configuration Platform Condition= '$(Platform)' == '' x64/Platform ... /PropertyGroup PropertyGroup Condition= '$(Configuration)|$(Platform)' == 'Debug|x64' ... /PropertyGroup PropertyGroup Condition= '$(Configuration)|$(Platform)' == 'Release|x64' ... /PropertyGroup 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
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) edwin.cas...@fiserv.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
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 binary 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 binary element that makes the DLL part of the .msi
maybe needs to know about the bited-ness: of the source and target. All of
this is just supposition as I am a relative beginner with WiX.
-Original Message-
From: Michael Osmond [mailto:mosm...@baytech.com.au]
Sent: Thursday, March 10, 2011 5:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
Hi Kevin
I think your error that it can't find the CA is in the call
private static bool CheckCredentials
Should be something like:
[CustomAction]
public static ActionResult CheckCredentials(Session session)
The class it is a member of also needs to be public.
Note you need to get the credentials out of properties.
Michael
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Friday, 11 March 2011 8:41 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I hear you. Where I work there is already considerable skepticism on the
installation package and anything that goes wrong is blamed on the
installation so when the installation locks the account (because of bad
credentials) there is a call to not use any deployment and go to copy
deployment because of similar mysteries. If I can avoid the account lockout
with a CA that would sweep the problem under the rug at least for now.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: Thursday, March 10, 2011 4:24 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
When I was at Continental Airlines we had an application that I had to
distribute where the service used a service account
Re: [WiX-users] C# Custom Action questions
How does the custom action indicate that the credentials are incorrect? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com] Sent: Wednesday, March 09, 2011 11:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You shouldn't return failure if the credentials are incorrect, if you do so you will get this error. been there, done that... On Mar 10, 2011 6:34 AM, Kevin Burton kev...@buyseasons.com wrote: I read that. Which of the four rules is this violating? I made the warning go away by making the C# CA 'immediate' thus I don't have to have another custom action to remember the property. So I have CustomAction Id=CA_CheckCredentials Return=check Execute=immediate BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And the schedule InstallExecuteSequence Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence But in the verbose log I get: MSI (s) (B8:9C) [22:04:26:415]: Note: 1: 1723 2: CA_CheckCredentials 3: CheckCredentials 4: D:\WINDOWS\Installer\MSI410.tmp Action start 22:04:26: CA_CheckCredentials. MSI (s) (B8:9C) [22:04:26:415]: Product: Bsi WebServices -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp The error says that the DLL cannot be run. Why? I believe I have followed the instructions for writing a managed CA to the tee (though there seems to be some disagreement between the online tutorial http://www.tramontana.co.hu/wix/ and this book). -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, March 09, 2011 5:26 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions ICE63 - http://msdn.microsoft.com/en-us/library/aa369008.aspx Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Wednesday, March 09, 2011 2:15 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions I think I have solved this problem. The CA was scheduled in the InstallExecuteSequence and was marked as 'deferred' so I created the following 'Custom Data'. CustomAction Id=SetProperty Property=CA_CheckCredentials Value=[SERVICEUSER],[SERVICEPASSWORD] / CustomAction Id=CA_CheckCredentials Return=check Execute=deferred BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And scheduled it like (I am trying to follow the instructions on page 133 of 'WiX: A Developer's Guide to Windows Installer XML' by Nick Ramirez) InstallExecuteSequence Custom Action=SetProperty Before=CA_CheckCredentials / Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence Now I get the ICE warning: warning LGHT1076: ICE63: Some action falls between InstallInitialize and RemoveExistingProducts. Is this a bad warning? I don't completely understand why this scheduling is bad. I would like to know that the credentials are bad *before* the existing products are removed. If I look at the .msi generated with Orca I see that in the InstallExecuteSequence table InstallInitialize 1500 SetProperty 1501 CA_CheckCredentials 1502 RemoveExistingProducts 1503 This seems like a valid sequence to me but I am obviously missing something as the warning is there for a purpose. -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Wednesday, March 09, 2011 3:30 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions If I had to guess you calling this CA as a ControlEvent off a Dialog / Control in your UI sequence. Am I correct? If so, it's a known issue that Msi lacks the ability to process messages in this scenario. The workaround is to set a dummy property to see a PROPERTY CHANGED message in the log file where the value is the data you are trying to log. Chris --- Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves
Re: [WiX-users] C# Custom Action questions
This error occurs when the credentials are correct. I don't get the message that the CA is being called (the first line in the code) so I don't think the CA is even being called. Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com] Sent: Wednesday, March 09, 2011 11:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You shouldn't return failure if the credentials are incorrect, if you do so you will get this error. been there, done that... On Mar 10, 2011 6:34 AM, Kevin Burton kev...@buyseasons.com wrote: I read that. Which of the four rules is this violating? I made the warning go away by making the C# CA 'immediate' thus I don't have to have another custom action to remember the property. So I have CustomAction Id=CA_CheckCredentials Return=check Execute=immediate BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And the schedule InstallExecuteSequence Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence But in the verbose log I get: MSI (s) (B8:9C) [22:04:26:415]: Note: 1: 1723 2: CA_CheckCredentials 3: CheckCredentials 4: D:\WINDOWS\Installer\MSI410.tmp Action start 22:04:26: CA_CheckCredentials. MSI (s) (B8:9C) [22:04:26:415]: Product: Bsi WebServices -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp The error says that the DLL cannot be run. Why? I believe I have followed the instructions for writing a managed CA to the tee (though there seems to be some disagreement between the online tutorial http://www.tramontana.co.hu/wix/ and this book). -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, March 09, 2011 5:26 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions ICE63 - http://msdn.microsoft.com/en-us/library/aa369008.aspx Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Wednesday, March 09, 2011 2:15 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions I think I have solved this problem. The CA was scheduled in the InstallExecuteSequence and was marked as 'deferred' so I created the following 'Custom Data'. CustomAction Id=SetProperty Property=CA_CheckCredentials Value=[SERVICEUSER],[SERVICEPASSWORD] / CustomAction Id=CA_CheckCredentials Return=check Execute=deferred BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And scheduled it like (I am trying to follow the instructions on page 133 of 'WiX: A Developer's Guide to Windows Installer XML' by Nick Ramirez) InstallExecuteSequence Custom Action=SetProperty Before=CA_CheckCredentials / Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence Now I get the ICE warning: warning LGHT1076: ICE63: Some action falls between InstallInitialize and RemoveExistingProducts. Is this a bad warning? I don't completely understand why this scheduling is bad. I would like to know that the credentials are bad *before* the existing products are removed. If I look at the .msi generated with Orca I see that in the InstallExecuteSequence table InstallInitialize 1500 SetProperty 1501 CA_CheckCredentials 1502 RemoveExistingProducts 1503 This seems like a valid sequence to me but I am obviously missing something as the warning is there for a purpose. -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Wednesday, March 09, 2011 3:30 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions If I had to guess you calling this CA as a ControlEvent off a Dialog / Control in your UI sequence. Am I correct? If so, it's a known issue that Msi lacks the ability to process messages in this scenario. The workaround is to set a dummy property to see a PROPERTY CHANGED message in the log file where the value is the data you are trying to log. Chris --- Christopher Painter, Author
Re: [WiX-users] C# Custom Action questions
You'll want to set a property that can be checked in a condition. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 6:05 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions How does the custom action indicate that the credentials are incorrect? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com] Sent: Wednesday, March 09, 2011 11:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You shouldn't return failure if the credentials are incorrect, if you do so you will get this error. been there, done that... On Mar 10, 2011 6:34 AM, Kevin Burton kev...@buyseasons.com wrote: I read that. Which of the four rules is this violating? I made the warning go away by making the C# CA 'immediate' thus I don't have to have another custom action to remember the property. So I have CustomAction Id=CA_CheckCredentials Return=check Execute=immediate BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And the schedule InstallExecuteSequence Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence But in the verbose log I get: MSI (s) (B8:9C) [22:04:26:415]: Note: 1: 1723 2: CA_CheckCredentials 3: CheckCredentials 4: D:\WINDOWS\Installer\MSI410.tmp Action start 22:04:26: CA_CheckCredentials. MSI (s) (B8:9C) [22:04:26:415]: Product: Bsi WebServices -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp The error says that the DLL cannot be run. Why? I believe I have followed the instructions for writing a managed CA to the tee (though there seems to be some disagreement between the online tutorial http://www.tramontana.co.hu/wix/ and this book). -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, March 09, 2011 5:26 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions ICE63 - http://msdn.microsoft.com/en-us/library/aa369008.aspx Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Wednesday, March 09, 2011 2:15 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions I think I have solved this problem. The CA was scheduled in the InstallExecuteSequence and was marked as 'deferred' so I created the following 'Custom Data'. CustomAction Id=SetProperty Property=CA_CheckCredentials Value=[SERVICEUSER],[SERVICEPASSWORD] / CustomAction Id=CA_CheckCredentials Return=check Execute=deferred BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And scheduled it like (I am trying to follow the instructions on page 133 of 'WiX: A Developer's Guide to Windows Installer XML' by Nick Ramirez) InstallExecuteSequence Custom Action=SetProperty Before=CA_CheckCredentials / Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence Now I get the ICE warning: warning LGHT1076: ICE63: Some action falls between InstallInitialize and RemoveExistingProducts. Is this a bad warning? I don't completely understand why this scheduling is bad. I would like to know that the credentials are bad *before* the existing products are removed. If I look at the .msi generated with Orca I see that in the InstallExecuteSequence table InstallInitialize 1500 SetProperty 1501 CA_CheckCredentials 1502 RemoveExistingProducts 1503 This seems like a valid sequence to me but I am obviously missing something as the warning is there for a purpose. -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Wednesday, March 09, 2011 3:30 PM To: General
Re: [WiX-users] C# Custom Action questions
So CA's always return Success. What are the other return values used for? Thank you. For the tip. The problem that I am having now is that it doesn't appear that the CA is getting called. I look in the log and see the message indicated earlier in this thread indicating that the DLL could not be run. Any idea for this? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Thursday, March 10, 2011 12:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You'll want to set a property that can be checked in a condition. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 6:05 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions How does the custom action indicate that the credentials are incorrect? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com] Sent: Wednesday, March 09, 2011 11:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You shouldn't return failure if the credentials are incorrect, if you do so you will get this error. been there, done that... On Mar 10, 2011 6:34 AM, Kevin Burton kev...@buyseasons.com wrote: I read that. Which of the four rules is this violating? I made the warning go away by making the C# CA 'immediate' thus I don't have to have another custom action to remember the property. So I have CustomAction Id=CA_CheckCredentials Return=check Execute=immediate BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And the schedule InstallExecuteSequence Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence But in the verbose log I get: MSI (s) (B8:9C) [22:04:26:415]: Note: 1: 1723 2: CA_CheckCredentials 3: CheckCredentials 4: D:\WINDOWS\Installer\MSI410.tmp Action start 22:04:26: CA_CheckCredentials. MSI (s) (B8:9C) [22:04:26:415]: Product: Bsi WebServices -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp The error says that the DLL cannot be run. Why? I believe I have followed the instructions for writing a managed CA to the tee (though there seems to be some disagreement between the online tutorial http://www.tramontana.co.hu/wix/ and this book). -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, March 09, 2011 5:26 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions ICE63 - http://msdn.microsoft.com/en-us/library/aa369008.aspx Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Wednesday, March 09, 2011 2:15 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions I think I have solved this problem. The CA was scheduled in the InstallExecuteSequence and was marked as 'deferred' so I created the following 'Custom Data'. CustomAction Id=SetProperty Property=CA_CheckCredentials Value=[SERVICEUSER],[SERVICEPASSWORD] / CustomAction Id=CA_CheckCredentials Return=check Execute=deferred BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And scheduled it like (I am trying to follow the instructions on page 133 of 'WiX: A Developer's Guide to Windows Installer XML' by Nick Ramirez) InstallExecuteSequence Custom Action=SetProperty Before=CA_CheckCredentials / Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence Now I get the ICE warning: warning LGHT1076: ICE63: Some action falls between
Re: [WiX-users] C# Custom Action questions
In cases where you checking things like credentials you want the actions to return success so that the install does not fail. As it was said, you set a property if the call succeeded and check if the property is set. You use the other return values in those cases where you want the install to fail and not continue such as when updating configuration files or updating anything that the application requires to function. The basic rule of thumb is when in the UI sequence always have actions return success and set properties use in conditional statements. When the action is called in the Execute sequence and it is critical to the success of the product always have the action return success or failure so that the install can fail and rollback when needed. Mat Skildum -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions So CA's always return Success. What are the other return values used for? Thank you. For the tip. The problem that I am having now is that it doesn't appear that the CA is getting called. I look in the log and see the message indicated earlier in this thread indicating that the DLL could not be run. Any idea for this? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Thursday, March 10, 2011 12:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You'll want to set a property that can be checked in a condition. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 6:05 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions How does the custom action indicate that the credentials are incorrect? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com] Sent: Wednesday, March 09, 2011 11:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You shouldn't return failure if the credentials are incorrect, if you do so you will get this error. been there, done that... On Mar 10, 2011 6:34 AM, Kevin Burton kev...@buyseasons.com wrote: I read that. Which of the four rules is this violating? I made the warning go away by making the C# CA 'immediate' thus I don't have to have another custom action to remember the property. So I have CustomAction Id=CA_CheckCredentials Return=check Execute=immediate BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And the schedule InstallExecuteSequence Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence But in the verbose log I get: MSI (s) (B8:9C) [22:04:26:415]: Note: 1: 1723 2: CA_CheckCredentials 3: CheckCredentials 4: D:\WINDOWS\Installer\MSI410.tmp Action start 22:04:26: CA_CheckCredentials. MSI (s) (B8:9C) [22:04:26:415]: Product: Bsi WebServices -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp The error says that the DLL cannot be run. Why? I believe I have followed the instructions for writing a managed CA to the tee (though there seems to be some disagreement between the online tutorial http://www.tramontana.co.hu/wix/ and this book). -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, March 09, 2011 5:26 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions ICE63 - http://msdn.microsoft.com/en-us/library/aa369008.aspx Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev
Re: [WiX-users] C# Custom Action questions
But I want the install to fail. If it continues with the wrong credentials it will try to start services with the wrong credentials. Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Skildum, Mathew [mailto:mathew.skil...@aspect.com] Sent: Thursday, March 10, 2011 12:32 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions In cases where you checking things like credentials you want the actions to return success so that the install does not fail. As it was said, you set a property if the call succeeded and check if the property is set. You use the other return values in those cases where you want the install to fail and not continue such as when updating configuration files or updating anything that the application requires to function. The basic rule of thumb is when in the UI sequence always have actions return success and set properties use in conditional statements. When the action is called in the Execute sequence and it is critical to the success of the product always have the action return success or failure so that the install can fail and rollback when needed. Mat Skildum -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions So CA's always return Success. What are the other return values used for? Thank you. For the tip. The problem that I am having now is that it doesn't appear that the CA is getting called. I look in the log and see the message indicated earlier in this thread indicating that the DLL could not be run. Any idea for this? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Thursday, March 10, 2011 12:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You'll want to set a property that can be checked in a condition. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 6:05 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions How does the custom action indicate that the credentials are incorrect? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com] Sent: Wednesday, March 09, 2011 11:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You shouldn't return failure if the credentials are incorrect, if you do so you will get this error. been there, done that... On Mar 10, 2011 6:34 AM, Kevin Burton kev...@buyseasons.com wrote: I read that. Which of the four rules is this violating? I made the warning go away by making the C# CA 'immediate' thus I don't have to have another custom action to remember the property. So I have CustomAction Id=CA_CheckCredentials Return=check Execute=immediate BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And the schedule InstallExecuteSequence Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence But in the verbose log I get: MSI (s) (B8:9C) [22:04:26:415]: Note: 1: 1723 2: CA_CheckCredentials 3: CheckCredentials 4: D:\WINDOWS\Installer\MSI410.tmp Action start 22:04:26: CA_CheckCredentials. MSI (s) (B8:9C) [22:04:26:415]: Product: Bsi WebServices -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp The error says that the DLL cannot be run. Why? I believe I have followed the instructions for writing a managed CA to the tee (though there seems to be some disagreement between the online tutorial http://www.tramontana.co.hu/wix/ and this book). -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, March 09
Re: [WiX-users] C# Custom Action questions
This is where you use the property that the action set. You do not allow the user off of the dialog until they enter credentials that work and the property is set to the value you expect. This way it is up to the installer to exit the install if they do not have the needed information, but you give them all the chances they need to get it right. Mat Skildum -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:38 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions But I want the install to fail. If it continues with the wrong credentials it will try to start services with the wrong credentials. Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Skildum, Mathew [mailto:mathew.skil...@aspect.com] Sent: Thursday, March 10, 2011 12:32 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions In cases where you checking things like credentials you want the actions to return success so that the install does not fail. As it was said, you set a property if the call succeeded and check if the property is set. You use the other return values in those cases where you want the install to fail and not continue such as when updating configuration files or updating anything that the application requires to function. The basic rule of thumb is when in the UI sequence always have actions return success and set properties use in conditional statements. When the action is called in the Execute sequence and it is critical to the success of the product always have the action return success or failure so that the install can fail and rollback when needed. Mat Skildum -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions So CA's always return Success. What are the other return values used for? Thank you. For the tip. The problem that I am having now is that it doesn't appear that the CA is getting called. I look in the log and see the message indicated earlier in this thread indicating that the DLL could not be run. Any idea for this? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Thursday, March 10, 2011 12:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You'll want to set a property that can be checked in a condition. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 6:05 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions How does the custom action indicate that the credentials are incorrect? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com] Sent: Wednesday, March 09, 2011 11:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You shouldn't return failure if the credentials are incorrect, if you do so you will get this error. been there, done that... On Mar 10, 2011 6:34 AM, Kevin Burton kev...@buyseasons.com wrote: I read that. Which of the four rules is this violating? I made the warning go away by making the C# CA 'immediate' thus I don't have to have another custom action to remember the property. So I have CustomAction Id=CA_CheckCredentials Return=check Execute=immediate BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And the schedule InstallExecuteSequence Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence But in the verbose log I get: MSI (s) (B8:9C) [22:04:26:415]: Note: 1: 1723 2: CA_CheckCredentials 3: CheckCredentials 4: D:\WINDOWS\Installer\MSI410.tmp Action start 22:04:26: CA_CheckCredentials. MSI (s) (B8:9C) [22:04:26:415]: Product: Bsi WebServices -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp Error 1723. There is a problem with this Windows Installer package
Re: [WiX-users] C# Custom Action questions
and Kevin, are you sure that attempting to validate will not be treated as a logon failure and put you back to square one? User account validation schemes are often nothing more than an attempt to log on with the supplied credentials. That might be what Context.ValidateCredentials does - I don't know enough about AD and AdsOpenObject() to know if that's what happens. Reflector seems to indicate that's the underlying Win32 call. Phil Wilson -Original Message- From: Skildum, Mathew [mailto:mathew.skil...@aspect.com] Sent: Thursday, March 10, 2011 10:49 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions This is where you use the property that the action set. You do not allow the user off of the dialog until they enter credentials that work and the property is set to the value you expect. This way it is up to the installer to exit the install if they do not have the needed information, but you give them all the chances they need to get it right. Mat Skildum -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:38 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions But I want the install to fail. If it continues with the wrong credentials it will try to start services with the wrong credentials. Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Skildum, Mathew [mailto:mathew.skil...@aspect.com] Sent: Thursday, March 10, 2011 12:32 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions In cases where you checking things like credentials you want the actions to return success so that the install does not fail. As it was said, you set a property if the call succeeded and check if the property is set. You use the other return values in those cases where you want the install to fail and not continue such as when updating configuration files or updating anything that the application requires to function. The basic rule of thumb is when in the UI sequence always have actions return success and set properties use in conditional statements. When the action is called in the Execute sequence and it is critical to the success of the product always have the action return success or failure so that the install can fail and rollback when needed. Mat Skildum -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions So CA's always return Success. What are the other return values used for? Thank you. For the tip. The problem that I am having now is that it doesn't appear that the CA is getting called. I look in the log and see the message indicated earlier in this thread indicating that the DLL could not be run. Any idea for this? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Thursday, March 10, 2011 12:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You'll want to set a property that can be checked in a condition. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 6:05 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions How does the custom action indicate that the credentials are incorrect? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Simon Dahlbacka [mailto:simon.dahlba...@gmail.com] Sent: Wednesday, March 09, 2011 11:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You shouldn't return failure if the credentials are incorrect, if you do so you will get this error. been there, done that... On Mar 10, 2011 6:34 AM, Kevin Burton kev...@buyseasons.com wrote: I read that. Which of the four rules is this violating? I made the warning go away by making the C# CA 'immediate' thus I don't have to have another custom action to remember the property. So I have CustomAction Id=CA_CheckCredentials Return=check Execute=immediate BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And the schedule InstallExecuteSequence Custom Action
Re: [WiX-users] C# Custom Action questions
I am not sure what you mean by square one? Are you saying that the checking of credentials that are invalid will throw an exception that is not caught? First I have to solve the problem that I don't think the CA is being called as evidenced by the snippet of log I posted earlier. Unless the log entry will be suppressed by an exception. But the entry on the log indicates that the DLL could not be run so I don't think I am even getting to that point. Also I get the same error (DLL could not be run) whether I supply the correct credentials or incorrect ones. Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Thursday, March 10, 2011 1:55 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions and Kevin, are you sure that attempting to validate will not be treated as a logon failure and put you back to square one? User account validation schemes are often nothing more than an attempt to log on with the supplied credentials. That might be what Context.ValidateCredentials does - I don't know enough about AD and AdsOpenObject() to know if that's what happens. Reflector seems to indicate that's the underlying Win32 call. Phil Wilson -Original Message- From: Skildum, Mathew [mailto:mathew.skil...@aspect.com] Sent: Thursday, March 10, 2011 10:49 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions This is where you use the property that the action set. You do not allow the user off of the dialog until they enter credentials that work and the property is set to the value you expect. This way it is up to the installer to exit the install if they do not have the needed information, but you give them all the chances they need to get it right. Mat Skildum -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:38 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions But I want the install to fail. If it continues with the wrong credentials it will try to start services with the wrong credentials. Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Skildum, Mathew [mailto:mathew.skil...@aspect.com] Sent: Thursday, March 10, 2011 12:32 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions In cases where you checking things like credentials you want the actions to return success so that the install does not fail. As it was said, you set a property if the call succeeded and check if the property is set. You use the other return values in those cases where you want the install to fail and not continue such as when updating configuration files or updating anything that the application requires to function. The basic rule of thumb is when in the UI sequence always have actions return success and set properties use in conditional statements. When the action is called in the Execute sequence and it is critical to the success of the product always have the action return success or failure so that the install can fail and rollback when needed. Mat Skildum -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions So CA's always return Success. What are the other return values used for? Thank you. For the tip. The problem that I am having now is that it doesn't appear that the CA is getting called. I look in the log and see the message indicated earlier in this thread indicating that the DLL could not be run. Any idea for this? Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Thursday, March 10, 2011 12:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions You'll want to set a property that can be checked in a condition. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 6:05 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions How does the custom action indicate that the credentials are incorrect? Kevin Burton Senior Software Engineer BUYSEASONS
Re: [WiX-users] C# Custom Action questions
This is nothing to do with exceptions. I'm telling you that the act of verifying credentials is a flavor of logon, and that a failure to verify may be treated in exactly the same way as when your service tries to log on with invalid credentials. In other words you can write a bunch of code that tries to verify an account and the result is that the account gets locked out, or you can just go back to what you were doing before and have the service logon failure cause account lockout. I'm saying that this is what you may end up with, so all your code gives you very little advantage, if any at all. You should run your custom action in a program and use an invalid password. Try it a dozen times and see if the account gets locked out. Phil Wilson -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:27 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions I am not sure what you mean by square one? Are you saying that the checking of credentials that are invalid will throw an exception that is not caught? First I have to solve the problem that I don't think the CA is being called as evidenced by the snippet of log I posted earlier. Unless the log entry will be suppressed by an exception. But the entry on the log indicates that the DLL could not be run so I don't think I am even getting to that point. Also I get the same error (DLL could not be run) whether I supply the correct credentials or incorrect ones. Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Thursday, March 10, 2011 1:55 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions and Kevin, are you sure that attempting to validate will not be treated as a logon failure and put you back to square one? User account validation schemes are often nothing more than an attempt to log on with the supplied credentials. That might be what Context.ValidateCredentials does - I don't know enough about AD and AdsOpenObject() to know if that's what happens. Reflector seems to indicate that's the underlying Win32 call. Phil Wilson -Original Message- From: Skildum, Mathew [mailto:mathew.skil...@aspect.com] Sent: Thursday, March 10, 2011 10:49 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions This is where you use the property that the action set. You do not allow the user off of the dialog until they enter credentials that work and the property is set to the value you expect. This way it is up to the installer to exit the install if they do not have the needed information, but you give them all the chances they need to get it right. Mat Skildum -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:38 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions But I want the install to fail. If it continues with the wrong credentials it will try to start services with the wrong credentials. Kevin Burton Senior Software Engineer BUYSEASONS 262-901-2000 Office 262-901-2312 Fax kev...@buyseasons.com -Original Message- From: Skildum, Mathew [mailto:mathew.skil...@aspect.com] Sent: Thursday, March 10, 2011 12:32 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions In cases where you checking things like credentials you want the actions to return success so that the install does not fail. As it was said, you set a property if the call succeeded and check if the property is set. You use the other return values in those cases where you want the install to fail and not continue such as when updating configuration files or updating anything that the application requires to function. The basic rule of thumb is when in the UI sequence always have actions return success and set properties use in conditional statements. When the action is called in the Execute sequence and it is critical to the success of the product always have the action return success or failure so that the install can fail and rollback when needed. Mat Skildum -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Thursday, March 10, 2011 12:21 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions So CA's always return Success. What are the other return values used for? Thank you. For the tip. The problem that I am having now is that it doesn't appear that the CA is getting called. I look in the log and see the message indicated earlier in this thread indicating that the DLL could not be run. Any
Re: [WiX-users] C# Custom Action questions
I can check the credentials with invalid credentials and then I am able to
check the credentials using valid credentials. No lock out. Here is the code:
private static bool CheckCredentials(string userName, string password)
{
bool valid = false;
using(PrincipalContext context = new
PrincipalContext(ContextType.Domain, ASGARD))
{
valid = context.ValidateCredentials(userName, password);
}
return valid;
}
static void Main(string[] args)
{
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, invalid)));
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, valid)));
}
And the output is:
Credentials are False
Credentials are True
Now my biggest problem is that the CA is not getting called.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Thursday, March 10, 2011 3:10 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
This is nothing to do with exceptions. I'm telling you that the act of
verifying credentials is a flavor of logon, and that a failure to verify may
be treated in exactly the same way as when your service tries to log on with
invalid credentials. In other words you can write a bunch of code that tries to
verify an account and the result is that the account gets locked out, or you
can just go back to what you were doing before and have the service logon
failure cause account lockout. I'm saying that this is what you may end up
with, so all your code gives you very little advantage, if any at all.
You should run your custom action in a program and use an invalid password. Try
it a dozen times and see if the account gets locked out.
Phil Wilson
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 12:27 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I am not sure what you mean by square one? Are you saying that the checking
of credentials that are invalid will throw an exception that is not caught?
First I have to solve the problem that I don't think the CA is being called as
evidenced by the snippet of log I posted earlier. Unless the log entry will be
suppressed by an exception. But the entry on the log indicates that the DLL
could not be run so I don't think I am even getting to that point. Also I get
the same error (DLL could not be run) whether I supply the correct credentials
or incorrect ones.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Thursday, March 10, 2011 1:55 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
and Kevin, are you sure that attempting to validate will not be
treated as a logon failure and put you back to square one? User account
validation schemes are often nothing more than an attempt to log on with the
supplied credentials. That might be what Context.ValidateCredentials does - I
don't know enough about AD and AdsOpenObject() to know if that's what happens.
Reflector seems to indicate that's the underlying Win32 call.
Phil Wilson
-Original Message-
From: Skildum, Mathew [mailto:mathew.skil...@aspect.com]
Sent: Thursday, March 10, 2011 10:49 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
This is where you use the property that the action set. You do not allow the
user off of the dialog until they enter credentials that work and the property
is set to the value you expect. This way it is up to the installer to exit the
install if they do not have the needed information, but you give them all the
chances they need to get it right.
Mat Skildum
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 12:38 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
But I want the install to fail. If it continues with the wrong credentials it
will try to start services with the wrong credentials.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Skildum, Mathew [mailto:mathew.skil...@aspect.com]
Sent: Thursday, March 10, 2011 12:32 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
In cases where you checking things like credentials you want the actions to
return success
Re: [WiX-users] C# Custom Action questions
Phil and I both mentioned the potential problem. Run your code for invalid
credentials more than once. Try it about 4-12 times (as suggested by Phil). The
flow for the custom action is the following:
User enters credentials in dialog.
Dialog asks custom action to validate.
Dialog checks validation result property letting the user know if the password
was valid or invalid.
Suppose that a user incorrect enters invalid credentials enough times... At my
work you only get 3 tries! On the third validation the account is locked out
and the fourth and future attempts all fail regardless of whether the
credentials were valid or not.
Running it once is not enough to verify that this is not the case.
Now, to address the CA running to begin with... Check that the CA is getting
compiled with the correct bitness as required by the target platform. In other
words, are you compiling a 64-bit CA and trying to call it on a 32-bit machine
or vice versa?
If you can post a minimal reproduction (wix source, CA source, etc) of the CA
running problem I can try to reproduce it on my end.
Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 1:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I can check the credentials with invalid credentials and then I am able to
check the credentials using valid credentials. No lock out. Here is the code:
private static bool CheckCredentials(string userName, string password)
{
bool valid = false;
using(PrincipalContext context = new
PrincipalContext(ContextType.Domain, ASGARD))
{
valid = context.ValidateCredentials(userName, password);
}
return valid;
}
static void Main(string[] args)
{
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, invalid)));
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, valid)));
}
And the output is:
Credentials are False
Credentials are True
Now my biggest problem is that the CA is not getting called.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Thursday, March 10, 2011 3:10 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
This is nothing to do with exceptions. I'm telling you that the act of
verifying
credentials is a flavor of logon, and that a failure to verify may be
treated in
exactly the same way as when your service tries to log on with invalid
credentials. In other words you can write a bunch of code that tries to verify
an account and the result is that the account gets locked out, or you can just
go back to what you were doing before and have the service logon failure
cause account lockout. I'm saying that this is what you may end up with, so
all
your code gives you very little advantage, if any at all.
You should run your custom action in a program and use an invalid password.
Try it a dozen times and see if the account gets locked out.
Phil Wilson
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 12:27 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I am not sure what you mean by square one? Are you saying that the
checking of credentials that are invalid will throw an exception that is not
caught?
First I have to solve the problem that I don't think the CA is being called as
evidenced by the snippet of log I posted earlier. Unless the log entry will be
suppressed by an exception. But the entry on the log indicates that the DLL
could not be run so I don't think I am even getting to that point. Also I get
the
same error (DLL could not be run) whether I supply the correct credentials or
incorrect ones.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Thursday, March 10, 2011 1:55 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
and Kevin, are you sure that attempting to validate will not be
treated
as a logon failure and put you back to square one? User account validation
schemes are often nothing more than an attempt to log on with the supplied
credentials. That might be what
Re: [WiX-users] C# Custom Action questions
The same is true here running the validation with invalid credentials 3 or more
times locks the account out. So the user will not get that many tries I will
fail the installation after the first invalid entry. But this is to avoid the
situation where installing and starting the service just once causes the
account to be locked out if invalid credentials are entered.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
Sent: Thursday, March 10, 2011 4:11 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
Phil and I both mentioned the potential problem. Run your code for invalid
credentials more than once. Try it about 4-12 times (as suggested by Phil). The
flow for the custom action is the following:
User enters credentials in dialog.
Dialog asks custom action to validate.
Dialog checks validation result property letting the user know if the password
was valid or invalid.
Suppose that a user incorrect enters invalid credentials enough times... At my
work you only get 3 tries! On the third validation the account is locked out
and the fourth and future attempts all fail regardless of whether the
credentials were valid or not.
Running it once is not enough to verify that this is not the case.
Now, to address the CA running to begin with... Check that the CA is getting
compiled with the correct bitness as required by the target platform. In other
words, are you compiling a 64-bit CA and trying to call it on a 32-bit machine
or vice versa?
If you can post a minimal reproduction (wix source, CA source, etc) of the CA
running problem I can try to reproduce it on my end.
Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
P Please consider the environment before printing this e-mail
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 1:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I can check the credentials with invalid credentials and then I am
able to check the credentials using valid credentials. No lock out. Here is
the code:
private static bool CheckCredentials(string userName, string password)
{
bool valid = false;
using(PrincipalContext context = new
PrincipalContext(ContextType.Domain, ASGARD))
{
valid = context.ValidateCredentials(userName, password);
}
return valid;
}
static void Main(string[] args)
{
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, invalid)));
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, valid)));
}
And the output is:
Credentials are False
Credentials are True
Now my biggest problem is that the CA is not getting called.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Thursday, March 10, 2011 3:10 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
This is nothing to do with exceptions. I'm telling you that the act of
verifying credentials is a flavor of logon, and that a failure to
verify may be treated in exactly the same way as when your service
tries to log on with invalid credentials. In other words you can write
a bunch of code that tries to verify an account and the result is that
the account gets locked out, or you can just go back to what you were
doing before and have the service logon failure cause account lockout.
I'm saying that this is what you may end up with, so all your code gives you
very little advantage, if any at all.
You should run your custom action in a program and use an invalid password.
Try it a dozen times and see if the account gets locked out.
Phil Wilson
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 12:27 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I am not sure what you mean by square one? Are you saying that the
checking of credentials that are invalid will throw an exception that
is not caught?
First I have to solve the problem that I don't think the CA is being
called as evidenced by the snippet of log I posted earlier. Unless the
log entry will be suppressed by an exception. But the entry on the log
indicates that the DLL could not be run so I don't think I am even
getting to that point. Also I get
Re: [WiX-users] C# Custom Action questions
The CA is compile on a 32 bit machine and installed on a 64 bit machine. Is
that a problem? Will not WoW take care of that? It does for the other
assemblies.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
Sent: Thursday, March 10, 2011 4:11 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
Phil and I both mentioned the potential problem. Run your code for invalid
credentials more than once. Try it about 4-12 times (as suggested by Phil). The
flow for the custom action is the following:
User enters credentials in dialog.
Dialog asks custom action to validate.
Dialog checks validation result property letting the user know if the password
was valid or invalid.
Suppose that a user incorrect enters invalid credentials enough times... At my
work you only get 3 tries! On the third validation the account is locked out
and the fourth and future attempts all fail regardless of whether the
credentials were valid or not.
Running it once is not enough to verify that this is not the case.
Now, to address the CA running to begin with... Check that the CA is getting
compiled with the correct bitness as required by the target platform. In other
words, are you compiling a 64-bit CA and trying to call it on a 32-bit machine
or vice versa?
If you can post a minimal reproduction (wix source, CA source, etc) of the CA
running problem I can try to reproduce it on my end.
Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
P Please consider the environment before printing this e-mail
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 1:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I can check the credentials with invalid credentials and then I am
able to check the credentials using valid credentials. No lock out. Here is
the code:
private static bool CheckCredentials(string userName, string password)
{
bool valid = false;
using(PrincipalContext context = new
PrincipalContext(ContextType.Domain, ASGARD))
{
valid = context.ValidateCredentials(userName, password);
}
return valid;
}
static void Main(string[] args)
{
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, invalid)));
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, valid)));
}
And the output is:
Credentials are False
Credentials are True
Now my biggest problem is that the CA is not getting called.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Thursday, March 10, 2011 3:10 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
This is nothing to do with exceptions. I'm telling you that the act of
verifying credentials is a flavor of logon, and that a failure to
verify may be treated in exactly the same way as when your service
tries to log on with invalid credentials. In other words you can write
a bunch of code that tries to verify an account and the result is that
the account gets locked out, or you can just go back to what you were
doing before and have the service logon failure cause account lockout.
I'm saying that this is what you may end up with, so all your code gives you
very little advantage, if any at all.
You should run your custom action in a program and use an invalid password.
Try it a dozen times and see if the account gets locked out.
Phil Wilson
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 12:27 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I am not sure what you mean by square one? Are you saying that the
checking of credentials that are invalid will throw an exception that
is not caught?
First I have to solve the problem that I don't think the CA is being
called as evidenced by the snippet of log I posted earlier. Unless the
log entry will be suppressed by an exception. But the entry on the log
indicates that the DLL could not be run so I don't think I am even
getting to that point. Also I get the same error (DLL could not be
run) whether I supply the correct credentials or incorrect ones.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
Re: [WiX-users] C# Custom Action questions
When I was at Continental Airlines we had an application that I had to
distribute where the service used a service account. For reasons never
determined ( aka damn service account ) something out there would periodically
lock the account and group policy would have it unlocked 10 minutes later.
One of the worst dependencies I ever had to take. It wasn't fun.
---
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves
attention? E-Mail Me
- Original Message
From: Castro, Edwin G. (Hillsboro) edwin.cas...@fiserv.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Thu, March 10, 2011 4:11:13 PM
Subject: Re: [WiX-users] C# Custom Action questions
Phil and I both mentioned the potential problem. Run your code for invalid
credentials more than once. Try it about 4-12 times (as suggested by Phil). The
flow for the custom action is the following:
User enters credentials in dialog.
Dialog asks custom action to validate.
Dialog checks validation result property letting the user know if the password
was valid or invalid.
Suppose that a user incorrect enters invalid credentials enough times... At my
work you only get 3 tries! On the third validation the account is locked out
and
the fourth and future attempts all fail regardless of whether the credentials
were valid or not.
Running it once is not enough to verify that this is not the case.
Now, to address the CA running to begin with... Check that the CA is getting
compiled with the correct bitness as required by the target platform. In other
words, are you compiling a 64-bit CA and trying to call it on a 32-bit machine
or vice versa?
If you can post a minimal reproduction (wix source, CA source, etc) of the CA
running problem I can try to reproduce it on my end.
Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 1:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I can check the credentials with invalid credentials and then I am able to
check the credentials using valid credentials. No lock out. Here is the code:
private static bool CheckCredentials(string userName, string password)
{
bool valid = false;
using(PrincipalContext context = new
PrincipalContext(ContextType.Domain, ASGARD))
{
valid = context.ValidateCredentials(userName, password);
}
return valid;
}
static void Main(string[] args)
{
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, invalid)));
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, valid)));
}
And the output is:
Credentials are False
Credentials are True
Now my biggest problem is that the CA is not getting called.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Thursday, March 10, 2011 3:10 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
This is nothing to do with exceptions. I'm telling you that the act of
verifying
credentials is a flavor of logon, and that a failure to verify may be
treated
in
exactly the same way as when your service tries to log on with invalid
credentials. In other words you can write a bunch of code that tries to verify
an account and the result is that the account gets locked out, or you can just
go back to what you were doing before and have the service logon failure
cause account lockout. I'm saying that this is what you may end up with, so
all
your code gives you very little advantage, if any at all.
You should run your custom action in a program and use an invalid password.
Try it a dozen times and see if the account gets locked out.
Phil Wilson
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 12:27 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I am not sure what you mean by square one? Are you saying that the
checking of credentials that are invalid will throw an exception that is not
caught?
First I have to solve the problem that I don't think the CA is being called as
evidenced by the snippet of log I posted earlier. Unless the log entry will be
suppressed by an exception. But the entry on the log indicates that the DLL
could not be run so I don't
Re: [WiX-users] C# Custom Action questions
Hi Kevin
I think your error that it can't find the CA is in the call
private static bool CheckCredentials
Should be something like:
[CustomAction]
public static ActionResult CheckCredentials(Session session)
The class it is a member of also needs to be public.
Note you need to get the credentials out of properties.
Michael
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Friday, 11 March 2011 8:41 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I hear you. Where I work there is already considerable skepticism on the
installation package and anything that goes wrong is blamed on the installation
so when the installation locks the account (because of bad credentials) there
is a call to not use any deployment and go to copy deployment because of
similar mysteries. If I can avoid the account lockout with a CA that would
sweep the problem under the rug at least for now.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: Thursday, March 10, 2011 4:24 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
When I was at Continental Airlines we had an application that I had to
distribute where the service used a service account. For reasons never
determined ( aka damn service account ) something out there would periodically
lock the account and group policy would have it unlocked 10 minutes later.
One of the worst dependencies I ever had to take. It wasn't fun.
---
Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know
a secret or read a really good thread that deserves attention? E-Mail Me
- Original Message
From: Castro, Edwin G. (Hillsboro) edwin.cas...@fiserv.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Thu, March 10, 2011 4:11:13 PM
Subject: Re: [WiX-users] C# Custom Action questions
Phil and I both mentioned the potential problem. Run your code for invalid
credentials more than once. Try it about 4-12 times (as suggested by Phil). The
flow for the custom action is the following:
User enters credentials in dialog.
Dialog asks custom action to validate.
Dialog checks validation result property letting the user know if the password
was valid or invalid.
Suppose that a user incorrect enters invalid credentials enough times... At my
work you only get 3 tries! On the third validation the account is locked out and
the fourth and future attempts all fail regardless of whether the credentials
were valid or not.
Running it once is not enough to verify that this is not the case.
Now, to address the CA running to begin with... Check that the CA is getting
compiled with the correct bitness as required by the target platform. In other
words, are you compiling a 64-bit CA and trying to call it on a 32-bit machine
or vice versa?
If you can post a minimal reproduction (wix source, CA source, etc) of the CA
running problem I can try to reproduce it on my end.
Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
P Please consider the environment before printing this e-mail
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 1:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I can check the credentials with invalid credentials and then I am able to
check the credentials using valid credentials. No lock out. Here is the code:
private static bool CheckCredentials(string userName, string password)
{
bool valid = false;
using(PrincipalContext context = new
PrincipalContext(ContextType.Domain, ASGARD))
{
valid = context.ValidateCredentials(userName, password);
}
return valid;
}
static void Main(string[] args)
{
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, invalid)));
Debug.WriteLine(string.Format(Credentials are {0},
CheckCredentials(user, valid)));
}
And the output is:
Credentials are False
Credentials are True
Now my biggest problem is that the CA is not getting called.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com]
Sent: Thursday, March 10, 2011 3:10 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
This is nothing to do with exceptions. I'm telling you
Re: [WiX-users] C# Custom Action questions
Thank you Michael,
I tried
public class CustomActions
{
private static int checkCount = 1;
[CustomAction]
public static ActionResult CheckCredentials(Session session)
{
With the same error in the log file. It seems more related to the assembly than
the scope of the method. The error indicates that the DLL could not be run. I
don't think the process has even gotten to the point of looking for the member.
Something is wrong with the DLL that is produced by the custom action project
that is integrated with Visual Studio.
I think the issue that the .msi is compiled and built (and the CA project) in a
32 bit environment and the .msi is installing to a 64-bit environment may be
more of the problem. Although I am not sure how to tackle it if this is indeed
the problem. So the binary element that makes the DLL part of the .msi maybe
needs to know about the bited-ness: of the source and target. All of this is
just supposition as I am a relative beginner with WiX.
-Original Message-
From: Michael Osmond [mailto:mosm...@baytech.com.au]
Sent: Thursday, March 10, 2011 5:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
Hi Kevin
I think your error that it can't find the CA is in the call
private static bool CheckCredentials
Should be something like:
[CustomAction]
public static ActionResult CheckCredentials(Session session)
The class it is a member of also needs to be public.
Note you need to get the credentials out of properties.
Michael
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Friday, 11 March 2011 8:41 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I hear you. Where I work there is already considerable skepticism on the
installation package and anything that goes wrong is blamed on the installation
so when the installation locks the account (because of bad credentials) there
is a call to not use any deployment and go to copy deployment because of
similar mysteries. If I can avoid the account lockout with a CA that would
sweep the problem under the rug at least for now.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: Thursday, March 10, 2011 4:24 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
When I was at Continental Airlines we had an application that I had to
distribute where the service used a service account. For reasons never
determined ( aka damn service account ) something out there would periodically
lock the account and group policy would have it unlocked 10 minutes later.
One of the worst dependencies I ever had to take. It wasn't fun.
---
Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know
a secret or read a really good thread that deserves attention? E-Mail Me
- Original Message
From: Castro, Edwin G. (Hillsboro) edwin.cas...@fiserv.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Thu, March 10, 2011 4:11:13 PM
Subject: Re: [WiX-users] C# Custom Action questions
Phil and I both mentioned the potential problem. Run your code for invalid
credentials more than once. Try it about 4-12 times (as suggested by Phil). The
flow for the custom action is the following:
User enters credentials in dialog.
Dialog asks custom action to validate.
Dialog checks validation result property letting the user know if the password
was valid or invalid.
Suppose that a user incorrect enters invalid credentials enough times... At my
work you only get 3 tries! On the third validation the account is locked out
and the fourth and future attempts all fail regardless of whether the
credentials were valid or not.
Running it once is not enough to verify that this is not the case.
Now, to address the CA running to begin with... Check that the CA is getting
compiled with the correct bitness as required by the target platform. In other
words, are you compiling a 64-bit CA and trying to call it on a 32-bit machine
or vice versa?
If you can post a minimal reproduction (wix source, CA source, etc) of the CA
running problem I can try to reproduce it on my end.
Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
P Please consider the environment before printing this e-mail
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Thursday, March 10, 2011 1:51 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I can check the credentials with invalid
Re: [WiX-users] C# Custom Action questions
I think I hit something like that. Try building the CA with AnyCPU as the
platform rather than 32/64
I have got that error when I forgot the public on the class, though
Regards
Michael
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Friday, 11 March 2011 12:05 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
Thank you Michael,
I tried
public class CustomActions
{
private static int checkCount = 1;
[CustomAction]
public static ActionResult CheckCredentials(Session session)
{
With the same error in the log file. It seems more related to the assembly than
the scope of the method. The error indicates that the DLL could not be run. I
don't think the process has even gotten to the point of looking for the member.
Something is wrong with the DLL that is produced by the custom action project
that is integrated with Visual Studio.
I think the issue that the .msi is compiled and built (and the CA project) in a
32 bit environment and the .msi is installing to a 64-bit environment may be
more of the problem. Although I am not sure how to tackle it if this is indeed
the problem. So the binary element that makes the DLL part of the .msi maybe
needs to know about the bited-ness: of the source and target. All of this is
just supposition as I am a relative beginner with WiX.
-Original Message-
From: Michael Osmond [mailto:mosm...@baytech.com.au]
Sent: Thursday, March 10, 2011 5:08 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
Hi Kevin
I think your error that it can't find the CA is in the call
private static bool CheckCredentials
Should be something like:
[CustomAction]
public static ActionResult CheckCredentials(Session session)
The class it is a member of also needs to be public.
Note you need to get the credentials out of properties.
Michael
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Friday, 11 March 2011 8:41 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I hear you. Where I work there is already considerable skepticism on the
installation package and anything that goes wrong is blamed on the installation
so when the installation locks the account (because of bad credentials) there
is a call to not use any deployment and go to copy deployment because of
similar mysteries. If I can avoid the account lockout with a CA that would
sweep the problem under the rug at least for now.
Kevin Burton
Senior Software Engineer
BUYSEASONS
262-901-2000 Office
262-901-2312 Fax
kev...@buyseasons.com
-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: Thursday, March 10, 2011 4:24 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
When I was at Continental Airlines we had an application that I had to
distribute where the service used a service account. For reasons never
determined ( aka damn service account ) something out there would periodically
lock the account and group policy would have it unlocked 10 minutes later.
One of the worst dependencies I ever had to take. It wasn't fun.
---
Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know
a secret or read a really good thread that deserves attention? E-Mail Me
- Original Message
From: Castro, Edwin G. (Hillsboro) edwin.cas...@fiserv.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Thu, March 10, 2011 4:11:13 PM
Subject: Re: [WiX-users] C# Custom Action questions
Phil and I both mentioned the potential problem. Run your code for invalid
credentials more than once. Try it about 4-12 times (as suggested by Phil). The
flow for the custom action is the following:
User enters credentials in dialog.
Dialog asks custom action to validate.
Dialog checks validation result property letting the user know if the password
was valid or invalid.
Suppose that a user incorrect enters invalid credentials enough times... At my
work you only get 3 tries! On the third validation the account is locked out
and the fourth and future attempts all fail regardless of whether the
credentials were valid or not.
Running it once is not enough to verify that this is not the case.
Now, to address the CA running to begin with... Check that the CA is getting
compiled with the correct bitness as required by the target platform. In other
words, are you compiling a 64-bit CA and trying to call it on a 32-bit machine
or vice versa?
If you can post a minimal reproduction (wix source, CA source, etc) of the CA
running problem I can try to reproduce it on my end.
Edwin G. Castro
Software Developer - Staff
Electronic Banking
[WiX-users] C# Custom Action questions
I have a very simple C# Custom Action that is supposed to verify credentials:
using Microsoft.Deployment.WindowsInstaller;
namespace BuySeasons.BsiServices.Install
{
public class CustomActions
{
[CustomAction]
public static ActionResult CheckCredentials(Session session)
{
session.Log(string.Format(Begin CheckCredentials - {0}/{1},
session[SERVICEUSER], session[SERVICEPASSWORD]));
bool valid = false;
using (PrincipalContext context = new
PrincipalContext(ContextType.Domain, ASGARD))
{
valid = context.ValidateCredentials(session[SERVICEUSER],
session[SERVICEPASSWORD]);
}
if(valid)
return ActionResult.Success;
else
return ActionResult.Failure;
}
}
}
It is included in the WiX Product as
Binary Id=CustomActionsDLL
SourceFile=C:\Projects\\bin\$(var.Configuration)\BrainCustomActions.CA.dll
/
CustomAction Id=CA_CheckCredentials
Return=check
Execute=deferred
BinaryKey=CustomActionsDLL
DllEntry=CheckCredentials/
And scheduled as:
InstallExecuteSequence
Custom Action=CA_CheckCredentials After=InstallInitialize /
/InstallExecuteSequence
This all compiles to a .msi without error. I can see CA_CheckCredentials in
Orca just where I want it. But it doesn't seem to be called. I look at the
verbose log and the closest reference I see is:
Action start 14:56:05: InstallInitialize.
MSI (s) (B0:4C) [14:56:06:052]: Doing action: CA_CheckCredentials
MSI (s) (B0:4C) [14:56:06:052]: Note: 1: 2205 2: 3: ActionText
I don't see the string 'Begin CheckCredentials' as in the code above. What do
you think I have done wrong?
--
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
If I had to guess you calling this CA as a ControlEvent off a Dialog / Control
in your UI sequence. Am I correct? If so, it's a known issue that Msi lacks
the ability to process messages in this scenario. The workaround is to set a
dummy property to see a PROPERTY CHANGED message in the log file where
the value is the data you are trying to log.
Chris
---
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves
attention? E-Mail Me
- Original Message
From: Kevin Burton kev...@buyseasons.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Wed, March 9, 2011 3:24:17 PM
Subject: [WiX-users] C# Custom Action questions
I have a very simple C# Custom Action that is supposed to verify credentials:
using Microsoft.Deployment.WindowsInstaller;
namespace BuySeasons.BsiServices.Install
{
public class CustomActions
{
[CustomAction]
public static ActionResult CheckCredentials(Session session)
{
session.Log(string.Format(Begin CheckCredentials - {0}/{1},
session[SERVICEUSER], session[SERVICEPASSWORD]));
bool valid = false;
using (PrincipalContext context = new
PrincipalContext(ContextType.Domain, ASGARD))
{
valid = context.ValidateCredentials(session[SERVICEUSER],
session[SERVICEPASSWORD]);
}
if(valid)
return ActionResult.Success;
else
return ActionResult.Failure;
}
}
}
It is included in the WiX Product as
Binary Id=CustomActionsDLL
SourceFile=C:\Projects\\bin\$(var.Configuration)\BrainCustomActions.CA.dll
/
CustomAction Id=CA_CheckCredentials
Return=check
Execute=deferred
BinaryKey=CustomActionsDLL
DllEntry=CheckCredentials/
And scheduled as:
InstallExecuteSequence
Custom Action=CA_CheckCredentials After=InstallInitialize /
/InstallExecuteSequence
This all compiles to a .msi without error. I can see CA_CheckCredentials in
Orca
just where I want it. But it doesn't seem to be called. I look at the verbose
log and the closest reference I see is:
Action start 14:56:05: InstallInitialize.
MSI (s) (B0:4C) [14:56:06:052]: Doing action: CA_CheckCredentials
MSI (s) (B0:4C) [14:56:06:052]: Note: 1: 2205 2: 3: ActionText
I don't see the string 'Begin CheckCredentials' as in the code above. What do
you think I have done wrong?
--
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 think I have solved this problem. The CA was scheduled in the
InstallExecuteSequence and was marked as 'deferred' so I created the following
'Custom Data'.
CustomAction Id=SetProperty Property=CA_CheckCredentials
Value=[SERVICEUSER],[SERVICEPASSWORD] /
CustomAction Id=CA_CheckCredentials
Return=check
Execute=deferred
BinaryKey=CustomActionsDLL
DllEntry=CheckCredentials/
And scheduled it like (I am trying to follow the instructions on page 133 of
'WiX: A Developer's Guide to Windows Installer XML' by Nick Ramirez)
InstallExecuteSequence
Custom Action=SetProperty Before=CA_CheckCredentials /
Custom Action=CA_CheckCredentials After=InstallInitialize /
/InstallExecuteSequence
Now I get the ICE warning:
warning LGHT1076: ICE63: Some action falls between InstallInitialize and
RemoveExistingProducts.
Is this a bad warning? I don't completely understand why this scheduling is
bad. I would like to know that the credentials are bad *before* the existing
products are removed.
If I look at the .msi generated with Orca I see that in the
InstallExecuteSequence table
InstallInitialize 1500
SetProperty 1501
CA_CheckCredentials1502
RemoveExistingProducts 1503
This seems like a valid sequence to me but I am obviously missing something as
the warning is there for a purpose.
-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: Wednesday, March 09, 2011 3:30 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
If I had to guess you calling this CA as a ControlEvent off a Dialog / Control
in your UI sequence. Am I correct? If so, it's a known issue that Msi lacks
the ability to process messages in this scenario. The workaround is to set a
dummy property to see a PROPERTY CHANGED message in the log file where
the value is the data you are trying to log.
Chris
---
Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know
a secret or read a really good thread that deserves attention? E-Mail Me
- Original Message
From: Kevin Burton kev...@buyseasons.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Wed, March 9, 2011 3:24:17 PM
Subject: [WiX-users] C# Custom Action questions
I have a very simple C# Custom Action that is supposed to verify credentials:
using Microsoft.Deployment.WindowsInstaller;
namespace BuySeasons.BsiServices.Install
{
public class CustomActions
{
[CustomAction]
public static ActionResult CheckCredentials(Session session)
{
session.Log(string.Format(Begin CheckCredentials - {0}/{1},
session[SERVICEUSER], session[SERVICEPASSWORD]));
bool valid = false;
using (PrincipalContext context = new
PrincipalContext(ContextType.Domain, ASGARD))
{
valid = context.ValidateCredentials(session[SERVICEUSER],
session[SERVICEPASSWORD]);
}
if(valid)
return ActionResult.Success;
else
return ActionResult.Failure;
}
}
}
It is included in the WiX Product as
Binary Id=CustomActionsDLL
SourceFile=C:\Projects\\bin\$(var.Configuration)\BrainCustomActions.CA.dll
/
CustomAction Id=CA_CheckCredentials
Return=check
Execute=deferred
BinaryKey=CustomActionsDLL
DllEntry=CheckCredentials/
And scheduled as:
InstallExecuteSequence
Custom Action=CA_CheckCredentials After=InstallInitialize /
/InstallExecuteSequence
This all compiles to a .msi without error. I can see CA_CheckCredentials in
Orca
just where I want it. But it doesn't seem to be called. I look at the verbose
log and the closest reference I see is:
Action start 14:56:05: InstallInitialize.
MSI (s) (B0:4C) [14:56:06:052]: Doing action: CA_CheckCredentials
MSI (s) (B0:4C) [14:56:06:052]: Note: 1: 2205 2: 3: ActionText
I don't see the string 'Begin CheckCredentials' as in the code above. What do
you think I have done wrong?
--
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
Re: [WiX-users] C# Custom Action questions
ICE63 - http://msdn.microsoft.com/en-us/library/aa369008.aspx
Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail
-Original Message-
From: Kevin Burton [mailto:kev...@buyseasons.com]
Sent: Wednesday, March 09, 2011 2:15 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
I think I have solved this problem. The CA was scheduled in the
InstallExecuteSequence and was marked as 'deferred' so I created the
following 'Custom Data'.
CustomAction Id=SetProperty Property=CA_CheckCredentials
Value=[SERVICEUSER],[SERVICEPASSWORD] /
CustomAction Id=CA_CheckCredentials
Return=check
Execute=deferred
BinaryKey=CustomActionsDLL
DllEntry=CheckCredentials/
And scheduled it like (I am trying to follow the instructions on page 133 of
'WiX: A Developer's Guide to Windows Installer XML' by Nick Ramirez)
InstallExecuteSequence
Custom Action=SetProperty Before=CA_CheckCredentials /
Custom Action=CA_CheckCredentials After=InstallInitialize /
/InstallExecuteSequence
Now I get the ICE warning:
warning LGHT1076: ICE63: Some action falls between InstallInitialize and
RemoveExistingProducts.
Is this a bad warning? I don't completely understand why this scheduling is
bad. I would like to know that the credentials are bad *before* the existing
products are removed.
If I look at the .msi generated with Orca I see that in the
InstallExecuteSequence table
InstallInitialize 1500
SetProperty 1501
CA_CheckCredentials1502
RemoveExistingProducts 1503
This seems like a valid sequence to me but I am obviously missing something
as the warning is there for a purpose.
-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: Wednesday, March 09, 2011 3:30 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action questions
If I had to guess you calling this CA as a ControlEvent off a Dialog /
Control in
your UI sequence. Am I correct? If so, it's a known issue that Msi lacks the
ability to process messages in this scenario. The workaround is to set a
dummy property to see a PROPERTY CHANGED message in the log file
where the value is the data you are trying to log.
Chris
---
Christopher Painter, Author of Deployment Engineering Blog Have a hot tip,
know a secret or read a really good thread that deserves attention? E-Mail
Me
- Original Message
From: Kevin Burton kev...@buyseasons.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Wed, March 9, 2011 3:24:17 PM
Subject: [WiX-users] C# Custom Action questions
I have a very simple C# Custom Action that is supposed to verify credentials:
using Microsoft.Deployment.WindowsInstaller;
namespace BuySeasons.BsiServices.Install {
public class CustomActions
{
[CustomAction]
public static ActionResult CheckCredentials(Session session)
{
session.Log(string.Format(Begin CheckCredentials - {0}/{1},
session[SERVICEUSER], session[SERVICEPASSWORD]));
bool valid = false;
using (PrincipalContext context = new
PrincipalContext(ContextType.Domain, ASGARD))
{
valid = context.ValidateCredentials(session[SERVICEUSER],
session[SERVICEPASSWORD]);
}
if(valid)
return ActionResult.Success;
else
return ActionResult.Failure;
}
}
}
It is included in the WiX Product as
Binary Id=CustomActionsDLL
SourceFile=C:\Projects\\bin\$(var.Configuration)\BrainCustomActions.C
A.dll
/
CustomAction Id=CA_CheckCredentials
Return=check
Execute=deferred
BinaryKey=CustomActionsDLL
DllEntry=CheckCredentials/
And scheduled as:
InstallExecuteSequence
Custom Action=CA_CheckCredentials After=InstallInitialize /
/InstallExecuteSequence
This all compiles to a .msi without error. I can see CA_CheckCredentials in
Orca just where I want it. But it doesn't seem to be called. I look at the
verbose log and the closest reference I see is:
Action start 14:56:05: InstallInitialize.
MSI (s) (B0:4C) [14:56:06:052]: Doing action: CA_CheckCredentials MSI (s)
(B0:4C) [14:56:06:052]: Note: 1: 2205 2: 3: ActionText
I don't see the string 'Begin CheckCredentials' as in the code above. What do
you think I have done wrong?
--
Colocation vs. Managed Hosting
Re: [WiX-users] C# Custom Action questions
I read that. Which of the four rules is this violating? I made the warning go away by making the C# CA 'immediate' thus I don't have to have another custom action to remember the property. So I have CustomAction Id=CA_CheckCredentials Return=check Execute=immediate BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And the schedule InstallExecuteSequence Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence But in the verbose log I get: MSI (s) (B8:9C) [22:04:26:415]: Note: 1: 1723 2: CA_CheckCredentials 3: CheckCredentials 4: D:\WINDOWS\Installer\MSI410.tmp Action start 22:04:26: CA_CheckCredentials. MSI (s) (B8:9C) [22:04:26:415]: Product: Bsi WebServices -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp The error says that the DLL cannot be run. Why? I believe I have followed the instructions for writing a managed CA to the tee (though there seems to be some disagreement between the online tutorial http://www.tramontana.co.hu/wix/ and this book). -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, March 09, 2011 5:26 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions ICE63 - http://msdn.microsoft.com/en-us/library/aa369008.aspx Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Wednesday, March 09, 2011 2:15 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions I think I have solved this problem. The CA was scheduled in the InstallExecuteSequence and was marked as 'deferred' so I created the following 'Custom Data'. CustomAction Id=SetProperty Property=CA_CheckCredentials Value=[SERVICEUSER],[SERVICEPASSWORD] / CustomAction Id=CA_CheckCredentials Return=check Execute=deferred BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And scheduled it like (I am trying to follow the instructions on page 133 of 'WiX: A Developer's Guide to Windows Installer XML' by Nick Ramirez) InstallExecuteSequence Custom Action=SetProperty Before=CA_CheckCredentials / Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence Now I get the ICE warning: warning LGHT1076: ICE63: Some action falls between InstallInitialize and RemoveExistingProducts. Is this a bad warning? I don't completely understand why this scheduling is bad. I would like to know that the credentials are bad *before* the existing products are removed. If I look at the .msi generated with Orca I see that in the InstallExecuteSequence table InstallInitialize 1500 SetProperty 1501 CA_CheckCredentials1502 RemoveExistingProducts 1503 This seems like a valid sequence to me but I am obviously missing something as the warning is there for a purpose. -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Wednesday, March 09, 2011 3:30 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions If I had to guess you calling this CA as a ControlEvent off a Dialog / Control in your UI sequence. Am I correct? If so, it's a known issue that Msi lacks the ability to process messages in this scenario. The workaround is to set a dummy property to see a PROPERTY CHANGED message in the log file where the value is the data you are trying to log. Chris --- Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me - Original Message From: Kevin Burton kev...@buyseasons.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, March 9, 2011 3:24:17 PM Subject: [WiX-users] C# Custom Action questions I have a very simple C# Custom Action that is supposed to verify credentials: using
Re: [WiX-users] C# Custom Action questions
You shouldn't return failure if the credentials are incorrect, if you do so you will get this error. been there, done that... On Mar 10, 2011 6:34 AM, Kevin Burton kev...@buyseasons.com wrote: I read that. Which of the four rules is this violating? I made the warning go away by making the C# CA 'immediate' thus I don't have to have another custom action to remember the property. So I have CustomAction Id=CA_CheckCredentials Return=check Execute=immediate BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And the schedule InstallExecuteSequence Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence But in the verbose log I get: MSI (s) (B8:9C) [22:04:26:415]: Note: 1: 1723 2: CA_CheckCredentials 3: CheckCredentials 4: D:\WINDOWS\Installer\MSI410.tmp Action start 22:04:26: CA_CheckCredentials. MSI (s) (B8:9C) [22:04:26:415]: Product: Bsi WebServices -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action CA_CheckCredentials, entry: CheckCredentials, library: D:\WINDOWS\Installer\MSI410.tmp The error says that the DLL cannot be run. Why? I believe I have followed the instructions for writing a managed CA to the tee (though there seems to be some disagreement between the online tutorial http://www.tramontana.co.hu/wix/ and this book). -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, March 09, 2011 5:26 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions ICE63 - http://msdn.microsoft.com/en-us/library/aa369008.aspx Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: Kevin Burton [mailto:kev...@buyseasons.com] Sent: Wednesday, March 09, 2011 2:15 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions I think I have solved this problem. The CA was scheduled in the InstallExecuteSequence and was marked as 'deferred' so I created the following 'Custom Data'. CustomAction Id=SetProperty Property=CA_CheckCredentials Value=[SERVICEUSER],[SERVICEPASSWORD] / CustomAction Id=CA_CheckCredentials Return=check Execute=deferred BinaryKey=CustomActionsDLL DllEntry=CheckCredentials/ And scheduled it like (I am trying to follow the instructions on page 133 of 'WiX: A Developer's Guide to Windows Installer XML' by Nick Ramirez) InstallExecuteSequence Custom Action=SetProperty Before=CA_CheckCredentials / Custom Action=CA_CheckCredentials After=InstallInitialize / /InstallExecuteSequence Now I get the ICE warning: warning LGHT1076: ICE63: Some action falls between InstallInitialize and RemoveExistingProducts. Is this a bad warning? I don't completely understand why this scheduling is bad. I would like to know that the credentials are bad *before* the existing products are removed. If I look at the .msi generated with Orca I see that in the InstallExecuteSequence table InstallInitialize 1500 SetProperty 1501 CA_CheckCredentials 1502 RemoveExistingProducts 1503 This seems like a valid sequence to me but I am obviously missing something as the warning is there for a purpose. -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Wednesday, March 09, 2011 3:30 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] C# Custom Action questions If I had to guess you calling this CA as a ControlEvent off a Dialog / Control in your UI sequence. Am I correct? If so, it's a known issue that Msi lacks the ability to process messages in this scenario. The workaround is to set a dummy property to see a PROPERTY CHANGED message in the log file where the value is the data you are trying to log. Chris --- Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me - Original Message From: Kevin Burton kev...@buyseasons.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, March 9, 2011 3:24:17 PM Subject: [WiX-users] C# Custom Action questions I have a very simple C# Custom Action that is supposed to verify credentials: using Microsoft.Deployment.WindowsInstaller; namespace BuySeasons.BsiServices.Install
