nsalerno at securewatch24.com
Mon Sep 20 17:33:37 EDT 2010
> So you don't really have to care about the COM visible attribute just
> take advantage of it if you want to.
> Mono already has an installutil.exe (I don't know how mutch compatible
> it is with that of MS.NET) so the easiest implementation of...
Yes, I agree about Mono's installutil.exe, and the first thing I thought to myself was that the implementation should be moved into the System.Configuration.Install namespace.
With respect to compatibility with Microsoft's behavior, I have found two bugs in Mono's implementation of installutil:
1) It does not invoke the Installer instances that are contained in the main Installer (the one with the RunInstaller(true) attribute). One can work around this bug by manually invoking the child installers in their respective overridden Installer methods.
2) When you execute "installutil /u MyAssembly.exe" it calls the Install() method. The Uninstall() method is not invoked. However, the OnBeforeUninstall() method is called properly so one can work around this bug by setting a value in the IDictionary parameter. In the Install() method, the first thing you do is check for that value. If it exists then dispatch to the Uninstall() method and return. Else, proceed with your implementation of Install().
Both of these bugs I would like to fix because they really break the "write once, run everwhere" model and I (and company) do not want to maintain two code bases for dealing with Microsoft's way and Mono's way of installers.
> If you mean something else on "where implementations should fall into
> place" please be more specific.
You convinced me that installutil.exe is implemented by using ManagedInstallerClass. We agree on that.
What I am still undecided about is if ManagedInstallerClass uses AssemblyInstaller to get some of the work done. Right now both of these classes are not implemented in Mono and I am wondering if the code in installutil.exe is split amongst the two classes.
You can have ManagedInstallerClass do all the work, but what if somebody was interested in AssemblyInstaller only to find it is not implemented?
According to MSDN AssemblyInstaller "Loads an assembly, and runs all the installers in it." In using it with Microsoft's implementation, AssemblyInstaller handles the child installers contained in the parent installer (bug #1 that wrote about above).
Bug #2 that I wrote about above would be a problem in ManagedInstallerClass.
installutil.exe --uses--> ManagedInstallerClass --uses--> AssemblyInstaller
Provides command line user interface for ManagedInstallerClass.
Responsible for instantiating and managing IDictionary parameter for Installer methods.
Also responsible for managing the sequence of calls to Installer methods.
Responsible for invoking override methods of Installers found in the assembly (based on RunInstaller attribute).
In addition, for each installer found in assembly, invoke methods on the instances that exist in the "Installers" property of each installer instance.
From: Kornél Pál [mailto:kornelpal at gmail.com]
Sent: Monday, September 20, 2010 3:44 PM
To: Nicholas Salerno
Cc: mono-devel-list at lists.ximian.com
Subject: Re: [Mono-dev] AssemblyInstaller
A COM visible .NET class is a .NET class. If you use it from .NET you
don't see a difference, and there is no difference in the internals
eiher. The only difference is that you can access COM visible classes
using COM interfaces in unmanaged code. This is very much the same as
P/Invoke DLLs/delegates with the additional support for reference
counting and this argument. (HRESULT to exception translation is also
supported for pure non-OOP functions.)
So you don't really have to care about the COM visible attribute just
take advantage of it if you want to.
Mono already has an installutil.exe (I don't know how mutch compatible
it is with that of MS.NET) so the easiest implementation of
ManagedInstallerClass.InstallHelper is to move logic except
version/copyright header from installutil.exe to
installutil.exe should not be just a couple of lines longer than my
reference implementation in this thread.
If you mean something else on "where implementations should fall into
place" please be more specific.
> Thank you for the clarification. All that said, it still seems like ManagedInstallerClass.InstallHelper would utilize AssemblyInstaller. ManagedInstallerClass is COM visible, which may imply some things. AssemblyInstaller appears to be a plain old .NET class. I don't have any objection to ManagedInstallerClass, I'm just trying to understand where implementations should fall into place.
> -----Original Message-----
> From: Kornél Pál [mailto:kornelpal at gmail.com]
> Sent: Saturday, September 18, 2010 5:04 AM
> To: Nicholas Salerno
> Cc: mono-devel-list at lists.ximian.com
> Subject: Re: [Mono-dev] AssemblyInstaller
> That page documents exactly what it does.
> installutil.exe should be implemented as sometihng like the following
> (I've tried it and it works on MS.NET):
> class Program
> static void Main(string args)
> catch (Exception ex)
> Arguments accepted are documented here:
> So all the functionality of installutil.exe should be moved to
> ManagedInstallerClass. Even the help screen comes as an exception.
> Note that no version headers are not printed by ManagedInstallerClass
> that should remain in installutil.exe and some appropriate status code
> should be set on return as well.
> Based on the following example I belive that
> IManagedInstaller.ManagedInstall does exactly the same except that
> exceptions are not returned:
> class Program
> static void Main(string args)
> IManagedInstaller installer = new ManagedInstallerClass();
> StringBuilder sb = new StringBuilder();
> foreach (string arg in args)
> sb.Append(arg.Replace("\\", "\\\\").Replace("\"", "\\\""));
> sb.Append("\" ");
> if (sb.Length> 0)
> sb.Remove(sb.Length - 1, 1);
> installer.ManagedInstall(sb.ToString(), 0);
> catch (Exception ex)
> A search for hInstall in Platform SDK headers resulted in matches only
> from MsiQuery.h. So that method is most likely used by Windows Installer
> and I would guess that at least errors are reported using hInstall
> rather than exceptions.
> Nicholas Salerno write:
>> Vincent Povirk wrote:
>>> I don't know much about these classes, but my impression was that
>>> ManagedInstallerClass corresponds most directly to installutil.exe,
>>> but that that class must use AssemblyInstaller. It seems installutil
>>> duplicates some functionality of both of those, and it should probably
>>> call on them instead.
>> The ManagedInstallerClass is scarcely documented in MSDN (unlike the other classes in the System.Configuration.Install namespace). Also, the description states that the class is not meant to be directly used by one's code. I don't know much about this ManagedInstallerClass other than it doesn't seem to fit with the model established by the Installer class. It doesn't derive from Installer. It implements IManagedInstaller, an interface I don't know much about.
>> I am familiar with the Installer class that derives from Component and is meant to be subclassed. The AssemblyInstaller class seems to be the class to use if one wants to programmatically install and uninstall .NET components (without having to execute shell commands to instalutil). I do this in Windows.
>> If nobody has any objections I would like to submit a patch that implements the AssemblyInstaller class.
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list