Be very careful using C# within a Microsoft Installer based installation(like those generated using WiX). By doing so, you place an additional dependency on the .NET framework, and has been discussed many times this is a *bad thing*. Ideally you should choose something (e.g. C++) that can be built to have minimal (ideally no) external dependencies.
I couldn't disagree with this poster more. Adding the .NET framework as an install time dependency is not automatically and blanketly a "bad thing". It is increasingly becoming an "inevitable thing". After all, how else would you publish assemblies to the GAC? How else would you PreJIT assemblies?
I would agree that it's a bad thing to do things like use Installer Classes to use the framework to install services when MSI is natively capable of doing that, but not just because it's a MC CA, but because it's an unneeded CA in general.
The reality is we are now starting to see new API's that have no unmanaged counterpart. We are having developers write managed code and they are now business requirements for doing things that can only be done in .NET or are done in with 95% less effort in .NET.
We can bury our heads in the sand and repeat the '.NET is Evil' group think, or we can get with 2007 and start using .NET to our advantage and demand that the Windows Installer team do the same. Otherwise MSI's days are numbered.... remember after all that only about 50% of the setup space has switched to MSI. Other technologies are still out there.
5 comments:
No doubt. InstallShield's implementation of CoCreateObjectDotNet has been a lifesaver to me many times. A little tip for anyone using managed custom actions. As many people point out, managed code is "sticky". If you are using managed code custom actions in Windows Installer, make sure you free the module so that the next time you use it, it doesn't use the same one that is already in memory. I have found that when this happens, the module in memory has often held on to its properties.
Add this define to the top of your InstallScript:
prototype void ole32.CoFreeLibrary( byval int );
Then after you call the custom action, set the object to NOTHING and free the module using the following (hModule is an INT):
hModule = GetModuleHandle( MY_MC_CA );
if( !hModule ) then
//We can't get the handle to the module
else
CoFreeLibrary( hModule );
endif;
I've also noticed that in InstallShield 2008 CoCreateObjectDotNet is already deprecated. They have replaced it with a new function ( sorry, InstallScript doesn't suport overloads ) called DotNetCoCreateObject(). It takes an additional argument of AppDomain.
There is also a new function called DotNetUnloadAppDomain. I think this basically does what AJ is doing.
AJ-
About 2 years ago you once said:
"Wow, if InstallShield is the only option we have for Windows Installer, we are all in a lot of trouble.
I might be biased, but it's sad really that InstallShield and Windows Installations are synonymous with each other. ...considering IMHO it is one of the worst installer products on the market."
What is your feeling about InstallShield these days?
I am still not the biggest fan. That being said, they have a great interoperability with the .NET Framework. If it weren't such a PITA, I would stick to Orca. ;-)
My current employer is an InstallShield / WiX shop. Personally, I prefer to work in WiX, but InstallShield does some neat things as well.
I can't stand VB.NET either, but I'd sure help you out with something if you have a question.
I look forward to the day where I can seamlessly use the best of both WiX and InstallShield. I like the concept of WiX, but I don't like the current state of editing tools for WiX.
I mostly use Orca for `sneak and peek` and the occasional ad-hoc validation of a package. On occassion I've actually used it for authoring in conjunction with MSI2XML / XML2MSI. Examining raw table data is ok for trying to identify a problem or `how something works`.... but actually authoring it from scratch is a royal pain. WiX is better, but still the same general problem just easier to read.
Call me lazy, but I like designers... :)
Post a Comment