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
