[Opensim-dev] Proposal for removing "ERROR: There was an error while scanning assembly:" message

Mon Apr 21 11:42:44 UTC 2008

I thought the traditional way to deal with polytheistic areas such as 
configuration, module loading, etc. was to define a local interface whose 
syntax and semantics are fixed, and then allow the underlying 
implementation to evolve. We should have implementation agnostic 
specifications of loading and configuration to which we fit both OpenSim 
and the underlying implementations. That way OpenSim, and the majority of 
its developers and users, never needs to worry about how any of this is 
being implemented. And for those of us that do care, the interface remains 
a persistent testamenrt of what is supposed to exist ad how it is supposed 
to work. This principle should extend to all abstract notions such as 
plug-ins et al too. Without this the all of these areas will remain 
shrouded in mystery and confusion.

Best regards
Alan
-------------------
T.J. Watson Research Center, Hawthorne, NY
1-914-784-7286
alan_webb at us.ibm.com

Stefan Andersson <stefan at tribalmedia.se> 
Sent by: opensim-dev-bounces at lists.berlios.de
04/20/2008 02:58 PM
Please respond to
opensim-dev at lists.berlios.de

To
<opensim-dev at lists.berlios.de>
cc
opensim-users at lists.berlios.de
Subject
Re: [Opensim-dev] Proposal for removing "ERROR: There was an error while 
scanning assembly:" message

Justin,

First: we should strive to have one system/paradigm to maintain plugins. 
(We were supposed to have one system/paradigm to handle config files too, 
but we've all seen how far we've come on that...)

Second: A plugin handling infrastructure ain't no rocket science; and 
should not be construed as such. If we gave our current module system some 
love (as in refactoring and care) I'm pretty sure it can be made into 
something sexy, simple and solid.

Whatever we do, we should support
a) pick-up loading of modules (shared/non-shared region,and application) 
from one designated pick-up directory
b) explicit loading of modules (shared/non-shared region,and application) 
via path in config file

Best,
/Stefan

> Date: Sun, 20 Apr 2008 17:51:12 +0100
> From: jjustincc at googlemail.com
> To: opensim-dev at lists.berlios.de
> CC: opensim-users at lists.berlios.de
> Subject: Re: [Opensim-dev] Proposal for removing "ERROR: There was an 
error while scanning assembly:" message
> 
> Stefan Andersson wrote:
> > Justin,
> > 
> > what was the problem with moving plug-in dll's to a separate 
directory?
> > 
> > Or, doesn't mono plugins support loading named plugins from an xml 
file, 
> > for example?
> > 
> > Wouldn't either of these solve the problem?
> 
> Stefan,
> 
> The mono addins package doesn't appear to support picking up modules 
> from a root directory different from the one in which the assembly 
> loading the plugins is situated. The directory you give the addins 
> manager on initialization only appears to place the addin caching 
> information in a different directory instead. Possibly this is as yet 
> incomplete functionality.
> 
> The xml in the addins directory looks tantalisingly like it should allow 

> the naming of different plugin directories, but from reading the code 
> this doesn't appear to be the case.
> 
> I haven't done much more experimentation, mainly because I'm beginning 
> to think it would be better if we re-used the same module loading code 
> we use to load region modules to load application 'plugins'. This would 
> mean removing the mono addins manager. The cons of this are
> 
> * We end up writing (and maintaining) our own plugin code, though much 
> of this is written already for region modules.
> * We lose the ability to have a multiple application plugin cache, 
> though I'm not sure how useful this is for us.
> * We lose the ability to version plugins - we would have to write this 
> in our own code.
> 
> The pro is
> 
> * We get what will probably be a simpler to understand system without 
> the complexity of maintaining an addins cache and the bugs which result. 

> Mono.Addins pretty much has as much documentation as our own code, but 
> at least we wrote our own code...
> 
> On the whole, I think the pro outweighs the cons - particularly as it 
> seems odd for us to maintain two distinct plugin systems. Any changes 
> we make will also be with a view to enhancing the current modularization 

