addins scanning and code security

22 views
Skip to first unread message

matteo tesser

unread,
Feb 7, 2011, 6:33:49 AM2/7/11
to mono-...@googlegroups.com
hello,
I'm manifesting problemes in using momo.addins when the extensible
application which uses mono.addins is a COM / Excel Add-in:

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;
}
}

Lluis Sanchez

unread,
Feb 10, 2011, 5:14:15 AM2/10/11
to mono-...@googlegroups.com
El dl 07 de 02 de 2011 a les 12:33 +0100, en/na matteo tesser va
escriure:

> hello,
> I'm manifesting problemes in using momo.addins when the extensible
> application which uses mono.addins is a COM / Excel Add-in:
>
> 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?

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

matteo tesser

unread,
Feb 10, 2011, 12:22:54 PM2/10/11
to mono-...@googlegroups.com
Hello Luis,
Thanks for this, it would help a lot.

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.
>
>

Lluis Sanchez

unread,
Feb 10, 2011, 12:43:44 PM2/10/11
to mono-...@googlegroups.com
El dj 10 de 02 de 2011 a les 18:22 +0100, en/na matteo tesser va
escriure:

> Hello Luis,
> Thanks for this, it would help a lot.
>
> 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,

There is already an attribute for this (for almost a year):

[assembly: AddinAuthor ("Author 1")]
[assembly: AddinAuthor ("Author 2")]
...

Lluis.


matteo tesser

unread,
Feb 10, 2011, 12:56:37 PM2/10/11
to mono-...@googlegroups.com
thanks, then!

Reply all
Reply to author
Forward
0 new messages