Hello,

Glad to see that you find the answer. I will definitively consider your
patch for inclusion, as excluding assemblies for licensing reason is quite
important when bundling an application.

Thanks again for the work.

Regards, Laurent Etiemble.

2010/9/28 anthony taranto <anthony.tara...@gmail.com>

> Ah, I determined the cause of my issues. I had an event handler on the
> AppDomain.AssemblyResolve event which would load the assembly from my
> Contents/MacOS dir. This was being used to load another assembly at
> runtmie. The issue is that it did not handle assemblies with the name,
> version, and public key token included in the name string.
>
> So with the patched Nant.Monobjc.dll, i'm able to skp embedding the
> LGPL dll, copy it into Contents/MacOS as part of the <mkappl> task,
> and load it at runtime using the following handler:
>
>            AppDomain.CurrentDomain.AssemblyResolve += (sender, e) =>
>            {
>                string bundlePath =
>
>  Path.GetDirectoryName(NSBundle.MainBundle.ExecutablePath);
>
>                int index = e.Name.IndexOf(',');
>                string name = index == -1 ?
>                    e.Name :
>                    e.Name.Substring(0, index);
>
>                return Assembly.LoadFile(Path.Combine(bundlePath,
>                    name + ".dll"));
>            };
>
> This patch seems like it would be useful for others who bundle LGPL
> libraries. I wrote it hastily, let me know if there are any
> modifications you'd like me to make before accepting it.
>
> Thanks,
>
> --Anthony
>
> On Sun, Sep 26, 2010 at 11:50 AM, Laurent Etiemble
> <laurent.etiem...@monobjc.net> wrote:
> > Hello,
> > Thanks for the time you spent and the patch, I will take a look at it.
> > Meanwhile, you can try the following (not tested):
> > - Put the non-embedded assembly in the Resources folder.
> > - Set the BaseDirectory of the current AppDomain to point to the
> Resources
> > folder.
> > - Use the MONO_LOG_LEVEL environment variable to see the assembly
> resolution
> > logs.
> > Regards, Laurent Etiemble.
> >
> > 2010/9/21 anthony taranto <anthony.tara...@gmail.com>
> >>
> >> and of course i forgot the attachment. here it is.
> >>
> >> --anthony
> >>
> >> On Tue, Sep 21, 2010 at 1:41 PM, anthony taranto
> >> <anthony.tara...@gmail.com> wrote:
> >> > Hello,
> >> >
> >> > We're distributing an OS X application using Monobjc's <mkbundle> and
> >> > <mkappl> tasks. The <mkbundle> task embeds the .dll files that our app
> >> > depends on. We would like to selectively blacklist certain .dlls from
> >> > this process due to LGPL/licensing reasons. In other words, I want to
> >> > embed one set of dlls, and load another set of dlls at runtime from
> >> > standalone .dll files in our app bundle. I'd like to know the best way
> >> > to achieve this.
> >> >
> >> > I've attempted to add a <without-assemblies/> sub task to the
> >> > NAnt.Monobjc.dll, which would let me blacklist one or more dlls (patch
> >> > attached). This seems to work, but even after copying the non-embedded
> >> > dll files into My.App/Contents/MacOS, they still can't be loaded at
> >> > runtime. Instead I see the following message:
> >> >
> >> >        ** (MyApp.exe:12143): WARNING **: The following assembly
> >> > referenced
> >> > from My.Embedded.dll could not be loaded:
> >> >             Assembly:   My.NonEmbedded    (assemblyref_index=6)
> >> >             Version:    1.0.0
> >> >             Public Key: xxxxxxxxxxxxxxx
> >> >        The assembly was not found in the Global Assembly Cache, a path
> >> > listed in the MONO_PATH environment variable, or in the location of
> >> > the executing assembly (//).
> >> >
> >> > So, what's the correct way to distribute a standalone Mac application
> >> > that bundles and references LGPL assemblies?
> >> >
> >> > --Anthony
> >> >
> >
> >
>

Reply via email to