> a little further down the road (e.g. to allow the explicit selection of 
> plugins).
> 
> Thoughts?
> 
> 
> > 
> > Best,
> > Stefan
> > 
> > 
> > 
> > 
> > 
------------------------------------------------------------------------
> > 
> > > Date: Fri, 18 Apr 2008 20:00:38 +0100
> > > From: jjustincc at googlemail.com
> > > To: opensim-dev at lists.berlios.de; opensim-users at lists.berlios.de
> > > Subject: [Opensim-dev] Proposal for removing "ERROR: There was an 
> > error while scanning assembly:" messages
> > >
> > > Hello,
> > >
> > > This is a technical post but I'm copying it to users for 
information.
> > > You may (or may not) want to stop reading quickly :-)
> > >
> > > So, some of you may have noticed that the latest OpenSim revisions 
now
> > > have many more of the subject error messages on the console. The 
cause
> > > is the Mono Addins manager we're using, which writes these errors to 
the
> > > console if the dll doesn't contain the configuration data it's 
expecting.
> > >
> > > So today I looked at removing these errors. I had to follow several
> > > lines of investigation.
> > >
> > > 1. My initial thought was to move all the external libraries which 
are
> > > causing the problem to a separate $OPENSIM_ROOT/lib/ext directory.
> > > However, this means changes to make sure that the dlls can be found 
in
> > > the new directory. For a cross platform application, it's hard. On
> > > Microsoft's CLR we can simply use <Probing> in config files. 
However,
> > > Mono does appear to support this, at least according to
> > >
> > > http://www.mono-project.com/Assemblies_and_the_GAC
> > >
> > > I tried it anyway, without success. Instead, the only option on Mono 
is
> > > to either set the MONO_PATH or put the assemblies in the Global 
Assembly
> > > Cache.
> > >
> > > 2. This makes things awkward, so instead I looked at moving the 
plugin
> > > dlls. Same problem.
> > >
> > > 3. So instead I looked at simply suppressing the messages.
> > > Unfortunately, the Mono addins code writes these messages out to the
> > > console. Although in theory you could give it an IProgressMonitor 
and
> > > stop this, all the classes for this (and the interface) are internal 
and
> > > hence not accessible. Later versions of mono-addins than the one we 
are
> > > using would appear to have the same problem.
> > >
> > > So although we could hack the code in 3. to remove the message (or 
even
> > > replace or code our own plugin solution), the fact is that we really
> > > need to have dlls in different directories eventually anyway - bin/ 
is
> > > already overloaded. This means I'm forced to come back to suggestion
> > > 1. Putting things in the GAC is unrealistic at this stage I think, 
so
> > > I'm proposing that we move all the external libraries to
> > > $OPENSIM_ROOT/lib/ext and set the MONO_PATH environmental variable 
to
> > > point to this directory. Under Windows, we would instead put 
<Probing>
> > > entries in the executable's config files.
> > >
> > > I tried setting MONO_PATH programatically in OpenSimMain.cs, but the 
set
> > > doesn't look like it is exported so the load fails. The same path 
works
> > > fine when exported from the command line.
> > >
> > > If we go the MONO_PATH route, then I think we could provide shell
> > > scripts for all the executables to set the path and then launch the
> > > program, even though this is a little messy. The executable itself
> > > would complain loudly if it is not on Windows and MONO_PATH is unset
> > > (which would be inconvenient for Windows mono users, though there 
may
> > > not be that many of them).
> > >
> > > I'm open to constructive suggestions on this, particularly from core
> > > developers.
> > >
> > > --
> > > justincc
> > > Justin Clark-Casey
> > > http://justincc.wordpress.com
> > >
> > > _______________________________________________
> > > Opensim-dev mailing list
> > > Opensim-dev at lists.berlios.de
> > > https://lists.berlios.de/mailman/listinfo/opensim-dev
> > 
> > 
> > 
------------------------------------------------------------------------
> > 
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> 
> 
> -- 
> justincc
> Justin Clark-Casey
> http://justincc.wordpress.com
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080421/3fcaf886/attachment-0001.html>