I noticed that the add-ins scanning operation fails in the creation of
the remote setup:
remoteSetupDomain = (RemoteSetupDomain)
domain.CreateInstanceFromAndUnwrap(typeof(RemoteSetupDomain).Assembly.Location,
typeof(RemoteSetupDomain).FullName);
the runtime throws a code security exception
I had the same problem while trying to embedd mono.addins in a webservice.
I tried to modify mono.addins (0.5) code and I noticed that
instancing the RemoteSetupDomain class in the current domain instead
of the remote domain, as in the snippet below, the scan operation
succeeds.
I have a couple of questions:
1) Which Mono.Addins features are lost by doing in this way?
2) I do not undertand why mono.addins must execute the addins scanning
process in a different app domain: does cecil read assemblies
metadata without loading them? or I'm wrong in this point?
Thanks,
Matteo
----SetupDomain.cs (from line 66) -----
RemoteSetupDomain GetDomain ()
{
lock (this) {
if (useCount++ == 0) {
domain = AppDomain.CreateDomain ("SetupDomain");
remoteSetupDomain = new RemoteSetupDomain();//new code
//remoteSetupDomain = (RemoteSetupDomain)
domain.CreateInstanceFromAndUnwrap(typeof(RemoteSetupDomain).Assembly.Location,
typeof(RemoteSetupDomain).FullName);//old code
}
return remoteSetupDomain;
}
}
The goal of using a separate app domain is to reduce the memory impact
of the scanning process in the main application.
When using the default add-in reflector, using a separate domain is
necessary to avoid the scanned assemblies to be loaded in the host
process. When using the cecil based reflector, this is not such a big
problem, since cecil assembly metadata can be GCed, but using a separate
domain allows freeing the memory used by the cecil reflector itself,
which is as big as Mono.Addins.dll.
In any case, I can add an option for optionally disabling the use of the
app domain.
Lluis
Probaly more thant year ago I asked you the following feature request:
more overloads in the addin descriptions attribute, in particular I
was interested in the possibility of specifying the plug-in author
directly in the code, like
[assembly: Mono.Addins.Addin("My Addin", "1.0.0", Category = "Addin's
Category", Author="The Author" )]
if is suitable I can try to submit a patch for this,
Matteo
> --
> You received this message because you are subscribed to the Google Groups "Mono.Addins" group.
> To post to this group, send email to mono-...@googlegroups.com.
> To unsubscribe from this group, send email to mono-addins...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/mono-addins?hl=en.
>
>
There is already an attribute for this (for almost a year):
[assembly: AddinAuthor ("Author 1")]
[assembly: AddinAuthor ("Author 2")]
...
Lluis.