Re: [WiX-users] Managed Custom Action which call win 32 dll, possible?
Thanks. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Managed-Custom-Action-which-call-win-32-dll-possible-tp7590295p7590335.html Sent from the wix-users mailing list archive at Nabble.com. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Managed Custom Action which call win 32 dll,possible?
Hi, Is it possible to use MakeSfxCA.exe to add a window 32 dll called by the managed custom action? Thanks in advance -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Managed-Custom-Action-which-call-win-32-dll-possible-tp7590295.html Sent from the wix-users mailing list archive at Nabble.com. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed Custom Action which call win 32 dll, possible?
Just add it to the MakeSfxCA.exe commandline. It will be packaged into the *.CA.dll file and extracted with the managed assembly at runtime. If building from a *proj file using the wix.ca.targets file, you can use the CustomActionContents property to add files to your CA's payload. Date: Tue, 5 Nov 2013 12:02:21 -0800 From: tomer.d...@intergraph.com To: wix-users@lists.sourceforge.net Subject: [WiX-users] Managed Custom Action which call win 32 dll,possible? Hi, Is it possible to use MakeSfxCA.exe to add a window 32 dll called by the managed custom action? Thanks in advance -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Managed-Custom-Action-which-call-win-32-dll-possible-tp7590295.html Sent from the wix-users mailing list archive at Nabble.com. -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed Custom Action using CAS
Hi thanks for all the help, I resolved my issue by just reverting the custom action back to .net 2 and specifying the correct framework version in my custom action configuration file. This was the simplest way to support the older installer code. As stated by Jacob there wasn't any reason for the custom action to be on runtime 2 as well, as updating the plugin to use a newer CAS model for newer versions of office was not currently an option. Kind regards, Christoffel le Roux -Original Message- From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Sent: Tuesday, August 28, 2012 7:30 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Managed Custom Action using CAS I've never done one of those myself, but a bit of search engine foo shows a few potential links http://social.msdn.microsoft.com/Forums/eu/vsto/thread/f46b54a0-0fc3-4a76-a47c-aad05e31bb86 , http://social.msdn.microsoft.com/Forums/en/vsto/thread/890cb60c-11f6-4fea-8a44-e520341f3331 , and http://stackoverflow.com/questions/3089567/is-it-possible-to-create-an-office-2003-vsto-add-in-from-visual-studio-2010 . From the second link I find: Different Visual Studio Versions 1. Visual Studio 2010 supports creating VSTO 3.0 and VSTO 4.0 solutions. 2. Visual Studio 2008 supports creating VSTO 2.0 and VSTO 3.0 solutions. - Different VSTO Versions 1. VSTO 2.0 solutions work with Office 2003 and Office 2007 2. VSTO 3.0 solutions work with Office 2007 and Office 2010 - Since you stated you needed an Office 2003 VSTO, I don't think it would be possible to have it using the 4.0 framework (for the addin). As such, what benefit are you getting by upgrading the CA DLL? If you need the old behavior and a new feature then you could have 2 CA DLL's; one targeting 4.0 for the new stuff and one targeting 2.0 for the old CAS calls. If you want to continue to try to get 4.0 to work, then the actual framework call that is failing (the source to CustomAction.GetPolicyLevel ) would be helpful. -Original Message- From: Christoffel le Roux [mailto:christoffe...@tech.flowcentric.com] Sent: Tuesday, August 28, 2012 9:33 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Managed Custom Action using CAS Hi Jacob, Thanks for the reply, I'm installing an office 2003 VSTO project and using the custom action which in turn needs the CAS policy methods to register the DLL as safe to be consumed by Office. Kind regards, Christoffel le Roux -Original Message- From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Sent: Tuesday, August 28, 2012 4:22 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Managed Custom Action using CAS I guess the real question would be do you even need this in .Net 4? http://blogs.msdn.com/b/shawnfa/archive/2010/02/24/so-is-cas-dead-in-net-4-or-what.aspx What is the custom action trying to accomplish with CAS? -Original Message- From: Christoffel le Roux [mailto:christoffe...@tech.flowcentric.com] Sent: Tuesday, August 28, 2012 9:12 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Managed Custom Action using CAS Hi, I have upgraded an old installer to a wix 3.7 custom action project that uses the old CAS policy methods. I've upgraded the solution to runtime 4 and resulted receiving the exception This method explicitly uses CAS policy, which has been obsoleted by the .NET Framework. // Get the policy level. PolicyLevel policyLevel = CustomAction.GetPolicyLevel(SomePolicyLabel); In order to enable CAS policy for compatibility reasons, please use the NetFx40_LegacySecurityPolicy configuration switch. Please see http://go.microsoft.com/fwlink/?LinkID=155570 for more information. Following the link I ended up specifying in the CustomAction.config file to use the legacy CAS method overloads. ?xml version=1.0 encoding=utf-8 ? configuration startup useLegacyV2RuntimeActivationPolicy=true supportedRuntime version=v4.0 sku=.NETFramework,Version=v4.0/ supportedRuntime version=v2.0.50727/ /startup runtime NetFx40_LegacySecurityPolicy enabled=true/ /runtime /configuration I've tried a bunch of things to resolve the issue but with no luck. Any ideas anyone? Thanks in advanced. Kind regards, Christoffel le Roux -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net
[WiX-users] Managed Custom Action using CAS
Hi, I have upgraded an old installer to a wix 3.7 custom action project that uses the old CAS policy methods. I've upgraded the solution to runtime 4 and resulted receiving the exception This method explicitly uses CAS policy, which has been obsoleted by the .NET Framework. // Get the policy level. PolicyLevel policyLevel = CustomAction.GetPolicyLevel(SomePolicyLabel); In order to enable CAS policy for compatibility reasons, please use the NetFx40_LegacySecurityPolicy configuration switch. Please see http://go.microsoft.com/fwlink/?LinkID=155570 for more information. Following the link I ended up specifying in the CustomAction.config file to use the legacy CAS method overloads. ?xml version=1.0 encoding=utf-8 ? configuration startup useLegacyV2RuntimeActivationPolicy=true supportedRuntime version=v4.0 sku=.NETFramework,Version=v4.0/ supportedRuntime version=v2.0.50727/ /startup runtime NetFx40_LegacySecurityPolicy enabled=true/ /runtime /configuration I've tried a bunch of things to resolve the issue but with no luck. Any ideas anyone? Thanks in advanced. Kind regards, Christoffel le Roux -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed Custom Action using CAS
I guess the real question would be do you even need this in .Net 4? http://blogs.msdn.com/b/shawnfa/archive/2010/02/24/so-is-cas-dead-in-net-4-or-what.aspx What is the custom action trying to accomplish with CAS? -Original Message- From: Christoffel le Roux [mailto:christoffe...@tech.flowcentric.com] Sent: Tuesday, August 28, 2012 9:12 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Managed Custom Action using CAS Hi, I have upgraded an old installer to a wix 3.7 custom action project that uses the old CAS policy methods. I've upgraded the solution to runtime 4 and resulted receiving the exception This method explicitly uses CAS policy, which has been obsoleted by the .NET Framework. // Get the policy level. PolicyLevel policyLevel = CustomAction.GetPolicyLevel(SomePolicyLabel); In order to enable CAS policy for compatibility reasons, please use the NetFx40_LegacySecurityPolicy configuration switch. Please see http://go.microsoft.com/fwlink/?LinkID=155570 for more information. Following the link I ended up specifying in the CustomAction.config file to use the legacy CAS method overloads. ?xml version=1.0 encoding=utf-8 ? configuration startup useLegacyV2RuntimeActivationPolicy=true supportedRuntime version=v4.0 sku=.NETFramework,Version=v4.0/ supportedRuntime version=v2.0.50727/ /startup runtime NetFx40_LegacySecurityPolicy enabled=true/ /runtime /configuration I've tried a bunch of things to resolve the issue but with no luck. Any ideas anyone? Thanks in advanced. Kind regards, Christoffel le Roux -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed Custom Action using CAS
Hi Jacob, Thanks for the reply, I'm installing an office 2003 VSTO project and using the custom action which in turn needs the CAS policy methods to register the DLL as safe to be consumed by Office. Kind regards, Christoffel le Roux -Original Message- From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Sent: Tuesday, August 28, 2012 4:22 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Managed Custom Action using CAS I guess the real question would be do you even need this in .Net 4? http://blogs.msdn.com/b/shawnfa/archive/2010/02/24/so-is-cas-dead-in-net-4-or-what.aspx What is the custom action trying to accomplish with CAS? -Original Message- From: Christoffel le Roux [mailto:christoffe...@tech.flowcentric.com] Sent: Tuesday, August 28, 2012 9:12 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Managed Custom Action using CAS Hi, I have upgraded an old installer to a wix 3.7 custom action project that uses the old CAS policy methods. I've upgraded the solution to runtime 4 and resulted receiving the exception This method explicitly uses CAS policy, which has been obsoleted by the .NET Framework. // Get the policy level. PolicyLevel policyLevel = CustomAction.GetPolicyLevel(SomePolicyLabel); In order to enable CAS policy for compatibility reasons, please use the NetFx40_LegacySecurityPolicy configuration switch. Please see http://go.microsoft.com/fwlink/?LinkID=155570 for more information. Following the link I ended up specifying in the CustomAction.config file to use the legacy CAS method overloads. ?xml version=1.0 encoding=utf-8 ? configuration startup useLegacyV2RuntimeActivationPolicy=true supportedRuntime version=v4.0 sku=.NETFramework,Version=v4.0/ supportedRuntime version=v2.0.50727/ /startup runtime NetFx40_LegacySecurityPolicy enabled=true/ /runtime /configuration I've tried a bunch of things to resolve the issue but with no luck. Any ideas anyone? Thanks in advanced. Kind regards, Christoffel le Roux -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed Custom Action using CAS
I've never done one of those myself, but a bit of search engine foo shows a few potential links http://social.msdn.microsoft.com/Forums/eu/vsto/thread/f46b54a0-0fc3-4a76-a47c-aad05e31bb86 , http://social.msdn.microsoft.com/Forums/en/vsto/thread/890cb60c-11f6-4fea-8a44-e520341f3331 , and http://stackoverflow.com/questions/3089567/is-it-possible-to-create-an-office-2003-vsto-add-in-from-visual-studio-2010 . From the second link I find: Different Visual Studio Versions 1. Visual Studio 2010 supports creating VSTO 3.0 and VSTO 4.0 solutions. 2. Visual Studio 2008 supports creating VSTO 2.0 and VSTO 3.0 solutions. - Different VSTO Versions 1. VSTO 2.0 solutions work with Office 2003 and Office 2007 2. VSTO 3.0 solutions work with Office 2007 and Office 2010 - Since you stated you needed an Office 2003 VSTO, I don't think it would be possible to have it using the 4.0 framework (for the addin). As such, what benefit are you getting by upgrading the CA DLL? If you need the old behavior and a new feature then you could have 2 CA DLL's; one targeting 4.0 for the new stuff and one targeting 2.0 for the old CAS calls. If you want to continue to try to get 4.0 to work, then the actual framework call that is failing (the source to CustomAction.GetPolicyLevel ) would be helpful. -Original Message- From: Christoffel le Roux [mailto:christoffe...@tech.flowcentric.com] Sent: Tuesday, August 28, 2012 9:33 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Managed Custom Action using CAS Hi Jacob, Thanks for the reply, I'm installing an office 2003 VSTO project and using the custom action which in turn needs the CAS policy methods to register the DLL as safe to be consumed by Office. Kind regards, Christoffel le Roux -Original Message- From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] Sent: Tuesday, August 28, 2012 4:22 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Managed Custom Action using CAS I guess the real question would be do you even need this in .Net 4? http://blogs.msdn.com/b/shawnfa/archive/2010/02/24/so-is-cas-dead-in-net-4-or-what.aspx What is the custom action trying to accomplish with CAS? -Original Message- From: Christoffel le Roux [mailto:christoffe...@tech.flowcentric.com] Sent: Tuesday, August 28, 2012 9:12 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Managed Custom Action using CAS Hi, I have upgraded an old installer to a wix 3.7 custom action project that uses the old CAS policy methods. I've upgraded the solution to runtime 4 and resulted receiving the exception This method explicitly uses CAS policy, which has been obsoleted by the .NET Framework. // Get the policy level. PolicyLevel policyLevel = CustomAction.GetPolicyLevel(SomePolicyLabel); In order to enable CAS policy for compatibility reasons, please use the NetFx40_LegacySecurityPolicy configuration switch. Please see http://go.microsoft.com/fwlink/?LinkID=155570 for more information. Following the link I ended up specifying in the CustomAction.config file to use the legacy CAS method overloads. ?xml version=1.0 encoding=utf-8 ? configuration startup useLegacyV2RuntimeActivationPolicy=true supportedRuntime version=v4.0 sku=.NETFramework,Version=v4.0/ supportedRuntime version=v2.0.50727/ /startup runtime NetFx40_LegacySecurityPolicy enabled=true/ /runtime /configuration I've tried a bunch of things to resolve the issue but with no luck. Any ideas anyone? Thanks in advanced. Kind regards, Christoffel le Roux -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive
Re: [WiX-users] managed custom action cannot access target directory
Total shot in the dark, but are you declaring the deferred CA Impersonate=No? Otherwise you're running as the calling user, so maybe it's something to do with CAS. dB. @ dblock.org Moscow|Geneva|Seattle|New York -Original Message- From: Adam Langley [mailto:alang...@winscribe.com] Sent: Wednesday, May 05, 2010 11:28 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] managed custom action cannot access target directory I have written a deferred CA which I need to manipulate a file that is placed in the target-directory, at the end of the install. What is weird is that the path is correctly evaluated in my logging messages, but when I use the path to open a file, it says FILE NOT FOUND, even though I KNOW the file is there. I put in some extra logging, to enumerate the contents of the folder to prove that the file DOES exist, and I got this surprising result: CustomActionData: APPCONFIGPATH = C:\Program Files\Company\Client\Client.Windows.exe.config SECTIONTOENCRYPT = secureAppSettings Attempting to load 'C:\Program Files\Company\Client\Client.Windows.exe.config', to encrypt section 'secureAppSettings'. Configuration file 'C:\Program Files\Company\Client\Client.Windows.exe.config' was not found, have you scheduled the CA to execute after files are installed? Enumerating files in 'C:\Windows\assembly\GAC_MSIL\Microsoft.Deployment.WindowsInstaller\3.0. 0.0__ce35f76fcda82bad'... - Microsoft.Deployment.WindowsInstaller.dll As you can see, I am enumerating my target folder, but as soon as I start operating on the filesystem (such as Directory.GetFiles()), the .net runtime resolves all my queries to the GAC path where Microsoft.Deployment.WindowsInstaller.dll lives!!! What is up with that? Why am I being sandboxed like this?? -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] managed custom action cannot access target directory
I have written a deferred CA which I need to manipulate a file that is placed in the target-directory, at the end of the install. What is weird is that the path is correctly evaluated in my logging messages, but when I use the path to open a file, it says FILE NOT FOUND, even though I KNOW the file is there. I put in some extra logging, to enumerate the contents of the folder to prove that the file DOES exist, and I got this surprising result: CustomActionData: APPCONFIGPATH = C:\Program Files\Company\Client\Client.Windows.exe.config SECTIONTOENCRYPT = secureAppSettings Attempting to load 'C:\Program Files\Company\Client\Client.Windows.exe.config', to encrypt section 'secureAppSettings'. Configuration file 'C:\Program Files\Company\Client\Client.Windows.exe.config' was not found, have you scheduled the CA to execute after files are installed? Enumerating files in 'C:\Windows\assembly\GAC_MSIL\Microsoft.Deployment.WindowsInstaller\3.0. 0.0__ce35f76fcda82bad'... - Microsoft.Deployment.WindowsInstaller.dll As you can see, I am enumerating my target folder, but as soon as I start operating on the filesystem (such as Directory.GetFiles()), the .net runtime resolves all my queries to the GAC path where Microsoft.Deployment.WindowsInstaller.dll lives!!! What is up with that? Why am I being sandboxed like this?? -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] managed custom action cannot access target directory
I have written a deferred CA which I need to manipulate a file that is placed in the target-directory, at the end of the install. What is weird is that the path is correctly evaluated in my logging messages, but when I use the path to open a file, it says FILE NOT FOUND, even though I KNOW the file is there. I put in some extra logging, to enumerate the contents of the folder to prove that the file DOES exist, and I got this surprising result: CustomActionData: APPCONFIGPATH = C:\Program Files\Company\Client\Client.Windows.exe.config SECTIONTOENCRYPT = secureAppSettings Attempting to load 'C:\Program Files\Company\Client\Client.Windows.exe.config', to encrypt section 'secureAppSettings'. Configuration file 'C:\Program Files\Company\Client\Client.Windows.exe.config' was not found, have you scheduled the CA to execute after files are installed? Enumerating files in 'C:\Windows\assembly\GAC_MSIL\Microsoft.Deployment.WindowsInstaller\3.0.0.0__ce35f76fcda82bad'... - Microsoft.Deployment.WindowsInstaller.dll As you can see, I am enumerating my target folder, but as soon as I start operating on the filesystem (such as Directory.GetFiles()), the .net runtime resolves all my queries to the GAC path where Microsoft.Deployment.WindowsInstaller.dll lives!!! What is up with that? Why am I being sandboxed like this?? -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] managed custom action cannot access target directory
I found the problem. I had to expand my properties (session.Format(string)) during my immediate CA, so that the deferred CA gets the actual path values, not the path 'tokens'. Adam Langley Please consider the environment before printing this email! -Original Message- From: Adam Langley [mailto:alang...@winscribe.com] Sent: Thursday, 6 May 2010 3:35 p.m. To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] managed custom action cannot access target directory I have written a deferred CA which I need to manipulate a file that is placed in the target-directory, at the end of the install. What is weird is that the path is correctly evaluated in my logging messages, but when I use the path to open a file, it says FILE NOT FOUND, even though I KNOW the file is there. I put in some extra logging, to enumerate the contents of the folder to prove that the file DOES exist, and I got this surprising result: CustomActionData: APPCONFIGPATH = C:\Program Files\Company\Client\Client.Windows.exe.config SECTIONTOENCRYPT = secureAppSettings Attempting to load 'C:\Program Files\Company\Client\Client.Windows.exe.config', to encrypt section 'secureAppSettings'. Configuration file 'C:\Program Files\Company\Client\Client.Windows.exe.config' was not found, have you scheduled the CA to execute after files are installed? Enumerating files in 'C:\Windows\assembly\GAC_MSIL\Microsoft.Deployment.WindowsInstaller\3.0.0.0__ce35f76fcda82bad'... - Microsoft.Deployment.WindowsInstaller.dll As you can see, I am enumerating my target folder, but as soon as I start operating on the filesystem (such as Directory.GetFiles()), the .net runtime resolves all my queries to the GAC path where Microsoft.Deployment.WindowsInstaller.dll lives!!! What is up with that? Why am I being sandboxed like this?? -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed Custom Action using InstallUtilLib.dll
In article [EMAIL PROTECTED], Sankaranarayanan [EMAIL PROTECTED] writes: I am using Managed Custom Action [...] What is your custom action doing? The MSDN documentation leads people to believe that they need managed custom actions for all sorts of things that the standard actions and tables already cover. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed Custom Action using InstallUtilLib.dll
I use custom action for the following operations 1) Read XML Config file and set installer properties 2) Install Device Drivers 3) Loading MOF 4) Setting Windows Service privileges 5) Installing .NET Perf Counters. etc... WiX doesn't support these actions by default. Please let know if you have any approach for the following issue : I am using Managed Custom Action as details in http://blogs.msdn.com/josealmeida/archive/2004/11/08/253831.aspx This approach works like a charm but I didn't quite like the idea of packaging InstallUtilLib.dll file in MSI. Is there a way to use the InstallUtilLib.dll present in the client machine instead of packing it in MSI Binary table as follows Binary Id=InstallUtil src=$(var.FrameworkPath)\InstallUtilLib.dll /. (I have a Lauch Condition to check for .NET Framework presence in the client machine). Thanks, Sankaranarayanan MG - Original Message From: Richard [EMAIL PROTECTED] To: WiX Users wix-users@lists.sourceforge.net Cc: [EMAIL PROTECTED] Sent: Tuesday, 30 October, 2007 10:03:10 AM Subject: Re: [WiX-users] Managed Custom Action using InstallUtilLib.dll In article [EMAIL PROTECTED], Sankaranarayanan [EMAIL PROTECTED] writes: I am using Managed Custom Action [...] What is your custom action doing? The MSDN documentation leads people to believe that they need managed custom actions for all sorts of things that the standard actions and tables already cover. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ ___ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed Custom Action using InstallUtilLib.dll
Managed custom actions are officially unsupported by Windows Installer because of the way that the CLR 'taints' the process it loads into. You cannot reliably ensure that the correct CLR version is loaded at the correct time. See Rob's blog post http://robmensching.com/blog/archive/2007/04/19/Managed-Code-CustomActions-n o-support-on-the-way-and-heres.aspx. Yes, it's seriously annoying that the .NET Framework and Visual Studio guide you in the direction of a bad design. The whole Installer hierarchy (and especially ServiceInstaller which duplicates Windows Installer functionality) should be marked Deprecated in my view. What can you do? Unfortunately, the most reliable form of custom actions are native C/C++ DLLs. However, if you can write device drivers I would have thought you could write custom action DLLs. WiX does have support for .NET performance counters in v3 using the PerformanceCategory and PerformanceCounter elements in the Util schema. This is certainly present in build 3304. For v2 you will have to write an appropriate .h and .ini file and use the PerfCounter element. You can use the code for the ParsePerformanceCategoryElement method in v3 - which basically generates the .h and .ini files and dumps them into a custom table - as a template. See src\ext\UtilExtension\UtilCompiler.cs in the source distribution. .NET Framework doesn't provide a way to do this (well, it does, but only if you're prepared to use reflection to invoke it because the members are private). Wix's support currently won't work on NT 4.0 because the APIs LoadPerfCounterTextStrings and UnLoadPerCounterTextStrings are used, not the lodctr.exe program. The APIs were added in Windows 2000. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sankaranarayanan Sent: 30 October 2007 18:36 To: Richard; WiX Users Subject: Re: [WiX-users] Managed Custom Action using InstallUtilLib.dll I use custom action for the following operations 1) Read XML Config file and set installer properties 2) Install Device Drivers 3) Loading MOF 4) Setting Windows Service privileges 5) Installing .NET Perf Counters. etc... WiX doesn't support these actions by default. Please let know if you have any approach for the following issue : I am using Managed Custom Action as details in http://blogs.msdn.com/josealmeida/archive/2004/11/08/253831.aspx This approach works like a charm but I didn't quite like the idea of packaging InstallUtilLib.dll file in MSI. Is there a way to use the InstallUtilLib.dll present in the client machine instead of packing it in MSI Binary table as follows Binary Id=InstallUtil src=$(var.FrameworkPath)\InstallUtilLib.dll /. (I have a Lauch Condition to check for .NET Framework presence in the client machine). Thanks, Sankaranarayanan MG - Original Message From: Richard [EMAIL PROTECTED] To: WiX Users wix-users@lists.sourceforge.net Cc: [EMAIL PROTECTED] Sent: Tuesday, 30 October, 2007 10:03:10 AM Subject: Re: [WiX-users] Managed Custom Action using InstallUtilLib.dll In article [EMAIL PROTECTED], Sankaranarayanan [EMAIL PROTECTED] writes: I am using Managed Custom Action [...] What is your custom action doing? The MSDN documentation leads people to believe that they need managed custom actions for all sorts of things that the standard actions and tables already cover. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ ___ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed Custom Action using InstallUtilLib.dll
In article [EMAIL PROTECTED], Aris Green [EMAIL PROTECTED] writes: I have been using managec C++ CA's coded in Visual Studio 2003 for installs. IMO, you might as well just use native C++ at that point. Well, you get the picture. One wrinkle, the VC 2005 requires linking to the C++ CRT as a DLL when using .NET. You have to use a manifest when linking to the CRT, so if the same exact version that you built against in your CA is not on the target machine, BAM!. You still tattoo your process using this technique, though. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed Custom Action using InstallUtilLib.dll
I have been using managec C++ CA's coded in Visual Studio 2003 for installs. You create a .NET dll and use unmanaged exports .e.g __declspec(dllexport) int __stdcall MyCustomAction(MSIHANDLE hInstall); All your logic is in the installation package and you don't have to leave a carcass behind with the installed product as you do when using installutil. Well, you get the picture. One wrinkle, the VC 2005 requires linking to the C++ CRT as a DLL when using .NET. You have to use a manifest when linking to the CRT, so if the same exact version that you built against in your CA is not on the target machine, BAM!. You might try writing the CA code in VB .NET, or C#, decompile to IL, augment your class with a static method using an unmanaged export in pure IL, and recompile. I have played around with this a bit in .NET 1.1. Since I am upgrading an installed product for 1.1 to 2.0, I am seriously going to consider this as the C++ CRT DLL with its manifests is one strapping headache, or I might just try to do everything in native code. One thing you can do, which I've done before, is to create a native DLL that embeds the managed assembly as a resource. Extract the assembly, host the CLR in native code, and run your CA. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Managed Custom Action using InstallUtilLib.dll
Hi All, I am using Managed Custom Action as details in http://blogs.msdn.com/josealmeida/archive/2004/11/08/253831.aspx This approach works like a charm but I didn't quite like the idea of packaging InstallUtilLib.dll file in MSI. Is there a way to use the InstallUtilLib.dll present in the client machine instead of packing it in MSI Binary table as follows Binary Id=InstallUtil src=$(var.FrameworkPath)\InstallUtilLib.dll /. (I have a Lauch Condition to check for .NET Framework presence in the client machine). Thanks, Sankaranarayanan MG ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed custom action return values
Hi Phil, I think you're forgetting that not all custom actions run inside the setup process (I assume you're referring to msiexec.exe). Custom actions can be external executables that run in their own process. Well, at another abstraction of sight, they run in the setup process. ;-) I think you're reading this: http://robmensching.com/blog/archive/2007/04/19/Managed-Code-CustomActions-no-support-on-the-way-and-heres.aspx and assuming it applies to external managed code executables (Rob could clarify). The issue here is with managed code custom actions that run on msiexec.exe that tattoo your process, to use that MSI team phrase, because they are in an msiexec.exe process. There's nothing wrong with an external managed code custom action executable that was explicitly designed for and can be configured to run with a specific version of the framework. For example, a custom action type 18 is fine as a managed code executable. There's nothing wrong with it, but it is not recommended, cause of what is with the setup, if no CLR is on the system. For me, that's is no problem, cause our whole solution is a CLR project, but what about those out there, that have native software, and wish only to use a managed custom action on install (whoever think to need that combination ;-)) The first I read about WiX and managed custom actions was about that the CLR is needed otherwise the setup won't run. That could be easily checked in the conditions. The next point was, that the installer team mentioned a problem in the CLR implementation, if one uses the 1.1 CLR and wishes directly after that to use the 2.X CLR, he would get the already loaded 1.1 version. And that's why managed custom actions are not officially supported by windows installer, cause this behavior could lead to errors. For our solution this isn't a problem either, we only use CLR 2.X for our whole project, including the custom actions, which use some of our project code. Sure, it is no problem, to run a managed custom action inside setup-process, even those like we use here, but only if you know, what you're doing. Do not try to use code for different CLR versions in one setup and check if the CLR is installed correctly before. Additionally you'll have to sign your managed code, otherwise it surely won't run on the target system. Oliver From: Friedrich, Oliver [mailto:[EMAIL PROTECTED] On Behalf Of Mailinglist Sent: Tuesday, September 11, 2007 12:41 AM To: Wilson, Phil; wix-users@lists.sourceforge.net Subject: RE: Re: [WiX-users] Managed custom action return values Hi, To say writing managed custom actions is not supported is a rather broad brush statement. There's nothing wrong with running managed code executables that run in their own process space. It's the installer class custom actions that are not supported by WiX - I don't believe WiX cares if you fire off a managed code executable as a custom action. WiX at all doesn't care anything other than its own XML. But the Windows-Installer-Team does not support managed custom actions, for certain reasons, that can be easily found on this Mailinglist. To get to the point, custom actions are made, to run inside the setup-process and to enhance the windows-installer capabilities. Oliver - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed custom action return values
I think you're forgetting that not all custom actions run inside the setup process (I assume you're referring to msiexec.exe). Custom actions can be external executables that run in their own process. I think you're reading this: http://robmensching.com/blog/archive/2007/04/19/Managed-Code-CustomActio ns-no-support-on-the-way-and-heres.aspx and assuming it applies to external managed code executables (Rob could clarify). The issue here is with managed code custom actions that run on msiexec.exe that tattoo your process, to use that MSI team phrase, because they are in an msiexec.exe process. There's nothing wrong with an external managed code custom action executable that was explicitly designed for and can be configured to run with a specific version of the framework. For example, a custom action type 18 is fine as a managed code executable. Phil Wilson From: Friedrich, Oliver [mailto:[EMAIL PROTECTED] On Behalf Of Mailinglist Sent: Tuesday, September 11, 2007 12:41 AM To: Wilson, Phil; wix-users@lists.sourceforge.net Subject: RE: Re: [WiX-users] Managed custom action return values Hi, To say writing managed custom actions is not supported is a rather broad brush statement. There's nothing wrong with running managed code executables that run in their own process space. It's the installer class custom actions that are not supported by WiX - I don't believe WiX cares if you fire off a managed code executable as a custom action. WiX at all doesn't care anything other than its own XML. But the Windows-Installer-Team does not support managed custom actions, for certain reasons, that can be easily found on this Mailinglist. To get to the point, custom actions are made, to run inside the setup-process and to enhance the windows-installer capabilities. Oliver - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed custom action return values
Hello, Writing managed custom actions is not supported. A standalone executable will not see anything of the setup around. I took two half ready projects and used them, to build up something that gives you the possibility to write managed custom actions and access the current setup from within your managed code, so you can e.g. post a return value to a property in your setup. You can fetch the code and the samples under the following link: http://www.forestwalk.de/?p=31 sorry, my entry is just in German, but it's the latest link in the post you need. The source and comments are in English though. If you need help in using this, feel free to ask back to me. Oliver From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rachna Khune Sent: Sonntag, 9. September 2007 04:53 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Managed custom action return values Hi there My custom action is a managed exe and I am attempting to do one of the two choices below: 1) Show the exception messages from the custom action or be able to return some error codes which I can log 2) Change the message that pops up when the custom action fails. The default is There is a problem with this windows Is there any way of changing this default message? The Error attribute cannot coexist with the ExeCommand attribute in the CustomAction element: Current implementation: CustomAction Id=InstallRepository FileKey=RepositorySetupCustomActions.exe ExeCommand=create123 /InstallDir:quot;[INSTALLLOCATION]\quot; Return=check Impersonate=no Execute=deferred / Seems as if writing managed custom actions is not preferred due to messages popping up and not having access to the MSI thread. Thanks Rachna SDE Repository Modeling Team, CSD Microsoft 425.705.6966 [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] Cell: 425.533.1626 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed custom action return values
Thanks so much Oliver I will take a look at it and ping you if I have any questions danke rachna From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Mailinglist [EMAIL PROTECTED] Sent: Monday, September 10, 2007 12:29 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Managed custom action return values Hello, Writing managed custom actions is not supported. A standalone executable will not see anything of the setup around. I took two half ready projects and used them, to build up something that gives you the possibility to write managed custom actions and access the current setup from within your managed code, so you can e.g. post a return value to a property in your setup. You can fetch the code and the samples under the following link: http://www.forestwalk.de/?p=31 sorry, my entry is just in German, but it’s the latest link in the post you need. The source and comments are in English though. If you need help in using this, feel free to ask back to me. Oliver From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rachna Khune Sent: Sonntag, 9. September 2007 04:53 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Managed custom action return values Hi there My custom action is a managed exe and I am attempting to do one of the two choices below: 1) Show the exception messages from the custom action or be able to return some error codes which I can log 2) Change the message that pops up when the custom action fails. The default is “There is a problem with this windows…”. Is there any way of changing this default message? The Error attribute cannot coexist with the ExeCommand attribute in the CustomAction element: Current implementation: CustomAction Id=InstallRepository FileKey=RepositorySetupCustomActions.exe ExeCommand=create123 /InstallDir:quot;[INSTALLLOCATION]\quot; Return=check Impersonate=no Execute=deferred / Seems as if writing managed custom actions is not preferred due to messages popping up and not having access to the MSI thread. Thanks Rachna SDE Repository Modeling Team, CSD Microsoft 425.705.6966 [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] Cell: 425.533.1626 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed custom action return values
Just to clarify, this behavior of executables is nothing to do with the code being managed or not. Any executable that returns a non-zero exit code to a custom action that checks the result will cause the There is a problem with this installer package message and a rollback. It's important to note that this is a result of the exit code, so just make sure that an executable returns a zero exit code if it is successful. The executable might work fine, but if it returns a non-zero exit code it will fail the install. To say writing managed custom actions is not supported is a rather broad brush statement. There's nothing wrong with running managed code executables that run in their own process space. It's the installer class custom actions that are not supported by WiX - I don't believe WiX cares if you fire off a managed code executable as a custom action. Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rachna Khune Sent: Monday, September 10, 2007 8:43 AM To: Mailinglist Cc: (wix-users@lists.sourceforge.net) Subject: Re: [WiX-users] Managed custom action return values Thanks so much Oliver I will take a look at it and ping you if I have any questions danke rachna From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Mailinglist [EMAIL PROTECTED] Sent: Monday, September 10, 2007 12:29 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Managed custom action return values Hello, Writing managed custom actions is not supported. A standalone executable will not see anything of the setup around. I took two half ready projects and used them, to build up something that gives you the possibility to write managed custom actions and access the current setup from within your managed code, so you can e.g. post a return value to a property in your setup. You can fetch the code and the samples under the following link: http://www.forestwalk.de/?p=31 sorry, my entry is just in German, but it's the latest link in the post you need. The source and comments are in English though. If you need help in using this, feel free to ask back to me. Oliver From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rachna Khune Sent: Sonntag, 9. September 2007 04:53 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Managed custom action return values Hi there My custom action is a managed exe and I am attempting to do one of the two choices below: 1) Show the exception messages from the custom action or be able to return some error codes which I can log 2) Change the message that pops up when the custom action fails. The default is There is a problem with this windows Is there any way of changing this default message? The Error attribute cannot coexist with the ExeCommand attribute in the CustomAction element: Current implementation: CustomAction Id=InstallRepository FileKey=RepositorySetupCustomActions.exe ExeCommand=create123 /InstallDir:quot;[INSTALLLOCATION]\quot; Return=check Impersonate=no Execute=deferred / Seems as if writing managed custom actions is not preferred due to messages popping up and not having access to the MSI thread. Thanks Rachna SDE Repository Modeling Team, CSD Microsoft 425.705.6966 [EMAIL PROTECTED] Cell: 425.533.1626 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Managed custom action return values
Hi there My custom action is a managed exe and I am attempting to do one of the two choices below: 1) Show the exception messages from the custom action or be able to return some error codes which I can log 2) Change the message that pops up when the custom action fails. The default is There is a problem with this windows Is there any way of changing this default message? The Error attribute cannot coexist with the ExeCommand attribute in the CustomAction element: Current implementation: CustomAction Id=InstallRepository FileKey=RepositorySetupCustomActions.exe ExeCommand=create123 /InstallDir:quot;[INSTALLLOCATION]\quot; Return=check Impersonate=no Execute=deferred / Seems as if writing managed custom actions is not preferred due to messages popping up and not having access to the MSI thread. Thanks Rachna SDE Repository Modeling Team, CSD Microsoft 425.705.6966 [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] Cell: 425.533.1626 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Managed custom action return values
Hi there My custom action is a managed exe and I am attempting to do one of the two choices below: 1) Show the exception messages from the custom action or be able to return some error codes which I can log 2) Change the message that pops up when the custom action fails. The default is There is a problem with this windows Is there any way of changing this default message? The Error attribute cannot coexist with the ExeCommand attribute in the CustomAction element: Current implementation: CustomAction Id=InstallRepository FileKey=RepositorySetupCustomActions.exe ExeCommand=create123 /InstallDir:quot;[INSTALLLOCATION]\quot; Return=check Impersonate=no Execute=deferred / Seems as if writing managed custom actions is not preferred due to messages popping up and not having access to the MSI thread. Thanks Rachna SDE Repository Modeling Team, CSD Microsoft 425.705.6966 [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] Cell: 425.533.1626 - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed Custom Action
Have a look http://msdn2.microsoft.com/en-us/library/ms681383.aspx here - its the first one on the list. Course that's if it was an error from Windows Installer. If it was from your DLL then I got nothin'. However I believe the conventional wisdom is not to use managed CAs since they place too many pre-requisites on the target system - having the .NET framework installed for example. Frederic Mokren wrote: I've been attempting to add a managed custom action following instructions that I found on various blogs and by using dark on Visual Studio created MSI. The gist of it is I use installutillib.dll using ManagedInstall as the DLLEntry. I also created custom action that sets a property for the managed custom action. Anyhow I followed the guides on various blogs and rechecked my WiX many times over. Each time I run the install I get a '1001' error from the Custom Action (presumably from installutillib.dll). Does anyone have any more information on this error? Sincerely, Frederic Mokren -- View this message in context: http://www.nabble.com/Managed-Custom-Action-tf4270256.html#a12165631 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed Custom Action
Alexei wrote: Have a look http://msdn2.microsoft.com/en-us/library/ms681383.aspx here - its the first one on the list. Course that's if it was an error from Windows Installer. If it was from your DLL then I got nothin'. However I believe the conventional wisdom is not to use managed CAs since they place too many pre-requisites on the target system - having the .NET framework installed for example. If your application has the .NET framework as a prerequisite then that doesn't really matter. From reading Rob Mensching's post on the subject [1], the main problem is with the versions of the .NET runtime. Once a process has loaded a version of the runtime, it can't load any other. If it becomes common for CAs to be written in managed code then the probability of two CAs requiring different .NET runtimes increases and at some point you will get a conflict and your installer will mysteriously fail. There are also some other issues with Windows Server 2003 if you read the post. Regards, John [1] http://robmensching.com/blog/archive/2007/04/19/Managed-Code-CustomActio ns-no-support-on-the-way-and-heres.aspx - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed Custom Action
These are all problems that can be solved if only the MSI team would just do it. I've read the tactical/strategic arguments and I just don't buy it. ( Nor did anyone else who commented on that blog. ) John Hall [EMAIL PROTECTED] wrote: Alexei wrote: Have a look http://msdn2.microsoft.com/en-us/library/ms681383.aspx here - its the first one on the list. Course that's if it was an error from Windows Installer. If it was from your DLL then I got nothin'. However I believe the conventional wisdom is not to use managed CAs since they place too many pre-requisites on the target system - having the .NET framework installed for example. If your application has the .NET framework as a prerequisite then that doesn't really matter. From reading Rob Mensching's post on the subject [1], the main problem is with the versions of the .NET runtime. Once a process has loaded a version of the runtime, it can't load any other. If it becomes common for CAs to be written in managed code then the probability of two CAs requiring different .NET runtimes increases and at some point you will get a conflict and your installer will mysteriously fail. There are also some other issues with Windows Server 2003 if you read the post. Regards, John [1] http://robmensching.com/blog/archive/2007/04/19/Managed-Code-CustomActio ns-no-support-on-the-way-and-heres.aspx - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Choose the right car based on your needs. Check out Yahoo! Autos new Car Finder tool.- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed Custom Action
The InstallUtilLib infrastructure for calling managed code has no functionality that cannot be handled by running your managed code as an executable. Properties pass one way into the managed code whether into installer classes or executables. In the vast majority of cases there's simply no point calling a managed code custom action assembly via InstallUtilLib. You can achieve the same result by running an executable, passing the parameters via the command line, and waiting for the executable to complete. If you've already got code in installer classes in assemblies, just get a managed code executable to call them. This eliminates the issues relating to frameworks in the process and running in the context of the MSI process (instead of your application). Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frederic Mokren Sent: Tuesday, August 14, 2007 4:18 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Managed Custom Action I've been attempting to add a managed custom action following instructions that I found on various blogs and by using dark on Visual Studio created MSI. The gist of it is I use installutillib.dll using ManagedInstall as the DLLEntry. I also created custom action that sets a property for the managed custom action. Anyhow I followed the guides on various blogs and rechecked my WiX many times over. Each time I run the install I get a '1001' error from the Custom Action (presumably from installutillib.dll). Does anyone have any more information on this error? Sincerely, Frederic Mokren /* No Comment */ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Managed Custom Action
I've been attempting to add a managed custom action following instructions that I found on various blogs and by using dark on Visual Studio created MSI. The gist of it is I use installutillib.dll using ManagedInstall as the DLLEntry. I also created custom action that sets a property for the managed custom action. Anyhow I followed the guides on various blogs and rechecked my WiX many times over. Each time I run the install I get a '1001' error from the Custom Action (presumably from installutillib.dll). Does anyone have any more information on this error? Sincerely, Frederic Mokren /* No Comment */ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
