Well, for mono addins in particular, it looks like it can address this
issue too by declaring this directive in .addin files:
<Addins>
<Runtime>
<Import assembly="SharpKml.dll">
<Import assembly="Diva.Utils.dll">
</Runtime>
</Addins>
These other .addin files can (and should) come in the package itself. In
other words, in OpenSim we would have the file
addons.addin
which would just be something like this:
<Addins>
<Directory include-subdirs="true">addon-modules</Directory>
</Addins>
And then in each addon, there would be an .addin file that specifies the
dependencies with import directives, as exemplified above. So in my
specific example, there would be those 2 import statements in my package.
So now the only question in my mind is the specific tool/UI to manage
these packages. Mono addins itself has a command line interface called
mautil, I'm going to look at it next. Indeed, it may very well be that
we already have the entire framework for supporting 3rd party packages
in OpenSim, and we just aren't using it!
On 12/28/2014 2:41 PM, John Sheridan wrote:
Strange bit of synchronicity here, but I've come up with the same
conclusion for a similar issue with a non OpenSim project I'm working
on at my job.
With mine the system is split into two components being the terminal
(which provides a locked down runtime environment in the form of an
AppDomain) and a "distribution" counterpart containing the "guts" of
the system. The distributions are added into the terminal via package
file and then later launched into the AppDomain when selected by the
user.
The distributions themselves contain loadable plug-ins such as data
connectors, user interfaces, etc. some of which have external
dependencies which were failing since the distribution's files are
unpacked into a folder separate from the terminal's root.
Before the holiday break I had tried all sorts of things such as
tinkering with the ApplicationBase, PrivateBinPath, and
ShadowCopyFiles properties no no avail. In the end I too came to the
conclusion that the only way to overcome the path issues for
dependencies would be to hook into AssemblyResolve - short of
littering up the terminal's root folder by unpacking the distributions
there (which is not a viable option in my case).
On 12/28/2014 04:51 PM, Diva Canto wrote:
This works for the region modules themselves, but, as far as I can
tell, it doesn't work for external dlls on which those region modules
depend. For example, I have a region module that uses SharpKml.dll,
an external library. Placing the module's dll and SharpKml.dll
elsewhere, and then pointing mono addins to that directory loads the
module successfully, but it fails when code from SharpKml is invoked,
because the .Net runtime doesn't know where to find it.
So in general we need more than this mono addins directive. My
preference today is to catch the
AppDomain.CurrentDomain.AssemblyResolve event in OpenSim, and scan
some config-given directory tree when that event is raised.
On 12/28/2014 1:38 PM, David Saunders wrote:
To add a comment to having the dll in one dir. I use an .addin file
to add other directories to be search for Dlls. This way I separated
the addins from the core code and can switch them around just by
moving the .addin file.
This is the example of my current DN.addins dile.
<Addins>
<Directory>/opt/opensimcode/DN-AddIns/</Directory>
</Addins>
It makes life easyer for testing new core code with out worrying
about did i copy all the current addin DLLs over or not.
On Sun, Dec 28, 2014 at 3:45 PM, James Hughes
<[email protected] <mailto:[email protected]>> wrote:
Mono-Addins does 100% of what we need to manage (subscribe to)
remote
repositories and install plugins hosted in them.
-BlueWall
On Sun, 2014-12-28 at 08:43 -0800, Diva Canto wrote:
> On 12/27/2014 6:56 PM, Mister Blue wrote:
>
> > Is there a way to incorporate the NuGet package manager
> > (https://nuget.codeplex.com/).
>
> I looked at Nuget. Nuget is a package manager for VS
applications. It
> does a lot of things that we don't need, and it doesn't do
anything
> that we need to do. Essentially, Nuget takes your VS project,
and adds
> additional dlls in the bin folders and additional lines in
.csproj. It
> does more .Net things like keeping track of which .Net framework
> version the packages are for. It seems very much tied to Visual
> Studio, and mono support seems weak. From their FAQ: "Keep in mind
> that the focus of NuGet is to let you modify your projects and add
> references to Visual Studio projects." [1]
>
> This is not exactly what we need. We have our own runtime plugin
> loading mechanism, region modules. What we need is a package
manager
> for region modules. Region modules have specific needs, such
as having
> their own configuration files and their own runtime
dependencies. And
> they don't have many of the needs that static link-time
packages do:
> usually region modules don't depend on other region modules,
they tend
> to be self-contained packages. (although dependencies are
possible)
> And obviously, they aren't listed explicitly as dependencies of
> OpenSim.Region.
>
> There's a console interface to Nuget that seems to be more
inline with
> what we need:
>
http://blog.davidebbo.com/2011/01/installing-nuget-packages-directly-from.html
> This seems to be a niche use of Nuget, though, and it doesn't
do the
> most critical part of what we need, which is to automate the
dll load
> path and the .ini path. If we use Nuget with this interface,
it serves
> solely to upload/download packages to/from a central
repository, which
> I'm not sure where it is, and we'd have to fix the paths by
some other
> means.
>
> Nuget is designed to help people incorporate 3rd party
libraries into
> their own VS projects, which is the kind of activity that we
do when
> we develop for OpenSim (in Windows). But that's not what we are
> talking about here. We need something that helps non-developers
> incorporate 3rd party custom plugins into a specific application,
> OpenSim. There is no compilation/static link steps at the
user's site;
> there's just dropping in additional dlls and configuration files
> somewhere.
>
> The question is where those files should be dropped, and how
they are
> picked up by OpenSim. Dumping everything in bin (which is what
Nuget
> does) doesn't sound like a good idea and, in fact, we already
have the
> basics in place to host 3rd party plugins under addon-modules.
I think
> we should proceed on that route.
>
> So if someone is interested in figuring out how to hack around
Nuget
> to make it work well for OpenSim region modules, go ahead. I
am not
> going to explore that option any further, as what I saw
doesn't seem
> seem a good fit with what we need. My sense is that in the
beginning
> Nuget (called Nu) seemed in line with Linux-like package
managers, and
> at some point it made a sharp turn to become an extension of
Visual
> Studio.
>
> (It would also be weird to host OpenSim region modules -- a
> specific .Net application's plugins -- in the generic Nuget
Gallery.
> Region modules aren't useful for anything but OpenSim.)
>
> [1] http://docs.nuget.org/docs/start-here/nuget-faq
>
> >
> > On Sat, Dec 27, 2014 at 5:37 PM, Diva Canto
<[email protected] <mailto:[email protected]>>
> > wrote:
> > On 12/27/2014 3:33 PM, Diva Canto wrote:
> > Unfortunately, .Net doesn't seem to
understand wild
> > cards in the <probing> element, so the
installation
> > procedure will need to edit this <probing>
element
> > and add the new directory explicitly to the
> > privatePath, with semi-colon in between,
which is
> > not very nice. But that's Windows philosophy, I
> > guess...
> >
> > We could do this too, and scan everything under
> > addon-modules/*/bin until we find a match. This
would have
> > to be done in OpenSim.
> >
> >
http://stackoverflow.com/questions/1561806/looking-for-net-assembly-in-a-different-place
> >
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > [email protected]
<mailto:[email protected]>
> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
> >
> >
> >
> >
> >
> > _______________________________________________
> > Opensim-dev mailing list
> > [email protected]
<mailto:[email protected]>
> > http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
> _______________________________________________
> Opensim-dev mailing list
> [email protected]
<mailto:[email protected]>
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected] <mailto:[email protected]>
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
