[us...@lists.monobjc.net] dll.config paths in redistributable apps
Hello, I'm building an application using monobjc. This application has a dll that relies on a compiled c library (dylib). When running my application using the mono installation, I have a dll.config file with the following contents: This config file is placed in the same directory as my .exe and .dll files and i can run the application. When building a standalone application, I can't run it because it can't find libfoo.dylib. This seems to have something to do with relative paths. I notice that the mkappl nant task outputs that it is including and "relocating" the config file. My question is, what path can I supply to the target attribute to get my standalone application to load libfoo.dylib appropriately? Alternatively, how should I approach this problem? Thanks, --Anthony
Re: [us...@lists.monobjc.net] dll.config paths in redistributable apps
I was able to solve my problem by defining target="@executable_path/libfoo.dylib". this has worked great. I have a new issue now. I need to embed a dll into my redistributable application. Some code is trying to load this dll using Assembly.LoadWithPartialName() at runtime. It seems that embedding this dll using the with-assembly sub-tag of my mkbundle task is not sufficient for it to be found by LoadWithPartialName(). I _can_ however distribute this dll outside of the app bundle, and run the app from the command line with the MONO_PATH environment pointed to the dll's path. My question is: how can I include or embed this dll in the app bundle in a way that it can be loaded at runtime? --Anthony On Tue, Feb 16, 2010 at 1:40 PM, Duane Wandless wrote: > I embed my app so your solution will most likely be different. I call: > > mono_config_parse ([configFile UTF8String]); > > Where configFile contains the full path to my target libfoo.dylib. > You can also do this: > MONO_LOG_LEVEL="debug" MONO_LOG_MASK="dll" mono MyProgram.exe > Which will give lots of debug output and help identify why it cannot find > the dll. > Hope this points you in the right direction. > Duane > On Tue, Feb 16, 2010 at 3:49 PM, anthony taranto > wrote: >> >> Hello, >> >> I'm building an application using monobjc. This application has a dll >> that relies on a compiled c library (dylib). When running my >> application using the mono installation, I have a dll.config file with >> the following contents: >> >> >> >> >> >> This config file is placed in the same directory as my .exe and .dll >> files and i can run the application. >> >> When building a standalone application, I can't run it because it >> can't find libfoo.dylib. This seems to have something to do with >> relative paths. I notice that the mkappl nant task outputs that it is >> including and "relocating" the config file. >> >> My question is, what path can I supply to the target attribute to get >> my standalone application to load libfoo.dylib appropriately? >> Alternatively, how should I approach this problem? >> >> Thanks, >> >> --Anthony > >
[us...@lists.monobjc.net] DllImport paths
Hello,
I'm going to ship a custom framework in my monobjc application's app
bundle. This framework is located at
"Contents/Frameworks/Foo.framework/Framework".
When I build a _non_ standalone application bundle (mkappl), i'm able
to successfully invoke methods in this framework using
[DllImport("Contents/Frameworks/Foo.framework/Framework")]. However.
when I build a standalone application bundle (mkbundle, mkappl), the
DllImport fails to find the correct directory.
How should I arrange things so that I can load this framework from
both standalone and non standalone application bundles? Is there some
relative path or dllmap magic that I'm missing?
Thanks.
--Anthony
Re: [us...@lists.monobjc.net] DllImport paths
mport loading:
'libContents/Frameworks/Foo.framework/Foo'.
3/16/10 6:55:02 PM [0x0-0xe33e33].com.MyCompany.MyProject[9524]
Mono-INFO: DllImport error loading library
'dlopen(libContents/Frameworks/Foo.framework/Foo, 9): image not
found'.
3/16/10 6:55:02 PM [0x0-0xe33e33].com.MyCompany.MyProject[9524]
(MyProject.exe:9524): Mono-WARNING **: DllImport unable to load
library 'dlopen(libContents/Frameworks/Foo.framework/Foo, 9): image
not found'.
3/16/10 6:55:02 PM [0x0-0xe33e33].com.MyCompany.MyProject[9524]
System.DllNotFoundException: Contents/Frameworks/Foo.framework/Foo
On Tue, Mar 16, 2010 at 6:42 PM, anthony taranto
wrote:
> Hello,
>
> I'm going to ship a custom framework in my monobjc application's app
> bundle. This framework is located at
> "Contents/Frameworks/Foo.framework/Framework".
>
> When I build a _non_ standalone application bundle (mkappl), i'm able
> to successfully invoke methods in this framework using
> [DllImport("Contents/Frameworks/Foo.framework/Framework")]. However.
> when I build a standalone application bundle (mkbundle, mkappl), the
> DllImport fails to find the correct directory.
>
> How should I arrange things so that I can load this framework from
> both standalone and non standalone application bundles? Is there some
> relative path or dllmap magic that I'm missing?
>
> Thanks.
>
> --Anthony
>
Re: [us...@lists.monobjc.net] DllImport paths
Laurent,
Ah, I'd used @executable_path in a dll.config, it hadn't occurred to
me that it could also be passed to DllImportAttribute.
If I switch my DllImport parameter to use @executable_path/../..., I
can successfully call the unmanaged methods when running my
application as a standalone app bundle, however, it no longer works
when running from a non-standalone app build.
If I can use the same string for both configurations, that would
obviously be ideal. As it is now, I'll probably set up a try/catch
fallback so that I can operate in both configurations.
Thanks,
--Anthony
On Wed, Mar 17, 2010 at 1:56 AM, Laurent Etiemble
wrote:
> Hello,
> If you only want to load the framework (to register some classes), you can
> use the ObjectiveCRuntime.LoadFramework method. It is able to pick private
> framework within an application bundle.
> If you want to access a function within the private framework, then you have
> to use the @executable_path tag in the DllImport attribute.
> th...@executable_path will be expanded at runtime by the dylib loader and
> will refer to the path of the executable. Monobjc uses this trick to be able
> to load at runtime its native library. In you case, the DllImport tag will
> look like:
> [DllImport("@executable_path/../Frameworks/Foo.framework/Foo", ...)]
> Regards, Laurent Etiemble.
>
> 2010/3/17 anthony taranto
>>
>> Here's the mono output when running my standalone app with
>> MONO_LOG_LEVEL="debug" MONO_LOG_MASK="dll"
>>
>> 3/16/10 6:55:02 PM [0x0-0xe33e33].com.MyCompany.MyProject[9524]
>> Mono-INFO: DllImport attempting to load:
>> 'Contents/Frameworks/Foo.framework/Foo'.
>> 3/16/10 6:55:02 PM [0x0-0xe33e33].com.MyCompany.MyProject[9524]
>> Mono-INFO: DllImport loading location:
>> 'libContents/Frameworks/Foo.framework/Foo.dylib'.
>> 3/16/10 6:55:02 PM [0x0-0xe33e33].com.MyCompany.MyProject[9524]
>> Mono-INFO: DllImport error loading library:
>> 'dlopen(libContents/Frameworks/Foo.framework/Foo.dylib, 9): image not
>> found'.
>> 3/16/10 6:55:02 PM [0x0-0xe33e33].com.MyCompany.MyProject[9524]
>> Mono-INFO: DllImport loading location:
>> 'libContents/Frameworks/Foo.framework/Foo.so'.
>> 3/16/10 6:55:02 PM [0x0-0xe33e33].com.MyCompany.MyProject[9524]
>> Mono-INFO: DllImport error loading library:
>> 'dlopen(libContents/Frameworks/Foo.framework/Foo.so, 9): image not
>> found'.
>> 3/16/10 6:55:02 PM [0x0-0xe33e33].com.MyCompany.MyProject[9524]
>> Mono-INFO: DllImport loading location:
>> 'libContents/Frameworks/Foo.framework/Foo.bundle'.
>> 3/16/10 6:55:02 PM [0x0-0xe33e33].com.MyCompany.MyProject[9524]
>> Mono-INFO: DllImport error loading library:
>> 'dlopen(libContents/Frameworks/Foo.framework/Foo.bundle, 9): image not
>> found'.
>> 3/16/10 6:55:02 PM [0x0-0xe33e33].com.MyCompany.MyProject[9524]
>> Mono-INFO: DllImport loading library:
>> './libContents/Frameworks/Foo.framework/Foo.dylib'.
>> 3/16/10 6:55:02 PM [0x0-0xe33e33].com.MyCompany.MyProject[9524]
>> Mono-INFO: DllImport error loading library
>> 'dlopen(./libContents/Frameworks/Foo.framework/Foo.dylib, 9): image
>> not found'.
>> 3/16/10 6:55:02 PM [0x0-0xe33e33].com.MyCompany.MyProject[9524]
>> Mono-INFO: DllImport loading library:
>> './libContents/Frameworks/Foo.framework/Foo.so'.
>> 3/16/10 6:55:02 PM [0x0-0xe33e33].com.MyCompany.MyProject[9524]
>> Mono-INFO: DllImport error loading library
>> 'dlopen(./libContents/Frameworks/Foo.framework/Foo.so, 9): image not
>> found'.
>> 3/16/10 6:55:02 PM [0x0-0xe33e33].com.MyCompany.MyProject[9524]
>> Mono-INFO: DllImport loading library:
>> './libContents/Frameworks/Foo.framework/Foo.bundle'.
>> 3/16/10 6:55:02 PM [0x0-0xe33e33].com.MyCompany.MyProject[9524]
>> Mono-INFO: DllImport error loading library
>> 'dlopen(./libContents/Frameworks/Foo.framework/Foo.bundle, 9): image
>> not found'.
>> 3/16/10 6:55:02 PM [0x0-0xe33e33].com.MyCompany.MyProject[9524]
>> Mono-INFO: DllImport loading: 'Contents/Frameworks/Foo.framework/Foo'.
>> 3/16/10 6:55:02 PM [0x0-0xe33e33].com.MyCompany.MyProject[9524]
>> Mono-INFO: DllImport error loading library
>> 'dlopen(Contents/Frameworks/Foo.framework/Foo, 9): image not found'.
>> 3/16/10 6:55:02 PM [0x0-0xe33e33].com.MyCompany.MyProject[9524]
>> Mono-INFO: DllImport loading location:
>> 'libContents/Frameworks/Foo.framework/Foo.dylib'.
>> 3/16/10 6:55:02 PM [0x0-0xe33e33].com.MyCompany.MyProject[9524]
>> Mono-INFO: DllImport error loading l
[us...@lists.monobjc.net] Intermittent crash potentially related to garbage collection
I'm experiencing an intermittent crash with my multi-threaded monobjc application on OSX 10.6 Snow Leopard. There doesn't seem to be any reliable sequence of user interaction that triggers this crash, but the crash dumps all show a similar pattern: EXC_CRASH in thread 0 while another thread is executing a managed garbage collection after a String.Split(). Example follows. I'm not sure what an appropriate fix or workaround to this problem is. Any help is greatly appreciated. Exception Type: EXC_CRASH (SIGILL) Exception Codes: 0x, 0x Crashed Thread: 0 Dispatch queue: com.apple.main-thread Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 libSystem.B.dylib 0x92b6d2fa mach_msg_trap + 10 1 libSystem.B.dylib 0x92b6da67 mach_msg + 68 2 com.apple.CoreFoundation 0x9945d00f __CFRunLoopRun + 2079 3 com.apple.CoreFoundation 0x9945c0f4 CFRunLoopRunSpecific + 452 4 com.apple.CoreFoundation 0x9945bf21 CFRunLoopRunInMode + 97 5 com.apple.HIToolbox 0x97ada0fc RunCurrentEventLoopInMode + 392 6 com.apple.HIToolbox 0x97ad9eb1 ReceiveNextEventCommon + 354 7 com.apple.HIToolbox 0x97ad9d36 BlockUntilNextEventMatchingListInMode + 81 8 com.apple.AppKit 0x97e12135 _DPSNextEvent + 847 9 com.apple.AppKit 0x97e11976 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 156 10 com.apple.AppKit 0x97dd3bef -[NSApplication run] + 821 11 ??? 0x14b5cdda 0 + 347459034 12 ??? 0x14b5cd04 0 + 347458820 13 ??? 0x14b5cc96 0 + 347458710 14 ??? 0x14b5cc76 0 + 347458678 15 ??? 0x020bc1f2 0 + 34324978 [...] Thread 13: 0 libmono.0.dylib 0x018a9ae4 GC_clear_stack_inner + 22 (misc.c:295) 1 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 (misc.c:301) 2 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 (misc.c:301) 3 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 (misc.c:301) 4 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 (misc.c:301) 5 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 (misc.c:301) 6 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 (misc.c:301) 7 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 (misc.c:301) 8 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 (misc.c:301) 9 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 (misc.c:301) 10 libmono.0.dylib 0x018a9bc1 GC_clear_stack + 153 (misc.c:343) 11 libmono.0.dylib 0x018a5484 GC_malloc_atomic + 150 (malloc.c:262) 12 libmono.0.dylib 0x018114dd mono_object_allocate_ptrfree + 46 (object.c:3824) 13 libmono.0.dylib 0x018117fb mono_string_new_size + 146 (object.c:4395) 14 libmono.0.dylib 0x018407b5 ves_icall_System_String_InternalSplit + 921 (string-icalls.c:145) 15 ??? 0x164849b6 0 + 373836214 [...]
Re: [us...@lists.monobjc.net] Intermittent crash potentially related to garbage collection
Ah good news. This crash was caused by infinite recursion in my code. It wasn't obvious from the trace but luckily I was able to stumble on a repro. --Anthony On Sun, May 16, 2010 at 11:55 PM, Laurent Etiemble wrote: > Hello, > Have you tried to make a small test-case application that would be easy to > debug ? > Maybe a small Cocoa application, with an event loop (as in thread-0) and > some worker threads that create strings, split them and call GC would do the > trick. > Regards, Laurent Etiemble. > > 2010/5/15 anthony taranto >> >> I'm experiencing an intermittent crash with my multi-threaded monobjc >> application on OSX 10.6 Snow Leopard. There doesn't seem to be any >> reliable sequence of user interaction that triggers this crash, but >> the crash dumps all show a similar pattern: EXC_CRASH in thread 0 >> while another thread is executing a managed garbage collection after a >> String.Split(). Example follows. I'm not sure what an appropriate fix >> or workaround to this problem is. Any help is greatly appreciated. >> >> >> Exception Type: EXC_CRASH (SIGILL) >> Exception Codes: 0x, 0x >> Crashed Thread: 0 Dispatch queue: com.apple.main-thread >> >> Thread 0 Crashed: Dispatch queue: com.apple.main-thread >> 0 libSystem.B.dylib 0x92b6d2fa mach_msg_trap + 10 >> 1 libSystem.B.dylib 0x92b6da67 mach_msg + 68 >> 2 com.apple.CoreFoundation 0x9945d00f __CFRunLoopRun + 2079 >> 3 com.apple.CoreFoundation 0x9945c0f4 CFRunLoopRunSpecific + 452 >> 4 com.apple.CoreFoundation 0x9945bf21 CFRunLoopRunInMode + 97 >> 5 com.apple.HIToolbox 0x97ada0fc RunCurrentEventLoopInMode + >> 392 >> 6 com.apple.HIToolbox 0x97ad9eb1 ReceiveNextEventCommon + >> 354 >> 7 com.apple.HIToolbox 0x97ad9d36 >> BlockUntilNextEventMatchingListInMode + 81 >> 8 com.apple.AppKit 0x97e12135 _DPSNextEvent + 847 >> 9 com.apple.AppKit 0x97e11976 -[NSApplication >> nextEventMatchingMask:untilDate:inMode:dequeue:] + 156 >> 10 com.apple.AppKit 0x97dd3bef -[NSApplication run] + 821 >> 11 ??? 0x14b5cdda 0 + 347459034 >> 12 ??? 0x14b5cd04 0 + 347458820 >> 13 ??? 0x14b5cc96 0 + 347458710 >> 14 ??? 0x14b5cc76 0 + 347458678 >> 15 ??? 0x020bc1f2 0 + 34324978 >> >> [...] >> >> Thread 13: >> 0 libmono.0.dylib 0x018a9ae4 GC_clear_stack_inner + 22 >> (misc.c:295) >> 1 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 >> (misc.c:301) >> 2 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 >> (misc.c:301) >> 3 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 >> (misc.c:301) >> 4 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 >> (misc.c:301) >> 5 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 >> (misc.c:301) >> 6 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 >> (misc.c:301) >> 7 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 >> (misc.c:301) >> 8 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 >> (misc.c:301) >> 9 libmono.0.dylib 0x018a9b15 GC_clear_stack_inner + 71 >> (misc.c:301) >> 10 libmono.0.dylib 0x018a9bc1 GC_clear_stack + 153 >> (misc.c:343) >> 11 libmono.0.dylib 0x018a5484 GC_malloc_atomic + 150 >> (malloc.c:262) >> 12 libmono.0.dylib 0x018114dd >> mono_object_allocate_ptrfree + 46 (object.c:3824) >> 13 libmono.0.dylib 0x018117fb mono_string_new_size + 146 >> (object.c:4395) >> 14 libmono.0.dylib 0x018407b5 >> ves_icall_System_String_InternalSplit + 921 (string-icalls.c:145) >> 15 ??? 0x164849b6 0 + 373836214 >> [...] > >
[us...@lists.monobjc.net] Re: [us...@lists.monobjc.net] Creating an agent application
Monobjc's NSApplication.Bootstrap() method actually calls TransformProcessType() and turns your app into a foreground (ie, non agent) app at startup. This will clobber whatever plist settings you have. Luckily, that's the _only_ thing that Bootstrap() is doing, so you can just choose to not call it. --Anthony On Mon, Jun 7, 2010 at 4:56 AM, Laurent Etiemble wrote: > Hello, > I will take a look at it. Stay tuned. > Regards, Laurent Etiemble. > 2010/5/27 Vadim Goldstein >> >> I'm developing an application that should act as agent i.e. application >> without dock icon and menu. >> Documentation states that the only way to do that is adding LSUIElement >> key with value 1 to info.plist file. The problem is that it doesn't work. >> The key is ignored and application acts as a regular application. >> >> I have tried it on sample applications the outcome was the same. >> >> Thanks in advance. >
[users@lists.monobjc.net] [patch] How to _not_ embed a dll using the mkbundle nant task
Hello, We're distributing an OS X application using Monobjc's and tasks. The 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 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: xxx 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
Re: [us...@lists.monobjc.net] [patch] How to _not_ embed a dll using the mkbundle nant task
and of course i forgot the attachment. here it is.
--anthony
On Tue, Sep 21, 2010 at 1:41 PM, anthony taranto
wrote:
> Hello,
>
> We're distributing an OS X application using Monobjc's and
> tasks. The 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 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: xxx
> 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
>
Only in Monobjc-2.0.505.0.orig: dist
diff -ur Monobjc-2.0.505.0.orig/src/tools/NAnt.MonobjcTasks/Tasks/MakeBundleTask.Generation.cs Monobjc-2.0.505.0/src/tools/NAnt.MonobjcTasks/Tasks/MakeBundleTask.Generation.cs
--- Monobjc-2.0.505.0.orig/src/tools/NAnt.MonobjcTasks/Tasks/MakeBundleTask.Generation.cs 2010-06-07 01:05:38.0 -0700
+++ Monobjc-2.0.505.0/src/tools/NAnt.MonobjcTasks/Tasks/MakeBundleTask.Generation.cs 2010-09-21 12:54:12.0 -0700
@@ -22,6 +22,7 @@
using System.Xml;
using System.Xml.Xsl;
using NAnt.Core;
+using NAnt.Core.Types;
using NAnt.Monobjc.Properties;
namespace NAnt.Monobjc.Tasks
@@ -56,6 +57,12 @@
List bundleNames = new List();
Dictionary configNames = new Dictionary();
+Dictionary excludedAssemblies = new Dictionary();
+
+foreach (Argument argument in this.ExcludedAssemblies)
+{
+excludedAssemblies[argument.File.ToString()] = null;
+}
using (StreamWriter sourceWriter = new StreamWriter(File.Create(sourceFile)))
{
@@ -85,6 +92,12 @@
program = absoluteName;
}
+if (excludedAssemblies.ContainsKey(fileName))
+{
+this.Log(Level.Info, "\t\tSkipping Assembly '{0}'", fileName);
+continue;
+}
+
if (this.UseCache)
{
this.Log(Level.Info, "\t\tEmbedding Assembly '{0}'", fileName);
@@ -361,4 +374,4 @@
}
}
}
-}
\ No newline at end of file
+}
diff -ur Monobjc-2.0.505.0.orig/src/tools/NAnt.MonobjcTasks/Tasks/MakeBundleTask.cs Monobjc-2.0.505.0/src/tools/NAnt.MonobjcTasks/Tasks/MakeBundleTask.cs
--- Monobjc-2.0.505.0.orig/src/tools/NAnt.MonobjcTasks/Tasks/MakeBundleTask.cs 2010-02-15 14:35:44.0 -0800
+++ Monobjc-2.0.505.0/src/tools/NAnt.MonobjcTasks/Tasks/MakeBundleTask.cs 2010-09-21 11:34:51.0 -0700
@@ -115,6 +115,13 @@
public Argument[] AdditionalAssemblies { get; set; }
///
+/// Gets or sets the assemblies that will not be embedded.
+///
+/// The assemblies that will not be embedded.
+[BuildElementArray("without-assembly")]
+public Argument[] ExcludedAssemblies { get; set; }
+
+///
/// Gets or sets the additional libraries.
///
/// The additional libraries.
@@ -146,6 +153,15 @@
}
}
+// Check excluded assemblies
+foreach (Argument arg in this.ExcludedAssemblies)
+{
+if (arg.File == null)
+{
+throw new BuildException("Missing 'file' attribute on sub-task");
+}
+}
+
// Check additionnal libraries
foreach (Argument arg in this.AdditionalLibraries)
{
@@ -207,4 +223,4 @@
this.executableFile = Path.Combine(this.ToDirectory.ToString(), baseName);
}
}
-}
\ No newline at end of file
+}
Re: [us...@lists.monobjc.net] [patch] How to _not_ embed a dll using the mkbundle nant task
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 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
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
>>
>> and of course i forgot the attachment. here it is.
>>
>> --anthony
>>
>> On Tue, Sep 21, 2010 at 1:41 PM, anthony taranto
>> wrote:
>> > Hello,
>> >
>> > We're distributing an OS X application using Monobjc's and
>> > tasks. The 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 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: xxx
>> > 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
>> >
>
>
[users@lists.monobjc.net] mkbundle task failing with mono 2.8
Hello, It looks like the mkbundle NAnt task is failing with the mono 2.8 builds for os x. apparently this is because the mono.pc file now does not define any library or include paths. these paths are instead defined in the mono-2.pc pkgconfig file. I had to make a simple change to the file src/tools/NAnt.MonobjcTasks/Tasks/MakeBundleTask.Generation.cs to get it to call pkgconfig with "mono-2" as the argument. --Anthony
