<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <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 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>