Re: [Mono-dev] Building nant-0.85 against Mono-1.2.4
AFAIK this is fixed in nant repo, try building nant-nightly. Or build nant with older mono, it'll work the same. On 4/24/07, marek safar [EMAIL PROTECTED] wrote: Hello Paul, I'm trying to build NAnt-0.85 against Mono-1.2.4 and it's throwing the following error. Does anyone know of a fix for it? The Nant bug reporter has something about it here http://sourceforge.net/tracker/index.php?func=detailaid=1675297group_id=31650atid=402868 but there isn't a fix on the site for it - is there one? The warning is correct and can be easily fixed. InitializeElement is virtual method marked as obsolete but not in all its instances. To fix the warning you have to either remove Obsolete attribute or add Obsolete attribute to all virtual/overrides of the method. Regards, Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- MS-DOS user since 5.0 Windows user since 3.11 Linux user since kernel 2.4 Novell Netware user since 2.2 WARCRAFT user since 1.0 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Building nant-0.85 against Mono-1.2.4
- Oorspronkelijk bericht - Van: Leszek Ciesielski [mailto:[EMAIL PROTECTED] Verzonden: dinsdag, april 24, 2007 08:28 AM Aan: 'marek safar', 'mono-devel' Onderwerp: Re: [Mono-dev] Building nant-0.85 against Mono-1.2.4 AFAIK this is fixed in nant repo, try building nant-nightly. This was indeed fixed in cvs a while ago. I've also modified our build procedure to only consider warnings as error for nightly builds and dev builds; as a result, we won't run into a similar situation again. Gert Or build nant with older mono, it'll work the same. On 4/24/07, marek safar [EMAIL PROTECTED] wrote: Hello Paul, I'm trying to build NAnt-0.85 against Mono-1.2.4 and it's throwing the following error. Does anyone know of a fix for it? The Nant bug reporter has something about it here http://sourceforge.net/tracker/index.php?func=detailaid=1675297group_id=31650atid=402868 but there isn't a fix on the site for it - is there one? The warning is correct and can be easily fixed. InitializeElement is virtual method marked as obsolete but not in all its instances. To fix the warning you have to either remove Obsolete attribute or add Obsolete attribute to all virtual/overrides of the method. Regards, Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- MS-DOS user since 5.0 Windows user since 3.11 Linux user since kernel 2.4 Novell Netware user since 2.2 WARCRAFT user since 1.0 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list - Oorspronkelijk bericht - Van: Leszek Ciesielski [mailto:[EMAIL PROTECTED] Verzonden: dinsdag, april 24, 2007 08:28 AM Aan: 'marek safar', 'mono-devel' Onderwerp: Re: [Mono-dev] Building nant-0.85 against Mono-1.2.4 AFAIK this is fixed in nant repo, try building nant-nightly. This was indeed fixed in cvs a while ago. I've also modified our build procedure to only consider warnings as error for nightly builds and dev builds; as a result, we won't run into a similar situation again. Gert Or build nant with older mono, it'll work the same. On 4/24/07, marek safar [EMAIL PROTECTED] wrote: Hello Paul, I'm trying to build NAnt-0.85 against Mono-1.2.4 and it's throwing the following error. Does anyone know of a fix for it? The Nant bug reporter has something about it here http://sourceforge.net/tracker/index.php?func=detailaid=1675297group_id=31650atid=402868 but there isn't a fix on the site for it - is there one? The warning is correct and can be easily fixed. InitializeElement is virtual method marked as obsolete but not in all its instances. To fix the warning you have to either remove Obsolete attribute or add Obsolete attribute to all virtual/overrides of the method. Regards, Marek ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- MS-DOS user since 5.0 Windows user since 3.11 Linux user since kernel 2.4 Novell Netware user since 2.2 WARCRAFT user since 1.0 ___ 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-dev] Problem with Request.Browser.MSDomVersion and Firefox
try this aspx with firefox
%@ Page Language=C# %
Head
script language=CS runat=server
void Page_Load(object sender, System.EventArgs e)
{
Console.WriteLine(Request.Browser.W3CDomVersion);
Console.WriteLine(Request.Browser.MSDomVersion);
}
/script
/Head
and you'll get
Argument cannot be null. Parameter name: browscaps.ini does not contain
a definition for capability msdomversion for userAgent Mozilla
Description: Error processing request.
Error Message: HTTP 500. System.ArgumentNullException: Argument cannot
be null. Parameter name: browscaps.ini does not contain a definition for
capability msdomversion for userAgent Mozilla
Stack Trace:
System.ArgumentNullException: Argument cannot be null.
Parameter name: browscaps.ini does not contain a definition for capability
msdomversion for userAgent Mozilla
at System.Web.HttpBrowserCapabilities.ReadVersion (System.String key)
[0x0]
at System.Web.HttpBrowserCapabilities.get_MSDomVersion () [0x0]
at MetaBuilders.WebControls.ClientScriptUtil.get_RenderUplevel () [0x0]
at MetaBuilders.WebControls.ConfirmedLinkButton.OnPreRender (System.EventArgs
e) [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Page.InternalProcessRequest () [0x0]
at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context)
[0x0]
It use to work well with mono 1.2.3
The problem is that we have an external asp.net component using this
property... This should'nt crash...
___
Ce message et les éventuels documents joints peuvent contenir des informations
confidentielles.
Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir
le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce
message non conforme à sa destination, toute diffusion ou publication, totale
ou partielle et quel qu'en soit le moyen est formellement interdite.
Les communications sur internet n'étant pas sécurisées, l'intégrité de ce
message n'est pas assurée et la société émettrice ne peut être tenue pour
responsable de son contenu.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Semaphores problem with latest mono 1.2.4 svn...
Ok the problem appear when i use mono-service... i'm investigating on this issue... Le lundi 23 avril 2007 à 14:46 +0200, Hubert FONGARNAND a écrit : I've tried to upgrade my beta server with mono 1.2.4 from svn from 1.2.3.50 I launch my mod_mono_servers and i get semaphore errors problem... When i launch webpage (or when i launch xsp) I never had such problems before... was passiert??? Sincerely Hubert FONGARNAND [EMAIL PROTECTED] CASServer]$ xsp ** ERROR **: shm_semaphores_init: semget error: Aucun espace disponible sur le périphérique. Try deleting some semaphores with ipcs and ipcrm or increase the maximum number of semaphore in the system. aborting... Stacktrace: Native stacktrace: /usr/bin/mono [0x8154055] [0xe440] /lib/tls/libc.so.6(abort+0xe9) [0x2c1199] /usr/lib/libglib-2.0.so.0(g_log+0) [0x5ffebe] /usr/lib/libglib-2.0.so.0(g_log+0x32) [0x5ffef0] /usr/bin/mono [0x8106a2c] /usr/bin/mono [0x80fffae] /usr/bin/mono(mono_once+0xdc) [0x80f6068] /usr/bin/mono [0x8100594] /usr/bin/mono [0x80fb9c8] /usr/bin/mono [0x80defbc] /usr/bin/mono(mono_runtime_init+0x21) [0x80b262d] /usr/bin/mono [0x8140eaa] /usr/bin/mono(mono_main+0x2a3) [0x8058293] /usr/bin/mono [0x8057ba7] /lib/tls/libc.so.6(__libc_start_main+0xd3) [0x2ace23] /usr/bin/mono [0x8057b09] Debug info from gdb: = Got a SIGABRT while executing native code. This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application. = Abandon [EMAIL PROTECTED] CASServer]$ ipcs -- Segment de mémoire partagé clé shmid propriétaire perms octets nattch états 0x 65536 hubert600393216 2 dest 0x 98305 hubert600196608 2 dest 0x 131074 hubert600393216 2 dest 0x 163843 hubert600196608 2 dest 0x 196612 hubert600393216 2 dest 0x 229381 hubert600393216 2 dest 0x 262150 hubert600393216 2 dest 0x 294919 hubert600393216 2 dest 0x 327688 hubert600393216 2 dest 0x 360457 hubert600393216 2 dest 0x 393226 hubert600196608 2 dest 0x 425995 hubert600393216 2 dest 0x 458764 hubert600393216 2 dest 0x 491533 hubert600196608 2 dest 0x 557070 hubert600393216 2 dest -- Tableaux de sémaphores clé semid propriétaire perms nsems 0x4d00184c 0 hubert6008 0x4d00184d 65537 hubert6008 0x 819202 hubert6001 0x 851971 hubert6001 0x4d00185d 884740 hubert6008 0x4d00184e 196613 hubert6008 0x4d00184f 229382 hubert6008 0x4d001850 262151 hubert6008 0x4d001851 294920 hubert6008 0x4d001852 327689 hubert6008 0x4d001853 360458 hubert6008 0x4d001854 393227 hubert6008 0x4d001855 425996 hubert6008 0x4d001856 458765 hubert6008 0x4d001857 491534 hubert6008 0x4d001858 524303 hubert6008 0x4d001859 557072 hubert6008 0x4d00185a 589841 hubert6008 0x4d00185b 622610 hubert6008 0x4d00185c 655379 hubert6008 0x4d00185e 917524 hubert6008 0x4d00185f 950293 hubert6008 0x4d001860 983062 hubert6008 0x4d001861 1015831hubert6008 0x4d001862 1048600hubert6008 0x4d001863 1081369hubert6008 0x4d001864 1114138hubert6008 0x4d001865 1146907hubert6008 0x4d001866 1179676hubert6008 0x4d001867 1212445hubert6008 0x4d001868 1245214hubert6008 0x4d001869 1277983hubert6008 0x4d00186a 1310752hubert6008 0x4d00186b 1343521hubert6008 0x4d00186c 1376290hubert6008 0x4d00186d 1409059hubert6008 0x4d00186e 1441828hubert6008 0x4d00186f 1474597hubert6008 0x4d001870 1507366hubert6008 0x4d001871 1540135hubert6008 0x4d001872 1572904hubert600
Re: [Mono-dev] Stubs for two missing methods in Managed.Windows.Forms
-Original Message- From: [EMAIL PROTECTED] [mailto:mono-devel-list- [EMAIL PROTECTED] On Behalf Of Leszek Ciesielski Sent: viernes, 20 de abril de 2007 19:51 To: mono-devel Subject: [Mono-dev] Stubs for two missing methods in Managed.Windows.Forms I am fiddling around trying to get EveMon to work on mono, this patch adds stubs for two missing methods. Changelog included. Patch committed, thanks! Rolf ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] patch to start bonding navigator and masked textbox
-Original Message- From: [EMAIL PROTECTED] [mailto:mono-devel-list- [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: lunes, 23 de abril de 2007 23:31 To: mono-devel-list@lists.ximian.com Subject: [Mono-dev] patch to start bonding navigator and masked textbox Hi, I try again to send a patch to mailing list. Hope this one this will work... This patch is just a basic bindingnavigator with test and a stub of masked textbox with some basic things taken from msdn but with no methode implementation. I have been working a Little bit on MaskedTextBox, so I'll copy over parts of your patches as you have some things I didn't. Rolf ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] patch to start bonding navigator and masked textbox
Olivier, the first revision of Binding Navigator has hit SVN. Thanks for the patch! Alan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] This code not this worked in Linux.
Module1.vb Module Module1 Sub Main() FileOpen(1, file.txt, OpenMode.Input, OpenAccess.Read) Do Until EOF(1) Console.Write(LineInput(1) Chr(10) Chr(13)) Loop FileClose(1) End Sub End Module file.txt Hello Word Line 01 Hello Word Line 02 Hello Word Line 03 Some help? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] This code not this worked in Linux.
Hi, FileOpen seems not to be implemented yet in Mono. Use StreamReader instead that is much better than the VB6-like file handling and is implemented by Mono as well. Also note that Chr(10) Chr(13) sequence is not used by an modern operating systems as new line. Windows uses CR, LF (#13, #10) and Unix-like systems use LF (#10). You should use ReadLine, WriteLine methods or Environment.NewLine property instead of using hard coded new line sequences. Kornél - Original Message - From: LB Audio Uchoa NET [EMAIL PROTECTED] To: mono-devel-list@lists.ximian.com Sent: Tuesday, April 24, 2007 3:07 PM Subject: [Mono-dev] This code not this worked in Linux. Module1.vb Module Module1 Sub Main() FileOpen(1, file.txt, OpenMode.Input, OpenAccess.Read) Do Until EOF(1) Console.Write(LineInput(1) Chr(10) Chr(13)) Loop FileClose(1) End Sub End Module file.txt Hello Word Line 01 Hello Word Line 02 Hello Word Line 03 Some help? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] System.Diagnostics.Process thoughts
Hello,
I've started an attempt at implementing some
System.Diagnostics.Processfunctionality that is currently missing.
Currently it has backends started
for Windows and Linux. This is far from complete, but before I put any more
effort it, I wanted to get some feedback (especially from Dick as this is
his area). It seems what I've done is in a tugging match with the code that
is currently in place (as it is mostly done via icalls to the runtime).
So, does this approach look acceptable?
Should this code be in C in the runtime instead?
Any other thoughts?
Thanks,
Jonathan
Index: System.dll.sources
===
--- System.dll.sources (revision 76183)
+++ System.dll.sources (working copy)
@@ -471,9 +471,11 @@
System.Diagnostics/EventSourceCreationData.cs
System.Diagnostics/FileVersionInfo.cs
System.Diagnostics/ICollectData.cs
+System.Diagnostics/IProcessAPI.cs
System.Diagnostics/InstanceDataCollectionCollection.cs
System.Diagnostics/InstanceDataCollection.cs
System.Diagnostics/InstanceData.cs
+System.Diagnostics/LinuxProcessAPI.cs
System.Diagnostics/LocalFileEventLog.cs
System.Diagnostics/MonitoringDescriptionAttribute.cs
System.Diagnostics/NullEventLog.cs
@@ -514,6 +516,7 @@
System.Diagnostics/TraceSource.cs
System.Diagnostics/TraceSwitch.cs
System.Diagnostics/Win32EventLog.cs
+System.Diagnostics/Win32ProcessAPI.cs
System.Diagnostics/XmlWriterTraceListener.cs
System/FileStyleUriParser.cs
System/FtpStyleUriParser.cs
Index: System.Diagnostics/Win32ProcessAPI.cs
===
--- System.Diagnostics/Win32ProcessAPI.cs (revision 0)
+++ System.Diagnostics/Win32ProcessAPI.cs (revision 0)
@@ -0,0 +1,299 @@
+using System;
+using System.Collections;
+using System.Text;
+using System.Diagnostics;
+using System.Runtime.InteropServices;
+#if NET_2_0
+using COMNamespace = System.Runtime.InteropServices.ComTypes;
+#else
+using COMNamespace = System.Runtime.InteropServices;
+#endif
+
+namespace System.Diagnostics
+{
+ class Win32ProcessAPI : IProcessAPI
+ {
+ #region IProcessAPI Members
+
+ [DllImport (psapi.dll, CharSet = CharSet.Auto)]
+ static extern int EnumProcesses (IntPtr pProcessIds, uint cb, out uint pBytesReturned);
+
+ public int[] GetProcessIDs () {
+ uint bytesRequested = 5 * (uint)Marshal.SizeOf (typeof (uint));
+ uint bytesReturned;
+ IntPtr pids = Marshal.AllocHGlobal ((int)bytesRequested);
+ EnumProcesses (pids, bytesRequested, out bytesReturned);
+ while (bytesRequested == bytesReturned) {
+Marshal.FreeHGlobal (pids);
+bytesRequested = 2;
+pids = Marshal.AllocHGlobal ((int)bytesRequested);
+EnumProcesses (pids, bytesRequested, out bytesReturned);
+ }
+
+ int[] pids_array = new int[bytesReturned/Marshal.SizeOf (typeof (uint))];
+ Marshal.Copy (pids, pids_array, 0, pids_array.Length);
+ Marshal.FreeHGlobal (pids);
+
+ return pids_array;
+ }
+
+ // See link for mapping between PriorityClass and BasePriority
+ // http://msdn2.microsoft.com/en-us/library/system.diagnostics.process.basepriority.aspx
+ public int BasePriority (Process process) {
+ switch (PriorityClass (process)) {
+ case ProcessPriorityClass.Idle:
+return 4;
+ case ProcessPriorityClass.Normal:
+return 8;
+ case ProcessPriorityClass.High:
+return 13;
+ case ProcessPriorityClass.RealTime:
+return 24;
+ default:
+return 0;
+ }
+ }
+
+ [DllImport (kernel32.dll, CharSet = CharSet.Auto)]
+ static extern uint GetProcessHandleCount (IntPtr hProcess, out int pdwHandleCount);
+
+ public int HandleCount (Process process) {
+ int dwHandleCount;
+ GetProcessHandleCount (process.Handle, out dwHandleCount);
+ return dwHandleCount;
+ }
+
+ [DllImport (user32.dll, CharSet = CharSet.Auto)]
+ static extern uint GetWindowThreadProcessId (IntPtr hWnd, out uint lpdwProcessId);
+
+ delegate bool EnumWindowsCallback (IntPtr hWnd, IntPtr lParam);
+
+ [DllImport (user32.dll, CharSet = CharSet.Auto)]
+ static extern bool EnumWindows (EnumWindowsCallback lpEnumFunc, IntPtr lParam);
+
+ [DllImport (user32.dll, CharSet = CharSet.Auto)]
+ public static extern IntPtr GetParent (IntPtr hWnd);
+
+ static bool MainWindowHandleCallback (IntPtr hWnd, IntPtr lParam) {
+ uint process_id;
+ GetWindowThreadProcessId (hWnd, out process_id);
+ int target_process_id = Marshal.ReadInt32 (lParam);
+ if (target_process_id != process_id)
+return true;
+
+ IntPtr hParent = GetParent (hWnd);
+
+ if (hParent != IntPtr.Zero)
+return true;
+
+ // we have the top level window for the app
+ Marshal.WriteIntPtr (lParam, hWnd);
+
+ return false;
+ }
+
+ public IntPtr MainWindowHandle (Process process) {
+ IntPtr lparam = Marshal.AllocHGlobal (IntPtr.Size);
+ Marshal.WriteInt32(lparam, process.Id);
+ EnumWindowsCallback callback = new EnumWindowsCallback (MainWindowHandleCallback);
+ EnumWindows (callback, lparam);
+ IntPtr hMainWnd =
[Mono-dev] Problems with roleManager and web services
I have an application that worked fine until today when I've made an update from the svn. Here is the exception I get: Server Error in '/test' Application The section roleManager can't be defined in this configuration file (the allowed definition context is 'MachineToApplication'). () ( line 193) Description: Error processing request. Error Message: HTTP 500. System.Configuration.ConfigurationErrorsException: The section roleManager can't be defined in this configuration file (the allowed definition context is 'MachineToApplication'). () ( line 193) Stack Trace: System.Configuration.ConfigurationErrorsException: The section roleManager can't be defined in this configuration file (the allowed definition context is 'MachineToApplication'). () ( line 193) at System.Configuration.SectionInfo.ReadData (System.Configuration.Configuration config, System.Xml.XmlTextReader reader, Boolean overrideAllowed) [0x0] at System.Configuration.SectionGroupInfo.ReadContent (System.Xml.XmlTextReader reader, System.Configuration.Configuration config, Boolean overrideAllowed, Boolean root) [0x0] at System.Configuration.SectionGroupInfo.ReadData (System.Configuration.Configuration config, System.Xml.XmlTextReader reader, Boolean overrideAllowed) [0x0] at System.Configuration.SectionGroupInfo.ReadContent (System.Xml.XmlTextReader reader, System.Configuration.Configuration config, Boolean overrideAllowed, Boolean root) [0x0] at System.Configuration.SectionGroupInfo.ReadRootData (System.Xml.XmlTextReader reader, System.Configuration.Configuration config, Boolean overrideAllowed) [0x0] at System.Configuration.Configuration.ReadConfigFile (System.Xml.XmlTextReader reader, System.String fileName) [0x0] at System.Configuration.Configuration.Load () [0x0] at System.Configuration.Configuration.Init (IConfigSystem system, System.String configPath, System.Configuration.Configuration parent) [0x0] at System.Configuration.Configuration..ctor (System.Configuration.InternalConfigurationSystem system, System.String locationSubPath) [0x0] at System.Configuration.InternalConfigurationFactory.Create (System.Type typeConfigHost, System.Object[] hostInitConfigurationParams) [0x0] at System.Configuration.ConfigurationManager.OpenMachineConfiguration () [0x0] at System.Web.Services.Protocols.SoapDocumentationHandler..ctor (System.Type type, System.Web.HttpContext context) [0x0] at System.Web.Services.Protocols.WebServiceHandlerFactory.GetHandler (System.Web.HttpContext context, System.String verb, System.String url, System.String filePath) [0x0] at System.Web.HttpApplication.GetHandler (System.Web.HttpContext context) [0x0] at System.Web.HttpApplication+c__CompilerGenerated2.MoveNext () [0x0] 04/24/2007 14:08:56 In the root of the application I have a web.config file that looks pretty much like this: ?xml version=1.0? configuration xmlns=http://schemas.microsoft.com/.NetConfiguration/v2.0; appSettings/ connectionStrings add name=MySQLConnectionString connectionString=server=localhost; user id=test; password=...; database=test; pooling=false; providerName=MySql.Data.MySqlClient/ /connectionStrings system.web compilation debug=true assemblies add assembly=MySql.Data/ add assembly=System.Transactions, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089/ add assembly=System.Configuration.Install, Version=2.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A/ /assemblies /compilation roleManager enabled=true defaultProvider=MySQLRoleProvider providers clear/ add connectionStringName=MySQLConnectionString applicationName=/test name=MySQLRoleProvider type=Test.Web.MySQLRoleProvider/ /providers /roleManager authentication mode=Forms forms loginUrl=common/login.aspx timeout=30 defaultUrl=common/login.aspx/ /authentication membership defaultProvider=MySQLMembershipProvider providers clear/ add name=MySQLMembershipProvider type=Test.Web.MySQLMembershipProvider connectionStringName=MySQLConnectionString applicationName=/test requiresUniqueEmail=false autoUnlockTimeout=30/ /providers /membership /system.web /configuration The web service file is web_services/myWebServices.asmx. When I'm trying this http://localhost/test/web_services/myWebServices.asmx I get the exception. If I'm accessing any other page everything works fine (i.e., http://localhost/test/common/login.aspx) Any ideas? Thanks, Dumi.___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] 2 Small patches related to bug #78533
Here are 2 Small patches related to bug
#78533http://bugzilla.ximian.com/show_bug.cgi?id=78533.
The first one (Control.cs.patch) is the actual fix, which addes an error
message making Mono's behaviour similar to MS.Net's one. The exception can
be seen on MS implementation using the code on my comments at bugzilla.
The second part makes ListControls selected items viewstate's data match the
MS behaviour.
With both patches applied the error message is still displayed even the
dropdown's list has no properties or data set, unlike MS. This is because
there is still some data beeing persisted into Mono's Viewstate which
shouldn't be - waste of space. The second patch fixes this on the
ListControl side but there are some internal stuff still need debugging to
get things equal.
If there is no objection to my code can I add the changelogs and commit
them? And close the bug too...
--
Alexandre Gomes, Portugal
Index: System.Web.UI/Control.cs
===
--- System.Web.UI/Control.cs (revision 76195)
+++ System.Web.UI/Control.cs (working copy)
@@ -105,6 +105,7 @@
DataBindingCollection dataBindings;
Hashtable pendingVS; // may hold unused viewstate data from child controls
+ const string VS_OUTOFORDER_ERROR = The viewstate control tree doesn't match the previous request control tree. This can happen when loading dynamic controls and not reloading them in the same order.;
#if NET_2_0
TemplateControl _templateControl;
@@ -1447,8 +1448,22 @@
}
#endif
Triplet savedInfo = (Triplet) savedState;
- LoadViewState (savedInfo.First);
+
+ try
+ {
+LoadViewState (savedInfo.First);
+ }
+ catch (InvalidCastException)
+{
+throw new HttpException(VS_OUTOFORDER_ERROR);
+}
+catch (IndexOutOfRangeException)
+{
+throw new HttpException(VS_OUTOFORDER_ERROR);
+}
+
+
ArrayList controlList = savedInfo.Second as ArrayList;
if (controlList == null)
return;
Index: System.Web.UI.WebControls/ListControl.cs
===
--- System.Web.UI.WebControls/ListControl.cs (revision 76195)
+++ System.Web.UI.WebControls/ListControl.cs (working copy)
@@ -528,7 +528,15 @@
if (manager != null)
second = manager.SaveViewState ();
- ArrayList selected = GetSelectedIndicesInternal ();
+ ArrayList selected = null;
+
+ Type listCtlType = base.GetType ();
+ if (!Enabled || !Visible || base.Events[SelectedIndexChangedEvent]!=null || ((listCtlType != typeof(DropDownList)) (listCtlType != typeof(ListBox)) (listCtlType != typeof(CheckBoxList)) (listCtlType != typeof(RadioButtonList
+ {
+selected = GetSelectedIndicesInternal ();
+if (selected.Count1)
+ selected = null;
+ }
if (first == null second == null selected == null)
return null;
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono on Windows/x64
This is now in svn (r76209). Thanks, Jonathan On 4/23/07, Miguel de Icaza [EMAIL PROTECTED] wrote: Hey, This patch is confirmed to compile clean on gcc now. Feedback? It can go in; Feel free to commit. Mike __ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Jerris Sent: Monday, April 23, 2007 2:04 PM To: Jonathan Chambers Cc: Kornél Pál; Miguel de Icaza; mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Mono on Windows/x64 Fixes gcc compile error below, and moves project file as requested. __ From: Jonathan Chambers [mailto:[EMAIL PROTECTED] Sent: Monday, April 23, 2007 1:45 PM To: Michael Jerris Cc: mono-devel-list@lists.ximian.com; Kornél Pál; Miguel de Icaza Subject: Re: [Mono-dev] Mono on Windows/x64 Michael, I get the following compiler error building with gcc: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I. -Wall -Werror -D_FORTIFY_SOURCE=2 -g -O0 -D_GNU_SOURCE -MT libeglib_la-gstr.lo -MD -MP -MF .deps/libeglib_la- gstr.Tpo -c gstr.c -fPIC -DPIC -o .libs/libeglib_la-gstr.o gstr.c: In function 'g_filename_to_uri': gstr.c:429: error: syntax error before ')' token cc1: warnings being treated as errors gstr.c :457: warning: control reaches end of non-void function gstr.c: In function 'g_filename_from_uri': gstr.c:482: error: syntax error before ')' token gstr.c:517: warning: control reaches end of non-void function make[2]: *** [libeglib_la-gstr.lo] Error 1 make[2]: Leaving directory `/home/jschambe/monosvn/mono/eglib/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jschambe/monosvn/mono/eglib' make: *** [all] Error 2 - Jonathan On 4/23/07, Michael Jerris [EMAIL PROTECTED] wrote: Agreed, still tons to do… the location of the vcproj makes no difference to me, can someone confirm where you want it and I'll roll another project file in the right location. __ From: Jonathan Chambers [mailto:[EMAIL PROTECTED] Sent: Monday, April 23, 2007 1:22 PM To: Michael Jerris Cc: mono-devel-list@lists.ximian.com; Kornél Pál; Miguel de Icaza Subject: Re: [Mono-dev] Mono on Windows/x64 Michael, This looks good; you may want to put the vsproj in mono/msvc since I stuck all other VS related files in there. There is some warnings that need fixed (passing chars to Unicode routines), and the issues you mentioned, but this should help alot in getting mono on Win64. If eglib is working, I can build mono with no gc initially to get any other issues worked out. I think my colleage has the beta version libgc 7 working. I can try with that as well. Thanks, Jonathan On 4/23/07, Michael Jerris [EMAIL PROTECTED] wrote: Step 1. Attached patch for review, should have no affect at all on non msvc build. Resolves all build errors on msvc 2005. Still needs implementations for quite a few things on msvc, and windows in general, this patch makes no effort to address those. Note several things throughout marked FIXME that need to be looked at when the implementation is addressed. Mike -Original Message- From: [EMAIL PROTECTED] [mailto:mono-devel-list- [EMAIL PROTECTED] On Behalf Of Miguel de Icaza Sent: Monday, April 23, 2007 12:06 PM To: Jonathan Chambers Cc: Kornél Pál; mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Mono on Windows/x64 Hey, Knowing this previously would have helped ;-). I have got conflicting advice in the past about whether glib or eglib would be the best approach. Well, we were developing it ;-) But our goal is to drop glib and get back some of the memory usage we have been using. As with every large change, this is not something we want to do in the incremental 1.2.xx releases. Miguel. ___ 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] Problem with Request.Browser.MSDomVersion and Firefox
Hi Hubert,
We recently implemented all the missing capabilities in the
HttpBrowserCapablities class.
During the implementation we implemented this throw to be compatible with
MS.Net which
throws if the capability isn't defined at all. The code is based on the
assumption that the
browscaps.ini file should contain the correct values for all the common
browsers.
However, this is not the case! Since browscaps.ini has it's own maintainer
we did not update
that file.
In order to fix this problem add the missing definitions to the
browscaps.ini file.
Find the browscaps.ini file next to your machine.config file. This is the
code that
finds and loads it, from CapabilitiesLoader.cs:
#if TARGET_J2EE
string filepath = browscap.ini;
#else
string dir = HttpRuntime.MachineConfigurationDirectory;
string filepath = Path.Combine (dir, browscap.ini);
if (!File.Exists (filepath)) {
// try removing the trailing version directory
dir = Path.GetDirectoryName (dir);
filepath = Path.Combine (dir, browscap.ini);
}
#endif
If you don't know what values to put in the configuration you can find the
values from looking
in Microsoft's definitions in the
C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers
folder.
I hope this helps.
Adar Wesley
Mainsoft
On 4/24/07, Hubert FONGARNAND [EMAIL PROTECTED] wrote:
try this aspx with firefox
%@ Page Language=C# %
Head
script language=CS runat=server
void Page_Load(object sender, System.EventArgs e)
{
Console.WriteLine(Request.Browser.W3CDomVersion);
Console.WriteLine(Request.Browser.MSDomVersion);
}
/script
/Head
and you'll get
*Argument cannot be null. Parameter name: browscaps.ini does not contain a
definition for capability msdomversion for userAgent Mozilla*
*Description: *Error processing request.
*Error Message: *HTTP 500. System.ArgumentNullException: Argument cannot
be null. Parameter name: browscaps.ini does not contain a definition for
capability msdomversion for userAgent Mozilla
*Stack Trace: *
System.ArgumentNullException: Argument cannot be null.
Parameter name: browscaps.ini does not contain a definition for capability
msdomversion for userAgent Mozilla
at System.Web.HttpBrowserCapabilities.ReadVersion (System.String key)
[0x0]
at System.Web.HttpBrowserCapabilities.get_MSDomVersion () [0x0]
at MetaBuilders.WebControls.ClientScriptUtil.get_RenderUplevel () [0x0]
at MetaBuilders.WebControls.ConfirmedLinkButton.OnPreRender (System.EventArgs
e) [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Control.PreRenderRecursiveInternal () [0x0]
at System.Web.UI.Page.InternalProcessRequest () [0x0]
at System.Web.UI.Page.ProcessRequest (System.Web.HttpContext context)
[0x0]
It use to work well with mono 1.2.3
The problem is that we have an external asp.net component using this
property... This should'nt crash...
___
Ce message et les éventuels documents joints peuvent contenir des
informations confidentielles.
Au cas où il ne vous serait pas destiné, nous vous remercions de bien
vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute
utilisation de ce message non conforme à sa destination, toute diffusion ou
publication, totale ou partielle et quel qu'en soit le moyen est
formellement interdite.
Les communications sur internet n'étant pas sécurisées, l'intégrité de ce
message n'est pas assurée et la société émettrice ne peut être tenue pour
responsable de son contenu.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
---
Adar Wesley
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problem with Request.Browser.MSDomVersion and Firefox
On Tue, 24 Apr 2007 21:51:38 +0300, Adar Wesley [EMAIL PROTECTED] scribbled: Hi Hubert, Hey Adar We recently implemented all the missing capabilities in the HttpBrowserCapablities class. During the implementation we implemented this throw to be compatible with MS.Net which throws if the capability isn't defined at all. The code is based on the assumption that the browscaps.ini file should contain the correct values for all the common browsers. However, this is not the case! Since browscaps.ini has it's own maintainer we did not update that file. That's not entirely true, we do update it to add the ecmaversion entry to some browsers. In order to fix this problem add the missing definitions to the browscaps.ini file. I have committed today a fix that provides defaults for the browser caps if they are missing from the definition or browsercaps.ini is broken/missing. Even if Microsoft .NET throws an exception in that case, I don't like the behavior as it is completely unjustified imho. If you want Mono to still throw the exception in case caps are missing, we can add an environment variable that will turn the MS.NET behavior on. best regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Problems with the Session_end event
On Tue, 24 Apr 2007 17:54:56 +0300, Dumitru Ban [EMAIL PROTECTED] scribbled: Hi Marek, Hey Dumitru, Thanks for fixing bug #81140. Unfortunatelly another one, which I'm pretty sure is related to this one, is still there. I've entered a bug for it with the necessary information - bug #81440. It seems that there are a lot of issues related to the Session_end event. Oh, that's entirely possible. The 2.0 session code is totally new and as such not thoroughly tested. I'll try to spend some time to figure out what's the mechanism around the sessions. Any guidelines and ideas would be appreciated. Just ask questions - the 2.0 session stuff is quite well documented (on the public API level) on msdn, but if you have questions - do feel free to email me directly. regards, marek signature.asc Description: PGP signature ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono on Windows/x64
eglib is not yet linking on Windows, so I haven't tried it with mono yet. Also, mono-ehash.c isn't even included in the mono vcproj at this point (due to oversight and it's absence not causing any errors), so I probably wouldn't see it. - Jonathan On 4/24/07, Andreas Färber [EMAIL PROTECTED] wrote: I fixed a build problem with ABS in eglib's mono-ehash.c and will post a patch this evening if noone else is quicker. http://bugzilla.ximian.com/show_bug.cgi?id=81433 Could someone please review this one-liner? Is the fix okay or was another macro intended there? The ABS macro, as defined in eglib, only takes one argument while mono-ehash.c calls it with two arguments, leading to a build error. Are you not witnessing this on Windows? Andreas ___ 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] Mono on Windows/x64
Hello, Could someone please review this one-liner? Is the fix okay or was another macro intended there? The ABS macro, as defined in eglib, only takes one argument while mono-ehash.c calls it with two arguments, leading to a build error. Are you not witnessing this on Windows? This was a lack of updates on my part, thanks for pointing this out. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] System.Diagnostics.Process thoughts
Hello, So, does this approach look acceptable? Should this code be in C in the runtime instead? My preference is to keep as much code as possible in C# to keep the runtime small. Miguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] - System.IO.FileSystemWatcher Unit Tests for Events
Alan McGovern [EMAIL PROTECTED] wrote:
One thing you should do is make sure your temp files and directories are
cleaned up when your tests finish running. The best way to do this would be
to use [TestFixtureSetup] and [TestFixtureTeardown] to create a setup and
cleanup method. The first one creates your temp directory, the second one
deletes it.
Other than that, it looks good.
Alan,
Thanks for the feedback. I have updated the patch with your suggestions.
The new diff is attached to this note. Can you apply it?
Thanks,
Louis
--
Louis R. Marascio - www.fitnr.com
... fixed in the next release ...
Index: class/System/Test/System.IO/FileSystemWatcherTest.cs
===
--- class/System/Test/System.IO/FileSystemWatcherTest.cs(revision 76226)
+++ class/System/Test/System.IO/FileSystemWatcherTest.cs(working copy)
@@ -2,6 +2,7 @@
//
// Authors:
// Gonzalo Paniagua Javier ([EMAIL PROTECTED])
+// Louis R. Marascio ([EMAIL PROTECTED])
//
// (C) 2004 Novell, Inc. http://www.novell.com
//
@@ -9,12 +10,17 @@
using NUnit.Framework;
using System;
using System.IO;
+using System.Threading;
namespace MonoTests.System.IO
{
[TestFixture]
public class FileSystemWatcherTest : Assertion
{
+ // Path to the temporary directory that we'll use for various
tests
+ private static string tempPath = Path.Combine
(Path.GetTempPath(),
+
MonoTests.System.IO.FileSystemWatcherTest);
+
[Test]
public void CheckDefaults ()
{
@@ -81,6 +87,159 @@
FileSystemWatcher fw = new FileSystemWatcher
(Path.GetTempPath (), *);
fw.Path = *;
}
+
+ #region FileSystemWatcher Event Tests
+
+ private AutoResetEvent eventFired = new AutoResetEvent (false);
+ private static string tempFile = FSWTempFile;
+ private static string tempFilePath = Path.Combine (tempPath,
tempFile);
+
+ // Used to store state from each event call back
+ private string lastName, lastFullPath;
+ private WatcherChangeTypes lastChangeType;
+
+ [Test]
+ public void CheckChangedEvent ()
+ {
+ // Test various combinations of the Changed event. We
pass in a test name, our test
+ // filename, a test filter, and whether we expect the
event to fire or not.
+ DoChangedEventTest (ChangedWildcard,
tempFilePath,*.*,true);
+ DoChangedEventTest (ChangedSpecificFile,
tempFilePath+2,tempFile+2, true);
+ DoChangedEventTest (ChangedOutsideOfFilter,
tempFilePath,fooFilter, false);
+ DoChangedEventTest (ChangedFilterExtGood,
tempFilePath+.abc, *.abc, true);
+ DoChangedEventTest (ChangedFilterExtBad,
tempFilePath+.xyz, *.abc, false);
+ }
+
+ // Test various combinations of the Changed event handler
+ public void DoChangedEventTest (string testName, string
filename, string filter, bool eventExpected)
+ {
+ CleanupTempDir ();
+
+ // Open our temporary file and write some initial data,
before we start monitoring for events.
+ using (StreamWriter w = new StreamWriter (filename)) {
+ w.WriteLine (foo);
+ }
+
+ FileSystemWatcher fw = new FileSystemWatcher (tempPath,
filter);
+ fw.Changed += new FileSystemEventHandler
(OnFileSystemWatcherEvent);
+ fw.EnableRaisingEvents = true;
+
+ // Now that we're monitoring for Changed events, write
some more data to the same file.
+ using (StreamWriter w = new StreamWriter (filename,
true)) {
+ w.WriteLine (bar);
+ }
+
+ bool gotEvent = eventFired.WaitOne (1000, true);
+
+ fw.EnableRaisingEvents = false;
+ fw.Dispose ();
+
+ AssertEquals (testName+-#15, gotEvent, eventExpected);
+ if (eventExpected) {
+ AssertEquals (testName+-#16, filename,
lastFullPath);
+ AssertEquals (testName+-#17,
WatcherChangeTypes.Changed, lastChangeType);
+ }
+
+ lastName = lastFullPath = null;
+ }
+
+ [Test]
+ public void CheckCreatedEvent ()
+ {
+
Re: [Mono-dev] Mono on Windows/x64
The previous patch has been committed now. This is a follow up patch that: 1. provides more standard ifdefs for conditionally including headers. I did not do autoconf checks for header availability, how would you like that done? 2. Supply several replacement functions that were not available in msvc. 3. Provided a few windows specific implementations. 4. added building of the eglib test suite (including a getopt replacement). 5. add and/or ifdef a bunch of includes in the eglib tests. 6. resolve many warnings, mostly related to signedness or int type overflows. 7. standardized line endings to LF only. 8. change warning levels to the project files for eglib and it's tests to the max, warnings as errors, disable a few warnings. Current status of eglib and test build is that everything compiles and links but there are some now commented incomplete windows implementations as follows: gspawn.c:g_spawn_async_with_pipes (probably requires alternate implementation) gspawn.c:g_spawn_command_line_sync (probably requires alternate implementation) gunicode.c:g_convert (requires iconv or alternate implementation) gunicode.c:g_get_charset (requires iconv or alternate implementation) We still need to handle msvc/windows implementations for the 4 functions above so that we can run the test suite and see how much more work is to go. For the gunicode functions, do we really need iconv, or does windows already provide the functionality needed in other api's? Does anyone have windows api implementations for any of those 4 functions that they could provide or wish to write? Also, attached results.txt shows the test results of the code after this patch on windows. There are still quite a few that need to get fixed. TODO: Test on gcc (if someone could provide feedback on the mailing list that it still builds and does not introduce any regressions I would appreciate it) Answer to the question posed in #1 above. (I can add the checks or implement as required, just need to know how it should go) Mike -Original Message- From: Miguel de Icaza [mailto:[EMAIL PROTECTED] Sent: Monday, April 23, 2007 4:22 PM To: Michael Jerris Cc: mono-devel-list@lists.ximian.com; Kornél Pál; Jonathan Chambers Subject: RE: [Mono-dev] Mono on Windows/x64 Hey, This patch is confirmed to compile clean on gcc now. Feedback? It can go in; Feel free to commit. eglibmsvc2005.build.rev1.diff.gz Description: eglibmsvc2005.build.rev1.diff.gz [string] append-speed: OK append_c-speed: OK ctor+append: OK ctor+sized: OK truncate: OK prepend: OK append_len: OK macros: FAILED (did not find a valid line number) 7 / 8 (87.5%) [strutil] g_strfreev: OK g_strconcat: OK g_strsplit: FAILED (Expected only 3 elements) g_strreverse: OK g_strjoin: OK g_strchug: OK g_strchomp: OK g_strstrip: OK g_filename_to_uri: OK g_filename_from_uri: OK g_ascii_xdigit_value: OK g_strdelimit: OK g_strlcpy: OK g_strescape: OK g_ascii_strncasecmp: OK 14 / 15 (93.%) [ptrarray] alloc: OK for_iterate: OK foreach_iterate: OK set_size: OK remove_index: OK remove: OK sort: OK 7 / 7 (100%) [slist] append: OK concat: OK find: OK remove: OK remove_link: OK insert_sorted: OK insert_before: OK sort: OK 8 / 8 (100%) [list] length: OK nth: OK index: OK last: OK append: OK concat: OK insert_sorted: OK insert_before: OK copy: OK reverse: OK remove: OK remove_link: OK remove_link: OK sort: OK 14 / 14 (100%) [hashtable] t1: OK t2: OK grow: OK default: OK null_lookup: OK 5 / 5 (100%) [sizes] formats: OK ptrconv: OK g_struct_offset: OK 3 / 3 (100%) [array] big: OK append: OK insert_val: OK index: OK remove: OK append_zero_term: OK 6 / 6 (100%) [queue] push: OK pop: OK new: OK is_empty: OK 4 / 4 (100%) [path] g_buildpath: OK g_build_filename: FAILED (1 Got wrong result, got: a\b\c\d) g_path_get_dirname: FAILED (Expected /home, got .) g_path_get_basename: FAILED (1 Expected dingus, got /home/dingus/) g_find_program_in_path: FAILED (No shell on this system (This assumes Unix)?) g_find_program_in_path2: FAILED (It should find 'test-glib' in the current directory.) test_cwd: FAILED (No /bin?) test_misc: FAILED (Where did my home go?) 1 / 8 (12.5%) [shell] g_shell_parse_argv1: OK g_shell_parse_argv2: OK g_shell_parse_argv3: OK 3 / 3 (100%) [markup] invalid_documents: OK good_documents: OK mono_domain: OK mcs_config: OK xml_parse: OK machine_config: FAILED (Too many closing tags, not enough open tags) 5 / 6 (83.%) [spawn] g_shell_spawn_sync: FAILED (Status is -1) g_shell_spawn_async_with_pipes: FAILED (2 child pid not returned) 0 / 2 (0%) [timer] g_timer: FAILED (usecs are wrong.) 0 / 1 (0%) [file] g_file_get_contents: FAILED (The error is 4 Error opening file )
