<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 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 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 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 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 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 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 href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> > <a 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 href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> > <a 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 href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
> <a 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 href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
<a 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>