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.
Heath Stewart has posted an item on his blog that I wanted to link to here so that hopefully more setup developers will find it. The post, located at http://blogs.msdn.com/heaths/archive/2007/04/20/custom-action-guidelines.aspx, provides a set of high-level guidelines for creating custom actions if you find that they are necessary for your MSI-based setup.
Included in these guidelines are items such as the following:
If you are a setup developer working with custom actions in an MSI-based setup, I encourage you to take a look at Heath's post for more detailed information about guidelines for creating custom actions.
Well if MSI is going to be stuck in early 1990's thinking, maybe it's time to stop using the SDK.
Hi Christopher - I'm not sure how these guidelines qualify as early 1990's thinking, so could you please clarify your statement?
The Windows API has evolved over many iterations over many years. While there are have been many stops along the way, the three basic technologies are:
Basically when making such statements to exclude the use of COM and .NET ( ala activescript is evil, managed code is evil, all dependencies are bad ) you are telling everyone to throw away 10+ years worth of progress and roll their own everything using the lowest level API and language possible. This is early 1990's thinking.
Windows Installer really should spend the energy to create bulletproof hosting models for COM and Managed Code Classes to facilitate the modern development languages.
I have no interest poking around in C++ using 15 year old API's because someone at Microsoft is afraid of dependencies.
I fully expect the SDK to provide a story for implementing an interface on a class and wiring it up as a custom action. Beyond that I expect a built-in interop layer that presents MSI session information to my code so that I can easily write fully transactional datadriven custom action patterns using modern languages and frameworks.
Hi Christopher - Thanks for the clarifying post, I understand better the point you're trying to make now. I think Rob addressed this on some level in his blog post at http://www.robmensching.com/blog/archive/2007/04/19/Managed-Code-CustomActions-no-support-on-the-way-and-heres.aspx. This is at least in part a strategic investment decision on the part of the Windows Installer team. Given finite resources, they would prefer to invest in eliminating the need for custom actions in more cases as opposed to making it easier (and therefore more highly encouraged) to create custom actions in the first place. This is based on data that they've gathered over the years about the root causes of setup failures, etc. That being said, of course there will always be cases where custom actions are needed.
In general though, I'm not sure I agree with your assessment about dependencies and setup. I don't think it is fair to simply say that someone at Microsoft is afraid of dependencies. This is something that should be in the mind of all developers as they work on their applications and setups, and should not be adopted lightly.
For example, I would almost always choose to have a setup that minimizes the dependencies it needs to get itself installed compared to a setup that requires more dependencies in order to be able to install because in my experience, the more possible points of fragility, the more often the setup is going to fail, which causes more support calls, more tricky debugging (that can end up crossing the boundary into the dependency itself as opposed to being a bug in your custom action code), etc.
I agree with the strategic direction, but I'm concerned that I've seen little to no progress from the MSI team in this area. It's now 2007 and the built-in standard actions and tables still can't describe basic stories that are common place in todays XML/.NET/SaaS world.
I see some progress from various MSI setup vendors, but the job really should fall on the MSI team and be part of the SDK for all setup development tools to benefit from.
I can understand that if the MSI team wants to implement the `perfect` custom action pattern, then rolling your own everything in native C++ is ideal. But to say managed code isn't acceptable for any CA is almost as crazy as expecting everyone to write all CA's in C++.
Consider this example: A dialog that prompts the user for a servername and invokes a webservice on the server to get the servers instance name. This instance name is then given to the user who's asked to confirm yes/no or ignore if the connection failed.
This pattern is easily implemented in a C# class to consume the webservice and expose itself to InstallScript via the ComVisible(true) / CoCreateObjectDotNet() pattern. There are try/catch blocks all over the place and the bootstrapper already makes sure the framework is installed since we need it for our application anyways.
I've never seen this CA fail in the last 6 months that it has existed and the failure mode allows for skipping the confirmation. I can't think of anyway this would be harmful to the installation.
Now imagine writing that pattern using raw C++ with roll your own everything anti-dependencies and tell me how much more work it would be.
We need to solve these interop/dependency problems and get back to 2007 where managed code / component based software with minimal plumbing is a good thing.
i am mostly ask these types of questions.I can understand that if the MSI team wants to implement the `perfect` custom action pattern, then rolling your own everything in native C++ is ideal. But to say managed code isn't acceptable for any CA is almost as crazy as expecting everyone to write all CA's in C++.
Hi Holiday Packages in India - Rob's blog post at www.robmensching.com/.../Managed-Code-CustomActions-no-support-on-the-way-and-heres.aspx outlines some of the issues that can be faced when using managed code in custom actions. That post was written in 2007 though, and there has been some work done to address these issues since then. You can find more information in the follow-up blog post at robmensching.com/.../Deployment-Tools-Foundation-joins-the-WiX-toolset.aspx.