Re: [Mono-dev] [PATCH] Implement configuration loading for System.ServiceModel.Web

Hello, Thanks for the patch. I have applied large part of your patch in svn trunk. I fixed WebHttpBindingElement.Properties to include those from base type in less changes instead of your entire rewrite. (And some coding convention fixes.) Atsushi Eno On 2010/03/01 20:50, Sander Rijken wrote:

Re: [Mono-dev] Removing Obsolete Code from Mono 2.8

Hello, > just grepped under mcs/tools/*: prj2make, svcutil We should also obsolete prj2make as it no longer works with newer versions of Visual Studio, and also because we now have xbuild. iguel. ___ Mono-devel-list mailing list Mono-devel-list@lists.

Re: [Mono-dev] Removing Obsolete Code from Mono 2.8

Hello Daniel, [ Marek, there is a note for you here, can you check it? ] Thanks for your feedback, it was very useful. > Remove Mono.Data.dll which has been superceded by the provider factory added > to System.Data.dll in .NET 2.0. The Mono.Data.dll assembly has had the > Obsolete at

Re: [Mono-dev] Removing Obsolete Code from Mono 2.8

just grepped under mcs/tools/*: prj2make, svcutil Atsushi Eno Jonathan Pobst wrote: > On 3/1/2010 5:20 PM, Atsushi Eno wrote: >> Mono.GetOptions is used in a couple of our tools. I wouldn't mind much >> you volunteer to replace them with newer ones though (but others >> still may). > > Which ones

Re: [Mono-dev] Removing Obsolete Code from Mono 2.8

On 3/1/2010 5:20 PM, Atsushi Eno wrote: > Mono.GetOptions is used in a couple of our tools. I wouldn't mind much > you volunteer to replace them with newer ones though (but others still may). Which ones? Jonathan ___ Mono-devel-list mailing list Mono-de

Re: [Mono-dev] Removing Obsolete Code from Mono 2.8

Mono.GetOptions is used in a couple of our tools. I wouldn't mind much you volunteer to replace them with newer ones though (but others still may). Atsushi Eno Jonathan Pobst wrote: > On 3/1/2010 12:54 AM, Miguel de Icaza wrote: > >> In addition to this, I would like to stop distributing some

Re: [Mono-dev] Removing Obsolete Code from Mono 2.8

Hello, > Some other candidates are: > > - Mono.GetOptions I like this; Let us drop it from the build, and see what breaks. > - SharpZipLib > We currently ship two copies of this: 0.6 and 0.84. We should probably > drop 0.6, and possibly look at upgrading 0.84 to their latest, 0.85.5. In th

Re: [Mono-dev] Removing Obsolete Code from Mono 2.8

Why don't keep 2.x series API (I don't if ABI is used here) compatible. If you want to remove API why don't bump to 3.0? Like in GNOME 2.x, any software running can run while it is on any 2.x series. If you want to create a software for new or non-deprecated API, use 3.0. 2010/3/1 Jonathan Pobst

Re: [Mono-dev] Removing Obsolete Code from Mono 2.8

On Mon, 2010-03-01 at 10:13 -0800, Daniel Morgan wrote: > Obsolete Types in .NET 4.0 > http://msdn.microsoft.com/en-us/library/ee461503%28VS.100%29.aspx > > Here's my 2 cents. > > Remove Mono.Data.dll which has been superceded by the provider factory added > to System.Data.dll in .NET 2.0. The

Re: [Mono-dev] Removing Obsolete Code from Mono 2.8

Obsolete Types in .NET 4.0 http://msdn.microsoft.com/en-us/library/ee461503%28VS.100%29.aspx Here's my 2 cents. Remove Mono.Data.dll which has been superceded by the provider factory added to System.Data.dll in .NET 2.0. The Mono.Data.dll assembly has had the Obsolete attributes on it for a lo

Re: [Mono-dev] Removing Obsolete Code from Mono 2.8

On 3/1/2010 12:54 AM, Miguel de Icaza wrote: > In addition to this, I would like to stop distributing some libraries > that were either never completed and are not being actively maintained. >We could move these libraries to a separate module if people would > like to maintain them or keep dist

Re: [Mono-dev] Removing Obsolete Code from Mono 2.8

On Mon, Mar 1, 2010 at 03:54, Miguel de Icaza wrote: > With the upcoming release of Mono 2.8 we are dropping the 1.0 profile as > developers moved a long time ago to the generics-based 2.0 profile and > because it is maintenance burden for us. > > In addition to this, I would like to stop distribu

Re: [Mono-dev] Patch for DateTime.TryParseExact handling of null input string

Hello! Thanks for the patch. > .NET 3.5 does not throw a null reference exception on DateTime.TryParseExact > if the first parameter is null. > > Attached is a test case and a fix for DateTime.cs > > Index: System/DateTime.cs > ===

Re: [Mono-dev] Removing Obsolete Code from Mono 2.8

hello, > > With the upcoming release of Mono 2.8 we are dropping the 1.0 profile > > as developers moved a long time ago to the generics-based 2.0 profile > > and because it is maintenance burden for us. > > Is there a date for this? Last I saw from Andrew was another spin on the > 2.6 branch...

[Mono-dev] [PATCH] Implement configuration loading for System.ServiceModel.Web

Hi, This patch fixes the issues I've found while attempting to use webHttpBinding. Changelog: Move away from static ConfigurationProperty fields, to allow including the ConfigurationProperties in base in the Properties getter. Add testcases to verify configuration loading. -- Sander Rijken Web

Re: [Mono-dev] [PATCH] Improve compiler generated class handling and ReferenceEquality comparer.

Attached the same patch with coding style fixed. Kornél Pál wrote: Hi Marek, Emit and close top level compiler generated classes as well. They are already closed. Most of the compiler generated classes are nested types and those are closed. On the other hand DynamicExpressionStatement.St

Re: [Mono-dev] [PATCH] Improve compiler generated class handling and ReferenceEquality comparer.

Hi Marek, >> Emit and close top level compiler generated classes as well. > They are already closed. Most of the compiler generated classes are nested types and those are closed. On the other hand DynamicExpressionStatement.StaticDataClass in dynamic.cs is a top level compiler generated class.

Re: [Mono-dev] [PATCH] Improve compiler generated class handling and ReferenceEquality comparer.

Hi Kornél, > ChangeLog: > Don't make compiler generated classes sealed by default. What is benefit of not doing that? > Emit and close top level compiler generated classes as well. They are already closed. Marek ___ Mono-devel-list mailing list Mono-deve

Re: [Mono-dev] System.ServiceModel.Web configuration problems

Hello, On 2010/03/01 17:06, Sander Rijken wrote: > > > On Mon, Mar 1, 2010 at 4:26 AM, Atsushi Eno > > wrote: > > Hi, > > > On 2010/02/28 1:42, Sander Rijken wrote: > > Hi, > > I've been working on getting the configuration of

Re: [Mono-dev] System.ServiceModel.Web configuration problems

On Mon, Mar 1, 2010 at 4:26 AM, Atsushi Eno < atsushi...@veritas-vos-liberabit.com> wrote: > Hi, > > > On 2010/02/28 1:42, Sander Rijken wrote: > >> Hi, >> >> I've been working on getting the configuration of System.ServiceModel.Web >> up to speed, after finding out that it wasn't working at all w