<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Well, for mono addins in particular, it
looks like it can address this issue too by declaring this
directive in .addin files:<br>
<br>
<Addins><br>
<Runtime><br>
<Import assembly="SharpKml.dll"><br>
<Import assembly="Diva.Utils.dll"><br>
</Runtime><br>
</Addins><br>
<br>
These other .addin files can (and should) come in the package
itself. In other words, in OpenSim we would have the file<br>
addons.addin<br>
which would just be something like this:<br>
<Addins><br>
<Directory
include-subdirs="true">addon-modules</Directory><br>
</Addins><br>
<br>
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.<br>
<br>
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!<br>
<br>
On 12/28/2014 2:41 PM, John Sheridan wrote:<br>
</div>
<blockquote cite="mid:54A08702.40308@pseudospace.net" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
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. <br>
<br>
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. <br>
<br>
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. <br>
<br>
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).<br>
<br>
<div class="moz-cite-prefix">On 12/28/2014 04:51 PM, Diva Canto
wrote:<br>
</div>
<blockquote cite="mid:54A07B60.4080403@metaverseink.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">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. <br>
<br>
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.<br>
<br>
On 12/28/2014 1:38 PM, David Saunders wrote:<br>
</div>
<blockquote
cite="mid:CAOjZz+nOMAS3YzYegMvm_731C9YMNCFm6Nkk=wuCW0JiUEZOWw@mail.gmail.com"
type="cite">
<div dir="ltr">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.
<div>This is the example of my current DN.addins dile. <br>
<div>
<div><Addins></div>
<div><span class="" style="white-space:pre"> </span><Directory>/opt/opensimcode/DN-AddIns/</Directory></div>
<div></Addins></div>
</div>
</div>
<div><br>
</div>
<div>It makes life easyer for testing new core code with out
worrying about did i copy all the current addin DLLs over
or not. </div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Dec 28, 2014 at 3:45 PM,
James Hughes <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:jamesh@bluewallgroup.com" target="_blank">jamesh@bluewallgroup.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Mono-Addins
does 100% of what we need to manage (subscribe to)
remote<br>
repositories and install plugins hosted in them.<br>
<br>
-BlueWall<br>
<div class="HOEnZb">
<div class="h5"><br>
On Sun, 2014-12-28 at 08:43 -0800, Diva Canto wrote:<br>
> On 12/27/2014 6:56 PM, Mister Blue wrote:<br>
><br>
> > Is there a way to incorporate the NuGet
package manager<br>
> > (<a moz-do-not-send="true"
href="https://nuget.codeplex.com/" target="_blank">https://nuget.codeplex.com/</a>).<br>
><br>
> I looked at Nuget. Nuget is a package manager
for VS applications. It<br>
> does a lot of things that we don't need, and it
doesn't do anything<br>
> that we need to do. Essentially, Nuget takes
your VS project, and adds<br>
> additional dlls in the bin folders and
additional lines in .csproj. It<br>
> does more .Net things like keeping track of
which .Net framework<br>
> version the packages are for. It seems very
much tied to Visual<br>
> Studio, and mono support seems weak. From their
FAQ: "Keep in mind<br>
> that the focus of NuGet is to let you modify
your projects and add<br>
> references to Visual Studio projects." [1]<br>
><br>
> This is not exactly what we need. We have our
own runtime plugin<br>
> loading mechanism, region modules. What we need
is a package manager<br>
> for region modules. Region modules have
specific needs, such as having<br>
> their own configuration files and their own
runtime dependencies. And<br>
> they don't have many of the needs that static
link-time packages do:<br>
> usually region modules don't depend on other
region modules, they tend<br>
> to be self-contained packages. (although
dependencies are possible)<br>
> And obviously, they aren't listed explicitly as
dependencies of<br>
> OpenSim.Region.<br>
><br>
> There's a console interface to Nuget that seems
to be more inline with<br>
> what we need:<br>
> <a moz-do-not-send="true"
href="http://blog.davidebbo.com/2011/01/installing-nuget-packages-directly-from.html"
target="_blank">http://blog.davidebbo.com/2011/01/installing-nuget-packages-directly-from.html</a><br>
> This seems to be a niche use of Nuget, though,
and it doesn't do the<br>
> most critical part of what we need, which is to
automate the dll load<br>
> path and the .ini path. If we use Nuget with
this interface, it serves<br>
> solely to upload/download packages to/from a
central repository, which<br>
> I'm not sure where it is, and we'd have to fix
the paths by some other<br>
> means.<br>
><br>
> Nuget is designed to help people incorporate
3rd party libraries into<br>
> their own VS projects, which is the kind of
activity that we do when<br>
> we develop for OpenSim (in Windows). But that's
not what we are<br>
> talking about here. We need something that
helps non-developers<br>
> incorporate 3rd party custom plugins into a
specific application,<br>
> OpenSim. There is no compilation/static link
steps at the user's site;<br>
> there's just dropping in additional dlls and
configuration files<br>
> somewhere.<br>
><br>
> The question is where those files should be
dropped, and how they are<br>
> picked up by OpenSim. Dumping everything in bin
(which is what Nuget<br>
> does) doesn't sound like a good idea and, in
fact, we already have the<br>
> basics in place to host 3rd party plugins under
addon-modules. I think<br>
> we should proceed on that route.<br>
><br>
> So if someone is interested in figuring out how
to hack around Nuget<br>
> to make it work well for OpenSim region
modules, go ahead. I am not<br>
> going to explore that option any further, as
what I saw doesn't seem<br>
> seem a good fit with what we need. My sense is
that in the beginning<br>
> Nuget (called Nu) seemed in line with
Linux-like package managers, and<br>
> at some point it made a sharp turn to become an
extension of Visual<br>
> Studio.<br>
><br>
> (It would also be weird to host OpenSim region
modules -- a<br>
> specific .Net application's plugins -- in the
generic Nuget Gallery.<br>
> Region modules aren't useful for anything but
OpenSim.)<br>
><br>
> [1] <a moz-do-not-send="true"
href="http://docs.nuget.org/docs/start-here/nuget-faq"
target="_blank">http://docs.nuget.org/docs/start-here/nuget-faq</a><br>
><br>
> ><br>
> > On Sat, Dec 27, 2014 at 5:37 PM, Diva
Canto <<a moz-do-not-send="true"
href="mailto:diva@metaverseink.com">diva@metaverseink.com</a>><br>
> > wrote:<br>
> > On 12/27/2014 3:33 PM, Diva Canto
wrote:<br>
> > Unfortunately, .Net
doesn't seem to understand wild<br>
> > cards in the
<probing> element, so the installation<br>
> > procedure will need to
edit this <probing> element<br>
> > and add the new directory
explicitly to the<br>
> > privatePath, with
semi-colon in between, which is<br>
> > not very nice. But that's
Windows philosophy, I<br>
> > guess...<br>
> ><br>
> > We could do this too, and scan
everything under<br>
> > addon-modules/*/bin until we find
a match. This would have<br>
> > to be done in OpenSim.<br>
> ><br>
> > <a moz-do-not-send="true"
href="http://stackoverflow.com/questions/1561806/looking-for-net-assembly-in-a-different-place"
target="_blank">http://stackoverflow.com/questions/1561806/looking-for-net-assembly-in-a-different-place</a><br>
> ><br>
> ><br>
> >
_______________________________________________<br>
> > Opensim-dev mailing list<br>
> > <a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> > <a moz-do-not-send="true"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev"
target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> >
_______________________________________________<br>
> > Opensim-dev mailing list<br>
> > <a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> > <a moz-do-not-send="true"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev"
target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> <a moz-do-not-send="true"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev"
target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
<br>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
<a moz-do-not-send="true"
href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev"
target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Opensim-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Opensim-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
<a class="moz-txt-link-freetext" href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>