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

Reply via email to