Managed Code CustomActions, no support on the way and here's why.

<< WiX v3 Roadmap Draft | Home | It's like riding ghost. >>

Managed Code CustomActions, no support on the way and here's why.

I was recently pinged by a triumvirate of individuals asking me about using managed code to write CustomActions. This is a hot topic that comes up about every other month on the wix-users mailing list at SourceForge. Those of you that hang out on that mailing list know that I've repeatedly stated that the WiX toolset does not support managed code CustomActions because the Windows Installer team does not support managed code CustomActions.

However, since I was asked by three people (all of them knowledgeable and respectable) at the same time I thought I would again ask the Windows Installer team about supporting managed code CustomActions. I got the same answer I got last time, "The Windows Installer does not support CustomActions written in managed code." However, this time we had time to have a deeper conversation about why the managed code is not supported for CustomActions. There are essentially two reasons managed code is not supported: one technical, one strategic.

Technical

The technical issue that managed code CustomActions have is due to the fact that the .NET Framework is "sticky" (Carolyn, MSI Dev Lead, used the phrase "tattoos your process"). Once you load a version of the .NET Framework into a process, the .NET Framework is not unloaded. More importantly, if you attempt to load a different version of the .NET Framework into your process later you will get the previously loaded version.

I have to admit this technical issue with using managed code in CustomActions surprised me. I had heard of the problem before (of course, Carolyn had mentioned it a few times) but I didn't truly understand the ramifications until I wrote the code tonight then stepped through it in the debugger. It is kinda' cool to see the .NET Framework v1.1 get loaded by one CustomAction then later have a second CustomAction try to load the .NET Framework v2.0, get the v1.1 Framework handed to it, then fail when trying to create an app domain later. Well, it's only cool because I anticipated the failure.

What this mean is that if you end up in a scenario where you have a CustomAction written for one version of the .NET Framework and a second CustomAction written for a different version of the .NET Framework that your second CustomAction will fail before it can even get started. Well, you could mark your .NET Framework 1.1 CustomAction to say that it will run in the .NET Framework 2.0 and then try to ensure that the .NET Framework 2.0 is loaded everywhere. That might work until there is another .NET Framework version (4.0?).

