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
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
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
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:
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 .
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
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
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 -
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;
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:
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
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
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
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
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
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.
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
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
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
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
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
Hi,
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;
domain = mono_jit_init (system);
assembly =
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
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
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
Hi,
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
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
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
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
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
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
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,
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
Hello there, I'm new to the forums and to mono.
Hopefully I'm at the right place here...
I want to embed mono to a C++ application, using Visual C++.
Unfortunately I'm not very experienced at including and linking and whatever
is needed to get external libaries working with my project.
I've
Hello everyone,
I've managed to embed Mono in a c++ program without trouble (under MS Windows)
but I would like to optimize this a little...
As I want to do a standalone application, I used the mono_set_dirs()
function and copied the whole of lib and etc directories from the mono
installation
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
Hi, All!
Now I'm playing with embeddig mono in my own apache2 module. Everything
works fine except one think, that can be a big problem in future module
developing. The problem is that mono produce some errors on apache server
stopping. So i try to reduce my sources to few line with just one
Hi Guys,
I’m trying to embed the mono runtime into a test application and then pass
“script” code to a class in the assembly which is supposed to compile the
script into an assembly and run it (etc etc..).
The basics seem to work, I can call methods in the class, show message boxes
etc, but
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
Hi Guys,
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? Or is there some obvious exported
method somewhere in the dll where I can directly inject
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
[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
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
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
Hi,
I'm embedding Mono and using SWIG to wrap a few simple C++ objects.
They use PInvoke to wrap these objects and for string/char* return
values they use a C# delegate in order to obtain a string owned by the
GC so it can safely be returned. They use a simple C# static method
where the string
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
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
Hi
if mono is embedded on OS X into an application that already has the
Carbon framework loaded, we run into two name collisions. This eg was
also referred to by
http://lists.ximian.com/pipermail/mono-list/2006-October/032929.html
My suggestion is to extend the already existing renaming
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
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
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
Hasn't anyone used Visual Studio 2005 for running Mono embed samples? I'm still trying to figure why I get Access violation reading location -error messages when I try to run my program. I've located the error in GetSystemTimeAsFileTime -method which is called from __security_init_cookie(), but
52 matches
Mail list logo
