[Mono-list] Failed to create shadow copy (CopyFile) exception
Hi, We are working on a project that loads a set of assemblies from different directories starting from a base directory. It is fully functional on Linux (not tested yet on Mac) but on Windows we receive a Failed to create shadow copy (CopyFile) exception just after starting the app. Let me describe a bit the application startup. It is a single executable that loads assemblies found on directories starting from the base path: c:\application\app.exe c:\application\Common\skelwindow\skelwindow.dll c:\application\Common\plugins\plugins.dll ...(and so on) That is, once app.exe starts, he looks inside Common directory to load assemblies matching the pattern NAME\NAME.dll Tracking the problem down to mono/metadata/appdomain.c file, it seems the function that is failing is get_shadow_assembly_location. This is because the following call: dyn_base = mono_string_to_utf8 (domain-setup-dynamic_base); ..which returns NULL because domain-setup-dynamic_base is also NULL. This causes the following g_build_filename to also return NULL, making the caller to fail on CopyFile function (because he tries to copy our assembly to a NULL location). We've tried to check which value should have domain-setup-dynamic_base and why it is NULL, but this goes beyond our knowledge about mono internals... At this point we're not sure if this shadow copy should happen (since we don't reload or update those dll on-the-fly). Any clue or comment on which direction to go would be *really* appreciated. Thanks for your fantastic job. Cheers! PD: All tests are done with mono 2.0 sources, under windows XP professional with all updates included. I'm also attaching differences applied to appdomain.c and output produced by them. -- Francis Brosnan Blazquez [EMAIL PROTECTED] Advanced Software Production Line, S.L. 1097a1098,1099 printf ( MONO: building path dyn_base='%s'\n domain-setup-dynamic_base='%s'\n name_hash='%s'\n path_hash='%s'\n bname='%s'\n, dyn_base, domain-setup-dynamic_base, name_hash, path_hash, bname); 1101a1104 printf ( MONO: returning shadow assembly location '%s'..\n, location); 1254a1258 printf ( MONO: Shadow assembly location: '%s'..\n, shadow); 1262a1267 printf ( MONO: Creating shadow copy '%s' - '%s'..\n, filename, shadow); MONO: building path dyn_base='(null)' domain-setup-dynamic_base='(null)' name_hash='6fe9c425' path_hash='4786f06f_286f344a_' bname='skelwindow.dll' MONO: returning shadow assembly location ''.. MONO: Shadow assembly location: ''.. MONO: Creating shadow copy 'c:\Archivos de programa\gestor-2.0\Common\skelwindow\skelwindow.dll' - ''..___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Failed to create shadow copy (CopyFile) exception
Hi Gonzalo, Looks like a bug. Can you enter it in bugzilla.novell.com? Sure, done [1]. Thanks. To you Gonzalo. Cheers! [1] https://bugzilla.novell.com/show_bug.cgi?id=436189 -Gonzalo -- Francis Brosnan Blazquez [EMAIL PROTECTED] Advanced Software Production Line, S.L. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Mono 1.1.13 has been released.
El mié, 11-01-2006 a las 19:35 +, Bill Seddon escribió: Hi Bill, I have a couple of questions arising from my trials. The first is to ask whether I am the only Windows user of Mono and, if not, am I alone in experiencing problems trying to get applications to run? I think you are not alone, we are producing applications running on top of mono and using Gtk# because we want to run .NET applications on Windows and Linux. I think the main problem you have is that you are using Windows Forms that is still not complete in mono. It's reasonable to ask why someone should be interested in running Mono on Windows when the original .NET is available. Many reasons, first because you can run the same code (we are actually doing so) on windows [1] and linux platforms. Obviously, something could fail. What it could be done is to track and report those failures found so next releases gets better. From our experience, using Mono + Gtk# to produce windows applications is getting more a more stable. From the initial releases we started to use (1.0.5) until now, Mono have increased its quality, and stability. But the point is: how alone is a .NET developer when it gets outside Windows platform? This is critical point to keep in mind if you are going to be a .NET developer. My reason is that Mono applications can be run without an install. .NET requires a lengthy installation (and a reboot with 1.1 SP) that many administrators (if not users) will not consider. Mono can be copied on (or even run from a memory stick). This is a good reason. The second is to ask if there is enough testing being on Windows. The error in the trivial example below results from trying to return the root folder of the drive on which an assembly is located. If there is no real motivation to support Windows, I'd welcome a statement to that effect so that know to look for an alternative solution. Of course, I'd like Windows to be a supported platform but I can understand that it may not be priority for Novell. Maybe it is not a main target for Novell to have a mono platform running on Windows, but I'm not wrong when I say you that there are lot of interest on making mono running on Windows. Cheers! [1] http://gmovil.aspl.es -- Francis Brosnan Blazquez [EMAIL PROTECTED] Advanced Software Production Line, S.L. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
RE: [Mono-list] Re: Embedded Mono with native threads
El vie, 26-08-2005 a las 11:44 +0500, Alexey Tsynaev escribió: On 08/25/05 Alexey Tsynaev wrote: But actually I don't invoke any unmanaged code from c# code Hi Alexey, Where I can get your patch? You can find it in the following Paolo's message: http://lists.ximian.com/pipermail/mono-list/2005-August/028134.html Cheers, ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- Francis Brosnan Blazquez [EMAIL PROTECTED] ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] P/Invoke and threading
El jue, 11-08-2005 a las 11:15 +0100, Steven Kirk escribió: Hello, Hi Steven, I am trying to wrap libjack in mono using P/Invoke but am having problems with the process callback. However when libjack tries to call the delegate I have registered with it, I get the following error: ** ERROR **: Thread 0x409 calling into managed code is not registered with the GC. On UNIX, this can be fixed by #include-ing gc.h before pthread.h in the file containing the thread creation code. This is a long term issue already discused. Thread start here: http://lists.ximian.com/pipermail/mono-list/2004-November/024666.html Then, discuss keep on moving here (where a solution is described): http://lists.ximian.com/pipermail/mono-list/2004-December/024864.html I assume what this is saying is that libjack is calling the delegate on a thread created by itself, which the GC does not know about. I obviously don't want to go adding #includes into the libjack code, is there any other way around this? Maybe there is a solution. Depending on your requirements. Inside the second thread you can find a solution which isolates threading from unmanaged context from managed one. We are using this approach on our project. If the previous solution doesn't work for you, you can try the following: 1) Use the GLib main loop module to attach tasks inside a main loop created by your library (or reusing the main loop the mono runtime creates). You can find more about this issue here: http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html 2) Then, write a glue, outside libjack library, that receives the thread notification and queue the task as a job to be done inside the main loop With this step you have converted the umanaged thread notification into a managed event notification. Event notification will run inside the context of mono. I could provide you source code for a module which makes previous description easy. That is, to execute callbacks inside the mono context. This module will work as the previous glue described. However, if your library is not based on glib, to implement previous solution will make you mono specific. Cheers, -- Francis Brosnan Blazquez [EMAIL PROTECTED] ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Re: [Gtk-sharp-list] Dos window - when launch app on Win32 OS - how to remove it ?
El vie, 15-07-2005 a las 00:45 -0700, Todd Berman escribió: On Fri, 2005-07-15 at 03:45 -0400, ted leslie wrote: I just started using GTK# with mono and was happy that a small little app worked on my linux OS. I moved it to Win2000 and ran it (after installing gtk# runtime) and it works!!! but it brings up a dos window (cmd window?) as well as my GUI window. I don't use Windows to often, but i have to check to make sure what I create in mono/gtk# that I run on Linux, will run on Windows ... I remember something about setting an app to run via console in a older Win OS but I don't see that as an option under properties on Win2000 (on the app icon on desktop), so is the cmd console coming up by default via gtk#/mono? and if so, how can i get rid of it? I thought it might be coming up as a result of some Console.write's so i nuked them, so nothing is going out to STDOUT, but it didn't change it, the cmd console still pops up in addition to my GUI app. Anyone know how to stop this? build your executable with /target:winexe instead of /target:exe Todd, Maybe I'm wrong but on windows installation it isn't posible to disable dos command box while starting mono application. Even setting /target:winexe. On Linux station, this works ---well actually on linux station a console never is showed while starting any application--- but on windows, /target option only disables that the dos box opened doesn't write out info to the console. However it keeps on getting showed. It would be great to ear someone who have managed to disable this dos box on windows platforms. Best regards, --Todd ___ Gtk-sharp-list maillist - Gtk-sharp-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/gtk-sharp-list -- Francis Brosnan Blazquez [EMAIL PROTECTED] Advanced Software Production Line, S.L. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Re: [Gtk-sharp-list] Dos window - when launch app onWin32 OS - how to remove it ?
El vie, 15-07-2005 a las 11:37 +0200, Kornél Pál escribió: Managed applications are not native Win32 applications so the console window (official name of dos box) is not dependent on them. It is dependent however on the exe file that was used to create the native Win32 process. In the case of MS .NET Framework runtime this is the managed exe file altough it's runned against the runtime. In case of Mono this is mono.exe. There is a flag in PE header (IMAGE_OPTIONAL_HEADER.Subsystem) that specifies a subsystem (for example Win32 GUI, Win32 CUI) used by the application. If it is IMAGE_SUBSYSTEM_WINDOWS_CUI it will be attached to the existing console or a new console window will be created it the process group hasn't got one. If it is IMAGE_SUBSYSTEM_WINDOWS_GUI no new console window will be created and the process will not be attached to the existing console window. Mono has IMAGE_SUBSYSTEM_WINDOWS_CUI to be able to provide /target:exe (console) functionality. This results however in a console window for /target:winexe (GUI) applications as well. Hi Kornél, Thanks for your reply, Does this mean that using mono on windos will imply to have allways a dos box, no matter the value used for the /target option? Does this also mean that in the future, mono runtime on windows will allways generate a dos box withtout being a bug, according to your description? Cheers, Kornél -- Francis Brosnan Blazquez [EMAIL PROTECTED] Advanced Software Production Line, S.L. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] is it possible to make C# wrapper for Xfce libraries ?
El mié, 13-07-2005 a las 14:49 +0200, Joeri Belis escribió: I want to extent my Xfce desktop. the Xfce platform libraries are written in C++. Hi Joeri can i make a wrapper in C# around these libs? Not as easy as it would be wrapping C but you still can. Have a look to the following document. http://www.mono-project.com/Interop_with_Native_Libraries Especially Invoking Unmanaged Code section. J Cheers. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- Francis Brosnan Blazquez [EMAIL PROTECTED] Advanced Software Production Line, S.L. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Cygwin woes
El vie, 17-12-2004 a las 17:04 +, Colin JN Breame escribió: Oh right, that might explain it. If mono was built from source in cygwin, will it link to msvcrt.dll? Yes. I'm not sure about the method mono is using to get it compiled, I mean, VisualStudio or Cygwin throught its mingw interface, but this issue doens't matter: both compile mono against msvcrt.dll. Cheers -- Francis Brosnan Blazquez [EMAIL PROTECTED] ___ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
