Hi Paul,
Several alternatives can be provided in Registry, separated by commas. For each an attempt to execute it (spawnvp with OVERLAY flag set). The exception is the keyword MONOEMBED that will try to locate and dynamically load an installed Win32 mono.
I tried your patch with Win32 Mono-1.1.17.2 installed but the MONOEMBED option failed for me. I found out this is because mono-1.dll depends on a number of other dlls that can't be found in the search path.
Maybe you could add the Mono dir to the search path? Or instead hand the command line over to mono.exe?
Getting past that hurdle I get this Mono exception:
... System.ArgumentException: FontFamily wasn't found.
-Hans
Hans,
Please see answers inline.
On Mon, 9 Oct 2006, Hans Leidekker wrote:
Hi Paul,
Several alternatives can be provided in Registry, separated by commas. For each an attempt to execute it (spawnvp with OVERLAY flag set). The exception is the keyword MONOEMBED that will try to locate and dynamically load an installed Win32 mono.
I tried your patch with Win32 Mono-1.1.17.2 installed but the MONOEMBED option failed for me. I found out this is because mono-1.dll depends on a number of other dlls that can't be found in the search path.
I have Mono-1.1.17.1 and it loaded the DLL just fine.
Maybe you could add the Mono dir to the search path? Or instead hand the command line over to mono.exe?
I changed the patch to temporarily change the current directory to Mono's so that libraries can be loaded from there. Calling mono.exe is a bad idea but if you want to use it you can put the unix path in registry.
Getting past that hurdle I get this Mono exception:
... System.ArgumentException: FontFamily wasn't found.
Well, mono isn't running all .NET executables, mainly because of lack of libraries. The Win32 version is better in that it supports more than the native one.
Does the same application run with mono.exe or with native mono? That would make it a bug in wine.
-Hans
Paul
On Monday 09 October 2006 17:50, Paul Chitescu wrote:
I changed the patch to temporarily change the current directory to Mono's so that libraries can be loaded from there. Calling mono.exe is a bad idea but if you want to use it you can put the unix path in registry.
Why? Is calling mono.exe worse than calling native mono? At least it's a stable interface. I see you are now checking mono.dll, mono-1.dll and mono-2.dll. What if Mono releases mono-2007.dll? Are the APIs you use declared stable by the Mono project?
Does the same application run with mono.exe or with native mono? That
It produces the same error with mono.exe and a different one with native.
-Hans