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

Sun Apr 20 18:58:46 UTC 2008

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080420/30f6cf33/attachment-0001.html>