Re: [Mono-dev] Embedding Mono: multiple calls to mono_jit_init
Thanks, I will try the dynamic loading. Global variables are gone after my driver is restarted from the host application. -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-multiple-calls-to-mono-jit-init-tp3519842p3525805.html Sent from the Mono - Dev mailing list archive at Nabble.com.___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono: multiple calls to mono_jit_init
Hi, Supporting this would be a _lot_ of work, the most basic problem is that the runtime depends on non-automatic C variables being 0 initialized on startup. You can support this in your app by putting the runtime into a linux shared library (.so) and loading/unloading the shared library yourself using dlopen/dlclose. Zoltan On Fri, May 13, 2011 at 11:56 AM, MartinAlexander martin.arvids...@gmail.com wrote: Hello, Calling mono_jit_init several times is not supported as discussed in other forum posts, but my question is why? Is it a bug that have plans to be solved? Or is it a problem with the Linux architecture? My problem is that I am writing a DLL which is called from an closed-source commercial application with calls like OnInit, OnUninit, OnThis, OnThat and so on. This application has a reload/restart function which unloads the DLL completely and then starts it again. On Windows this works, but not on Linux. Thanks! -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-multiple-calls-to-mono-jit-init-tp3519842p3519842.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono: multiple calls to mono_jit_init
How do you mean? I think this is what I am doing now . I admit I was unclear but the commercial application is written in native C++ and calls my native library (dll/so). In OnInit I call mono_jit_init and in OnUninit I call mono_jit_cleanup. -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-multiple-calls-to-mono-jit-init-tp3519842p3520110.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono: multiple calls to mono_jit_init
You need to use mono's shared library libmono.so, and somehow make the OS load/unload it. Its not easy to do, but doable. Zoltan On Fri, May 13, 2011 at 2:43 PM, MartinAlexander martin.arvids...@gmail.com wrote: How do you mean? I think this is what I am doing now . I admit I was unclear but the commercial application is written in native C++ and calls my native library (dll/so). In OnInit I call mono_jit_init and in OnUninit I call mono_jit_cleanup. -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-multiple-calls-to-mono-jit-init-tp3519842p3520110.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono: multiple calls to mono_jit_init
Wikipedia described how this can be done: http://en.wikipedia.org/wiki/Dynamic_loading#In_C.2FC.2B.2B It's not so difficult at all. You just need to create function pointer variables for the functions you want to call, then use dlopen(...) to open the mono library, and dlsym(...) to lookup a symbol. However, do you really need to cleanup/unload the mono runtime? You could use a global variable to indicate whether the mono runtime has been initialized before, and if it is you don't initialize the runtime again. You don't need to unload the runtime itself. If you want to get rid of what's running, you can probably unload the assembly and application domain. -- Ivo Op 13-5-2011 15:30, Zoltan Varga schreef: You need to use mono's shared library libmono.so, and somehow make the OS load/unload it. Its not easy to do, but doable. Zoltan On Fri, May 13, 2011 at 2:43 PM, MartinAlexander martin.arvids...@gmail.com mailto:martin.arvids...@gmail.com wrote: How do you mean? I think this is what I am doing now . I admit I was unclear but the commercial application is written in native C++ and calls my native library (dll/so). In OnInit I call mono_jit_init and in OnUninit I call mono_jit_cleanup. -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-multiple-calls-to-mono-jit-init-tp3519842p3520110.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto:Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
On 18 March 2011 10:48, vinay_rk vinay.kash...@ironmountain.com wrote: Hi, After several tests with Mono Embedding on Mac OSX on returning to Windows, I see that the first issue that I started this thread with is still the same on windows (Things seem to be fine on Mac). The code I have on windows is as follows: MonoDomain *domain; MonoAssembly *assembly; char *args[1]; args[0] = Test Param; //mono_config_parse(NULL); //mono_set_dirs(NULL,NULL); domain = mono_jit_init (C:\Work\CommonAgent\TestManagedAssembly\TestManagedAssembly\bin\Debug\TestManagedAssembly.exe); assembly = mono_domain_assembly_open (domain, C:\Work\CommonAgent\TestManagedAssembly\TestManagedAssembly\bin\Debug\TestManagedAssembly.exe); if (!assembly) printf(Error); else { mono_jit_exec (domain, assembly,1, args); } While mono_jit_init gets a valid looking pointer, the mono_domain_assembly_open returns a null pointer. Is this because of something I did wrong with the mono.lib I' am linking against.. ? I created the Mono.lib using the mono.def file and with the command: lib /nologo /def:mono.def /out:mono.lib /machine:x86. should I ensure the mono.def file is copied in some particular directory amongst the mono framework installation (directory structure) ? PS: If I try un-commenting the calls to either mono_config_parse or mono_set_dirs, then the mono_jit_init crashes without any particular exception. This is looking like a complete dead end as of now.. ! Regards -Vinay -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-tp3345310p3386882.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Hi, You need to put double backslashes in your path name, as a single backslash is an escape character, in a string literal. e.g.: C:\\Work\\CommonAgent\\TestManagedAssembly\\TestManagedAssembly\\bin\\Debug\\TestManagedAssembly.exe Tom. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
Thanks Tom... !! That looked like the issue.. !! I didn't worry about that earlier coz the domain seemed to get created just fine with such a string... Regards -Vinay -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-tp3345310p3398536.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
Hi, After several tests with Mono Embedding on Mac OSX on returning to Windows, I see that the first issue that I started this thread with is still the same on windows (Things seem to be fine on Mac). The code I have on windows is as follows: MonoDomain *domain; MonoAssembly *assembly; char *args[1]; args[0] = Test Param; //mono_config_parse(NULL); //mono_set_dirs(NULL,NULL); domain = mono_jit_init (C:\Work\CommonAgent\TestManagedAssembly\TestManagedAssembly\bin\Debug\TestManagedAssembly.exe); assembly = mono_domain_assembly_open (domain, C:\Work\CommonAgent\TestManagedAssembly\TestManagedAssembly\bin\Debug\TestManagedAssembly.exe); if (!assembly) printf(Error); else { mono_jit_exec (domain, assembly,1, args); } While mono_jit_init gets a valid looking pointer, the mono_domain_assembly_open returns a null pointer. Is this because of something I did wrong with the mono.lib I' am linking against.. ? I created the Mono.lib using the mono.def file and with the command: lib /nologo /def:mono.def /out:mono.lib /machine:x86. should I ensure the mono.def file is copied in some particular directory amongst the mono framework installation (directory structure) ? PS: If I try un-commenting the calls to either mono_config_parse or mono_set_dirs, then the mono_jit_init crashes without any particular exception. This is looking like a complete dead end as of now.. ! Regards -Vinay -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-tp3345310p3386882.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
On 18.03.2011 11:48, vinay_rk wrote: While mono_jit_init gets a valid looking pointer, the mono_domain_assembly_open returns a null pointer. Is this because of something I did wrong with the mono.lib I' am linking against.. ? I created the Mono.lib using the mono.def file and with the command: lib /nologo /def:mono.def /out:mono.lib /machine:x86. should I ensure the mono.def file is copied in some particular directory amongst the mono framework installation (directory structure) ? No. PS: If I try un-commenting the calls to either mono_config_parse or mono_set_dirs, then the mono_jit_init crashes without any particular exception. You need to call mono_set_dirs under Windows. And mono_config_parse(NULL) must be called *after* mono_set_dirs. This is looking like a complete dead end as of now.. ! This stuff is known to work just fine... As long as you don't post a self-contained test case for these issues, no one will be able to help you. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
Hi, I' am compiling my App from MonoDevelop (with Gcc under the hood). I tried using mono_assembly_setrootdir to set the path to the mono Libraries where MonoPosixHelper.dll and libMonoPosixHelper.dylib are present but it doesn't change anything, I still get the dll not found exception. I also tried mono_config_parse with a dll map element to Map MonoPosixHelper to libMonoPosixHelper.dylib. This didn't help either. Regarding Otool and install_name_tool etc I am not able to follow the suggestions regarding them since I' am not familiar with Mac OSX development. I mainly develop on windows platform but am working on Mac now to make one of our apps cross platform. What else should I try now.. ?? Regards -Vinay -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-tp3345310p3384079.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
On 17.03.2011 11:01, vinay_rk wrote: Hi, I' am compiling my App from MonoDevelop (with Gcc under the hood). I tried using mono_assembly_setrootdir to set the path to the mono Libraries where MonoPosixHelper.dll and libMonoPosixHelper.dylib are present but it doesn't change anything, I still get the dll not found exception. I also tried mono_config_parse with a dll map element to Map MonoPosixHelper to libMonoPosixHelper.dylib. This didn't help either. Regarding Otool and install_name_tool etc I am not able to follow the suggestions regarding them since I' am not familiar with Mac OSX development. I mainly develop on windows platform but am working on Mac now to make one of our apps cross platform. What else should I try now.. ?? Try this (before initializing the root domain): mono_set_dirs (/path/to/mono's/lib, /path/to/mono's/etc); mono_config_parse (NULL); Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
Hi Robert, Thanks for the suggestion... I tried a slight modification of what you posted.. : mono_set_dirs (NULL, NULL); so that the default paths from the installation is applied. My use cases guarentee a Mono framework installed on OSX so I can safely do this. Regards -Vinay -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-tp3345310p3384443.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
Hi, I got the thing to work... but I' am not very thrilled with the resolution... It seems like it'll work only if I use the same string for both MonoDomain creation thru mono_jit_init and also for loading assembly thru mono_domain_assembly_open.. In essense I am having to pass the assembly file path string even for the Domain, I used to think that it just requires a string name for the domain. But with this issue gone.. when I continued my work I hit upon another issue: My managed app uses the Mono.Unix.UnixDirectoryInfo class and at the instantiation of this class I get an exception that says : Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for Mono.Unix.Native.Syscall --- System.DllNotFoundException: MonoPosixHelper at (wrapper managed-to-native) Mono.Unix.Native.Syscall:_L_ctermid () at Mono.Unix.Native.Syscall..cctor () [0x0] in :0 --- End of inner exception stack trace --- at Mono.Unix.UnixFileSystemInfo.GetFileStatus (System.String path, Mono.Unix.Native.Stat stat) [0x0] in :0 at Mono.Unix.UnixFileSystemInfo.Refresh (Boolean force) [0x0] in :0 at Mono.Unix.UnixFileSystemInfo..ctor (System.String path) [0x0] in :0 at Mono.Unix.UnixDirectoryInfo..ctor (System.String path) [0x0] in :0 at SimpleScanner.Program.Main (System.String[] args) [0x0] in :0 I am trying this on Mac OSX and I dont get this problem if I run my exe directly from Terminal using: Mono . So how is the environment different in case of Mono Embedding for this to happen. Any help is highly appreciated... Thanks in advance. -Vinay -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-tp3345310p3356206.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
If you saw the example code I sent I was passing the full path to the EXE to both mono_jit_init and mono_domain_assembly_open. The purpose of embedding is to embed the Mono runtime into your app so that it runs without installing Mono. This error indicates the embedded runtime could not find the MonoPosixHelper dll or dylib. When running mono from the terminal you have the fully installed mono runtime so everything resolved. In my code before calling mono_jit_init I do this: NSString *mPath = [[[NSBundle mainBundle] bundlePath] stringByAppendingPathComponent:@Contents/Libraries/lib]; mono_assembly_setrootdir([mPath UTF8String]); Then I have the folder structure: MyApp.app/Contents/Libraries/lib/mono/2.0/mscorlib.dll MyApp.app/Contents/Libraries/*.dll MyApp.app/Contents/Libraries/libmono-2.0.1.dylib MyApp.app/Contents/Libraries/MyApp.exe I have all DLLs my app depends on. For example, System.Configuration.dll, System.dll, System.Core.dll, Mono.Posix.dll, etc. As well as my DLLs. Your app may also depend on: /Library/Frameworks/Mono.framework/Versions/2.8.2/lib/libMonoPosixHelper.dylib So you have to include that file in the Libraries folder as well as link against it so that it loads at runtime. You can also manually call dlopen passing the correct path to libMonoPosixHelper.dylib. Correct being relative or full, though I recommend full. I do not know how you are compiling your OSX app but otool and install_name_tool were very useful in my understanding of the embedding process. There are also older threads on the mono mailing lists that have more details. You can do a google search to find them mono embed osx duane. http://go-mono.com/forums/#nabble-td1548393 http://web.archiveorange.com/archive/v/IMVlhkecSBeuoQZ4wDcv Hope that helps you move along. Duane On Tue, Mar 15, 2011 at 6:45 AM, vinay_rk vinay.kash...@ironmountain.comwrote: Hi, I got the thing to work... but I' am not very thrilled with the resolution... It seems like it'll work only if I use the same string for both MonoDomain creation thru mono_jit_init and also for loading assembly thru mono_domain_assembly_open.. In essense I am having to pass the assembly file path string even for the Domain, I used to think that it just requires a string name for the domain. But with this issue gone.. when I continued my work I hit upon another issue: My managed app uses the Mono.Unix.UnixDirectoryInfo class and at the instantiation of this class I get an exception that says : Unhandled Exception: System.TypeInitializationException: An exception was thrown by the type initializer for Mono.Unix.Native.Syscall --- System.DllNotFoundException: MonoPosixHelper at (wrapper managed-to-native) Mono.Unix.Native.Syscall:_L_ctermid () at Mono.Unix.Native.Syscall..cctor () [0x0] in :0 --- End of inner exception stack trace --- at Mono.Unix.UnixFileSystemInfo.GetFileStatus (System.String path, Mono.Unix.Native.Stat stat) [0x0] in :0 at Mono.Unix.UnixFileSystemInfo.Refresh (Boolean force) [0x0] in :0 at Mono.Unix.UnixFileSystemInfo..ctor (System.String path) [0x0] in :0 at Mono.Unix.UnixDirectoryInfo..ctor (System.String path) [0x0] in :0 at SimpleScanner.Program.Main (System.String[] args) [0x0] in :0 I am trying this on Mac OSX and I dont get this problem if I run my exe directly from Terminal using: Mono . So how is the environment different in case of Mono Embedding for this to happen. Any help is highly appreciated... Thanks in advance. -Vinay -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-tp3345310p3356206.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
I do not know how you are compiling your OSX app but otool and install_name_tool were very useful in my understanding of the embedding process. If you linking against shared libraries and using install_name_tool, you'll also want to provide the linker flag -headerpad_max_install_names. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
On 10.03.2011 08:26, vinay_rk wrote: I' am trying to Embed Mono with C/C++ and so far I've been able to compile and link my c++ project with the required Mono headers and lib. My code looks something like this: MonoDomain *domain; MonoAssembly *assembly; This will initialize the runtime with its default profile. Depending on the Mono version, this is either 2.0 or 4.0: domain = mono_jit_init (system); You should use mono_jit_init_version () instead and specify v4.0.30319 or v2.0.50727. Maybe your assembly was compiled for the 4.0 profile: assembly = mono_domain_assembly_open (domain, TestManagedAssembly.exe); if (!assembly) printf(Error); else { mono_jit_exec (domain, assembly,0, NULL); This is wrong. mono_jit_exec expects that the file name of the assembly is passed as the first argument. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
Hi Robert, Thanks for the response. As per your suggestion I tried both v4.0.30319 and v2.0.50727 in the mono_jit_init call and used the MonoDomain created from this call to invoke mono_domain_assembly_open. The behavior is still the same. Also for your suggestion about mono_jit_exec, I will try out passing the file name as first argument but as of now I' am not even able to get till there because the mono_domain_assembly_open fails always. Is there any thing else I need to change/try ? Regards -Vinay -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-tp3345310p3345541.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
As Robert indicated your call to mono_jit_exec is wrong. It expects at least 1 argument. It should be the assembly file name. Best of luck, Duane On Thu, Mar 10, 2011 at 5:24 AM, vinay_rk vinay.kash...@ironmountain.comwrote: Hi Robert, Thanks for the response. As per your suggestion I tried both v4.0.30319 and v2.0.50727 in the mono_jit_init call and used the MonoDomain created from this call to invoke mono_domain_assembly_open. The behavior is still the same. Also for your suggestion about mono_jit_exec, I will try out passing the file name as first argument but as of now I' am not even able to get till there because the mono_domain_assembly_open fails always. Is there any thing else I need to change/try ? Regards -Vinay -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-tp3345310p3345541.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
Sorry... read too fast. It might also be useful to indicate which version of Mono you are using and on what platform. This is the code that I use on OSX with Mono 2.6.7 and 2.8.2. Where sampleAssemblyPath is the full path to the EXE. MonoDomain *domain; domain = mono_jit_init ([sampleAssemblyPath UTF8String]); MonoAssembly *monoAssembly = mono_domain_assembly_open(domain, [sampleAssemblyPath UTF8String]); mono_jit_exec (domain, monoAssembly, 1, argv); On Thu, Mar 10, 2011 at 6:15 AM, vinay_rk vinay.kash...@ironmountain.comwrote: Hi Duane, I agree to the point about the call to mono_jit_exec, but as I have mentioned in my previous post I am not able to get to the point of this call since mono_domain_assembly_open never returns a valid pointer. I always get a null pointer from this call. And a non null pointer to MonoAssembly is returned if I try to load mscorlib. Something like this: assembly = mono_domain_assembly_open (domain, mscorlib); Any thoughts ? Regards -Vinay -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-tp3345310p3345621.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
Hi Duane, My Mono version is 2.8. And I have been trying this both on Windows XP and Mac OSX (Leopard and Snow Leopard). And the behavior is exactly the same mono_domain_assembly_open returning a null pointer. I' am totally stumped with trying to figure out what could be wrong with just these 2 lines of code: domain = mono_jit_init (system); assembly = mono_domain_assembly_open (domain, TestManagedAssembly.exe); Since there are not linking errors I' am assuming the right libraries have been linked. Regards -Vinay -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-tp3345310p3347505.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono - NULL return value in C#
On 15.12.2010 09:51, marcus julius wrote: Hi, I call a c++ function from C# using mono. For instance, [MethodImplAttribute(MethodImplOptions.InternalCall)] extern internal static Object get_ai_behavior_object(int id); When the function returns a NULL object, there is a NullReferenceException. I think it occurs because C# tries to cast null to System.Object. Is there a way to avoid this without using try-catch which slows the program or a dummy Null object I need to create? This is expected to work. Please show more code or better file a bug with a self-contained test case. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono into C++
Wow I almost missed your answer. It works like a charm! Thank you! On 24.07.2010 15:11, Frank Fuchs wrote: On a related note is there a way to invoke the mcs compiler from within the code to compile some .cs file. Of course one could try to invoke mcs with a system call or ExecuteProcess but is there something more convenient? As far as I read about the evaluator it seems not to so well suited for this purpose since i don't want/ need line-by-line action or repl. Look at System.CodeDom.Compiler.CodeDomProvider. Something like that: CodeDomProvider provider = CodeDomProvider.CreateProvider (C#); CompilerParameters parms = new CompilerParameters (); params.GenerateExecutable = true; params.OutputAssembly = test.exe; provider.CompileAssemblyFromFile (parms, new string [] {test.cs}); Then wrap this code in a handy C# method that can be conveniently mono_runtime_invoke()-ed from C++. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono into C++
Hi Lucas, thank you very much! Implementing your answer mad me stumble over this one https://bugzilla.novell.com/show_bug.cgi?id=624498. Did you find a workaround? Win7 is one of my deployment platforms. On a related note is there a way to invoke the mcs compiler from within the code to compile some .cs file. Of course one could try to invoke mcs with a system call or ExecuteProcess but is there something more convenient? As far as I read about the evaluator it seems not to so well suited for this purpose since i don't want/ need line-by-line action or repl. -Frank Am 24.07.2010 um 13:53 schrieb Lucas Meijer: Hey Frank, I want to test mono for embedding it into my C++ application. I was following the articles http://www.mono-project.com/Scripting_With_Mono, http://www.mono-project.com/Embedding_Mono and the examples here http://anonsvn.mono-project.com/viewvc/trunk/mono/samples/embed/. So far everything worked well, although I don't understand the restriction for mono_jit_init to be callable just once. So I'm able to load assemblies into the domain and run them, as well as expose some c methods to the Jit. It is possible to load different assemblies, but obviously each assembly can be loaded only once. If the assembly changes on disk after the first load calling mono_domain_assembly_open again, does not reload the changed assembly. Is there any way to achieve the reloading? You can only call mono_jit_init() once. However you can achieve what you want by creating a new domain (mono_domain_create()), and loading your assemblies in that domain. when you decide you want to reload an assembly, you would need to unload your domain, and create a new one again in which you can load your updated assembly. (on win32, you need to make sure you load your assembly into memory first, and ask mono to load it from memory, otherwise it will keep a lock on the on disk assembly, preventing another process from overwriting it). This does mean that you basically loose all your instantiated objects and program state. Depending on what problem you're trying to solve, you can try to somehow store your program's state, then unload domain, recreate domain, and then somehow restore your program's state. that's what we do in unity. Be aware that there's quite significant memory leaks currently when unloading a domain. It's mostly leaking wrapper functions in marshall.c. Depending how on much code you've jitted it might or might not become enough to be a problem. Bye, Lucas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono into C++
On 24.07.2010 15:11, Frank Fuchs wrote: On a related note is there a way to invoke the mcs compiler from within the code to compile some .cs file. Of course one could try to invoke mcs with a system call or ExecuteProcess but is there something more convenient? As far as I read about the evaluator it seems not to so well suited for this purpose since i don't want/ need line-by-line action or repl. Look at System.CodeDom.Compiler.CodeDomProvider. Something like that: CodeDomProvider provider = CodeDomProvider.CreateProvider (C#); CompilerParameters parms = new CompilerParameters (); params.GenerateExecutable = true; params.OutputAssembly = test.exe; provider.CompileAssemblyFromFile (parms, new string [] {test.cs}); Then wrap this code in a handy C# method that can be conveniently mono_runtime_invoke()-ed from C++. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
Guy, You just need to build the runtime. You could also build everything yourself, and then build runtime in 64-bit. You should be able to take a recent mono install for windows, get matching source and build the VS solution for the runtime. There is a x64 target that was working; it may need a little effort now though. I'd be able to help you through any issues if you have them. Thanks, Jonathan On Wed, Jun 9, 2010 at 4:00 PM, guysherman g...@guysherman.com wrote: Hi, I'm looking to embed mono, but I want to embed it inside an x64 C++ application on Windows 7. From what I've heard, a 64-bit assembly on windows cannot load a 32-bit assembly, so I assume I need a 64-bit version of mono. Do I just need to build the runtime for 64-bit, or must I also build mcs and the framework? Thanks, Guy Sherman. -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-tp2249428p2249428.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
Hi Jonathan, I'm also working with an embedded mono application, do you know if I can have full control on the assembly loader for mono? So far I only found a way to specify the probing directory, but what I really need is to instrument assemblies on demand, and that can only be done if I control the loading process. Thanks in advance. On Wed, Jun 9, 2010 at 5:06 PM, Jonathan Chambers jonc...@gmail.com wrote: Guy, You just need to build the runtime. You could also build everything yourself, and then build runtime in 64-bit. You should be able to take a recent mono install for windows, get matching source and build the VS solution for the runtime. There is a x64 target that was working; it may need a little effort now though. I'd be able to help you through any issues if you have them. Thanks, Jonathan On Wed, Jun 9, 2010 at 4:00 PM, guysherman g...@guysherman.com wrote: Hi, I'm looking to embed mono, but I want to embed it inside an x64 C++ application on Windows 7. From what I've heard, a 64-bit assembly on windows cannot load a 32-bit assembly, so I assume I need a 64-bit version of mono. Do I just need to build the runtime for 64-bit, or must I also build mcs and the framework? Thanks, Guy Sherman. -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-tp2249428p2249428.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
Hi Jonathan, Thanks, that's helpful. I don't have cygwin installed so it's a relief that I only need to build the runtime. I'll probably be using VS2010, which will be interesting, but I dare say the projects will upgrade without too much trouble. I'll let you know how it goes. Regards, Guy. On Wed, 9 Jun 2010 16:06:45 -0400, Jonathan Chambers wrote: Guy, You just need to build the runtime. You could also build everything yourself, and then build runtime in 64-bit. You should be able to take a recent mono install for windows, get matching source and build the VS solution for the runtime. There is a x64 target that was working; it may need a little effort now though. I'd be able to help you through any issues if you have them. Thanks, Jonathan On Wed, Jun 9, 2010 at 4:00 PM, guysherman wrote: Hi, I'm looking to embed mono, but I want to embed it inside an x64 C++ application on Windows 7. From what I've heard, a 64-bit assembly on windows cannot load a 32-bit assembly, so I assume I need a 64-bit version of mono. Do I just need to build the runtime for 64-bit, or must I also build mcs and the framework? Thanks, Guy Sherman. -- View this message in context: http://mono.1490590.n4.nabble.com/Embedding-Mono-tp2249428p2249428.html [2] Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com [3] http://lists.ximian.com/mailman/listinfo/mono-devel-list [4] -- GUY SHERMAN web: www.guysherman.com phone: +64 21 355 190 email g...@guysherman.com Links: -- [1] mailto:g...@guysherman.com [2] http://mono.1490590.n4.nabble.com/Embedding-Mono-tp2249428p2249428.html [3] mailto:Mono-devel-list@lists.ximian.com [4] http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono
On 09.06.2010 23:14, Thiago Padilha wrote: Hi Jonathan, I'm also working with an embedded mono application, do you know if I can have full control on the assembly loader for mono? So far I only found a way to specify the probing directory, but what I really need is to instrument assemblies on demand, and that can only be done if I control the loading process. Look at metadata/assembly.h: /* Installs a function which is called before a new assembly is loaded * The hook are invoked from last hooked to first. If any of them returns * a non-null value, that will be the value returned in mono_assembly_load */ typedef MonoAssembly * (*MonoAssemblyPreLoadFunc) (MonoAssemblyName *aname, gchar **assemblies_path, gpointer user_data); void mono_install_assembly_preload_hook (MonoAssemblyPreLoadFunc func, gpointer user_data); void mono_install_assembly_refonly_preload_hook (MonoAssemblyPreLoadFunc func, gpointer user_data); Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding mono and reducing the number of etc/lib required files
romain lelong wrote: - Is it possible to fuse all these lib etc files directly inside the .EXE file or into one big external resources file ? I would like to hide all these small files and limit the risk for an user to damage or hijack my program by removing/replacing the libraries in these directories... Have a look at mkbundle, a tool which comes with Mono: http://www.mono-project.com/Guide:Running_Mono_Applications#Bundles Use the --nomain option and call mono_mkbundle_init () just before mono_jit_init () in you app. Note that you need cygwin to be able to create bundles on Windows. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono.
On Tue, 2008-08-05 at 04:17 +0200, BaSS wrote: When using mono.dll for scripting/embedding purposes, the only way to get “scrip code” into the compiler is to use a “native” .net assembly and move the script code into the managed world first? AFAIK, yes. The rationale is that Mono provides a .NET runtime, and a plain .NET runtime does not contain a compiler-interpreter for an arbitrary scripting language... it just allows you to execute managed code from existing assemblies. Or is there some obvious exported method somewhere in the dll where I can directly inject “(script) code to be executed” into the JIT (and execute it)? If you provide a managed DLL containing your interpreter-compiler, you can invoke its methods from unmanaged code using the embedding API. This would be a single invocation that executes a script. Otherwise you could try to use a methodbuilder from unmanaged code, but I don't know if it can work and I doubt it would be worth the effort... My 2c, Massi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono + SWIG string return values leads to bad free
Looking at the marshal.c code, this may be a problem in the runtime. We allocate return strings using mono_marshal_alloc (evaluates to CoTaskMemAlloc on Windows). However, we always free returned strings using g_free on all platforms. I suppose we should use mono_marshal_free instead? Please review attached patch. Not sure if this will fix your issue, but it may. Code is contributed under MIT/X11 license. Thanks, Jonathan On Fri, Apr 25, 2008 at 7:16 PM, Miguel de Icaza [EMAIL PROTECTED] wrote: [resending, email server not working] On Thu, 2008-04-24 at 18:33 -0400, Miguel de Icaza wrote: Hello, The returned string is passed back to the SWIG C# class and used (successfully) and then later the GC tries to collect it and fails. The C# delegate is just something like The GC does not collect strings returned from P/Invoke, but it will free return values. If you are returning strings that are now malloc()ed (and ownership is transferred to the caller), you may want to change the P/Invoke signature to return an IntPtr, and then use Marshal.PtrToStringAuto ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Index: mono/mono/metadata/ChangeLog === --- mono/mono/metadata/ChangeLog (revision 103274) +++ mono/mono/metadata/ChangeLog (working copy) @@ -1,3 +1,10 @@ +2008-05-15 Jonathan Chambers [EMAIL PROTECTED] + + * metadata.c (emit_marshal_string): Free return strings using mono_marshal_free + instead of g_free. + + Code is contributed under MIT/X11 license. + 2008-05-14 Rodrigo Kumpera [EMAIL PROTECTED] * class.c: Revert unrelated change. Index: mono/mono/metadata/marshal.c === --- mono/mono/metadata/marshal.c (revision 103274) +++ mono/mono/metadata/marshal.c (working copy) @@ -6230,7 +6230,7 @@ if (conv == MONO_MARSHAL_CONV_BSTR_STR) mono_mb_emit_icall (mb, mono_free_bstr); else - mono_mb_emit_icall (mb, g_free); + mono_mb_emit_icall (mb, mono_marshal_free); break; case MARSHAL_ACTION_MANAGED_CONV_IN: ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono + SWIG string return values leads to bad free
[resending, email server not working] On Thu, 2008-04-24 at 18:33 -0400, Miguel de Icaza wrote: Hello, The returned string is passed back to the SWIG C# class and used (successfully) and then later the GC tries to collect it and fails. The C# delegate is just something like The GC does not collect strings returned from P/Invoke, but it will free return values. If you are returning strings that are now malloc()ed (and ownership is transferred to the caller), you may want to change the P/Invoke signature to return an IntPtr, and then use Marshal.PtrToStringAuto ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono + SWIG string return values leads to bad free
Hi, Ewen Cheslack-Postava wrote: This seems to work well on Linux and Mac OS X, but on Windows it causes an exception when the GC tries to free that same memory. I've verified that I do in fact get a new copy of the string out at a different address from the original. It looks like maybe the string is just being double freed. The specific error I get (only in the Visual Studio debugger) is: HEAP[x.exe]: Invalid Address specified to RtlFreeHeap( 01E0, 00166C78 ) On Windows, the char* returned by the C# method must be freed with GlobalFree (). You're probable using free () which is expecting that the memory was allocated from another heap. This is for compatibility with MS.NET. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono + SWIG string return values leads to bad free
That's what's odd, I'm not even freeing the memory. Mono's GC is. The call path goes something like: My C code - mono_runtime_invoke - C# methods - SWIG C# class - PInvoke call returning char* - C call to C# delegate - C# returns a string The returned string is passed back to the SWIG C# class and used (successfully) and then later the GC tries to collect it and fails. The C# delegate is just something like static string CreateString(string input) { return input; } I assumed what was happening was that the callback being returned to C code for calling was handling marshalling the char* to a MonoString and passing it into C# code and that same string was being returned and was safe to use (since Mono allocated it). But for some reason on Windows its giving me the free error when the GC tries to free it. -Ewen On Wed, Apr 23, 2008 at 5:12 AM, Robert Jordan [EMAIL PROTECTED] wrote: Hi, Ewen Cheslack-Postava wrote: This seems to work well on Linux and Mac OS X, but on Windows it causes an exception when the GC tries to free that same memory. I've verified that I do in fact get a new copy of the string out at a different address from the original. It looks like maybe the string is just being double freed. The specific error I get (only in the Visual Studio debugger) is: HEAP[x.exe]: Invalid Address specified to RtlFreeHeap( 01E0, 00166C78 ) On Windows, the char* returned by the C# method must be freed with GlobalFree (). You're probable using free () which is expecting that the memory was allocated from another heap. This is for compatibility with MS.NET. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding mono on windows: the missing (lib)mono.lib
Hi, Sebastian Good wrote: I am attempting to embed a mono runtime in my C++ application. I'm using the standard 1.4.2 mono install (on WinXP) Visual Studio 2005. I've generated the expected C++ compiler flags using pkg-config --msvc-syntax --cflags --libs mono And while my simple hello-world embedding application now compiles nicely, it fails to link with LNK1104: cannot open file 'mono.lib' I can confirm my install has no 'mono.lib', or even 'libmono.lib'. A search of this list and other sites suggests this is not all that uncommon. People seem to be trying to build mono using Cygwin in order to recreate the missing mono.lib (and sometimes running into other problems doing that). Am I being a knucklehead or is the standard mono Windows install missing this library? Is there an alternative to building mono myself? Should I be more interested in the '*.a' files sitting in my /lib directory? Quick workaround: mono.def (see attachment) is built during the cygwin build process. From this file, you can generate mono.lib using MSVC's lib tool: lib /nologo /machine:x86 /def:mono.def /out:mono.lib Because the embedded API is stable, i.e. doesn't change often, you can use the lib with several Mono versions. Robert ; file generated by create-windef.pl LIBRARY mono.dll EXPORTS mono_add_internal_call mono_alloc_special_static_data mono_array_class_get mono_array_clone mono_array_element_size mono_array_new mono_array_new_full mono_array_new_specific mono_assemblies_cleanup mono_assemblies_init mono_assembly_close mono_assembly_fill_assembly_name mono_assembly_foreach mono_assembly_get_assemblyref mono_assembly_get_image mono_assembly_get_main mono_assembly_get_object mono_assembly_getrootdir mono_assembly_invoke_load_hook mono_assembly_invoke_search_hook mono_assembly_load mono_assembly_load_from mono_assembly_load_from_full mono_assembly_load_full mono_assembly_load_module mono_assembly_load_reference mono_assembly_load_references mono_assembly_load_with_partial_name mono_assembly_loaded mono_assembly_loaded_full mono_assembly_names_equal mono_assembly_open mono_assembly_open_full mono_assembly_set_main mono_assembly_setrootdir mono_bitset_alloc_size mono_bitset_clear mono_bitset_clear_all mono_bitset_clone mono_bitset_copyto mono_bitset_count mono_bitset_equal mono_bitset_find_first mono_bitset_find_first_unset mono_bitset_find_last mono_bitset_find_start mono_bitset_foreach mono_bitset_free mono_bitset_intersection mono_bitset_intersection_2 mono_bitset_invert mono_bitset_mem_new mono_bitset_new mono_bitset_set mono_bitset_set_all mono_bitset_size mono_bitset_sub mono_bitset_test mono_bitset_test_bulk mono_bitset_union mono_bounded_array_class_get mono_burg_emit mono_burg_init mono_burg_kids mono_burg_label mono_burg_rule mono_check_corlib_version mono_class_array_element_size mono_class_data_size mono_class_describe_statics mono_class_enum_basetype mono_class_from_generic_parameter mono_class_from_mono_type mono_class_from_name mono_class_from_name_case mono_class_from_typeref mono_class_get mono_class_get_byref_type mono_class_get_element_class mono_class_get_event_token mono_class_get_events mono_class_get_field mono_class_get_field_from_name mono_class_get_field_token mono_class_get_fields mono_class_get_flags mono_class_get_full mono_class_get_image mono_class_get_interfaces mono_class_get_method_from_name mono_class_get_method_from_name_flags mono_class_get_methods mono_class_get_name mono_class_get_namespace mono_class_get_nested_types mono_class_get_nesting_type mono_class_get_parent mono_class_get_properties mono_class_get_property_from_name mono_class_get_property_token mono_class_get_rank mono_class_get_type mono_class_get_type_token mono_class_inflate_generic_method mono_class_inflate_generic_method_full mono_class_inflate_generic_type mono_class_init mono_class_instance_size mono_class_is_assignable_from mono_class_is_enum mono_class_is_subclass_of mono_class_is_valuetype mono_class_min_align mono_class_name_from_token mono_class_num_events mono_class_num_fields mono_class_num_methods mono_class_num_properties mono_class_value_size mono_class_vtable mono_cli_rva_image_map mono_code_manager_commit mono_code_manager_destroy mono_code_manager_foreach mono_code_manager_invalidate mono_code_manager_new mono_code_manager_new_dynamic mono_code_manager_reserve mono_compile_method mono_config_for_assembly mono_config_parse mono_config_parse_memory mono_config_string_for_assembly_file mono_context_get mono_context_init mono_context_set mono_counters_dump mono_counters_enable mono_counters_register mono_custom_attrs_construct mono_custom_attrs_free mono_custom_attrs_from_assembly mono_custom_attrs_from_class mono_custom_attrs_from_event mono_custom_attrs_from_field mono_custom_attrs_from_index mono_custom_attrs_from_method mono_custom_attrs_from_param mono_custom_attrs_from_property mono_custom_attrs_get_attr mono_custom_attrs_has_attr mono_debug_add_method mono_debug_cleanup
Re: [Mono-dev] Embedding Mono and HandleRef...
Thomas Wiest wrote: Robert Jordan wrote: You don't need HandleRefs when using icalls and the embedded API. Just declare the icalls as non-static and they will automatically get the MonoObject* pointer of the managed object: Ah, very interesting. I assume this increases the ref count which assures that the object won't get collected until after the native code returns. Is that right? It doesn't increase any ref count because Mono'n GC is not based on ref counts. The circumstance that you're able to call the icall at all, means that the object is still alive, i.e. it's on the current execution stack or stored in another object that is still alive. During the icall itself the object is on the stack (1) (it's the first argument of the icall), hence it can't be GCed. Since P/Invoke methods don't have the this parameter (they are static), the object could be GCed during the p/invoke call. That's why GCHandles and HandeRefs are needed. (1) or in a processor register, but they are monitored as well. Also, to pass the person struct IntPtr from C# to C, which is recommended; pass it as a parameter, or use mono_runtime_invoke to pull it out of the property? I would assume that passing it as a parameter is quicker since it saves a function call. It is faster to pass it as a parameter. Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono and HandleRef...
Thomas Wiest wrote: Hey, I'm using the Mono embedding API and I'm using HandleRef's instead of IntPtr's (as per the instructions on the interop page). http://www.mono-project.com/Interop_with_Native_Libraries However, the HandleRef's seem to only be marshaled to IntPtr's if you're using p/invoke's. I've attached a tar ball with two examples of what I'm trying to do. Both examples can be compiled and run using make run. The Dll_Import example works flawlessly, marshaling the HandleRef into an IntPtr. The mono_embed fails miserably because the HandleRef is still a MonoObject (notice the memory address' don't line up as they do in the Dll_Import example). From Robert Jordan's earlier e-mail it seems that the HandleRef is intentionally not marshaled. So my question is, how do I get the advantages of HandleRef's when using the embedding API? And if I just switch back to IntPtr's, will my C# objects get collected before my native code is done executing? You don't need HandleRefs when using icalls and the embedded API. Just declare the icalls as non-static and they will automatically get the MonoObject* pointer of the managed object: C# class Person { [MethodImplAttribute(MethodImplOptions.InternalCall)] public extern void print_person(); } C: void print_person(MonoObject* this) { } Robert ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Embedding Mono and HandleRef...
Robert Jordan wrote: You don't need HandleRefs when using icalls and the embedded API. Just declare the icalls as non-static and they will automatically get the MonoObject* pointer of the managed object: Ah, very interesting. I assume this increases the ref count which assures that the object won't get collected until after the native code returns. Is that right? Also, to pass the person struct IntPtr from C# to C, which is recommended; pass it as a parameter, or use mono_runtime_invoke to pull it out of the property? I would assume that passing it as a parameter is quicker since it saves a function call. Thanks for your help, it's quite an eye opener. Thomas ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list