Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS
with no warranties, and confer no rights. Additionally, views expressed
herein are my own and not those of my employer, Microsoft.
After posting a brief article about my opinions regarding script-based custom actions, I started thinking more about what I consider an even bigger personal pet peeve of mine - managed code custom actions.
I want to caveat everything I am about to say by explaining that in general, I think managed code is great and not just because I work at Microsoft :-) It offers developers the power of modern object-oriented languages while allowing for rapid development for small and large scale projects. In fact, I have basically spent my entire career trying to make it as easy as possible for everyone to deploy the .NET Framework as part of OEM-manufactured machines or managed applications - and yes I know there is still a lot of work for us to do in this space.
But I also believe that managed code is not the best choice for certain types of development, and setup is one of those places. The biggest concern I have with managed code being used in custom action code is the additional dependency that it introduces to setup. If the underlying .NET Framework runtime is damaged it can lead to unpredictable results in a setup that would not occur if the custom actions were written as a native code DLL (or better yet, were eliminated in favor of standard Windows Installer actions).
I have also seen setup issues related to .NET Framework runtime migration policy. The policy of migrating managed apps to use the latest version of the .NET Framework on the machine (which is on by default in .NET 1.1 and 2.0) can cause your custom actions to run on top of a different version of the .NET Framework than you originally tested and shipped with. We used some managed executables during setup in previous versions of the .NET Framework. Then in future versions of the .NET Framework we decided to set the default runtime migration policy so that any managed code running on the system would use the most recent version of the .NET Framework by default. In general, the .NET Framework is side-by-side compatible and apps written against one version will continue to run correctly against future versions. However, for specific functionality such as parsing configuration files or calling APIs that have had breaking changes introduced for security reasons, this may not hold true. It is possible to include a config file with a managed app to lock it in so it will require a specific version of the .NET Framework to run correctly. However, if you neglect to include a config file (like we have done in the past) that can potentially cause issues if/when your managed code is migrated to run on top of a later version of the runtime. Also, if you author a managed DLL custom action you leave your fate in the hands of Windows Installer, because it will use the latest version of the .NET Framework on the machine in all cases (as opposed to a custom action that calls an installed EXE which can also have a config file installed next to it).As a side note here, if you install the .NET Framework 1.1 you will notice a couple of files installed to the v1.0.3705 folder instead of the v1.1.4322 folder. A couple of those files are intended to fix policy migration issues like the ones I just described. You will also see the .NET Framework 2.0 setup install a few files to the v1.0.3705 and the v1.1.4322 folder for the same reason.
So, in summary, I strongly encourage you to not use managed code in your product setup. I realize that some teams do this here at Microsoft, but please don't use our bad (in my opinion) examples to justify doing so in your own setup....
A while back, I wrote a post with my opinion about managed code custom actions - http://blogs.msdn.com/astebner/archive/2005/03/10/392280.aspx
Rob Mensching, father of Windows Installer XML (WiX), blogs about why managed custom actions are a bad
PingBack from http://www.itwriting.com/blog/?p=197
First made available to the public in WiX weekly release 3.0.4116.0 (http://wix.sourceforge.net/releases/3.0.4116.0/ ), DTF provides a framework for easily and reliably writing managed code custom actions for the Windows Installer. In a nutshell, it provides a robust set of interop classes to simplify communicating with MSI and a hosting model to abstract the CLR code from the MSI process. At runtime, MSI thinks it’s calling a Win32 DLL in it’s own sandbox but in reality the CLR is being fired up out of process and communicated with through a named pipe. From your managed codes perspective, you are simply communicating with MSI through the interop classes with no need (generally) to be concerned with all of the nightmares of unmanaged code.
Why does the post have to be worded like it's a "bad" thing to write managed custom actions? If my requirements are not affected by the issues documented well here, managed custom action I will write. For that matter, if the .NET framework is corrupt, there's a good chance my application isn't going to run anyway. The customer is STILL going to pick up the phone and call the developer. Or, maybe the application WILL run? I've seen different parts of the .NET framework get "corrupt" (ASP.NET, for example), while other areas function normally. For the same reason, the Wix team shouldn't thrive to prevent us from writing custom actions.
But, honestly, what do I know? I've never even used WiX or written a custom action!
I should just shut my mouth and go to sleep. :)
Gosh, I didn't realize this was written so long ago. See, I told you I need to go to sleep. :)
Hi Alexdresko - There are some architectural issues related to the way that Windows Installer hosts the CLR to run managed code custom actions that can lead to problems. Rob Mensching described them in a bit of detail at http://robmensching.com/blog/archive/2007/04/19/Managed-Code-CustomActions-no-support-on-the-way-and-heres.aspx.
Since then, a solution has been developed to host managed code custom actions out of process to avoid these issues. The WiX v3.0 toolset now ships a set of managed libraries for Windows Installer APIs called the Deployment Tools Framework that contains this functionality. There is some more information introducing DTF at http://robmensching.com/blog/archive/2008/05/16/Deployment-Tools-Foundation-joins-the-WiX-toolset.aspx.
There is a problem with this Windows Installer package: A program run as part of the setup did not finish as expected.
I get this message when i try to install itunes..what should i do it feels like i been trying to do everything that people have been saying on google..
Hi Mike Lew - It might help to look in the setup log file if there is one created during this failed installation. If there is one, it will probably be in your %temp% directory, and if you'd like, I can try to take a look. To do that, I'll need you to upload your log file to a file server (such as http://skydrive.live.com) and then reply here and post a link that I can use to download your log file.
It might also help to search on the Apple iTunes web site to see if there are any known issues or workarounds that they suggest for this type of error.