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 when I needed
Hello,
On 2010/03/01 17:06, Sander Rijken wrote:
On Mon, Mar 1, 2010 at 4:26 AM, Atsushi Eno
atsushi...@veritas-vos-liberabit.com
mailto:atsushi...@veritas-vos-liberabit.com wrote:
Hi,
On 2010/02/28 1:42, Sander Rijken wrote:
Hi,
I've been working on
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
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.
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
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
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...
No
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
===
On Mon, Mar 1, 2010 at 03:54, Miguel de Icaza mig...@novell.com 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
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
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
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
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
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 this
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
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
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?
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
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
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:
20 matches
Mail list logo
