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]> 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]> > > > 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] > > > 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