There is additional complication on Windows Server 2003. On that OS, the Windows Installer will attempt to load the .NET Framework 1.1 into the deferred CustomAction server (for a reason that Carolyn mentioned but I've forgotten now, should have taken better notes). If you have already loaded the .NET Framework 2.0 (say, for a CustomAction) then the Windows Installer can fail to add files to the Global Assembly Cache.

All of these complications when managed code CustomActions are introduced reduce the chances that an installation package will successfully install and uninstall (let alone upgrade or be patchable). When you approach the problem from a platform point of view (as the Windows Installer team must), I hope you agree that there are way too many common failure cases to support managed code CustomActions.

Now the intrepid developer might suggest that managed code CustomActions could be hosted in a separate process from the Windows Installer's CustomAction server. That way the separate process would disappear and take the .NET Framework with it each time the CustomAction exited. Make no mistake, this solution takes a lot of work and is most likely something along the lines of what the Windows Installer team would need to do to support managed code CustomActions.

However, they are focusing on other features because of their strategic position on CustomActions.

Strategic

Inside Windows there is a fair bit of discussion going on right now about how to improve application deployment on the operating system. Knowing about the discussions, I invited a couple of the Windows architects to my conversation with the Windows Installer team about managed code CustomActions. My hope was to provide the architects with a couple real world examples of problems facing setup developers today and maybe get some insight from them along the way. What I got was validation of something I've seen coming for a long while.

Strategically the goal is to reduce the number of CustomActions shipping in installation packages. It is generally accepted that a great majority of the installation failures out there today are failures inside CustomActions. CustomActions in installation packages also surface as major problem for application compatibility between operating systems. The data collected thus far suggests that application deployment would be improved by reducing the number CustomActions in installation packages.

Making it easier to create more CustomActions (which a managed code for CustomAction would certainly do) does not align with the strategic goal.

Now, having written something like 75% of the CustomActions in the WiX toolset let me assure you that I'm one of the first to point out that CustomActions are quite often a necessity today. However, I also know that the code in the Windows Installer has had far more scrutiny and testing than the WiX CustomActions to date. Thus, I can agree that it would be better if there were fewer CustomActions shipping in installation packages today and that the installation functionality was instead built into the Windows Installer or the operating system in general.

For example, imagine that to configure a web site in IIS that you didn't need a CustomAction from the WiX toolset (or some other vendor). Instead, you just declare that you want your web site (much like you do in the WiX toolset today) and code that was installed with IIS would be activated by the Windows Installer to do the work. That means that you and I would not be responsible for reverse engineering the IIS store (i.e. the metabase) then writing the CustomAction to ship in our installation package. That would move us all a great many steps away from CustomActions and hopefully towards a more stable operating system.

Now, I know there are a good number of other things that people use CustomActions for today. I also know that it would be very convenient to be able to write CustomActions in managed code. However, today the Windows Installer does not support managed code CustomActions and the general direction appears to be to try to reduce the need for CustomActions overall.

tags: rob, mensching, managed, code, custom, action, wix, windows, installer, setup

Print posted @ Thursday, April 19, 2007 12:49 AM

Feedback

re: Managed Code CustomActions, no support on the way and here's why.

I think this misses one of the big uses of Custom Actions - to perform application-specific activities, such as upgrading configuration data. Without re-writing some core application logic in native code, the current solution we've adopted is to fire off an installed .NET executable at the end of the install, loosing the good parts of MSI (transactional behaviour, for example).

There are other ways to acheive this, such as performing app-specific 'upgrade' logic on first use - but consider unattended installs, and similar scenarios.

Reducing the need to write custom actions is great, but there is a risk it will be used as a reason for not providing the support that app vendors need. 4/19/2007 3:09 AM | Kenneth Bell

re: Managed Code CustomActions, no support on the way and here's why.

Let's say that Windows Installer in Vista+1 ships with more built-in actions. Very few people will use them. While Microsoft lives on the bleeding edge, out in the real world, most people do not. No software vendor can afford to ignore the installed base, which will be running Vista, Srv2003, XP, and even 2000. If the vendor has to write their own custom actions to support older OS versions, they're going to use them on Vista+1 too. 4/19/2007 5:42 AM | Anonymous Coward

# re: Managed Code CustomActions, no support on the way and here's why.

Regarding the strategic direction, I completely agree with you that built-in Windows Installer stories should be updated to eliminate the need for custom actions.

Unfortunately I've lost confidence that the Windows Installer team will get this job done. The last generally available release of MSI isn't available down-level and only adds stories related to Vista UAC/RM functionality. Cool stuff, but not the additional standard action patterns that many people have been begging for over the last several years. The release before that seemed to focus mainly on patching. Even if the Windows Installer team was to pull a rabbit out of the hat and support these stories, I doubt they would port it down-level to a 3.x branch.

Please, tell me I'm wrong with that assessment. Please tell me that Bill G is going to throw so money at that team and we are going to get the framework improvements we have all been begging for.

Until that day comes, Custom Actions aren't only tactical; they are strategic because there is no other viable solution. You raise some interesting points about AppDomains and the CLR and yet I've seen InstallShield address these issues with their CoCreateObjectDotNet() pattern. I've also done some work on my own with .NET 2.0 IPC remoting and I've found it to be a very reliable way of hosting custom actions out of process and yet still giving them the ability to communicate with MSI.

For the rest of Microsoft, managed code is clearly marketed as the future of software development. Windows Installer should adopt this strategic initiative and simply overcome the technical hurdles. This way we can have really good custom action patterns to play with until the day comes that MSI natively supports the patterns that we are writing custom actions for. Then we can gladly dump our CA's and refactor using the built-in standard actions.

4/19/2007 6:47 AM | Christopher Painter

re: Managed Code CustomActions, no support on the way and here's why.

I have to agree that, while the technical reasons present large hurdles and the strategic ideology is one which I find pleasant, we collectively aren't realizing the stratgy, and only a select few know the technical reasons. This leaves it up to each setup author (or setup solution author) to try to scale the wall of technical problems without the knowledge of what each Windows Installer version does behind the scenes.

If we are not going to see built in patterns, whether it's because something Windows Installer does only on 2003 can conflict, or because the team just hasn't gotten to it yet, we all need more documentation of the sort you just posted here so when we tackle a technical problem, we can weigh the tradeoffs. Thanks for sharing this gem. 4/19/2007 8:44 AM | Michael Urman

# re: Managed Code CustomActions, no support on the way and here's why.

I think the other issue that is being missed her is all about timing. We setup developers are dealing with these problems now and as far as I have been able to find (and I have been looking) there is no timeline information about when the strategy you mention will be implemented. If it is with "Vista+1", as someone labeled it, that means waiting at least four years. That's a whole lot of time to be waiting for something that may not even meet needs when it finally arrives. 4/19/2007 9:06 AM | Nathan Stohlmann

re: Managed Code CustomActions, no support on the way and here's why.

If managed code custom actions won't be supported then Microsoft should stop creating them.

I have no desire to create managed custom actions, I want to be able to use the managed custom actions that Microsoft is releasing. What's the best way to register a PowerShell snap-in, call the managed code produced by the PowerShell team or reverse engineer that code so I can do it without the managed code?

It was particularly galling to read that the Windows Installer team's strategic direction is exactly what I want to do, let the PowerShell (or IIS or MMC) team write the code that does the right thing during installation. Most (maybe all) of those teams are writing managed custom actions.

4/19/2007 9:16 AM | John Vottero

re: Managed Code CustomActions, no support on the way and here's why.

Hmm, the technical reason sounds like it can be worked around and the strategic reason doesn’t hold water in my opinion.

Saying, and please excuse the paraphrasing, that “CAs cause the majority of failures so we want to make it hard to make CAs” just doesn’t make any sense. CAs were created to provide a way for installation developers to perform tasks that the Windows Installer team didn’t implement or couldn’t. The need for CAs will never change. Installation developers will always have requirements unique to their applications. When they have to write those CAs, does it support the Windows Installer team’s goal to have more stable installs for the installation developers to write their CAs in managed or unmanaged code?

If the concern is that installation developers will write CAs instead of utilizing the built in tables (when available) than that is an education problem and not a reason not to bring CAs into the present. 4/19/2007 10:19 AM | Peter Thomas

re: Managed Code CustomActions, no support on the way and here's why.

Rob, thank you for a clear explanation of the problem. May be you could tell the Visual Studio team to read this, then they might stop using managed custom actions in the setups that Visual Studio creates! 4/19/2007 10:44 AM | Neil Sleightholm

# re: Managed Code CustomActions, no support on the way and here's why.

At the risk of being called snarky, a former coworker of mine inspired me over lunch today...

<parody>
In other news, Microsoft announced today that future versions of MS-DOS will never support more then 640K of conventional memory. The tactical reason given was that protected mode memory remapping was too unreliable and difficult to do correctly. Besides, developers will never need more then 640K of memory.`
</parody>
4/19/2007 12:10 PM | Christopher Painter

re: Managed Code CustomActions, no support on the way and here's why.

But anyway, there are so many people are using managed CA's as .net console applications or other way, why not include functionality to make their life easier? No matter what bugs it cause then, additional functionality would only benefit WiX. 4/20/2007 6:01 AM | Albert

# re: Managed Code CustomActions, no support on the way and here's why.

I think the reponders have basically summed it up here:

- The technical limitations can be overcome as you suggested and Christopher seems to have already built
- The strategy appears to be broken, as they are basically saying "CA's are unstable, so we'd like to discourage their use in general, but we you will need to wait for a future MS OS (4+ years for relase!) to make the need for these CAs go away." How does that help anyone get work done for the next decade!?
- Managed CAs could potentially offer some advantages for cross-OS compat as they offer an abstraction layer over the OS.
- Managed code is also an important part of the strategy for coding on the Windows platform, so why shouldn't set up be part of that strategy?
- A good technical implementation and guidance on how to use managed CA's effectively (transactional, table driven, etc.) would probably do more to address the needs of setup developers now and would produce far better set up results for the next 5 years or so while this more far reaching strategy comes to fruition. 4/20/2007 10:49 AM | Joe Kaplan

# re: Managed Code CustomActions, no support on the way and here's why.

>It is kinda' cool to see the .NET Framework
>v1.1 get loaded by one CustomAction...

In the COM interop world, the latest version of the Framework that's installed always gets loaded. Why wouldn't the MSI world work the same? Yes, there's still the possibility that the newer version of the framework is incompatible with the older version, but MS works pretty darn hard to avoid that (sometimes too hard).

I agree with the other comments here. Saying that custom actions shouldn't be required is really just sticking your heads in the sand. There will always be the need for application specific install actions - MS can only deliver platform specific install actions. And with more stuff out of Redmond moving toward managed APIs only, even that will eventually run out of steam. 4/20/2007 11:30 AM | Kevin Dente

# re: Managed Code CustomActions, no support on the way and here's why.

CAs themselves are not unstable. Poorly designed and written CAs are unstable, and unfortunately many people seem to not follow good design practices sparsely outlined in the Windows Installer SDK. But good examples exist in WiX.

The point is that many people don't need to write CAs if they look for standard actions or existing, well-written CAs like those found in WiX and often commercial packages or other community sites like http://installsite.org.

Take, for example, application configuration data as the first comment states. Instead of treating the whole file as a resource, treat its contents. The XmlConfig CAs in WiX make operations on the content-level possible with XML files. Windows Installer supports INI (and INF) files through the standard IniFile table. If you have some proprietary format, you might consider the affect of that on users and switch to a more common format. If a common format doesn't already have a CA for editing the content, then a community contribution or requested CA should be created. There's no reason everyone should write their own CA to do the same thing with various levels of quality. 4/20/2007 7:17 PM | Heath Stewart

re: Managed Code CustomActions, no support on the way and here's why.

It seems that this is MS's new version of "DLL Hell."

It seems that the deployment section of the prodcut development cycle is the last thing on MS's "to do" list.

Thanks to Rob, the folks on WIX, and the current MSI team for all the great efforts they have put into this... I just wish the folks at the top would take more interest. 4/23/2007 10:39 PM | Dhaval Patel

re: Managed Code CustomActions, no support on the way and here's why.

Have to agree with the position the MSI team is taking.
The install process needs to be as simple and clean as possible. If an installer requires a considerable amount of code to configure the target system, then one should consider moving this code out of the installer and into the application.
I really don't understand how people can make a case for managed CA when the state of managed code and .NET is still in flux. Perhaps sometime in the future, but as it stands right now... no way.

4/24/2007 11:45 AM | MrMike

re: Managed Code CustomActions, no support on the way and here's why.

The issue is here is really about the infrastructure for calling user code during an install, and that the MSI infrastructure for this (custom actions, including managed code custom actions) is not a good fit for a lot of the things that people use them for. The strategy is moving towards having this code outside the MSI file. As soon as someone invents a launching infrastructure that (say) creates AppDomains, calls assemblies, runs programs, launches the MSI,
4/24/2007 1:43 PM | Phil Wilson

re: Managed Code CustomActions, no support on the way and here's why.

..contd...
The issue is here is really about the infrastructure for calling user code during an install, and that the MSI infrastructure for this (custom actions, including managed code custom actions) is not a good fit for a lot of the things that people use them for. The strategy is moving towards having this code outside the MSI file. What's needed is a launching infrastructure that (say) creates AppDomains, calls assemblies, runs programs, launches the MSI, runs post install stuff etc, with some corresponding rollback.

4/24/2007 1:48 PM | Phil Wilson

# re: Managed Code CustomActions, no support on the way and here's why.

I don't buy the `configuration data is a pain` argument. When I'd repackage software for a major U.S. airline, we'd frequently want to configure a piece of software to fit the situation that it was going to. A typical example might be a client server application that pointed to different MSSQL databases depending on where it was going to be installed. This was easily accomplished by passing public properties as part of the command line. Take MSDE for example, you can easily pass a few properties to it and when the package is being installed you have a fully functional sql instance.

Recently I did an install for MySQL which was a major pain because not only did the install have no points of variation for configuration, but it also didn't provide any automation layer ( that I could find reference to ) to configure the instance. The configuration wizard that set up the instance was GUI only. This made it very difficult to try to deploy MSSQL as an embedded private instance .... something that is VERY easy to do with MSDE because the package natively handles the configuration requirements.
4/26/2007 12:47 AM | Christopher Painter

re: Managed Code CustomActions, no support on the way and here's why.

I have almost completely moved away from the traditional Windows Installer design. All my MSIs do anymore is lay down files and registry keys. I am developing a C# framework around my installers that does everything else I need it to such as drive the install UI, configure web servers, run sql scripts, etc.

As far as I am concerned, Windows Installer has reached it's end of usefulness for ISV-based installations. The only real advantage of a pure MSI file is for repackaging legacy applications for deployment.

It makes no sense to use Windows Installer when there are more custom actions than standard actions (ahem...Office team). Hence, why I have moved to the C# wrapper that performs all the configuration tasks while maintaining a pristine, (custom action)less Windows Installer package.

The least the Windows Installer team could do is provide a supported .NET interop assembly. PLEASE!!!! 4/28/2007 1:12 PM | AJ

re: Managed Code CustomActions, no support on the way and here's why.

...my thoughts continued.

On the sticky .NET issue. Did anyone else stop to think that JUST MAYBE my custom actions and my installer project would be in the same solution...AND...get this, built on the same version of the .NET Framework?

I know it sounds revolutionary and all, but there are some people out there that actually code like this. I know, crazy right?

</sarcasm> 4/28/2007 1:21 PM | AJ

re: Managed Code CustomActions, no support on the way and here's why.

if the .NET versioning - resp. loading multiple .NET versions into the same process - is the big problem to support managed custom action as first class citizen why could the the Windows Installer not integrate Silverlight 1.1 technologies (effectively the .NET core runtime) and therefore providing a "stable" .NET runtime environment which is independent on the currently installed .NET runtime(s) ?
5/15/2007 4:33 AM | Daniel Steiner

re: Managed Code CustomActions, no support on the way and here's why.

Has anyone realized "why" so many especially new to microsoft folks are resorting to managed custom actions? They dont know HOW TO develop in unmanaged code.
I was on a team until last month where in the setup had more than 10 custom actions to do stupid things like showing custom messages and writing to log files. The setup was meant for installing an SDK which consisted of 1 binary and 4 tools binaries...that too free...and took longer than most other setup's.
IMO there should be a company wide rule to develop custom actions in unmanaged code only, there by improving the quality of setups overall 9/11/2007 11:43 AM | Rachna

re: Managed Code CustomActions, no support on the way and here's why.

@Rachna
not everybody you see here on the list for the first time have to been a newbie.

Speaking for my person I've more than 20 years experience with MS technologies starting with MS-DOS 2.x Int21h programming, Windows 2.11 assembler/pascal/c SDK etc. and have a rather good knowledge and understanding of MS technologies.

Coming back to the topic of this blog, there are some real and good reason why to have managed custom actions:

- smaller package than native code
- tested and stable code .NET Framework
- more flexible what you can do due to large BCL
- less coding by using BCL resp. C# programming language compared to native C++
- verifiable and digital signing of assembly
- cross plattform, you need only a single binary not for each plattform(IA32,x64,Itanium, etc.)
- you can use compiler you want especially you don't need to include some runtime libraries depending on you compiler.
eg. when using VC2005 you need to include runtime as it's not guaranteed to be present on the target system.

You can argue the same way for using managed code in SQL Server 2005 and nobody is asking why do we need it - we've already T-SQL and C++ native commands :-) 10/6/2007 10:45 AM | Daniel Steiner

# re: Managed Code CustomActions, no support on the way and here's why.

Hi Rob! (remember me from CoreXT :)

In my real world I need to write a CA and would like to write it in managed code. I have a bunch of small MSIs and I don't have CAs in different .NET framework versions so this isn't a problem. I have nothing to put in the GAC.

So this is for the least frustrating. Especially that I've used MsiManaged from MSFT toolbox before and several internal (and possibly external) Microsoft projects use that as well and very successfuly. Just ship that with all the notes and warnings. 10/11/2007 6:14 AM | dB.

# re: Managed Code CustomActions, no support on the way and here's why.

Another example of how some Microsoft teams have the luxury of all the time in the world to "solve" customer problems, and to do it on *their* terms (not the customers').

It's too bad that there was no product revenue at stake to be tied back to the Windows Installer team - perhaps then they'd worry more about solving customers' problems *today* and have less of the laissez-faire attitude of "we'll do it right, but only for future versions of Windows, and we don't care about the 'legacy' problems."

The *smart* response to the problem of too many Custom Actions creating too many compat issues is to build clear, actionable, step-by-step guidance/examples/templates that accommodate the customers' actual deployment scenarios, rather than living in the fantasy that the few scenarios that were built in to the product "should be sufficient for everyone, if they're 'smart' about it."

Grrr... 12/4/2007 9:53 AM | Mike Smith-Lonergan

# re: Managed Code CustomActions, no support on the way and here's why.

Does anyone know how I can make my custom action launch an .exe after my web setup project completes? I have tried the MSDN walkthrough that shows how to launch I.E but i couldnt launch an .exe packaged with my MSI.. Please help 2/11/2008 7:30 AM | Oladipo Olasemo

# Managed Code CA Is Supported

A short article detailing the support of Managed Code CA's in upcoming ISHNMET 2009.
3/20/2008 4:23 AM | Christopher Painter

Rob Mensching Openly Uninstalled