Re: [Mono-dev] Test suite failures (Mono 2.10.2)
I don't mean to cast aspersions on the maintenance of the tests (although I do think it would be unusual if a product was released with failures in its own automated test suite). I don't feel entitled to complain too much, but I'd like to understand the situation. I just want to find answers to these questions: 1. Is this expected - in general? (It sounds like yes, please somebody correct this if they think otherwise) - for a released version? (Sounds like yes again) - for 2.10.2? 2. Does it look like I'm doing something wrong? 3. How is Mono packaged if the test suite fails? Thanks again. Harry On 23 June 2011 20:05, Steve Bjorg ste...@mindtouch.com wrote: Here's a thought: only accept code changes that pass all tests? Just saying... - Steve -- Steve G. Bjorg http://mindtouch.com http://twitter.com/bjorg On Jun 23, 2011, at 11:43 AM, Zoltan Varga wrote: Hi, Our test suite contains 1000s of tests, written by dozens of people, its a bit hard to keep them all passing. Zoltan On Thu, Jun 23, 2011 at 7:44 PM, Harry Wilkinson hwilkin...@mdsol.comwrote: Hi, I'm encountering some test failures with the Mono 2.10.2 source tarball distributed at http://ftp.novell.com/pub/mono/sources/mono/ Basically I'm trying to package it for deployment on Ubuntu 10.04.2 servers in a cloud configuration. So far I've been building from source and encountered no significant problems other than the long build time. I'd like to be able to reduce that by building it once and deploying a compiled package. So I'm using dpkg-buildpackage. However, now that I'm packaging rather than just building and installing, it seems that the test suite is run and there are some test failures. The first and most obvious one is that it appears that a file is missing from the source tarball: mcs/class/corlib/Test/System.Runtime.Serialization.Formatters.Binary/VersionTolerantSerialization/VersionTolerantSerializationTestLib/6.0/Address.cs The file is there in the Git repo under the 2.10.2 tag, but it's not in the tarball. Unfortunately it's referenced in the associated Makefile (mcs/class/corlib/Makefile). The same applies to 2.10.1, so I'm guessing the file is omitted from whatever process builds the tarballs. I switched to compiling from the source taken from Git, checkout out the 2.10.2 tag, and I get a different error (which is also what I get with the tarball version if I just hack the makefile): make[8]: Entering directory `/home/hwilkinson/mono/mcs/class/System.Web.DynamicData' MCS [net_2_0] System.Web.DynamicData_test_net_2_0.dll Test/../../System.Web/Test/mainsoft/NunitWeb/NunitWeb/MyTemplateControls.cs(43,19): error CS0507: `MyTemplateControls.TestTemplateControl.CreateChildControls()': cannot change access modifiers when overriding `protected' inherited member `System.Web.UI.Control.CreateChildControls()' /home/hwilkinson/mono/mcs/class/lib/net_2_0/System.Web.dll (Location of the symbol related to previous error) Compilation failed: 1 error(s), 0 warnings make[8]: *** [System.Web.DynamicData_test_net_2_0.dll] Error 1 It looks like this could well be an incorrect preprocessor definition 'SYSTEM_WEB_EXTENSIONS' (not sure whether it should be defined or not) in mcs/class/System.Web/Test/mainsoft/NunitWeb/NunitWeb/MyTemplateControls.cs. Is this expected? I had sort of assumed that a released version would have a passing test suite. Am I doing something wrong? Any advice (well, almost) would be gratefully received. Thanks. Harry Wilkinson ___ 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] Test suite failures (Mono 2.10.2)
Okay, so I guess this answers 2 of the questions - the test failures are expected, and I'm not doing anything wrong. Please correct me if you think otherwise. I would still really like to know: how is Mono packaged if the test suite fails? This is important to me because I would like to build my own package so I don't have to compile Mono every time I deploy a Mono app. Is there a straightforward way to ignore the tests? Thanks. Harry Date: Fri, 24 Jun 2011 15:12:12 -0300 From: Rodrigo Kumpera kump...@gmail.com Subject: Re: [Mono-dev] Test suite failures (Mono 2.10.2) To: Kocsis L?szl? kocsis1...@gmail.com Cc: mono-devel-list@lists.ximian.com Message-ID: banlktinxujqsmhyu8jy48jxetzcxzfj...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 I think you misundestood my email. It's the opposite, right now we, at Xamarin, can't really afford the time to bring the mono CI infrastructure back so someone from the community needs to step up and do it. On Fri, Jun 24, 2011 at 3:07 PM, Kocsis L?szl? kocsis1...@gmail.com wrote: Hi Rodrigo, Good news the guys at Xamarin are working hard on getting the build infrastructure back. Would you please give us an estimate about when will it be up and running again? I would like to work on bugs in the Windows version of mono, but I could not even compile it. I hope the automatic build and test system will solve such problems and mono will compile and pass all tests at least on every major platform. Or am I naive and this cannot be expected? Best, Laszlo 2011/6/24, Rodrigo Kumpera kump...@gmail.com: It's hard to do such a thing when you factor in that mono supports many dozens of targets and configurations and that sometimes those breaks were caused my maintainers - I have my share of faults. Thing is, right now the team at Xamarin has tons of stuff on its hand so getting the build infrastructure back on track, which helps us a lot, won't happen without community help. A good first step would be to get CI back working at least on linux. S, if someone wants to rebuild the continuous integration farm over linode (or other VPS) please speak up. On Thu, Jun 23, 2011 at 4:05 PM, Steve Bjorg ste...@mindtouch.com wrote: Here's a thought: only accept code changes that pass all tests? Just saying... - Steve -- Steve G. Bjorg http://mindtouch.com http://twitter.com/bjorg On Jun 23, 2011, at 11:43 AM, Zoltan Varga wrote: Hi, Our test suite contains 1000s of tests, written by dozens of people, its a bit hard to keep them all passing. Zoltan On Thu, Jun 23, 2011 at 7:44 PM, Harry Wilkinson hwilkin...@mdsol.comwrote: Hi, I'm encountering some test failures with the Mono 2.10.2 source tarball distributed at http://ftp.novell.com/pub/mono/sources/mono/ Basically I'm trying to package it for deployment on Ubuntu 10.04.2 servers in a cloud configuration. So far I've been building from source and encountered no significant problems other than the long build time. I'd like to be able to reduce that by building it once and deploying a compiled package. So I'm using dpkg-buildpackage. However, now that I'm packaging rather than just building and installing, it seems that the test suite is run and there are some test failures. The first and most obvious one is that it appears that a file is missing from the source tarball: mcs/class/corlib/Test/System.Runtime.Serialization.Formatters.Binary/VersionTolerantSerialization/VersionTolerantSerializationTestLib/6.0/Address.cs The file is there in the Git repo under the 2.10.2 tag, but it's not in the tarball. Unfortunately it's referenced in the associated Makefile (mcs/class/corlib/Makefile). The same applies to 2.10.1, so I'm guessing the file is omitted from whatever process builds the tarballs. I switched to compiling from the source taken from Git, checkout out the 2.10.2 tag, and I get a different error (which is also what I get with the tarball version if I just hack the makefile): make[8]: Entering directory `/home/hwilkinson/mono/mcs/class/System.Web.DynamicData' MCS [net_2_0] System.Web.DynamicData_test_net_2_0.dll Test/../../System.Web/Test/mainsoft/NunitWeb/NunitWeb/MyTemplateControls.cs(43,19): error CS0507: `MyTemplateControls.TestTemplateControl.CreateChildControls()': cannot change access modifiers when overriding `protected' inherited member `System.Web.UI.Control.CreateChildControls()' /home/hwilkinson/mono/mcs/class/lib/net_2_0/System.Web.dll (Location of the symbol related to previous error) Compilation failed: 1 error(s), 0 warnings make[8]: *** [System.Web.DynamicData_test_net_2_0.dll] Error 1 It looks like this could well be an incorrect preprocessor definition 'SYSTEM_WEB_EXTENSIONS' (not sure whether it should be defined or not) in mcs/class/System.Web/Test/mainsoft
[Mono-dev] Test suite failures (Mono 2.10.2)
Hi, I'm encountering some test failures with the Mono 2.10.2 source tarball distributed at http://ftp.novell.com/pub/mono/sources/mono/ Basically I'm trying to package it for deployment on Ubuntu 10.04.2 servers in a cloud configuration. So far I've been building from source and encountered no significant problems other than the long build time. I'd like to be able to reduce that by building it once and deploying a compiled package. So I'm using dpkg-buildpackage. However, now that I'm packaging rather than just building and installing, it seems that the test suite is run and there are some test failures. The first and most obvious one is that it appears that a file is missing from the source tarball: mcs/class/corlib/Test/System.Runtime.Serialization.Formatters.Binary/VersionTolerantSerialization/VersionTolerantSerializationTestLib/6.0/Address.cs The file is there in the Git repo under the 2.10.2 tag, but it's not in the tarball. Unfortunately it's referenced in the associated Makefile (mcs/class/corlib/Makefile). The same applies to 2.10.1, so I'm guessing the file is omitted from whatever process builds the tarballs. I switched to compiling from the source taken from Git, checkout out the 2.10.2 tag, and I get a different error (which is also what I get with the tarball version if I just hack the makefile): make[8]: Entering directory `/home/hwilkinson/mono/mcs/class/System.Web.DynamicData' MCS [net_2_0] System.Web.DynamicData_test_net_2_0.dll Test/../../System.Web/Test/mainsoft/NunitWeb/NunitWeb/MyTemplateControls.cs(43,19): error CS0507: `MyTemplateControls.TestTemplateControl.CreateChildControls()': cannot change access modifiers when overriding `protected' inherited member `System.Web.UI.Control.CreateChildControls()' /home/hwilkinson/mono/mcs/class/lib/net_2_0/System.Web.dll (Location of the symbol related to previous error) Compilation failed: 1 error(s), 0 warnings make[8]: *** [System.Web.DynamicData_test_net_2_0.dll] Error 1 It looks like this could well be an incorrect preprocessor definition 'SYSTEM_WEB_EXTENSIONS' (not sure whether it should be defined or not) in mcs/class/System.Web/Test/mainsoft/NunitWeb/NunitWeb/MyTemplateControls.cs. Is this expected? I had sort of assumed that a released version would have a passing test suite. Am I doing something wrong? Any advice (well, almost) would be gratefully received. Thanks. Harry Wilkinson ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] mono X11 rendering
Hi guys, I am not sure where to post this questions. Hopefuly you guys are able to answer my questions: I am developing a simple applications using Thread class to change the color of the square (Lab assignment) everything working correctly, accept I have to drag the windows in linux to let the Thread working to change the color of a square. I think it has something todo with the X11 rendering in Linux. Are there any solutions to this problems? here is my code: using System; using System.Windows.Forms; using System.Threading; using System.Drawing; public class ColoredBoxes : Form { private Color c; public ColoredBoxes() { Thread t = new Thread(new ThreadStart(Run)); t.Start(); } protected override void OnPaint(PaintEventArgs e) { Graphics g = e.Graphics; Pen blue = new Pen(c, 3); g.DrawRectangle(blue, 100,100,30,30); base.OnPaint(e); } public void Run() { Random r = new Random(); while(true) { c = Color.FromArgb(r.Next(256), r.Next(256), r.Next(256)); Thread.Sleep(200); } } } public class Test{ public static void Main() { Application.Run(new ColoredBoxes()); } } Thank you for all your help guys -- Harry Tanama Programmer/Developer .NET / JAVA Powerd by GNU/LiNUX Let Christ be glorify in our words and actions. Jesus Christ save the entire human race from sins GNU/Linux save human from high cost software applications. __ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] mono X11 rendering
Hi guys, (sorry for the typo in the previous email) I am developing a simple applications using Thread class to change the color of the square (Lab assignment). Everything is working properly, except I have to drag or cls /opn the windows in linux to fix theThread and the only solutions to produce the color change. I think it has something todo with the X11 rendering in Linux. Are there any solutions to this problems? here is my code: (This code should be working in MS Windows) [code] using System; using System.Windows.Forms; using System.Threading; using System.Drawing; public class ColoredBoxes : Form { private Color c; public ColoredBoxes() { Thread t = new Thread(new ThreadStart(Run)); t.Start(); } protected override void OnPaint(PaintEventArgs e) { Graphics g = e.Graphics; Pen blue = new Pen(c, 3); g.DrawRectangle(blue, 100,100,30,30); base.OnPaint(e); } public void Run() { Random r = new Random(); while(true) { c = Color.FromArgb(r.Next(256), r.Next(256), r.Next(256)); Thread.Sleep(200); } } } public class Test{ public static void Main() { Application.Run(new ColoredBoxes()); } } [/code] Thank you for all your help guys -- Harry Tanama Programmer/Developer .NET / JAVA Powerd by GNU/LiNUX Let Christ be glorify in our words and actions. Jesus Christ save the entire human race from sins GNU/Linux save human from high cost software applications. __ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] libgdiplus-1.1.9.2.tar.gz
Hi guys, I am try to download the latest libgdiplus but I coudn't find it at Mono-Development-Project website release code and also on the svc. Please advise. Thanks you in advance __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Mono structure of development
Hi All, I have a questions regarding Mono structure development. I have tried all the link at Mono website, but I couldn't find it. here is my questions. 1. Is Mono only supporting runtime not the library for all other programming languages? 2. Why all the library such as System, System.Drawing, etc... class is in the mcs library not in Mono library i.g Mono[verions]/Class/System.Windows.Forms ? 3. Are you guys have different compiler for every languages and always includes the library such as System, System.Drawing, etc... i.g [../class/System] ? 4. Is Mono only support runtime for C# programming languages? Thank you in advance for your answers -- Harry Tanama Programmer/Developer .NET / JAVA Powerd by GNU/LiNUX Let Christ be glorify in our words and actions. Jesus Christ save the entire human race from sins GNU/Linux save human from high cost software applications. __ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Time zone problems with DateTime.Parse (patch and bug)
Hmmm... Will the changes in daylight saving time for 2007+ (http://aa.usno.navy.mil/faq/docs/daylight_time.html) have any affect on this? ... HHOn 9/7/05, Atsushi Eno [EMAIL PROTECTED] wrote: Hi, Test case: http://bugzilla.ximian.com/show_bug.cgi?id=75985 I think the problem here is that the internal DateTime(bool,long) constructor calls tz.GetUtcOffset(this) with the UTC time to get the timezone offset before applying it to get local time, but that function expects a local time to determine if DST is active. A bit of a chicken-and-egg problem, perhaps... ;) Agreed. But it seems possible to avoid that problem. Can you please try attached patch? I don't have sane Unix environment and I'm not in such region that has summer time ;-) It would be even nicer if you try the entire corlib Nunit tests as well. Cool, that's definitely closer! Unfortunately it's still a bit off; during the doubled hour in the DST transition it's an hour off in the wrong direction. Using output from my test proggy on that bug: Okk, based on your help, I found some things. The most important one is that there are different basis of TimeZone: UTC and local time (there might be other patterns). now I think we need our own TimeZone data store, that would store timezone names as well. At least DateTime.ToLocalTime() will be rewritten just to invoke TimeZone.CurrentTimeZone.ToLocalTime(this). So, I'll revisit here later. Thanks for all your help, Brion :-)After some attempt (I think) I could fix TimeZone.ToLocalTime() forPST/PDT (the attached patch is for bug #75985). However, I have nobetter idea than that it just fixes offsets in that timezone, asI mentioned my concern about the basis difference (UTC or localtime). So I will have to dig into POSIX timezone design in depth.And apart from the matter above, I will still have to extend ourlocale-builder to support TimeZone name.Atsushi EnoIndex: System/TimeZone.cs ===--- System/TimeZone.cs(revision 49638)+++ System/TimeZone.cs(working copy)@@ -108,27 +108,33 @@public virtual DateTime ToLocalTime (DateTime time){-// return time + GetUtcOffset (time);- TimeSpan offset = GetUtcOffset (time);-- if (offset.Ticks 0) {- if (DateTime.MaxValue - offset time)+ DaylightTime dlt = GetDaylightChanges (time.Year);+ TimeSpan utcOffset = GetUtcOffset (time);+ if (utcOffset.Ticks 0) {+ if (DateTime.MaxValue - utcOffset time)return DateTime.MaxValue;- } else if (offset.Ticks 0) {- // MS.NET fails to check validity here- // - it may throw ArgumentOutOfRangeException- /*- if (DateTime.MinValue - offset this)- return DateTime.MinValue;- */+ //} else if (utcOffset.Ticks 0) {+ //LAMESPEC: MS.NET fails to check validity here+ //it may throw ArgumentOutOfRangeException.}-- DateTime lt = new DateTime (time.Ticks + offset.Ticks);- TimeSpan ltoffset = GetUtcOffset (lt);- if (ltoffset != offset)- lt = lt.Add (ltoffset.Subtract (offset));- return lt;+ DateTime local = time.Add (utcOffset);+ if (dlt.Delta.Ticks == 0)+ return local;++ // FIXME: check all of the combination of+ //- basis: local-based or UTC-based+ //- hemisphere: Northern or Southern+ //- offset: positive or negative++ // PST should work fine here.+ if (local dlt.End dlt.End.Subtract (dlt.Delta) = local)+ return local;+ if (local = dlt.Start dlt.Start.Add (dlt.Delta) local)+ return local.Subtract (dlt.Delta);++ TimeSpan localOffset = GetUtcOffset (local);+ return time.Add (localOffset);}public virtual DateTime ToUniversalTime (DateTime time)___Mono-devel-list mailing listMono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list-- Robbie the Nanobot says:Only YOU can prevent gray goo(NEVER release nanobot assemblers without replication limiting code)http://lizardslounge.org ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Re: [PATCH] Fully Asynchronous and Re-Factored Ssl Streams in Mono.Security
This seems to work fine on W2k. Running under IIS5.1 on WXP, though, it always throws an ObjectDisposedException in SSLStreamBase.cs when a bind over SSL is attempted. Won't this: if (workthreads = (maxworkthreads - 4)) { async = false; } cause the SSL Stream to use synchronous handshake until threads start getting used? I would also recommend changing this: protected void checkDisposed() { if (this.disposed) { throw new ObjectDisposedException(The Stream is closed.); } } to this: protected void checkDisposed() { if (this.disposed) { throw new ObjectDisposedException(this.GetType().Name, The Stream is closed.); } } which produces a more readable error message. Thx... HHOn 8/25/05, Sebastien Pouliot [EMAIL PROTECTED] wrote: Hello JD,On Wed, 2005-24-08 at 21:12 -0700, JD Conley wrote: I took the plunge and fully implemented async Ssl streams for both client and server.This fixes http://bugzilla.ximian.com/show_bug.cgi?id=75687 as well as other bugs I've been talking with Sebastien and Carlos about off list. This patch passes the SocketHell tests that I contributed to them last week (multi threaded concurrent async streaming through TCP sockets).Wow! That's the kind of surprise I like when I wake up :-) It's also a bit of a re-factor, though I only touched two classes and added one.I pulled most of the code out of the individual SslClientStream and SslServerStream and moved it down into a new abstract SslStreamBase.Client and server are now practically the same implementation.I left all existing interfaces present, but obviously had to add some new ones.We always sticked to the Fx 1.2 preview specs for the Ssl[Client|Server]Stream API and didn't planned to change this before implementingthe new SslStream (in System.dll) for 2.0 - BUT this isn't a majorproblem if it doesn't break binary compatibility (for currentapplications linked with Mono.Security.dll). The only gotcha is if you start running low on threadpool threads. Then the Ssl Stream will fall back to a synchronous handshake. The other option here is to spawn a thread ourselves for the handshake instead of using Delegate.BeginInvoke(), use the IO ThreadPool (is that available to Mono.Security?), or just live with a synchronous handshake. Of course, 99.999% of the time this issue won't occur and won't be a problem unless you have both client and server sharing the same Threadpool causing a deadlock.That's not worse than the original (where the handshake was alwayssynchronous). I hope this helps and gets integrated.It's definitely necessary for our implementation.1. I'll review the patch and, in doing so, check for possible binarycompatibility problems. I'm sure Carlos will do likewise;2. I'll make public a new Mono.Security.dll assembly so that people that depends on Ssl*Stream may tests it and report any problem/difference;3. I'll run the regressions tests, the tools under /mcs/class/Mono.Security/Test/tools/*, to see if it works in previously reportedconditions. 4. Commit (both the patch and your SocketHell tests). Hopefully we cando all this before the next release.Many thanks!--Sebastien___Mono-devel-list mailing list Mono-devel-list@lists.ximian.comhttp://lists.ximian.com/mailman/listinfo/mono-devel-list -- Robbie the Nanobot says:Only YOU can prevent gray goo(NEVER release nanobot assemblers without replication limiting code) http://lizardslounge.org ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Unhandled Exceptions in Novell.Directory.Ldap and other Synchronization Issues
I don't know ?? On 8/22/05, JD Conley [EMAIL PROTECTED] wrote: Please submit any bug reports for the LdapCsharp library to Novell Forge at: http://forge.novell.com/modules/xfmod/tracker/?group_id=1318atid=1362 No problem. Does this library regularly get replicated into the Mono SVN repository? I'd obviously like to see any fixes put in the Mono tree. -JD -- Robbie the Nanobot says: Only YOU can prevent gray goo (NEVER release nanobot assemblers without replication limiting code) http://lizardslounge.org ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: SPAM: RE: [Mono-devel-list] DateTime Parameters in MSSQL Server
SQL Server will accept a variety of formats for datetime, but .NET will often hand it dates it can't deal with due to culture settings. DateTime.Now may return '7/13/2005' or '13/7/2005', and SQL is generally going to reject one or the other. It will also not accept dates earlier than January 1, 1753. Yes, it WILL accept ISO formatted datetime, but not UTC. It will generally only accept datetime strings with some type of delimiters for each part. A word of caution: If you are using the SQLHelper methods from Microsoft.ApplicationBlocks.Data, be careful to never use the ExecuteDataReader methods that accept connection strings. Instead, use the ones that accept a Connection object and manage the connection in your own code. The methods that accept a connection string will open new connections and leave them open indefinately. You will eventually run out of connections in the pool and your app will die. This was a pretty nasty bug that took me a while to track down, because it didn't show up until my application went into UAT, and I was looking for problems with MY code instead of the MS stuff (this behavior is completely the opposite of their own best practices). If you're having concurrency issues, don't assume it's mono or your own code - make sure that the application block is handling things correctly. ... HH On 7/13/05, Michael J. Ryan [EMAIL PROTECTED] wrote: AFAIK, sql server should accept an ISO formatted datetime.. iirc: -MM-ddTHH:mm:ss.fff not sure about appending a zzz for the offset? maybe entering as UTC with a Z after the .fff ? Chris van Wyk wrote: Hi, Datetime has also been giving me huge amounts of problems. The work around for me was to convert the item using ToString(s). If you are going to use stored procs, you will need to modify your stored proc parameters in the sql statement to string in stead of datetime. I have also been able to get the Microsoft.ApplicationBlocks.Data going with modification to specific DateTime parameter formatting. There seems to be problems with the data adapter using the sqlhelper from the above. I am getting concurrency errors on updates for instance. If someone else has had concurrency errors please let me know as I have been able to work round this, but I'm not sure if it is a bug in Mono. I am using 1.1.7 and have not tested the above on 1.1.8 Regards Chris -Original Message- From: [EMAIL PROTECTED] [mailto:mono-devel-list- [EMAIL PROTECTED] On Behalf Of Hubert FONGARNAND Sent: 12 July 2005 03:28 PM To: mono-devel-list@lists.ximian.com Subject: [Mono-devel-list] DateTime Parameters in MSSQL Server I've an issue with datetime parameters with MSSQL Server in Mono... It seem's that the parameters is badly sent to the SQL Server... Please test that : using System; using System.Data; using System.Data.SqlClient; class MainClass { static string cnx=user id=sa;password=sa;data source=10.69.100.93;initial catalog=Fiche_Produit; public static void Main(string[] args) { Console.WriteLine(Hello World!); SqlCommand cmd=new SqlCommand(); cmd.Connection=new SqlConnection(cnx); cmd.CommandText=INSERT INTO essais (date) VALUES (@date); cmd.Parameters.Clear(); cmd.Parameters.Add(@date,SqlDbType.DateTime).Value=DateTime.Now; cmd.Connection.Open(); cmd.ExecuteNonQuery(); cmd.Connection.Close(); } } it returns : Unhandled Exception: System.Data.SqlClient.SqlException: Erreur de conversion du type de données varchar en datetime. Erreur de conversion du type de données varchar en datetime. in [0x00034] (at /home/hubert/mono/mcs/class/System.Data/System.Data.SqlClient/SqlConnectio n.cs:266) System.Data.SqlClient.SqlConnection:ErrorHandler (System.Object sender, Mono.Data.Tds.Protocol.TdsInternalErrorMessageEventArgs e) in (wrapper delegate-invoke) System.MulticastDelegate:invoke_void_object_TdsInternalErrorMessageEventAr gs (object,Mono.Data.Tds.Protocol.TdsInternalErrorMessageEventArgs) In english : error when converting a varchar datatype into a datetime thanks -- Michael J. Ryan - tracker1(at)theroughnecks(dot)com - www.theroughnecks.net icq: 4935386 - AIM/AOL: azTracker1 - Y!: azTracker1 - MSN/Win: (email) ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list -- Robbie the Nanobot says: Only YOU can prevent gray goo (NEVER release nanobot assemblers without replication limiting code) http://lizardslounge.org ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
RE: [Mono-devel-list] Warning with Gnome.About
On Fri, 2005-07-01 at 09:15 -0700, Harry Chesley wrote: I use Gnome.About to display my about box. If I just open and close the about box, I get four of the following warnings (with sequential increasing ids): (Argeebee:5931): GLib-GObject-WARNING **: gsignal.c:1781: instance `0x9f08310' has no handler with id `183' If I open and close the credits sub-window before closing the about box, I don't get any warnings. Is there a way to avoid these warnings? (I can easily write my own about box, but it seems a shame not to use the standard one.) Thanks! This has to do with you calling Destroy with attached signal handlers, You should either let the gc handle it for you, or detach the signal handlers before you call Destroy. All I do in my program is this (with appropriate declarations of progname, progversion, prismIcon, authors, and documenters): new Gnome.About(progname, progversion, (C) 2005 Harry Chesley, Optics game, authors, documenters, null, prismIcon).Run(); So I suspect the offending behavior is inside the Gnome.About class. Short of fixing it there (which I'd rather not get into as a first Mono project :-), is there any way to work around it? Thanks. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-devel-list] Warning with Gnome.About
I use Gnome.About to display my about box. If I just open and close the about box, I get four of the following warnings (with sequential increasing ids): (Argeebee:5931): GLib-GObject-WARNING **: gsignal.c:1781: instance `0x9f08310' has no handler with id `183' If I open and close the credits sub-window before closing the about box, I don't get any warnings. Is there a way to avoid these warnings? (I can easily write my own about box, but it seems a shame not to use the standard one.) Thanks! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list