There are other issues with Installer classes too. As Rob M has pointed out, anything that's installed with code is outside the Windows Installer ref counting scheme. If you install a shared item with MSI and follow the usual component id rules it just works. Two products can share the same resource (registry entry, service, file) and you can uninstall one without impacting the other. When services and registry entries (snap-in registration, COM registration etc) are installed with code like Installer classes there is no reference counting. Products sharing these resources are easily broken by uninstalling one of them.
Regarding "Microsoft has adopted the Installer classes as the standard way to install "things" ", it's more accurate to say that Microsoft has adopted them as the standard way for *developers* to install things. This is Visual Studio that started them, remember, to provide a way for developers to get their "things" installed without building MSI files (mainly with InstallUtil). The idea that Installer classes should be used in production environments can pretty much be shot down based on the ref counting issue alone. The rest of it (the fragility, loading the CLR, kb 906766, lack of repair) are other things that make Installer classes undesirable. Phil Wilson ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Collins Sent: Thursday, July 20, 2006 2:32 PM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Should WiX add support for installingWindowsinstrumentation features? Whenever I sit at my desk, I have the potential to introduce bugs. :) Do C++ custom actions introduce less defects? Absolutely not. If you or I write a bad custom action, it's not going to work or it's going to be very buggy. The issue is really the dependency. A non-CLR-based C++ custom action only requires the Windows API and/or the Windows Installer API which is also C/C++-based. It doesn't need the runtime engine. In most cases, a C++ custom action is going to integrate cleanly into the installation environment and will work with Windows Installer. It's not so much a question of Windows Installer as it is just general usage of the CLR runtime. It's the same reason why Microsoft has recommended against writing .NET-based shell extensions because it means loading the CLR into Explorer. I guess that if you are in complete control of your installer, there's very little risk, as long as you can make sure that all of your custom actions require the same version of the CLR runtime. The issue is if you're using third-party components such as custom actions or merge modules with custom actions. Will you be able to guarantee that their custom actions, if they rely on the CLR, will use the same version? It's the same issue as with the Window shell. If you write a .NET-based shell extension, will you conflict with the .NET-based shell extension that I wrote if we're on different versions? Yes. If we are the same version, will we have a problem, maybe not. Michael ________________________________ From: "John Vottero" <[EMAIL PROTECTED]> Sent: Thursday, July 20, 2006 2:15 PM To: [EMAIL PROTECTED]>, <wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Should WiX add support for installing Windowsinstrumentation features? Creating an installer that uses custom actions that are based on two different versions of the .NET Framework is definitely a bad idea but, that doesn't mean that you shouldn't be able to use managed code at all. I've run into a similar problem with the C++ runtime, installing on x64 windows the 64 bit version of the C++ runtime was loaded and then a custom action wanted the 32bit version and the install failed. Why don't C/C++ custom actions have the potential to introduce bugs? ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of michael Sent: Thursday, July 20, 2006 3:19 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Should WiX add support for installing Windowsinstrumentation features? Here's my take on this subject. All of my applications at this time and the forseeable future are written in C# and run on the .NET platform. However, I still build things such as custom actions, shell integrations, etc., using C and C++. I do this because of how I understand that the CLR runtime works. In order to run .NET-based code in an installer, the installer has to load a CLR engine into the Windows Installer process. The problem is a versioning issue with relation to the CLR runtime engine. Let's say for example, that I have two versions of the .NET Framework installed, 1.1 and 2.0, and I have two .NET custom actions. If the first custom action to run is based on the .NET 1.1 framework, that runtime is going to load. Then, when my .NET 2.0-based custom action is called upon to run, it's not going to be able to run because the wrong version of the runtime is loaded. Using .NET-based custom action or install code has the potential to introduce bugs into the installer, where the C/C++-based custom action won't. I do understand that I could choose to run the installutil.exe program as an executable custom action, but I don't believe that is what this thread is about. I disagree with the statement below that Microsoft has "adopted the Installer classes as the standard way to install 'things'." I think that the Installer class is one way of configurating applications and has its place when doing xcopy deployment, which is also a valid way of installing an application. But Windows Installer is yet another way to install applications, but that doesn't mean that Windows Installer should accomodate .NET-based custom actions given the issues with runtime versioning. My opinion, based on what I've researched, is that .NET custom actions are like script-based custom actions: there are too many problems with supporting them which make them inherently unsafe for use in an installer package. On the other hand, if WiX supported .NET custom actions, I don't have to use them. I would prefer, however, that WiX not have features introduced that could potentially be used to create defects in installers that I create or for other products that I use. It's tough enough to get applications to run without Administrator privileges. I'd prefer not to have to deal with applications that have issues because of how many different CLR environments I have installed. Michael Collins ________________________________ From: "John Vottero" <[EMAIL PROTECTED]> Sent: Thursday, July 20, 2006 12:02 PM To: [EMAIL PROTECTED]>, <wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Should WiX add support for installing Windowsinstrumentation features? I think that WiX (and/or Windows Installer) needs to stop thinking that the Installer class is a bad idea and start thinking of how to support it. Whether you like it or not, Microsoft has adopted the Installer classes as the standard way to install "things". I still don't understand why an Installer class is a bad idea but creating a custom action in C++ is a good idea. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Phil Wilson > Sent: Tuesday, July 11, 2006 10:37 AM > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] Should WiX add support for > installing Windowsinstrumentation features? > > Anything Wix does to prevent a lot of Installer class code > would be a good > thing. I notice that the new MMC is going down a similar > route, using a > SnapinInstaller class with InstallUtil to create just a bunch > of registry > entries. > > For perf counters the LoadPerfCounterTextStrings API call > with an ini file > has always worked for me (although the format of the ini file > isn't well > documented). > > Phil Wilson > > ________________________________ > > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Joe Kaplan > Sent: Saturday, July 08, 2006 2:35 PM > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Should WiX add support for installing > Windowsinstrumentation features? > > > Hi all, > > Does anyone think that WiX should try to add explicit support > for installing > Windows instrumentation features such as event logs, > performance counters > (custom .NET ones) and WMI schema? It seems to me that one > of the primary > attractions for using installutil.exe for .NET-based apps is > that there are > very easy ways to do these things with installer classes in > .NET and it > isn't as straightforward or even possible to do that in WiX. > > I realize that event log sources are just a bunch of registry > entries and > maybe a message dll file, but it would be convenient if there > was explicit > schema in WiX to support this. I expect it would be easy to > translate that > schema internally into the appropriate registry and file > table entries to > make this work. > > My understanding is that perf counters, especially the .NET ones, are > tougher. I do realize that there is already some support in > WiX for native > perf counters, so perhaps this could be extended? I don't really know > anything about installing WMI schema, so I don't know what's > involved with > making this happen. > > I also think it would be interesting if Heat supported > reverse engineering > WiX authoring for they types of installer classs embedded in .NET > assemblies, similar to the way it can harvest stuff like COM > registration > now. > > I don't mention Windows services in this list as I'm pretty > happy with the > support these things have in WiX so far. Reverse engineering service > installer classes into WiX authoring would be cool though. > > Thoughts? I started this discussion with Derek offine a few > months ago and > he asked me to post here. I just finally got around to > bringing up with the > community. > > Joe Kaplan > > > > -------------------------------------------------------------- > ----------- > Using Tomcat but need to do more? Need to support web > services, security? > Get stuff done quickly with pre-integrated technology to make > your job easier > Download IBM WebSphere Application Server v.1.0.1 based on > Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&; > dat=121642 > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
