Re: [Mono-dev] Patch for Atom10{Item, Feed}Formatter for writing element extensions
Thanks, applied the patch. Atsushi Eno On 2009/11/26 8:13, Tom Philpot wrote: Here's a patch for Atom10ItemFormatter and Atom10FeedFormatter which writes ElementExtensions for the Feed and Item. This patch is MIT/X11 licenesed and brought to you by Martin Potter. Tom ___ 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] Request to include a patch for Gregoraian localization in mono
resending from my registered address. I didn't really write that code, but I'll review and apply the patch if it is ok, when I am back to work tomorrow. Atsushi Eno On 2009/12/16 9:42, Miguel de Icaza wrote: Hello Vladimir, Atsushi, I do not have a problem with most of the patch, but Atsushi should really review this patch as he wrote that code. Hey guys my colleague worked on some improvements in mono in order to allow support for Gregorian localization. That was needed as we have some potential clients in Georgia and our application works ok under Windows and .net but it turned out that the Georgian localization support was not complete under for mono. This post includes a patch that adds the required changes to add support for Gregorian. http://go-mono.com/forums/#nabble-p26766782 Can you please tell me if you can include that in the mono tree. Thanks, Vladimir Dimitrov ___ 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] [PATCH] Add missing DateTimeOffset operators to XElement
Oh, those are nice tests. Thanks for writing them :-) I'll examine the failing tests and will fix identified bugs. Atsushi Eno Tiaan Geldenhuys wrote: Thanks, Atsushi. Fair enough, see the attachment for the enhanced tests that you can also apply to the trunk; the test for my earlier patch is simply whether the enhanced code can compile under Mono. However, once compiled and running, the extra tests also highlight numerous discrepancies between the behavior of Mono and MS .NET when using the casting operators of XElement (all the new CastXxx tests pass under .NET, while many fail under Mono). It seems that the underlying XmlConvert class may cause some of the problems. Since I provided the welcomed tests, would you mind logging these bugs or fixing them? ;-) Regards, Tiaan. -Original Message- From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com] Sent: 09 January 2010 3:51 AM To: Tiaan Geldenhuys Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] [PATCH] Add missing DateTimeOffset operators to XElement Hello, Thanks, I'm going to apply the patch. (Patches with tests are more welcomed ;-) Atsushi Eno On 2010/01/09 13:04, Tiaan Geldenhuys wrote: This patch adds two of the newer DateTimeOffset operators that are still missing on the System.Xml.Linq.XElement class. Please commit. ___ 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] [PATCH] Add missing DateTimeOffset operators to XElement
They are all fixed in svn trunk, except the case that casts to UIntXX expect FormatException instead of OverflowException, which I believe is not possible due to NET's call to internal members in corlib (commented as r149388). Man, I'm exhausted to fix those extensive tests ;-) Thanks again for the great work! Atsushi Eno On 2010/01/12 9:00, Atsushi Eno wrote: Oh, those are nice tests. Thanks for writing them :-) I'll examine the failing tests and will fix identified bugs. Atsushi Eno Tiaan Geldenhuys wrote: Thanks, Atsushi. Fair enough, see the attachment for the enhanced tests that you can also apply to the trunk; the test for my earlier patch is simply whether the enhanced code can compile under Mono. However, once compiled and running, the extra tests also highlight numerous discrepancies between the behavior of Mono and MS .NET when using the casting operators of XElement (all the new CastXxx tests pass under .NET, while many fail under Mono). It seems that the underlying XmlConvert class may cause some of the problems. Since I provided the welcomed tests, would you mind logging these bugs or fixing them? ;-) Regards, Tiaan. -Original Message- From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com] Sent: 09 January 2010 3:51 AM To: Tiaan Geldenhuys Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] [PATCH] Add missing DateTimeOffset operators to XElement Hello, Thanks, I'm going to apply the patch. (Patches with tests are more welcomed ;-) Atsushi Eno On 2010/01/09 13:04, Tiaan Geldenhuys wrote: This patch adds two of the newer DateTimeOffset operators that are still missing on the System.Xml.Linq.XElement class. Please commit. ___ 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] [PATCH] Add missing DateTimeOffset operators to XElement
They are now in 2.6 branch too. Atsushi Eno On 2010/01/13 5:25, Tiaan Geldenhuys wrote: I'm glad you made it through the obstacle course in one piece, Atsushi! Sidestepping that tricky UIntXX case seems reasonable. What's the chance of a backport to the 2.6 branch? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] Add XAttribute's missing DateTimeOffset operators, with tests
Hello, Thanks for the massive tests again. All test failures are now fixed in trunk :) I'll backport the changes later. Atsushi Eno On 2010/01/15 10:09, Tiaan Geldenhuys wrote: [Resending with one attachment compressed, due to mailing-list's size restrictions.] This is probably again for Atsushi: Similar to the last round with XElement, but now for XAttribute, the attached patch adds the latter's missing DateTimeOffset operators. The extra tests only compile under Mono after applying the patch and now include test-cases for XAttribute that are similar to those for XElement; all pass under .NET, but some of the code underlying the casting operators may still need fixing for Mono. The tests also expand on what was previously testable under Mono, and there is one particularly interesting case where about 1 of every 8 DateTime values would lose a tick: it looks like a weird rounding-error and can now be reproduced reliably with these tests. Atsushi's patches from earlier this week already made a huge difference, and getting the new tests to work should make for an even more robust LINQ-to-XML implementation. Please commit the patches and investigate the new tests that fail. Thank you, Tiaan. ___ 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 Fix CanConvertTo and ConverTo of/for primitive types.
Let's just check in the patch. Alex, thanks for creating it.
Atsushi Eno
Ivan Zlatev wrote:
Hi and sorry for the delay,
I think that I am the last to have touched the
System.ComponentModel(.Design) namespaces and I think this patch looks
good.
Kind Regards,
Ivan Zlatev
http://ivanz.com
On Wed, Jan 20, 2010 at 8:05 PM, Alexandre Miguel Pedro Gomes
alexmip...@gmail.com wrote:
Hi again,
Can't anyone review or comment on it? Where is the maintainer for the
System.ComponentModel modules?
I would really like to have this committed ASAP so I can avoid patching my
sources when the next minor revision of Mono is released.
Cheers,
On Fri, Jan 15, 2010 at 20:28, Alexandre Miguel Pedro Gomes
alexmip...@gmail.com wrote:
Hi,
I've detected a problem with type convertion when using the TypeConverters
for a type. My initial test case for comparing Mono 2.4.* and trunk results
with the .Net framework was as such:
-- code --
using System;
using System.ComponentModel;
namespace PrimitiveTests
{
class Program
{
static void Main(string[] args)
{
Type[] types = { typeof(Boolean),
typeof(Byte),
typeof(SByte),
typeof(Int16),
typeof(UInt16),
typeof(Int32),
typeof(UInt32),
typeof(Int64),
typeof(UInt64),
typeof(IntPtr),
typeof(UIntPtr),
typeof(Char),
typeof(Double),
typeof(Single)};
foreach(Type type in types)
Console.WriteLine(CanConvert + type + to Int32? +
TypeDescriptor.GetConverter(type).CanConvertTo(typeof(Int32)));
Console.WriteLine(TypeDescriptor.GetConverter(typeof(uint)).ConvertTo((uint)134,
typeof(int)));
Console.ReadKey();
}
}
}
-- code --
This revealed that all primitives with a few exceptions (bool, intptr,
char) should be allowed to be converted and Mono's CanConvertTo (and the
actual conversion) was failing. I've created a patch and necessary unit
tests to fix the issue and tested both with the previous script and with my
(now patched) Mono 2.4.3 server's install.
If someone could review, it would be appreciated. I can commit if the
maintainer approves the code.
Regards,
--
Alexandre Gomes
http://www.alexandre-gomes.com
--
Alexandre Gomes
http://www.alexandre-gomes.com
___
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] [PATCH] Fix float.Parse, float.TryParse and XmlConvert.ToString for float.MaxValue, float.PositiveInfinity and TimeSpan.MinValue
The patch was checked in trunk and 2.6. Thanks. Atsushi Eno Tiaan Geldenhuys wrote: These patches fix the parsing of float.MaxValue and float.PositiveInfinity on the System.Single class, and the serialization of TimeSpan.MinValue on the System.Xml.XmlConvert.ToString method. Tests are included for the root-causes themselves, as well as for the System.Xml.Linq classes through which the problems were initially discovered. Please commit to trunk and the 2.6 branch. Thanks, Tiaan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] POSTing objects in JSON format...
Hello,
Our WebHttpBinding does support json-based requests and responses.
There is a lot of possibilities why you don't get json response instead
of xml, and I can't give you an answer with almost no information.
If you file a bug with the steps to configure and run the service, I'll
have a look.
Atsushi Eno
On 2010/01/26 9:47, ed.segura wrote:
Hi,
I'm wondering why this format doesn't work for mono, when it does for
windows?
I'm trying to send a simple post request to the service, which contains the
following:
{composite:{BoolValue:true,StringValue:aaa},composite2:{BoolValue:true,StringValue:bbb}}
This works fine in VS2008, but I keep getting an exception when I try to
POST that data using mono:
Exit HttpContextAcquired:
http://127.0.0.1:8080/Service1.svc/PostDataUsingTwoCompositeTypes
Exit AspNetReplyChannel.WaitForRequest
AspNetReplyChannel caught an error: System.Xml.XmlException: Text node
cannot appear in this state. Line 1, position 1.
at Mono.Xml2.XmlTextReader.ReadText (Boolean notWhitespace) [0x00199] in
/usr/src/packages/BUILD/mono-2.6.1/mcs/class/System.XML/System.Xml/XmlTextReader.cs:1699
at Mono.Xml2.XmlTextReader.ReadContent () [0x0015c] in
/usr/src/packages/BUILD/mono-2.6.1/mcs/class/System.XML/System.Xml/XmlTextReader.cs:1345
at Mono.Xml2.XmlTextReader.Read () [0x00141] in
/usr/src/packages/BUILD/mono-2.6.1/mcs/class/System.XML/System.Xml/XmlTextReader.cs:619
at System.Xml.XmlTextReader.Read () [0x0006b] in
/usr/src/packages/BUILD/mono-2.6.1/mcs/class/System.XML/System.Xml/XmlTextReader2.cs:564
...
Am I missing something? I tried with several variations of the syntax, but
nothing seems to work. I also looked in the forums for json serialization
issues on 'post', but no luck.
Any help will be highly appreciated...
ed-
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] POSTing objects in JSON format...
Hello Eduardo,
Thanks, your repro was simple enough to try :) Now I'm getting some
ASP.NET integration issue that should be fixed. I'll see if further
issues exist once I fixed the issue I faced now. It may take a while as
I'm now full with other bugs, but I put your case on my stack.
Atsushi Eno
On 2010/01/26 16:09, Eduardo Segura wrote:
Hi Atsushi,
Thanks for the quick answer. I'm attaching a solution with a simple
service. The method I'm trying to call is the one receiving two
composite types.
Could you quickly verify if this works for you? Sorry I didn't file a
bug or gave more details earlier today, but I thought it was just me
cutting my teeth with mono.
Bjorg, you might actually be on the right track. I did try to feed the
service with some well-formed xml, and the exceptions changed
immediately. Maybe it's something related to the selection of the mime
type? I'm using 'Poster' (firefox add-on) to hand-craft my post
requests to the service. The mime type I'm using is application/json,
as defined in RFC 4627
Thanks for the help,
Best,
ed-
On Mon, Jan 25, 2010 at 6:06 PM, Atsushi Eno
atsushi...@veritas-vos-liberabit.com wrote:
Hello,
Our WebHttpBinding does support json-based requests and responses.
There is a lot of possibilities why you don't get json response instead
of xml, and I can't give you an answer with almost no information.
If you file a bug with the steps to configure and run the service, I'll
have a look.
Atsushi Eno
On 2010/01/26 9:47, ed.segura wrote:
Hi,
I'm wondering why this format doesn't work for mono, when it does for
windows?
I'm trying to send a simple post request to the service, which contains
the
following:
{composite:{BoolValue:true,StringValue:aaa},composite2:{BoolValue:true,StringValue:bbb}}
This works fine in VS2008, but I keep getting an exception when I try to
POST that data using mono:
Exit HttpContextAcquired:
http://127.0.0.1:8080/Service1.svc/PostDataUsingTwoCompositeTypes
Exit AspNetReplyChannel.WaitForRequest
AspNetReplyChannel caught an error: System.Xml.XmlException: Text node
cannot appear in this state. Line 1, position 1.
at Mono.Xml2.XmlTextReader.ReadText (Boolean notWhitespace) [0x00199] in
/usr/src/packages/BUILD/mono-2.6.1/mcs/class/System.XML/System.Xml/XmlTextReader.cs:1699
at Mono.Xml2.XmlTextReader.ReadContent () [0x0015c] in
/usr/src/packages/BUILD/mono-2.6.1/mcs/class/System.XML/System.Xml/XmlTextReader.cs:1345
at Mono.Xml2.XmlTextReader.Read () [0x00141] in
/usr/src/packages/BUILD/mono-2.6.1/mcs/class/System.XML/System.Xml/XmlTextReader.cs:619
at System.Xml.XmlTextReader.Read () [0x0006b] in
/usr/src/packages/BUILD/mono-2.6.1/mcs/class/System.XML/System.Xml/XmlTextReader2.cs:564
...
Am I missing something? I tried with several variations of the syntax, but
nothing seems to work. I also looked in the forums for json serialization
issues on 'post', but no luck.
Any help will be highly appreciated...
ed-
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] problem compiling on cygwin.
Back to the original problem, what if you run make get-monolite-latest
first before running make?
Atsushi Eno
On 2010/01/27 7:02, Zoltan Varga wrote:
Hi,
You are trying to run mcs on the .net runtime, this is not
supported, the error message is
not very helpful tough.
On Fri, Jan 22, 2010 at 2:02 AM, Sin Li sinb...@gmail.com
mailto:sinb...@gmail.com wrote:
A trace reveals the culprit:
In codegen.cs method Init()
try {
Assembly.Builder = current_domain.DefineDynamicAssembly (an,
AssemblyBuilderAccess.RunAndSave | COMPILER_ACCESS,
Dirname (name));
}
COMPILER_ACCESS is defined as
#if MS_COMPATIBLE
const AssemblyBuilderAccess COMPILER_ACCESS = 0;
#else
/* Keep this in sync with
System.Reflection.Emit.AssemblyBuilder */
const AssemblyBuilderAccess COMPILER_ACCESS =
(AssemblyBuilderAccess)
0x800;
#endif
Seems like it's a compiler flag that's not compatible with the clr.
Lucas Meijer-4 wrote:
Hey,
I'm compiling mono on windows in sygwin.
After a few bumps on the road that google and the mono-devel
archive took
care of, I'm now running into this one:
snip
make[7]: Entering directory `/usr/src/mono/mcs/build'
make[7]: Leaving directory `/usr/src/mono/mcs/build'
make[6]: Leaving directory `/usr/src/mono/mcs/build'
make[6]: Entering directory `/usr/src/mono/mcs/jay'
make all-local
make[7]: Entering directory `/usr/src/mono/mcs/jay'
make[7]: Nothing to be done for `all-local'.
make[7]: Leaving directory `/usr/src/mono/mcs/jay'
make[6]: Leaving directory `/usr/src/mono/mcs/jay'
make[6]: Entering directory `/usr/src/mono/mcs/mcs'
make all-local
make[7]: Entering directory `/usr/src/mono/mcs/mcs'
MCS [basic] mcs.exe
Unhandled Exception: System.ArgumentException: Illegal enum
value: 2051.
Parameter name: access
at
System.AppDomain.InternalDefineDynamicAssembly(AssemblyName name,
Assembly
BuilderAccess access, String dir, Evidence evidence, PermissionSet
requiredPermi
ssions, PermissionSet optionalPermissions, PermissionSet
refusedPermissions,
Sta
ckCrawlMark stackMark, IEnumerable`1 unsafeAssemblyAttributes)
at System.AppDomain.DefineDynamicAssembly(AssemblyName name,
AssemblyBuilderA
ccess access, String dir)
at Mono.CSharp.CodeGen.Init(String name, String output, Boolean
want_debuggin
g_support)
at Mono.CSharp.Driver.Compile()
at Mono.CSharp.Driver.Main(String[] args)
make[7]: *** [../class/lib/basic/mcs.exe] Error 77
make[7]: Leaving directory `/usr/src/mono/mcs/mcs'
make[6]: *** [do-all] Error 2
make[6]: Leaving directory `/usr/src/mono/mcs/mcs'
make[5]: *** [all-recursive] Error 1
/snip
Does this ring a bell for anybody?
When I do a which mcs I get:
/cygdrive/h/Program\ Files/Mono-2.0/bin/mcs
which seems okay to me.
Bye, Lucas
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
mailto:Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
View this message in context:
http://old.nabble.com/problem-compiling-on-cygwin.-tp20737913p27266257.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
mailto: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] [PATCH] Fix float.Parse, float.TryParse and XmlConvert.ToString for float.MaxValue, float.PositiveInfinity and TimeSpan.MinValue
Oops, it was dropping in my commit. It's now in 2.6 branch too. Atsushi Eno On 2010/01/28 1:08, Tiaan Geldenhuys wrote: One of the files (XmlConvert.cs) was not included in the 2.6 backport during the r150106 commit, and some tests now fail. Would someone please copy that file from r150102? Thank you. -Original Message- From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com] Sent: 24 January 2010 11:43 PM To: Tiaan Geldenhuys Cc: mono-devel-list@lists.ximian.com Subject: Re: [PATCH] Fix float.Parse, float.TryParse and XmlConvert.ToString for float.MaxValue, float.PositiveInfinity and TimeSpan.MinValue The patch was checked in trunk and 2.6. Thanks. Atsushi Eno Tiaan Geldenhuys wrote: These patches fix the parsing of float.MaxValue and float.PositiveInfinity on the System.Single class, and the serialization of TimeSpan.MinValue on the System.Xml.XmlConvert.ToString method. Tests are included for the root-causes themselves, as well as for the System.Xml.Linq classes through which the problems were initially discovered. Please commit to trunk and the 2.6 branch. Thanks, Tiaan. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] MaxOS: WSDL proxy generation for WCF service running on Windows
You might want to check if your server machine is accessible from your client machine by, for example, wget. Atsushi Eno On 2010/02/23 2:21, cw wrote: Environment: WCF service implemented using .Net 3.5, running on windows machine in local network. Client shall be generated for mono on MacOS. If URL of WebService is opened in Firefox the WSDL is displayed. If wsdl is executed on Mac (wsdl http://url-of-my-wsdl) the following error is displayed: Error: ConnectFailure (connection refused). WSDL generation for public available WSDL (e.g. from amazon) is working. Any idea? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WCP and ServiceHost
Hello, As mentioned on [*1] you won't get NetTcpBinding working unless you are using trunk. Besides, 1) you use reliable session which is not implemented, and 2) those timeouts seem too short and I don't think they result in good connection. Basically NetTcpBinding is not very stable and it won't be suitable for those who cannot dig into its internals. [*1] http://veritas-vos-liberabit.com/monogatari/2009/12/mono-wcf-advent-day-11-nettcpbinding.html Atsushi Eno On 2010/02/24 2:15, Ásgeir Halldórsson wrote: Hello, I have a strange problem with WCF and ServiceHost is seams my server is not listening sometimes (like 50/50). Has anyone had the same problem, Also my client hangs on trying to connect and does not throw and error after 5 sec like the config tells it to. Any comments? CODE Server: Uri uri = new Uri(ConfigurationManager.AppSettings[addr]); host = new ServiceHost(typeof(GlobalService), uri); host.Open(); //Returns always Config Server: appSettings add key=addr value=net.tcp://private:2/globalservice / /appSettings system.serviceModel services service name=com.PageFlipper.GlobalServer.GlobalService behaviorConfiguration=GlobalServer.GlobalServiceBehavior endpoint address= binding=netTcpBinding bindingConfiguration=DuplexBinding contract=GlobalServer.IGlobalService /endpoint /service /services behaviors serviceBehaviors behavior name=GlobalServer.GlobalServiceBehavior serviceThrottling maxConcurrentSessions=1 / /behavior /serviceBehaviors /behaviors bindings netTcpBinding binding name=DuplexBinding openTimeout=00:00:05 closeTimeout=00:00:05 receiveTimeout=00:10:00 sendTimeout=00:00:05 reliableSession enabled=true / security mode=None / /binding /netTcpBinding /bindings /system.serviceModel Clinet CODE: var client = new Proxy.GlobalServiceClient(); client.Open(); // Hangs like 50/50 of the time Client config system.serviceModel client endpoint address=net.tcp://private:2/globalservice binding=netTcpBinding bindingConfiguration=DefaultBinding_IGlobalService contract=Proxy.IGlobalService name=DefaultBinding_IGlobalService_IGlobalService / /client bindings netTcpBinding binding name=DefaultBinding_IGlobalService openTimeout=00:00:05 closeTimeout=00:00:05 receiveTimeout=00:10:00 sendTimeout=00:00:05 reliableSession enabled=true / security mode=None / /binding /netTcpBinding /bindings /system.serviceModel ___ 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] System.ServiceModel.Web configuration problems
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 it in a project. I have some question now that I'm trying to include test code, and the fixes themselve. Oh, that's good news :) First of all, I think the fixes need to be split up in 3 commits. What's the best way to generate patches for this, in order to be able to apply them correctly? All changes are in the same file Ideally make incremental changes. First patch to include only the first changes, second patch, based on the first changes, and the third one follows. Alternatively you could use git and git-svn to get incremental diffs easier. Though no one is working on the config stuff, personally I probably wouldn't care to apply the changes at a time (depends on the changes). The test project for System.ServiceModel.Web includes a project nunit.framework.dll20. It seems like you're using 2.4 in other places, and also without an nunit.framework project in the test solution. Is it ok to get rid of the reference to the non-existing project, and update the sln / csproj to use the nunit.framework dll? What is the location of the dll that should be used here? I'm not sure what they are for (no one actually uses VS solutions for WCF hacking). Probably they are generated by someone, so let's just ignore them. I'll just omit them when committing them. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
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 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 getting the configuration of System.ServiceModel.Web up to speed, after finding out that it wasn't working at all when I needed it in a project. I have some question now that I'm trying to include test code, and the fixes themselve. Oh, that's good news :) First of all, I think the fixes need to be split up in 3 commits. What's the best way to generate patches for this, in order to be able to apply them correctly? All changes are in the same file Ideally make incremental changes. First patch to include only the first changes, second patch, based on the first changes, and the third one follows. Alternatively you could use git and git-svn to get incremental diffs easier. Though no one is working on the config stuff, personally I probably wouldn't care to apply the changes at a time (depends on the changes). You mean just use one big patch that fixes all problems? Yes, exactly. (Bad English, I meant to say Though since ;) The test project for System.ServiceModel.Web includes a project nunit.framework.dll20. It seems like you're using 2.4 in other places, and also without an nunit.framework project in the test solution. Is it ok to get rid of the reference to the non-existing project, and update the sln / csproj to use the nunit.framework dll? What is the location of the dll that should be used here? I'm not sure what they are for (no one actually uses VS solutions for WCF hacking). Probably they are generated by someone, so let's just ignore them. I'll just omit them when committing them. Can you indicate what determines which testcases run, and how to run them on a *nix based system? Once you checked out and built mono (and mcs) from svn, go to mcs/class/System.ServiceModel.Web , and then run make run-test Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
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 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 distributing them. Some other candidates are: - Mono.GetOptions - 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. Jonathan ___ 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] 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? Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
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: 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 ___ 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] WCF: ObjectDisposedException in System.ServiceModel.Channels
Hello, There are few things I can say from your input, but 1) I have never heard of this kind of problem and 2) trunk is way better than 2.6. Atsushi Eno On 2010/03/12 1:09, Matt Dargavel wrote: Hi there, I’ve found an issue in Mono 2.6.0 using a self hosted WCF service and was wondering if anyone had seen this before (Mono trace below). It appears to be caused by firing in a request to the Service that takes a long time and while that request is still running firing in another one. I’ve tried with both a Singleton service instance with ConcurrencyMode.Single and a service host with a type and ConcurrencyMode.Multiple but both seem to have the same problem. I’m just trying the latest svn and will try to pinpoint the issue, but any help / pointers would be appreciated! Regards, Matt. Trace: [0xb464bba0: 13.87800 3] ENTER: System.ServiceModel.Channels.ReplyChannelBase:BeginTryReceiveRequest (System.TimeSpan,System.AsyncCallback,object)(this:0x4eab0[System.ServiceModel.Channels.HttpSimpleReplyChannel SipGateway.exe], [00,bc,a0,65,01,00,00,00,], [System.AsyncCallback:0xcad90], [System.ServiceModel.Channels.HttpSimpleReplyChannel:0x4eab0], ) [0xb464bba0: 13.87843 4] ENTER: (wrapper delegate-begin-invoke) System.ServiceModel.Channels.ReplyChannelBase/TryReceiveDelegate:begin_invoke_IAsyncResult__this___TimeSpan_RequestContext_AsyncCallback_object (System.TimeSpan,System.ServiceModel.Channels.RequestContext,System.AsyncCallback,object)(this:0x1e78f8[.TryReceiveDelegate SipGateway.exe], [00,bc,a0,65,01,00,00,00,], [BYREF:0xb464b0f0], [System.AsyncCallback:0xcad90], [System.ServiceModel.Channels.HttpSimpleReplyChannel:0x4eab0], ) [0xb464bba0: 13.87927 4] LEAVE: (wrapper delegate-begin-invoke) System.ServiceModel.Channels.ReplyChannelBase/TryReceiveDelegate:begin_invoke_IAsyncResult__this___TimeSpan_RequestContext_AsyncCallback_object (System.TimeSpan,System.ServiceModel.Channels.RequestContext,System.AsyncCallback,object)[System.Runtime.Remoting.Messaging.AsyncResult:0xcad58] [0xb464bba0: 13.87969 3] LEAVE: System.ServiceModel.Channels.ReplyChannelBase:BeginTryReceiveRequest (System.TimeSpan,System.AsyncCallback,object)[System.Runtime.Remoting.Messaging.AsyncResult:0xcad58] [0xb464bba0: 13.88004 2] LEAVE: System.ServiceModel.Dispatcher.ListenerLoopManager:ProcessRequestOrInput (System.ServiceModel.Channels.IChannel) [0xb464bba0: 13.88058 1] LEAVE: System.ServiceModel.Dispatcher.ListenerLoopManager:ProcessRequest (System.ServiceModel.Channels.IReplyChannel,System.ServiceModel.Channels.RequestContext) [0xb464bba0: 13.88314 0] LEAVE: System.ServiceModel.Dispatcher.ListenerLoopManager:TryReceiveRequestDone (System.IAsyncResult) [0xb3af0ba0: 13.88414 0] ENTER: (wrapper runtime-invoke) Module:runtime_invoke_bool__this___TimeSpan_intptr (object,intptr,intptr,intptr)([.TryReceiveDelegate:0x1e78f8], 0xb3af0250, 0xb3af0300, 0xb46b6b38, ) [0xb3af0ba0: 13.88466 1] ENTER: System.ServiceModel.Channels.ReplyChannelBase:BeginTryReceiveRequestm__4 (System.TimeSpan,System.ServiceModel.Channels.RequestContext)(this:0x4eab0[System.ServiceModel.Channels.HttpSimpleReplyChannel SipGateway.exe], [00,bc,a0,65,01,00,00,00,], [BYREF:0x84a1c], ) [0xb3af0ba0: 13.88507 2] ENTER: System.ServiceModel.Channels.HttpSimpleReplyChannel:TryReceiveRequest (System.TimeSpan,System.ServiceModel.Channels.RequestContext)(this:0x4eab0[System.ServiceModel.Channels.HttpSimpleReplyChannel SipGateway.exe], [00,bc,a0,65,01,00,00,00,], [BYREF:0x84a1c], ) [0xb3af0ba0: 13.88593 3] ENTER: System.ServiceModel.Channels.HttpSimpleReplyChannel:WaitForRequest (System.TimeSpan)(this:0x4eab0[System.ServiceModel.Channels.HttpSimpleReplyChannel SipGateway.exe], [00,bc,a0,65,01,00,00,00,], ) [0xb3af0ba0: 13.88641 4] ENTER: System.ServiceModel.Channels.HttpListenerManager:GetHttpContextAsync (System.TimeSpan,System.Action`1System.ServiceModel.Channels.HttpContextInfo)(this:0x886c0[System.ServiceModel.Channels.HttpSimpleListenerManager SipGateway.exe], [00,bc,a0,65,01,00,00,00,], XX, ) [0xb3af0ba0: 13.88683 5] ENTER: System.ServiceModel.Channels.HttpListenerManager:FilterHttpContext (System.ServiceModel.Channels.HttpContextInfo)(this:0x886c0[System.ServiceModel.Channels.HttpSimpleListenerManager SipGateway.exe], [System.ServiceModel.Channels.HttpListenerContextInfo:0xc4640], ) [0xb3af0ba0: 13.88719 6] ENTER: System.ServiceModel.Channels.HttpListenerContextInfo:get_HttpMethod ()(this:0xc4640[System.ServiceModel.Channels.HttpListenerContextInfo SipGateway.exe], ) [0xb3af0ba0: 13.89048 6] LEAVE: System.ServiceModel.Channels.HttpListenerContextInfo:get_HttpMethod ()[STRING:0x8f7b0:POST] [0xb3af0ba0: 13.89179 5] LEAVE: System.ServiceModel.Channels.HttpListenerManager:FilterHttpContext (System.ServiceModel.Channels.HttpContextInfo)TRUE:1 [0xb3af0ba0: 13.89233 5] ENTER
[Mono-dev] exception stack trace (was Re: WCF: ObjectDisposedException in System.ServiceModel.Channels)
I don't think it is doable, but runtime guys might know. Atsushi Eno On 2010/03/16 2:24, Matt Dargavel wrote: It's alright, I'm pretty sure it's in TryReceiveRequest somewhere. Is there any way to get a stack trace for exceptions raised and handled within the runtime using the tracing? Would they have line numbers in? Cheers, Matt. -Original Message- From: Matt Dargavel Sent: 15 March 2010 3:58 PM To: 'Atsushi Eno' Cc: mono-devel-list@lists.ximian.com Subject: RE: [Mono-dev] WCF: ObjectDisposedException in System.ServiceModel.Channels I've tried the trunk version and it's still there. One question regarding the Mono tracing. Do the EXCEPTION traces come out as soon as the exception is thrown, or when they are handled. I'm trying to work out from the trace which function is using the disposed object / throwing the exception. Hopefully I might have a chance of working out what's causing the problem and coming up with a fix for it. Cheers, Matt. -Original Message- From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com] Sent: 12 March 2010 3:25 AM To: Matt Dargavel Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] WCF: ObjectDisposedException in System.ServiceModel.Channels Hello, There are few things I can say from your input, but 1) I have never heard of this kind of problem and 2) trunk is way better than 2.6. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WCF: ObjectDisposedException in System.ServiceModel.Channels
Hello, That sounds like a cool set of fixes :) Either this list or bugzilla is okay for me. Atsushi Eno On 2010/03/20 2:55, Matt Dargavel wrote: I've found the problem and I have a few patches to submit. The patches cover the following: * Some fixes for the issue I was seeing below (some multithreaded timing issues). * A change to make the check against ?wsdl case insensitive for the root wsdl page, after that you should follow the include links anyway. This appears to be more consistent with the way .NET works. * A change to the property handling of TransactionChannelListenerTChannel and ChannelListenerBase to fix a problem with the MetadataPublishingInfo property. This patch probably requires some extra explanation / discussion. * A change to ServiceHostBase so that ApplyDescription can add base addresses (a problem I noticed when using config files). I've made the changes against tip, although I've also tried the resulting dll with 2.6 (.1) and it seems to work fine. Do you have a preference as to how I submit the patches? Regards, Matt. -Original Message- From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com] Sent: 12 March 2010 3:25 AM To: Matt Dargavel Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] WCF: ObjectDisposedException in System.ServiceModel.Channels Hello, There are few things I can say from your input, but 1) I have never heard of this kind of problem and 2) trunk is way better than 2.6. Atsushi Eno On 2010/03/12 1:09, Matt Dargavel wrote: Hi there, I've found an issue in Mono 2.6.0 using a self hosted WCF service and was wondering if anyone had seen this before (Mono trace below). It appears to be caused by firing in a request to the Service that takes a long time and while that request is still running firing in another one. I've tried with both a Singleton service instance with ConcurrencyMode.Single and a service host with a type and ConcurrencyMode.Multiple but both seem to have the same problem. I'm just trying the latest svn and will try to pinpoint the issue, but any help / pointers would be appreciated! Regards, Matt. Trace: ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] WCF multithreaded and property handling
Hello,
Thanks for the patch. They are looking like a great set of attempts for
cool bugfixes :) However there is a lot of other changes that your
description cannot explain. So, please first split the changes into
further smaller patches for each purpose, and give explanation for each
change. For example,
- // FIXME: this should not be required, but it somehow saves some
failures wrt concurrent calls.
- Thread.Sleep (100);
This kind of change should not be made without explanation. (you aren't
really sure about why it exists, right?)
As for ChannelListenerBase.Properties, I'd rather make the changes much
smaller like the attached change. Isn't it enough? There's no test case
that I can verify your (and-my) changes.
Atsushi Eno
On 2010/03/23 20:28, Matt Dargavel wrote:
The included patches fix the following:
multithreaded_fixes.patch: ObjectDisposedException,
InvalidOperationException(Another async TryReceiveRequest operation
is in progress) and other multithreaded timing fixes. Also includes
change to make GET ?wsdl case insensitive.
properties_handling.patch: MetadataPublishingInfo not available in
TransactionChannelListener’s inner_listener. I created a new
RetrieveProperty function as overriding GetPropertyT didn’t work-
the ChannelListenerBase implementation was still called. Perhaps
there’s a bug with generic function overrides or maybe I’ve done
something silly there?
properties_and_wsdl.patch: patch for ServiceMetadataExtension.cs that
goes with the properties changes and the ?wsdl change.
Let me know if you have any questions. :-)
Matt.
Index: System.ServiceModel.Channels/ChannelListenerBase.cs
===
--- System.ServiceModel.Channels/ChannelListenerBase.cs (revision 154034)
+++ System.ServiceModel.Channels/ChannelListenerBase.cs (working copy)
@@ -84,7 +84,7 @@
get { return timeouts.SendTimeout; }
}
- internal KeyedByTypeCollectionobject Properties {
+ internal virtual KeyedByTypeCollectionobject Properties {
get {
if (properties == null)
properties = new
KeyedByTypeCollectionobject ();
Index: System.ServiceModel.Channels/TransactionFlowBindingElement.cs
===
--- System.ServiceModel.Channels/TransactionFlowBindingElement.cs
(revision 154034)
+++ System.ServiceModel.Channels/TransactionFlowBindingElement.cs
(working copy)
@@ -161,6 +161,13 @@
this.protocol = protocol;
}
+ internal override KeyedByTypeCollectionobject Properties {
+ get {
+ var b = inner_listener as ChannelListenerBase;
+ return b != null ? b.Properties :
base.Properties;
+ }
+ }
+
public override Uri Uri {
get { return inner_listener.Uri; }
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] WCF more detail on Destination Unreachable
It's looking fine, but how did you check your change? (I know it could happen not always reproducible, so that's okay if it's not really always reproducible.) BTW I thank a lot for your properties change, that fixed a bug that annoyed me today ;-) Atsushi Eno On 2010/03/23 20:28, Matt Dargavel wrote: A patch to return more detail when an endpoint / operation isn’t found. Not sure if you’ll want to apply this, but it helped in some service debugging I was doing. Matt. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] WCF multithreaded and property handling
Hi again, As for the properties test case, never mind. I happened to get one at hand (as my reply on DestinationUnreachable implies). Atsushi Eno On 2010/03/23 21:49, Atsushi Eno wrote: Hello, Thanks for the patch. They are looking like a great set of attempts for cool bugfixes :) However there is a lot of other changes that your description cannot explain. So, please first split the changes into further smaller patches for each purpose, and give explanation for each change. For example, - // FIXME: this should not be required, but it somehow saves some failures wrt concurrent calls. - Thread.Sleep (100); This kind of change should not be made without explanation. (you aren't really sure about why it exists, right?) As for ChannelListenerBase.Properties, I'd rather make the changes much smaller like the attached change. Isn't it enough? There's no test case that I can verify your (and-my) changes. Atsushi Eno On 2010/03/23 20:28, Matt Dargavel wrote: The included patches fix the following: multithreaded_fixes.patch: ObjectDisposedException, InvalidOperationException(Another async TryReceiveRequest operation is in progress) and other multithreaded timing fixes. Also includes change to make GET ?wsdl case insensitive. properties_handling.patch: MetadataPublishingInfo not available in TransactionChannelListener’s inner_listener. I created a new RetrieveProperty function as overriding GetPropertyT didn’t work- the ChannelListenerBase implementation was still called. Perhaps there’s a bug with generic function overrides or maybe I’ve done something silly there? properties_and_wsdl.patch: patch for ServiceMetadataExtension.cs that goes with the properties changes and the ?wsdl change. Let me know if you have any questions. :-) Matt. ___ 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] [PATCH] WCF multiple service contracts on one end point
I read and tried your patch, which indeed gives a great fix for your case. I'll recheck your changes and post my comments and/or apply the change. Thanks, it's really a nice fix :) Atsushi Eno On 2010/03/23 20:28, Matt Dargavel wrote: Patch to allow multiple service contracts on one end point. I’ve included an example source code file to show what I mean. Patch also includes a one line change (101-102 in patch) to ApplyConfiguration() to add base addresses to the list directly. I noticed that calling AddBaseAddress from here could cause problems when using setting up the service using configuration files. Regards, Matt ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] WCF more detail on Destination Unreachable
I still couldn't reproduce the detailed error message. Let's please post a runnable repro case instead of code-less explanation ;) Atsushi Eno On 2010/03/23 22:38, Matt Dargavel wrote: You can reproduce it by requesting an operation that doesn't exist. (It was happening before I implemented the two Service Contracts on one end point change as the wrong channel dispatcher was getting the request.) So I should be able to write a test case for that... -Original Message- From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com] Sent: 23 March 2010 12:57 PM To: Matt Dargavel Cc: mono-devel-list@lists.ximian.com Subject: Re: [PATCH] WCF more detail on Destination Unreachable It's looking fine, but how did you check your change? (I know it could happen not always reproducible, so that's okay if it's not really always reproducible.) BTW I thank a lot for your properties change, that fixed a bug that annoyed me today ;-) Atsushi Eno On 2010/03/23 20:28, Matt Dargavel wrote: A patch to return more detail when an endpoint / operation isn't found. Not sure if you'll want to apply this, but it helped in some service debugging I was doing. Matt. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] WCF multithreaded and property handling
I'll apply your changes only in split form. And I won't apply any unnecessary changes unless everything got sorted out appropriately right now, as they'd rather bring mess on applying incremental changes. So, I'll skip your properties changes and 2) I'll leave Thread.Sleep() until I test ASP.NET integration after applying your changes. - properties_*.patch I'll revisit the multithreading half after other part of patch review. Please be patient ;) Atsushi Eno On 2010/03/23 22:33, Matt Dargavel wrote: Ok, no problem. I can break them down more. You're right, I can provide no guarantees about the Thread.Sleep removal! But it could have been related to locking registered_channels instead of pending? I did quite a bit of multithreaded testing, and there were no problems; but I take your point. I implemented new functions rather than overriding Properties for a few reasons. I wanted to be sure that I found everywhere that used the properties mechanism to check there were no unwanted side effects, and to make it more obvious something a little special was going on. Also I thought that using a function hides the implementation from other classes. For example, the .NET documentation states that ChannelListenerBase should search for the property and then delegate down the stack if it can't find it, so I could see a scenario where only certain properties were passed to / from inner channels. But I guess that's refactoring and personal preference rather than a minimum change fix. :-) I can delve in to the test code and come up with some test cases for the properties fix, but unfortunately I think it'll be impossible to write test cases for the multithreading issues. Cheers, Matt. -Original Message- From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com] Sent: 23 March 2010 12:50 PM To: Matt Dargavel Cc: mono-devel-list@lists.ximian.com Subject: Re: [PATCH] WCF multithreaded and property handling Hello, Thanks for the patch. They are looking like a great set of attempts for cool bugfixes :) However there is a lot of other changes that your description cannot explain. So, please first split the changes into further smaller patches for each purpose, and give explanation for each change. For example, - // FIXME: this should not be required, but it somehow saves some failures wrt concurrent calls. - Thread.Sleep (100); This kind of change should not be made without explanation. (you aren't really sure about why it exists, right?) As for ChannelListenerBase.Properties, I'd rather make the changes much smaller like the attached change. Isn't it enough? There's no test case that I can verify your (and-my) changes. Atsushi Eno On 2010/03/23 20:28, Matt Dargavel wrote: The included patches fix the following: multithreaded_fixes.patch: ObjectDisposedException, InvalidOperationException(Another async TryReceiveRequest operation is in progress) and other multithreaded timing fixes. Also includes change to make GET ?wsdl case insensitive. properties_handling.patch: MetadataPublishingInfo not available in TransactionChannelListener's inner_listener. I created a new RetrieveProperty function as overriding GetPropertyT didn't work- the ChannelListenerBase implementation was still called. Perhaps there's a bug with generic function overrides or maybe I've done something silly there? properties_and_wsdl.patch: patch for ServiceMetadataExtension.cs that goes with the properties changes and the ?wsdl change. Let me know if you have any questions. :-) Matt. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] WCF multiple service contracts on one end point
I have applied the patch almost as is (with some coding style changes), with few exceptions: - AddBaseAddress (new Uri (baseAddress.BaseAddress)); + base_addresses.Add (new Uri (baseAddress.BaseAddress)); no need for this change. Thanks a lot! Atsushi Eno On 2010/03/23 20:28, Matt Dargavel wrote: Patch to allow multiple service contracts on one end point. I’ve included an example source code file to show what I mean. Patch also includes a one line change (101-102 in patch) to ApplyConfiguration() to add base addresses to the list directly. I noticed that calling AddBaseAddress from here could cause problems when using setting up the service using configuration files. Regards, Matt ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] WCF multithreaded and property handling
After examining the patch, I have applied some parts of your patch. -wait = new AutoResetEvent (false); -source.ListenerManager.GetHttpContextAsync (timeout, HttpContextAcquired); -if (wait != null) // in case callback is done before WaitOne() here. -return wait.WaitOne (timeout, false); -return waiting.Count 0; +var wait_ = new AutoResetEvent (false); +wait = wait_;// wait can be set to null if HttpContextAcquired runs to completion before we do WaitOne +source.ListenerManager.GetHttpContextAsync (timeout, HttpContextAcquired); +var result = wait_.WaitOne (timeout, false); +return result; This change is wrong. Since it is AutoResetEvent, it must not call WaitOne() if it has already finished (SignalAsyncWait). And It it set to null when SignalAsyncWait() is done. Also, it should not depend on specific GetHttpContextAsync() call result, as another async call may receive a context (hence waiting.Count 0). I think I have answered to all non-committed parts of your patch, but further comments are welcome. Thanks again for the patch. You're hero, few people dig in such depth into the WCF core engine :) Atsushi Eno On 2010/03/23 22:33, Matt Dargavel wrote: Ok, no problem. I can break them down more. You're right, I can provide no guarantees about the Thread.Sleep removal! But it could have been related to locking registered_channels instead of pending? I did quite a bit of multithreaded testing, and there were no problems; but I take your point. I implemented new functions rather than overriding Properties for a few reasons. I wanted to be sure that I found everywhere that used the properties mechanism to check there were no unwanted side effects, and to make it more obvious something a little special was going on. Also I thought that using a function hides the implementation from other classes. For example, the .NET documentation states that ChannelListenerBase should search for the property and then delegate down the stack if it can't find it, so I could see a scenario where only certain properties were passed to / from inner channels. But I guess that's refactoring and personal preference rather than a minimum change fix. :-) I can delve in to the test code and come up with some test cases for the properties fix, but unfortunately I think it'll be impossible to write test cases for the multithreading issues. Cheers, Matt. -Original Message- From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com] Sent: 23 March 2010 12:50 PM To: Matt Dargavel Cc: mono-devel-list@lists.ximian.com Subject: Re: [PATCH] WCF multithreaded and property handling Hello, Thanks for the patch. They are looking like a great set of attempts for cool bugfixes :) However there is a lot of other changes that your description cannot explain. So, please first split the changes into further smaller patches for each purpose, and give explanation for each change. For example, - // FIXME: this should not be required, but it somehow saves some failures wrt concurrent calls. - Thread.Sleep (100); This kind of change should not be made without explanation. (you aren't really sure about why it exists, right?) As for ChannelListenerBase.Properties, I'd rather make the changes much smaller like the attached change. Isn't it enough? There's no test case that I can verify your (and-my) changes. Atsushi Eno On 2010/03/23 20:28, Matt Dargavel wrote: The included patches fix the following: multithreaded_fixes.patch: ObjectDisposedException, InvalidOperationException(Another async TryReceiveRequest operation is in progress) and other multithreaded timing fixes. Also includes change to make GET ?wsdl case insensitive. properties_handling.patch: MetadataPublishingInfo not available in TransactionChannelListener's inner_listener. I created a new RetrieveProperty function as overriding GetPropertyT didn't work- the ChannelListenerBase implementation was still called. Perhaps there's a bug with generic function overrides or maybe I've done something silly there? properties_and_wsdl.patch: patch for ServiceMetadataExtension.cs that goes with the properties changes and the ?wsdl change. Let me know if you have any questions. :-) Matt. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] WCF more detail on Destination Unreachable
Thanks for the test, it cleared some things up :) So - first, I cannot apply your HttpRequestChannel change. The code you removed was introduced to fix real problem regarding HTTP 4xx; when HTTP 4xx is returned, the response stream is inaccessible and the channel should not try to read it. Instead, the server code seems to have an issue that it should just return 500. While it is set to 400 at HttpRequestContext with explicit comment that it is what .NET does, I was likely wrong by seeing response from WebHttpBinding, which likely has special error handling. In general our fault handling is not well done yet and I'm seeing a couple of issues to get correct fix there. Better fault handling is one of the tasks on my stack, but it may be time to give priority than ongoing bugfix as it's blocking your patch that will help my ongoing work... Atsushi Eno On 2010/03/24 19:41, Matt Dargavel wrote: Apologies for the wait- it's the time difference! :-) I've come up with a test for the DestinationUnreachable patch. When I was doing my testing I was using a combination of a .NET client and manually firing in requests using PuTTY and examining the reply. When I use a WCF Client in Mono the exception detail is currently lost in HttpRequestChannel, with a WebException being returned instead. The patch I've attached changes HttpRequestChannel so that 400+ errors are returned normally. This results in a FaultException being returned instead. The FaultException includes the extra details my previous patch added. Do you think this is acceptable and covers what you need? Hopefully you'll be able to add it to the NUnit tests fairly easily. Thanks, Matt. -Original Message- From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com] Sent: 24 March 2010 6:18 AM To: Matt Dargavel Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] [PATCH] WCF more detail on Destination Unreachable Instead of waiting for your reply, I've rather committed the patch (with a few change) and verify it later with a runnable repro. - DestinationUnreachableInfo.patch is done Atsushi Eno On 2010/03/24 14:35, Atsushi Eno wrote: I still couldn't reproduce the detailed error message. Let's please post a runnable repro case instead of code-less explanation ;) Atsushi Eno On 2010/03/23 22:38, Matt Dargavel wrote: You can reproduce it by requesting an operation that doesn't exist. (It was happening before I implemented the two Service Contracts on one end point change as the wrong channel dispatcher was getting the request.) So I should be able to write a test case for that... -Original Message- From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com] Sent: 23 March 2010 12:57 PM To: Matt Dargavel Cc: mono-devel-list@lists.ximian.com Subject: Re: [PATCH] WCF more detail on Destination Unreachable It's looking fine, but how did you check your change? (I know it could happen not always reproducible, so that's okay if it's not really always reproducible.) BTW I thank a lot for your properties change, that fixed a bug that annoyed me today ;-) Atsushi Eno On 2010/03/23 20:28, Matt Dargavel wrote: A patch to return more detail when an endpoint / operation isn't found. Not sure if you'll want to apply this, but it helped in some service debugging I was doing. Matt. ___ 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] [PATCH] WCF more detail on Destination Unreachable
Hi again, After a couple of fixes, this exception handling should be working in trunk now. Atsushi Eno On 2010/03/25 19:24, Matt Dargavel wrote: Thanks for the explanation, I had a feeling it wouldn't be as simple as I was hoping it was. :-) -Original Message- From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com] Sent: 25 March 2010 4:12 AM To: Matt Dargavel Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] [PATCH] WCF more detail on Destination Unreachable Thanks for the test, it cleared some things up :) So - first, I cannot apply your HttpRequestChannel change. The code you removed was introduced to fix real problem regarding HTTP 4xx; when HTTP 4xx is returned, the response stream is inaccessible and the channel should not try to read it. Instead, the server code seems to have an issue that it should just return 500. While it is set to 400 at HttpRequestContext with explicit comment that it is what .NET does, I was likely wrong by seeing response from WebHttpBinding, which likely has special error handling. In general our fault handling is not well done yet and I'm seeing a couple of issues to get correct fix there. Better fault handling is one of the tasks on my stack, but it may be time to give priority than ongoing bugfix as it's blocking your patch that will help my ongoing work... Atsushi Eno On 2010/03/24 19:41, Matt Dargavel wrote: Apologies for the wait- it's the time difference! :-) I've come up with a test for the DestinationUnreachable patch. When I was doing my testing I was using a combination of a .NET client and manually firing in requests using PuTTY and examining the reply. When I use a WCF Client in Mono the exception detail is currently lost in HttpRequestChannel, with a WebException being returned instead. The patch I've attached changes HttpRequestChannel so that 400+ errors are returned normally. This results in a FaultException being returned instead. The FaultException includes the extra details my previous patch added. Do you think this is acceptable and covers what you need? Hopefully you'll be able to add it to the NUnit tests fairly easily. Thanks, Matt. -Original Message- From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com] Sent: 24 March 2010 6:18 AM To: Matt Dargavel Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] [PATCH] WCF more detail on Destination Unreachable Instead of waiting for your reply, I've rather committed the patch (with a few change) and verify it later with a runnable repro. - DestinationUnreachableInfo.patch is done Atsushi Eno On 2010/03/24 14:35, Atsushi Eno wrote: I still couldn't reproduce the detailed error message. Let's please post a runnable repro case instead of code-less explanation ;) Atsushi Eno On 2010/03/23 22:38, Matt Dargavel wrote: You can reproduce it by requesting an operation that doesn't exist. (It was happening before I implemented the two Service Contracts on one end point change as the wrong channel dispatcher was getting the request.) So I should be able to write a test case for that... -Original Message- From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com] Sent: 23 March 2010 12:57 PM To: Matt Dargavel Cc: mono-devel-list@lists.ximian.com Subject: Re: [PATCH] WCF more detail on Destination Unreachable It's looking fine, but how did you check your change? (I know it could happen not always reproducible, so that's okay if it's not really always reproducible.) BTW I thank a lot for your properties change, that fixed a bug that annoyed me today ;-) Atsushi Eno On 2010/03/23 20:28, Matt Dargavel wrote: A patch to return more detail when an endpoint / operation isn't found. Not sure if you'll want to apply this, but it helped in some service debugging I was doing. Matt. ___ 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, Revision 2
Hey Jonathan, Thanks for heads up. On 2010/04/02 2:26, Jonathan Pobst wrote: -- test-System_ServiceModel -- 6 sporadic timeouts started in r154243 (Gonzalo) http://build.mono-project.com/GetFile.aspx?id=2257888 Gonzalo, tell me if you got some fixes. I'll stick to r154237 so far (after updating my repo it was blocking nunit test run there, so I have reverted to older version). -- test-System_ServiceModel_Web -- 1 timeout started in r154243 (Gonzalo) 1 json failure since test suite added: r154188 (Atsushi) http://build.mono-project.com/GetFile.aspx?id=2257906 I'll have a look at JSON issue. Atsushi Eno ___ 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, Revision 2
Thanks! It's looking good and working fine, so please go ahead and commit the change. Atsushi Eno On 2010/04/06 6:35, Gonzalo Paniagua Javier wrote: On Mon, 2010-04-05 at 14:28 +0900, Atsushi Eno wrote: -- test-System_ServiceModel -- 6 sporadic timeouts started in r154243 (Gonzalo) http://build.mono-project.com/GetFile.aspx?id=2257888 Gonzalo, tell me if you got some fixes. I'll stick to r154237 so far (after updating my repo it was blocking nunit test run there, so I have reverted to older version). These is fixed now. I'm attaching a patch for HttpRequestChannel.cs that avoids creating the ManualResetEvent when nobody needs it. Ok to commit? -Gonzalo ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Removing Mono.GetOptions dependency from svcutil
Hello, Thanks for the migration work. I'm not sure why it does not work at your side, but I could verify it's working by running below as an example: svcutil -moonlight http://memorabilia.hardrock.com/MemoService.svc Atsushi Eno On 2010/03/05 4:50, Jonathan Pryor wrote: As per the Removing Obsolete Code from Mono 2.8 thread, I've removed Mono.GetOptions.dll use from mcs/tools/svcutil, migrating it to use Mono.Options instead. These are in r153039. However, I'm unable to fully test these changes, as providing .wsdl or assemblies on the command line result in no files being generated (even without my changes). Consequently, I'm unable to do any sanity checking to ensure that it actually works. Could you please test svcutil to make sure I didn't break anything? Thanks, - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Windows Identity Foundation
No concrete plan now. At least we need the security basis on which WIF depends (and we don't have it). The base security stack in WCF is one of the next target once I got existing wcf stack stable to some extent. But security stack will need at least a lot of months to become usable. Atsushi Eno On 2010/03/12 1:40, Travis Spencer wrote: Hi All, Are there plans to port Windows Identity Foundation (WIF) to Mono? I've been using WIF 9 - 5 Monday - Friday for a year and half now. If you need help porting this new lib to your platform, please let me know how I can help. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] WCF multithreaded and property handling
Hi, sorry for the late reply, I'm back here again. Thanks, I'm going to apply your patch with a little change. This method should not return true if the channel has received null HTTP context, while WaitOne() just returns true unless it goes timeout. As for properties patch, I already made a relevant fix (I think I mentioned it in my previous posts) which fixed the issue you fixed in your own patch, and I didn't find it worthy enough to make an extra change. Atsushi Eno On 2010/04/08 18:35, Matt Dargavel wrote: Hi again, I'm just going through my outstanding local changes against the latest CVS. Did you have chance to revisit the AutoResetEvent issue as mentioned below? I've attached a new patch against the latest revision to show the changes. Also, I don't think the properties patch (my version or your version) got applied in the end? I saw it got rolled back due to a regression. If you could point me in the right direction I'd be happy to look in to this in a bit more. Regards, Matt. -Original Message- From: Matt Dargavel Sent: 24 March 2010 12:29 PM To: 'Atsushi Eno' Cc: mono-devel-list@lists.ximian.com Subject: RE: [PATCH] WCF multithreaded and property handling The problem I was trying to fix was that it's possible for wait to be set to null after: if (wait != null) and before: wait.WaitOne(...) causing a null reference exception. Looking at MSDN it sounds like an AutoResetEvent should remain signalled until a thread calls WaitOne? The problem is if another thread sets the event when it is already set. If this happens the second Set has no effect. I don't think that's an issue here as the only place that sets the event is the result of the operation we're starting? You're right that the waiting.Count 0 check should have stayed in there. My thanks to you for all the work you've put in to WCF- in case you're interested in how it's being used we're embedding a WCF web service in to one of our core products (a SIP Switch) and then providing a set of web pages that allow users to manage it. Matt. -Original Message- From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com] Sent: 24 March 2010 10:58 AM To: Matt Dargavel Cc: mono-devel-list@lists.ximian.com Subject: Re: [PATCH] WCF multithreaded and property handling After examining the patch, I have applied some parts of your patch. -wait = new AutoResetEvent (false); -source.ListenerManager.GetHttpContextAsync (timeout, HttpContextAcquired); -if (wait != null) // in case callback is done before WaitOne() here. -return wait.WaitOne (timeout, false); -return waiting.Count 0; +var wait_ = new AutoResetEvent (false); +wait = wait_;// wait can be set to null if HttpContextAcquired runs to completion before we do WaitOne +source.ListenerManager.GetHttpContextAsync (timeout, HttpContextAcquired); +var result = wait_.WaitOne (timeout, false); +return result; This change is wrong. Since it is AutoResetEvent, it must not call WaitOne() if it has already finished (SignalAsyncWait). And It it set to null when SignalAsyncWait() is done. Also, it should not depend on specific GetHttpContextAsync() call result, as another async call may receive a context (hence waiting.Count 0). I think I have answered to all non-committed parts of your patch, but further comments are welcome. Thanks again for the patch. You're hero, few people dig in such depth into the WCF core engine :) Atsushi Eno On 2010/03/23 22:33, Matt Dargavel wrote: Ok, no problem. I can break them down more. You're right, I can provide no guarantees about the Thread.Sleep removal! But it could have been related to locking registered_channels instead of pending? I did quite a bit of multithreaded testing, and there were no problems; but I take your point. I implemented new functions rather than overriding Properties for a few reasons. I wanted to be sure that I found everywhere that used the properties mechanism to check there were no unwanted side effects, and to make it more obvious something a little special was going on. Also I thought that using a function hides the implementation from other classes. For example, the .NET documentation states that ChannelListenerBase should search for the property and then delegate down the stack if it can't find it, so I could see a scenario where only certain properties were passed to / from inner channels. But I guess that's refactoring and personal preference rather than a minimum change fix. :-) I can delve in to the test code and come up with some test cases for the properties fix, but unfortunately I think it'll be impossible to write test cases
Re: [Mono-dev] 480152 - string.Normalize() frequently produces incorrect output
Hello, I have never had time enough to read this set of big changes, but my gut feeling is the new rewrite would be okay (on e.g. performance). Feel free to commit the changes, or I'll make changes leter in case you don't have write access. It has been five years since I volunteered to write it and I did only few bugfixes, so I'm not likely to pay attention to this stuff. Atsushi Eno On 2010/04/21 5:47, Damien Diederen wrote: Hello everybody, I just attached a (second) series of patches addressing a mix of Unicode normalization problems to the following bug: https://bugzilla.novell.com/show_bug.cgi?id=480152#c32 As noted in the “cover letter”: This, a couple other fixes, and the addition of the Hangul composition algorithm (complementing Gabriel's work on decomposition) causes the number of failures in the BMP subset of the Unicode canonicalization test suite to drop from 4k+ to 888. (Another, still experimental, and more controversial series of mine brings that number down to zero, but it still needs a bit of work before I post it as an RFC.) As I'm not sure anybody following that bug has any “free cycles,” I'm posting the link here for other committers to see. I would really appreciate if somebody could have a look at the patches and comment on what has to be done/changed/improved to get them in Mono. Thanks, Damien ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Deprecating OSX 10.4 in our binary packages
It is also great to see the chance that Gtk on OSX could be upgraded to 10.5+ so that we Japanese don't have to suffer from cairo-atsui that fails to display Japanese characters by default :) (Yes, it's not about gtk# but gtk+, still nice to see better chance.) Atsushi Eno On 2010/04/29 5:44, Geoff Norton wrote: Hello all, Going forward we will be setting our minimum build version of OSX to 10.5. This will make providing updated gtk+/gtk# stacks significantly easier. Please let me know if there are any concerns or questions. Thanks Geoff ___ 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] Self Hosted web service unstable – we see a new active port connection for each call
Hello,
I will first stabilize existing stuff as well as fill missing
functionalities, and there is a lot to do. There isn't any kind of
optimization. I'd rather welcome your contributions and won't work on it
so far.
Atsushi Eno
On 2010/05/08 0:14, Vilius Adamkavicius wrote:
We have implemented a simple self hosted web service in .NET using
ServiceHost. The Client is a simple Silverlight app that polls for
updated info every 5 seconds. The return messages tend to be no more
that 1-10K.
We ported the web service (self-hosted) to MONO 2.6. This seemed to go
perfectly and it stood up to stress testing in devel...then we
deployed it. Now we find that the service is unstable and can just
hangs after anywhere between 2 minutes and 2 days.
IP traces show that when it hangs the XML Post gets (request) gets
received by the webservice but nothing is ever transmitted back. Also
when it hangs netstat shows a persistent active connection on the port
to which it is allocated.
In an attempt to diagnose this we looked at the port behaviour using
netstat. We looked at this while the MONO implementation of the
webservice was running without problem; we compare this to the active
port connection behaviour of the windows/.NET implementation- what
found was worrying.
When we run a single client and connect the windows/.NET version of
the webservice we see *one port connection that persists*.
When we run a single client and connect the MONO version of the
webservice we see it holds around *12-16 active port connections at
any one time*...and these seem to be continuously dying and regenerating.
We postulated that each call to the webservice was making a new
connection (unlike Windows); each connection would be used once and
then timeout. Given the rate that the client polls we estimated that
the timeout must be around a minute...then we found this in the MONO
DefaultCommunicationTimeouts.cs
Vilius: private DefaultCommunicationTimeouts ()
{
close = open = send = TimeSpan.FromMinutes (1);
receive = TimeSpan.FromMinutes (10);
}
This strongly supports our theory...
The question is why does it keep creating a new connection for each
call? Can the MONO 2.6 implementation of ServiceHost maintain a single
connection for an application session (like Windows .NET) ? What is
the ramification of this?
___
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] Self Hosted web service unstable – we see a new active port connection for each call
Hi Vilius,
There isn't. As I wrote, there's a lot to do before that.
Atsushi Eno
On 2010/05/10 18:00, Vilius Adamkavicius wrote:
Hi Atsushi,
Thanks for your reply.
Let me just ask if there is a schedule for further development on this
section?
Regards,
Vilius.
On 10 May 2010 05:58, Atsushi Eno
atsushi...@veritas-vos-liberabit.com
mailto:atsushi...@veritas-vos-liberabit.com wrote:
Hello,
I will first stabilize existing stuff as well as fill missing
functionalities, and there is a lot to do. There isn't any kind of
optimization. I'd rather welcome your contributions and won't work
on it so far.
Atsushi Eno
On 2010/05/08 0:14, Vilius Adamkavicius wrote:
We have implemented a simple self hosted web service in .NET
using ServiceHost. The Client is a simple Silverlight app that
polls for updated info every 5 seconds. The return messages
tend to be no more that 1-10K.
We ported the web service (self-hosted) to MONO 2.6. This
seemed to go perfectly and it stood up to stress testing in
devel...then we deployed it. Now we find that the service is
unstable and can just hangs after anywhere between 2 minutes
and 2 days.
IP traces show that when it hangs the XML Post gets (request)
gets received by the webservice but nothing is ever
transmitted back. Also when it hangs netstat shows a
persistent active connection on the port to which it is allocated.
In an attempt to diagnose this we looked at the port behaviour
using netstat. We looked at this while the MONO implementation
of the webservice was running without problem; we compare this
to the active port connection behaviour of the windows/.NET
implementation- what found was worrying.
When we run a single client and connect the windows/.NET
version of the webservice we see *one port connection that
persists*.
When we run a single client and connect the MONO version of
the webservice we see it holds around *12-16 active port
connections at any one time*...and these seem to be
continuously dying and regenerating.
We postulated that each call to the webservice was making a
new connection (unlike Windows); each connection would be used
once and then timeout. Given the rate that the client polls we
estimated that the timeout must be around a minute...then we
found this in the MONO DefaultCommunicationTimeouts.cs
Vilius: private DefaultCommunicationTimeouts ()
{
close = open = send = TimeSpan.FromMinutes (1);
receive = TimeSpan.FromMinutes (10);
}
This strongly supports our theory...
The question is why does it keep creating a new connection for
each call? Can the MONO 2.6 implementation of ServiceHost
maintain a single connection for an application session (like
Windows .NET) ? What is the ramification of this?
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
mailto:Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
--
Regards,
Vilius.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCH] - optimization for System.Xml.XmlNode::SelectSingleNode
Hi, Thanks Tom, it looks like a good catch. The interface is internal, and cast exceptions should not happen there anyways. Once the build got fixed, I'll verify the patch and apply it unless it regresses. Atsushi Eno On 2010/05/11 2:09, tom hindle wrote: Hi, While performance profiling our code, with mono's nice profiling tools :), I noticed System.Xml.XmlNode::SelectSingleNode was taking 23ms a call while the sum of the methods it was calling took 5ms. SelectSingleNode is a very simple method however it contains a (dynamic) down cast. I replaced the (Cstyle/prefix) cast with a 'as' cast and this seem to reduce the method time by about 7ms. // With 'Cstyle' cast 39672.3031717 23.106 System.Xml.XmlNode::SelectSingleNode(string,XmlNamespaceManager) Callers (with count) that contribute at least for 1%: 1717 100 % System.Xml.XmlNode::SelectSingleNode(string) // With 'as' cast 29238.1171880 15.552 System.Xml.XmlNode::SelectSingleNode(string,XmlNamespaceManager) Callers (with count) that contribute at least for 1%: 1880 100 % System.Xml.XmlNode::SelectSingleNode(string) I read that this is because 'as' cast generates IL instr 'isinst' while 'cstyle' cast generates 'castclass'. The msdn documentation about XmlNode.SelectSingleNode doesn't state that an InvalidCastException, can/could be thrown. Is this a sensible thing to do? If so could someone review/commit my patch as I believe it will make a fairly major difference for applications that make much use of SelectSingleNode. Thanks Tom ___ 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] [PATCH] - optimization for System.Xml.XmlNode::SelectSingleNode
Well, it wasn't really internal, but that does not affect my statement. Atsushi Eno On 2010/05/11 2:55, Atsushi Eno wrote: Hi, Thanks Tom, it looks like a good catch. The interface is internal, and cast exceptions should not happen there anyways. Once the build got fixed, I'll verify the patch and apply it unless it regresses. Atsushi Eno On 2010/05/11 2:09, tom hindle wrote: Hi, While performance profiling our code, with mono's nice profiling tools :), I noticed System.Xml.XmlNode::SelectSingleNode was taking 23ms a call while the sum of the methods it was calling took 5ms. SelectSingleNode is a very simple method however it contains a (dynamic) down cast. I replaced the (Cstyle/prefix) cast with a 'as' cast and this seem to reduce the method time by about 7ms. // With 'Cstyle' cast 39672.3031717 23.106 System.Xml.XmlNode::SelectSingleNode(string,XmlNamespaceManager) Callers (with count) that contribute at least for 1%: 1717 100 % System.Xml.XmlNode::SelectSingleNode(string) // With 'as' cast 29238.1171880 15.552 System.Xml.XmlNode::SelectSingleNode(string,XmlNamespaceManager) Callers (with count) that contribute at least for 1%: 1880 100 % System.Xml.XmlNode::SelectSingleNode(string) I read that this is because 'as' cast generates IL instr 'isinst' while 'cstyle' cast generates 'castclass'. The msdn documentation about XmlNode.SelectSingleNode doesn't state that an InvalidCastException, can/could be thrown. Is this a sensible thing to do? If so could someone review/commit my patch as I believe it will make a fairly major difference for applications that make much use of SelectSingleNode. Thanks Tom ___ 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] [PATCH] - optimization for System.Xml.XmlNode::SelectSingleNode
As I have commented earlier, there is no chance that InvalidCastException could occur, so it is an extraneous suggestion to not use isinst here. Atsushi Eno On 2010/05/11 8:54, Andrés G. Aragoneses wrote: El 10/05/10 21:06, tom hindle escribió: On Mon, 2010-05-10 at 19:28 +0100, Alan McGovern wrote: Why would a c-cast be so much slower than an 'as' cast? Surely they should be equivalent or the c-cast should be faster. sorry bad terminology... I meant syntactically c-style cast not an actual c-cast. I wasn't sure the C# name for it, maybe it called a prefix cast? I think the correct terminology is static cast vs dynamic cast because this is the way it's called in C++ (some time ago I liked to called the latter safe cast). That being said, I second Alan statement (or, question, to be more correct). And I think a dynamic cast shouldn't be used ever if you're not checking for null later (otherwise you're replacing the InvalidCastException chance with a NullReferenceException chance, which is much worse, uglier, and more incorrect). Regards, Andrés ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [PATCHES] Bug 480178 - System.Globalization.CharUnicodeInfo.GetUnicodeCategory() does not handle surrogate characters appropriately.
Also, this patch (for string normalization) has nothing to do with string collation, which is very windows-specific and has nothing to do with unicode standards. .NET's string collation has (hence) nothing to do with Char.GetUnicodeCategory() either. It is getting obsoleted and turned off by default in .NET 4 anyways. Atsushi Eno On 2010/05/18 4:49, Miguel de Icaza wrote: To me this seems like it is time for a change in policy: our string collation should reflect what the rules are in Unicode as it will be easier for us to maintain. In that case, we might as well use ICU. I do not want to go back to the business of maintaining dependencies and carrying a new dependency in Mono for this. It was painful enough the first time, and I do not want go back to it. I want to keep Mono with as few dependencies as possible, specially now that we are being used more often in embedded setups. ___ 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] Patch for DuplexClientBase
Thanks, applied.
Atsushi Eno
On 2010/05/19 16:44, Pieter van der Berg wrote:
Hello,
Here is a patch to get rid of the two notimplemented exceptions.
public IDuplexContextChannel InnerDuplexChannel {
get { return (IDuplexContextChannel)base.InnerChannel; }
}
protected override TChannel CreateChannel ()
{
return ChannelFactory.CreateChannel();
}
Best regards,
Pieter van der Berg
ZiuZ – visual intelligence
*Pieter van der Berg*
mob. +31 6-13 60 60 18, fax +31 516 42 10 47
e-mail p.vanderb...@ziuz.com mailto:p.vanderb...@ziuz.com, internet
www.ziuz.com http://www.ziuz.com
___
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] System.NotImplementedException: The requested feature is not implemented. at System.ServiceModel.Configuration.WSHttpBindingElement.OnApplyConfiguration
WSHttpBinding is not usable at all. It involves the huge WS-* stack like WS-Security which is far from done. Atsushi Eno On 2010/05/24 21:42, Greg Robinson wrote: I have been making good progress on moving our .NET server application over to Mono 2.2 running on Ubuntu 2.2. Friday, I ported the WCF pieces over where all the server application does is make calls to a WCF service running on a windows server outside of our office. I am getting the following, which suggests to me these pieces of client side WCF are not implemented in Mono 2.2: System.NotImplementedException: The requested feature is not implemented. at System.ServiceModel.Configuration.WSHttpBindingElement.OnApplyConfiguration (System.ServiceModel.Channels.Binding binding) [0x0] at System.ServiceModel.Configuration.StandardBindingElement.ApplyConfiguration (System.ServiceModel.Channels.Binding binding) [0x0] at System.ServiceModel.Configuration.ConfigUtil.CreateBinding (System.String binding, System.String bindingConfiguration) [0x0] at System.ServiceModel.ChannelFactory.ApplyConfiguration (System.String endpointConfig) [0x0] at System.ServiceModel.ChannelFactory.InitializeEndpoint (System.String endpointConfigurationName, System.ServiceModel.EndpointAddress remoteAddress) [0x0] at System.ServiceModel.ChannelFactory`1[OurCompanyName.Common.WebServiceReference.OurCompanyNameWCFServiceProxy.IOurCompanyNameService]..ctor (System.String endpointConfigurationName, System.ServiceModel.EndpointAddress remoteAddress) [0x0] at System.ServiceModel.ClientBase`1[TChannel].Initialize (System.ServiceModel.InstanceContext instance, System.String configName, System.ServiceModel.EndpointAddress remoteAddress) [0x0] at System.ServiceModel.ClientBase`1[TChannel]..ctor (System.ServiceModel.InstanceContext instance, System.String configname) [0x0] at System.ServiceModel.ClientBase`1[TChannel]..ctor (System.ServiceModel.InstanceContext instance) [0x0] at System.ServiceModel.ClientBase`1[TChannel]..ctor () [0x0] at OurCompanyName.Common.WebServiceReference.OurCompanyNameWCFServiceProxy.OurCompanyNameServiceClient..ctor () [0x0] at OurCompanyName.Common.WebServiceReference.OurCompanyNameServiceProxyAgent.CreateServiceProxy (Boolean useLimited) [0x0] at OurCompanyName.Common.WebServiceReference.OurCompanyNameServiceProxyAgent.CreateServiceProxy () [0x0] at OurCompanyName.Common.WebServiceReference.OurCompanyNameServiceProxyAgent.GetConfiguration (System.String loggerSAN) [0x0] at OurCompanyName.Common.WebServiceReference.OurCompanyNameServiceProxyAgent.GetConfiguration () [0x0] at OurCompanyNameWCFClientTest.Program.Main (System.String[] args) [0x0] Any idea if\when this will be implemented? is there a workaround? Thanks -- Greg My Blog: http://dotnetrocks.blogspot.com/ My Techy Blog: http://weblogs.asp.net/grobinson/ Amy's Blog: http://amyshome.blogspot.com/ LinkedIn: http://www.linkedin.com/in/gregarobinson ___ 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] Altering our build system.
Since - 1 won't be determined without the actually altered build system, - 2 is just impossible (no make install alternative and we need it), and - 3 in VS requires non-express versions as long as it depends on NUnit addin (and of course we can't migrate our tons of existing NUnit tests to something else) this migrate to VS should be taken out of this core build change discussion IMO. Atsushi Eno On 2010/05/21 3:37, Jonathan Chambers wrote: I've been looking at a MSBuild based build for the class libs (based upon Jonathan Pobst's MonkeyBuilder). To actually make the projects usable in visual studio, they need to be one of a list of well known project types. While MSBuild can handle an arbitrary .proj file with arbitrary MSBuild tasks, to build inside VS you would need to use a .csproj. Currently, I have a build basically working using a .proj file with custom MSBuild tasks that mirror what MonkeyBuilder does (which mirrors the auto* based build). csproj files could be used, but it raises a few questions: 1. Can we build using either .Net compilers or mono compilers? 2. Is there the concept of make and make install (building class libs versus installing them in some location)? 3. Running unit tests There are more issues, but this is already a bit unrelated to Miguel's original post. The Windows build has recently gone downhill, so hopefully any changes we make might make life better (and hopefully no worse). Thanks, Jonathan On Thu, May 20, 2010 at 2:10 PM, Jonathan Pryor jonpr...@vt.edu mailto:jonpr...@vt.edu wrote: On Thu, 2010-05-20 at 12:52 -0400, Miguel de Icaza wrote: I would like to move to a setup where by default we assume we have a working mcs/runtime and we build the configured profiles (defaulting to 2.0 and 4.0). ... A final wish-list item would be to split up the *core* libraries from most of the extra libraries. The moonlight team is using a special process already to limit the number of assemblies built. This would dovetail nicely with the idea of splitting up mcs into smaller modules as part of the git migration; see: http://www.mono-project.com/GitMigration I would also suggest using xbuild to build the non-core libraries. This will make it easier for people who aren't using Unix to build the libraries, as Visual Studio could then (hopefully) be used for building, thus avoiding the pain that is Cygwin for everything except the runtime and core libraries. - Jon ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com mailto: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] System.NotImplementedException: The requested feature is not implemented. at System.ServiceModel.Configuration.WSHttpBindingElement.OnApplyConfiguration
In general, when you see NotImplementedException, it is not implemented yet i.e. you cannot use it in mono. It here means ClientCredentialsElement and clientCredentials configuration element. Atsushi Eno On 2010/05/25 22:27, Greg Robinson wrote: I changed the config file settings to basicHttpBinding, removed all of the related WSHttpBinding values and ran under Mono 2.6+. Now I receive this exception System.NotImplementedException: The requested feature is not implemented. at System.ServiceModel.Configuration.ClientCredentialsElement.CreateBehavior () [0x0] in filename unknown:0 On Mon, May 24, 2010 at 2:25 PM, Atsushi Eno atsushi...@veritas-vos-liberabit.com mailto:atsushi...@veritas-vos-liberabit.com wrote: It should in general work (we use its client side in moonlight too), depends on which parts of the features you use. Atsushi Eno On 2010/05/24 23:09, Greg Robinson wrote: What about BasicHttpBinding? On Mon, May 24, 2010 at 10:00 AM, Atsushi Eno atsushi...@veritas-vos-liberabit.com mailto:atsushi...@veritas-vos-liberabit.com mailto:atsushi...@veritas-vos-liberabit.com mailto:atsushi...@veritas-vos-liberabit.com wrote: WSHttpBinding is not usable at all. It involves the huge WS-* stack like WS-Security which is far from done. Atsushi Eno On 2010/05/24 21:42, Greg Robinson wrote: I have been making good progress on moving our .NET server application over to Mono 2.2 running on Ubuntu 2.2. Friday, I ported the WCF pieces over where all the server application does is make calls to a WCF service running on a windows server outside of our office. I am getting the following, which suggests to me these pieces of client side WCF are not implemented in Mono 2.2: System.NotImplementedException: The requested feature is not implemented. at System.ServiceModel.Configuration.WSHttpBindingElement.OnApplyConfiguration (System.ServiceModel.Channels.Binding binding) [0x0] at System.ServiceModel.Configuration.StandardBindingElement.ApplyConfiguration (System.ServiceModel.Channels.Binding binding) [0x0] at System.ServiceModel.Configuration.ConfigUtil.CreateBinding (System.String binding, System.String bindingConfiguration) [0x0] at System.ServiceModel.ChannelFactory.ApplyConfiguration (System.String endpointConfig) [0x0] at System.ServiceModel.ChannelFactory.InitializeEndpoint (System.String endpointConfigurationName, System.ServiceModel.EndpointAddress remoteAddress) [0x0] at System.ServiceModel.ChannelFactory`1[OurCompanyName.Common.WebServiceReference.OurCompanyNameWCFServiceProxy.IOurCompanyNameService]..ctor (System.String endpointConfigurationName, System.ServiceModel.EndpointAddress remoteAddress) [0x0] at System.ServiceModel.ClientBase`1[TChannel].Initialize (System.ServiceModel.InstanceContext instance, System.String configName, System.ServiceModel.EndpointAddress remoteAddress) [0x0] at System.ServiceModel.ClientBase`1[TChannel]..ctor (System.ServiceModel.InstanceContext instance, System.String configname) [0x0] at System.ServiceModel.ClientBase`1[TChannel]..ctor (System.ServiceModel.InstanceContext instance) [0x0] at System.ServiceModel.ClientBase`1[TChannel]..ctor () [0x0] at OurCompanyName.Common.WebServiceReference.OurCompanyNameWCFServiceProxy.OurCompanyNameServiceClient..ctor () [0x0] at OurCompanyName.Common.WebServiceReference.OurCompanyNameServiceProxyAgent.CreateServiceProxy (Boolean useLimited) [0x0] at OurCompanyName.Common.WebServiceReference.OurCompanyNameServiceProxyAgent.CreateServiceProxy () [0x0] at OurCompanyName.Common.WebServiceReference.OurCompanyNameServiceProxyAgent.GetConfiguration (System.String loggerSAN) [0x0] at OurCompanyName.Common.WebServiceReference.OurCompanyNameServiceProxyAgent.GetConfiguration () [0x0
Re: [Mono-dev] System.NotImplementedException: The requestedfeature is not implemented. atSystem.ServiceModel.Configuration.WSHttpBindingElement.OnApplyConfiguration
Hello, First of all, MoMA is not anything you can think this app SHOULD run on mono because MoMA reported nothing. It is rather to find out that MoMA reported some items that should be implemented, so this app won't run. It is because: - It only checks exposed API. Anything that depends on internals won't be reported. - It does not support configuration elements, and WCF has a lot of them. - There are many classes/members that itself is implemented but not supported in combined with others. Say, when we have FooServiceBehavior, BarBinding, and ServiceHost and the combination of all of them doesn't work, they could still be reported as implemented as long as they are implemented (and it's too silly to mark everything NotImplemented or MonoTODO). As for Credentials types, you should not basically expect them working except for some HTTP authentication stuff. For example IssuedToken will never work until we finish lots of WS-* stuff. It is easy to implement ClientCredentialsElement.CreateBehavior() right now, but it does not make a lot of sense so far. Atsushi Eno On 2010/05/26 4:40, Matt Dargavel wrote: Hi Greg, Have you tried running MoMA (http://www.mono-project.com/MoMa) against your application? This should give you an idea of how much is missing from Mono. With respect to WCF and the specific problem you saw, I’ve not used the security stuff at all but it looks like most of the ClientCredentials class is done so you might be able to configure the necessary ClientCredentials in code rather than using .config files. I don’t think the System.ServiceModel.Configuration namespace is as complete as some of the other bits. You can find information on the implementation status at the links below. http://go-mono.com/status/status.aspx?reference=3.5profile=2.0assembly=System.ServiceModel http://go-mono.com/status/status.aspx?reference=3.5profile=2.0assembly=System.ServiceModel http://www.mono-project.com/WCF Regards, Matt. *From:* mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] *On Behalf Of *Greg Robinson *Sent:* 25 May 2010 7:09 PM *To:* Stifu *Cc:* mono-devel-list@lists.ximian.com *Subject:* Re: [Mono-dev] System.NotImplementedException: The requestedfeature is not implemented. atSystem.ServiceModel.Configuration.WSHttpBindingElement.OnApplyConfiguration Understood, and that was my first thought. Was just wondering if there were alternative solutions. I am thinking of a Java/.NET split if you will where we keep what we can that WILL run under Mono and port the rest to Java. That assumes we can get the two to play nicely together. Is there a way to see if someone is already working on the bits in Mono we need? On Tue, May 25, 2010 at 2:05 PM, Stifu st...@free.fr mailto:st...@free.fr wrote: The obvious answer: contribute to Mono and help implement it. Or pay someone to do it. That's what some companies do. If you can afford it, that's an option (which might turn out to be cheaper than rewriting everything in Java; that said, I have no idea how much work is needed here). Greg Robinson wrote: I am new to Linux, new to Mono. I am really hoping we can use Mono for our .NET application to Linux port/migration. The other option on the table is to totally re-write in Java. So what do folks usually do at this point; the point where they find that something they need, our .NET Server application calling a WCF Service using System.ServiceModel bits, not implemented in Mono? It seems a shame to just give up and do a port to Java; is that my only solution though? On Tue, May 25, 2010 at 12:45 PM, Miguel de Icaza mig...@novell.com mailto:mig...@novell.com wrote: When I go to: http://mono-project.com/DistroPackages/Ubuntu it tells me Mono comes installed by default. We are running Ubuntu 10.04. What do I need to do to upgrade to Mono 2.6 on Ubuntu 10.04? I am told that there are no 2.6 packages available for Ubuntu by the Debian/Ubuntu community. The bad news is that you need to compile from source code; The good news is that this is a trivial process (as long as you use released tarballs): http://www.mono-project.com/Parallel_Mono_Environments Migue. On Mon, May 24, 2010 at 8:50 AM, Oskar Berggren oskar.bergg...@gmail.com mailto:oskar.bergg...@gmail.com wrote: 2.2 is fairly old. Have you checked with 2.4 or 2.6? Try searching for moma and mono class library status. /Oskar 2010/5/24 Greg Robinson gregarobin...@gmail.com mailto:gregarobin...@gmail.com: I have been making good progress on moving our .NET server application over to Mono 2.2 running on Ubuntu 2.2. Friday, I ported the WCF pieces over where all the server application does is make calls to a WCF service running on a windows server outside of our office
Re: [Mono-dev] System.NotImplementedException: The requestedfeature is not implemented. atSystem.ServiceModel.Configuration.WSHttpBindingElement.OnApplyConfiguration
I'm working on it, yes ;) On 2010/05/26 21:06, Greg Robinson wrote: Atsushi Eno, are you on thew Mono development team? Great feedback, just curious. On Wed, May 26, 2010 at 5:19 AM, Matt Dargavel m...@shout-telecoms.com mailto:m...@shout-telecoms.com wrote: When I was trying some WCF stuff out I found some scenarios where the app.config settings didn’t work, but using their code based counter-parts did. But Atsushi-san is the man in the know, so it looks like the Credentials types will only work for some basic http authentication. Matt. *From:* Greg Robinson [mailto:gregarobin...@gmail.com mailto:gregarobin...@gmail.com] *Sent:* 25 May 2010 9:10 PM *To:* Matt Dargavel *Cc:* mono-devel-list@lists.ximian.com mailto:mono-devel-list@lists.ximian.com *Subject:* Re: [Mono-dev] System.NotImplementedException: The requestedfeature is not implemented. atSystem.ServiceModel.Configuration.WSHttpBindingElement.OnApplyConfiguration Matt, it looks like most of the ClientCredentials class is done so you might be able to configure the necessary ClientCredentials in code rather than using .config files. So are you stating Mono is not app.config file friendly? So it's possible if we hard code these bits will run under Mono? On Tue, May 25, 2010 at 3:40 PM, Matt Dargavel m...@shout-telecoms.com mailto:m...@shout-telecoms.com wrote: Hi Greg, Have you tried running MoMA (http://www.mono-project.com/MoMa) against your application? This should give you an idea of how much is missing from Mono. With respect to WCF and the specific problem you saw, I’ve not used the security stuff at all but it looks like most of the ClientCredentials class is done so you might be able to configure the necessary ClientCredentials in code rather than using .config files. I don’t think the System.ServiceModel.Configuration namespace is as complete as some of the other bits. You can find information on the implementation status at the links below. http://go-mono.com/status/status.aspx?reference=3.5profile=2.0assembly=System.ServiceModel http://go-mono.com/status/status.aspx?reference=3.5profile=2.0assembly=System.ServiceModel http://www.mono-project.com/WCF Regards, Matt. *From:* mono-devel-list-boun...@lists.ximian.com mailto:mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com mailto:mono-devel-list-boun...@lists.ximian.com] *On Behalf Of *Greg Robinson *Sent:* 25 May 2010 7:09 PM *To:* Stifu *Cc:* mono-devel-list@lists.ximian.com mailto:mono-devel-list@lists.ximian.com *Subject:* Re: [Mono-dev] System.NotImplementedException: The requestedfeature is not implemented. atSystem.ServiceModel.Configuration.WSHttpBindingElement.OnApplyConfiguration Understood, and that was my first thought. Was just wondering if there were alternative solutions. I am thinking of a Java/.NET split if you will where we keep what we can that WILL run under Mono and port the rest to Java. That assumes we can get the two to play nicely together. Is there a way to see if someone is already working on the bits in Mono we need? On Tue, May 25, 2010 at 2:05 PM, Stifu st...@free.fr mailto:st...@free.fr wrote: The obvious answer: contribute to Mono and help implement it. Or pay someone to do it. That's what some companies do. If you can afford it, that's an option (which might turn out to be cheaper than rewriting everything in Java; that said, I have no idea how much work is needed here). Greg Robinson wrote: I am new to Linux, new to Mono. I am really hoping we can use Mono for our .NET application to Linux port/migration. The other option on the table is to totally re-write in Java. So what do folks usually do at this point; the point where they find that something they need, our .NET Server application calling a WCF Service using System.ServiceModel bits, not implemented in Mono? It seems a shame to just give up and do a port to Java; is that my only solution though? On Tue, May 25, 2010 at 12:45 PM, Miguel de Icaza mig...@novell.com mailto:mig...@novell.com wrote: When I go to: http://mono-project.com/DistroPackages/Ubuntu it tells me Mono comes installed by default. We are running Ubuntu 10.04. What do I need to do to upgrade to Mono 2.6 on Ubuntu 10.04? I am told that there are no 2.6 packages available for Ubuntu by the Debian/Ubuntu community
Re: [Mono-dev] [Mono-Dev]System.Xml.Schema.Extensions unit tests
Ohh, thanks, but since we use NUnit 2.4.8 your test code doesn't build. To confirm your test builds: - build mono and mcs from trunk. - go to mcs/class/System.Xml.Linq. - create Test/System.Xml.Schema directory and copy your test there. - in System.Xml.Linq_test.dll.sources file, add a line below: System.Xml.Schema/ExtensionsTest.cs - run this: make run-test Atsushi Eno On 2010/05/28 10:30, stefan prutianu wrote: Attached is ExtensionsTest.cs - source file containing NUnit Test Cases for Extensions.cs class under System.Xml.Schema namespace found in System.Xml.Linq assembly (System.Xml.Linq.dll). It has been tested (all tests being successful) on .Net framework 3.5 using NUnit 2.5.5 ___ 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] [PATCHES] Bug 480178 - System.Globalization.CharUnicodeInfo.GetUnicodeCategory() does not handle surrogate characters appropriately.
Hello, I keep silent as it's rather about runtime issue, but since there is no one giving further comments on the bug, I think no one can complain if it got checked in svn. Damien, thanks for the patch. Atsushi Eno On 2010/06/11 23:36, Damien Diederen wrote: Hello, Has anybody had a look at these patches? I'm (obviously) still open to comments, but I would be perfectly happy to learn that it is deemed acceptable—and that somebody with the commit bit will take care of integrating it :) (No hurry; this is just a “ping”). Cheers, Damien Damien Diederend...@crosstwine.com writes: Hi Miguel, I finally had an opportunity to look into this, and just uploaded v5 of this series: - The non-BMP portions of the tables are omitted when the preprocessor symbol DISABLE_ASTRAL is defined; - The runtime now supports two sets of tables, one for 2.0–3.5 and one for 4.0. This second set can be omitted by defining DISABLE_NET_4_0. Cf. https://bugzilla.novell.com/show_bug.cgi?id=480178#c42; following. Cheers, -D Miguel de Icazamig...@novell.com writes: That can certainly be done. I suppose you envision a compile-time switch? Is there already such an option/flag/preprocessor symbol I should use as a model? For C code, just use the symbol DISABLE_ASTRAL, then we can add that to configure.in Sure. I guess this means some more compile-time conditionalization of the runtime; corlib can just pass a version parameter at class init time as in v3 of my patches: #if NET_4_0 private const int CategoryDataVersion = 4; #else private const int CategoryDataVersion = 2; #endif Exactly right; Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Hosting simple WCF service in XSP
Hello, Unless you use trunk or daily snapshot version you won't get it working fine. (It might work for simple ones, but that's not the point.) (This list is for those who hack mono, use mono-list instead.) Atsushi Eno On 2010/06/28 23:31, Thiago Padilha wrote: Is it possible? Im a newbie to WCF so I followed the steps in http://www.netfxharmonics.com/2008/11/Understanding-WCF-Services-in-Silverlight to setup a simple service and it worked fine under asp.net development server(visual web developer 2010), but when I try with xsp2/mono 2.6 it fails. Thanks in advance. ___ 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 in SvcHttpHandler.cs ?
Hi,
Right, thanks for the analysis, that should be fixed, and I have an
idea. Though I am now rewriting ASP.NET channel support based on our new
HTTP (non-ASP.NET) channel stack and it does not use the code path you
mentioned, I'd rather finish the rewrite first and then fix the actual
issue.
The idea above is to use Uri comparison using UriComponents based on
HostNameComparisonMode value (which is ignored so far).
Atsushi Eno
On 2010/06/29 21:46, Thiago Padilha wrote:
Hi,
I'm hosting a WCF service using asp.net/mono from trunk (r159644)
but encountered a problem when accessing the service from a virtual
machine :
The argument HTTP context did not match any of the registered
listener manager (could be mismatch in URL, method etc.)
http://172.16.122.2:8080/Person.svc
Description: HTTP 500. Error processing request.
Stack Trace:
System.InvalidOperationException: The argument HTTP context did not
match any of the registered listener manager (could be mismatch in
URL, method etc.) http://172.16.122.2:8080/Person.svc
at System.ServiceModel.Channels.SvcHttpHandler.FindBestMatchListener
(System.Web.HttpContext ctx) [0x00120] in
/home/thiago/monotrunk/mcs/class/System.ServiceModel/System.ServiceModel.Channels/SvcHttpHandler.cs:141
at System.ServiceModel.Channels.SvcHttpHandler.ProcessRequest
(System.Web.HttpContext context) [0xd] in
/home/thiago/monotrunk/mcs/class/System.ServiceModel/System.ServiceModel.Channels/SvcHttpHandler.cs:156
at System.Web.HttpApplication+Pipelinec__Iterator2.MoveNext ()
[0x00ce5] in
/home/thiago/monotrunk/mcs/class/System.Web/System.Web/HttpApplication.cs:1344
at System.Web.HttpApplication.Tick () [0x0] in
/home/thiago/monotrunk/mcs/class/System.Web/System.Web/HttpApplication.cs:914
I think this happened because I tried to access the service trough
the 172.16.122.0 network which is the virtual network for my VMs.
The service works well if I access it on the local machine using the
http://127.0.0.1:8080/Person.svc; Url, but fails with the same error
if I use http://localhost:8080/Person.svc;. After looking into the
source code I think the problem may be on the following conditionals
(method 'FindBestMatchListener') :
if (l.Uri.Equals (ctx.Request.Url)) {
best = l;
break;
}
//
if (!ctx.Request.Url.ToString ().StartsWith (l.Uri.ToString (),
StringComparison.Ordinal))
continue;
Maybe it should check the Uris for all the network interfaces?(I have
no idea on how to do that).
___
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 in SvcHttpHandler.cs ?
Hello Thiago,
Thanks, there's a lot of major and minor missing functionalities all
around. Our class status
describes large part of those missing stuff (primarily in
System.ServiceModel.dll):
http://go-mono.com/status/
Right now we have no plan to build mono specific WCF libraries. IMO
libraries like
what you said should be released cross platform, at places like codeplex.
Instead you might have some useful code that could be used in our own
core WCF
assemblies (imagine if you have implemented WS-AtomicTransaction aside
TransactionFlowBindingElement, and we don't have working code now.)
Atsushi Eno
On 2010/07/05 21:27, Thiago Padilha wrote:
Hi Atsushi,
I have started messing with WCF last week but I'm very interested in
learning, If you need help with anything just send me a message.
Also, today I'm starting to develop an http binding/channel to allow
REST syncronous programming of WCF Services/Clients(compatible with
moonlight/silverlight 2/3). I know syncronous service calls aren't
officially supported by Silverlight, but(correct me if I'm wrong) I
don't see why that should'nt work if I extend at channel level. If you
want to integrate my source code in the Mono specific libraries I'd be
happy to send you.
On Fri, Jul 2, 2010 at 3:54 PM, Atsushi Eno
atsushi...@veritas-vos-liberabit.com wrote:
Hi,
Right, thanks for the analysis, that should be fixed, and I have an idea.
Though I am now rewriting ASP.NET channel support based on our new HTTP
(non-ASP.NET) channel stack and it does not use the code path you mentioned,
I'd rather finish the rewrite first and then fix the actual issue.
The idea above is to use Uri comparison using UriComponents based on
HostNameComparisonMode value (which is ignored so far).
Atsushi Eno
On 2010/06/29 21:46, Thiago Padilha wrote:
Hi,
I'm hosting a WCF service using asp.net/mono from trunk (r159644)
but encountered a problem when accessing the service from a virtual
machine :
The argument HTTP context did not match any of the registered
listener manager (could be mismatch in URL, method etc.)
http://172.16.122.2:8080/Person.svc
Description: HTTP 500. Error processing request.
Stack Trace:
System.InvalidOperationException: The argument HTTP context did not
match any of the registered listener manager (could be mismatch in
URL, method etc.) http://172.16.122.2:8080/Person.svc
at System.ServiceModel.Channels.SvcHttpHandler.FindBestMatchListener
(System.Web.HttpContext ctx) [0x00120] in
/home/thiago/monotrunk/mcs/class/System.ServiceModel/System.ServiceModel.Channels/SvcHttpHandler.cs:141
at System.ServiceModel.Channels.SvcHttpHandler.ProcessRequest
(System.Web.HttpContext context) [0xd] in
/home/thiago/monotrunk/mcs/class/System.ServiceModel/System.ServiceModel.Channels/SvcHttpHandler.cs:156
at System.Web.HttpApplication+Pipelinec__Iterator2.MoveNext ()
[0x00ce5] in
/home/thiago/monotrunk/mcs/class/System.Web/System.Web/HttpApplication.cs:1344
at System.Web.HttpApplication.Tick () [0x0] in
/home/thiago/monotrunk/mcs/class/System.Web/System.Web/HttpApplication.cs:914
I think this happened because I tried to access the service trough
the 172.16.122.0 network which is the virtual network for my VMs.
The service works well if I access it on the local machine using the
http://127.0.0.1:8080/Person.svc; Url, but fails with the same error
if I use http://localhost:8080/Person.svc;. After looking into the
source code I think the problem may be on the following conditionals
(method 'FindBestMatchListener') :
if (l.Uri.Equals (ctx.Request.Url)) {
best = l;
break;
}
//
if (!ctx.Request.Url.ToString ().StartsWith (l.Uri.ToString (),
StringComparison.Ordinal))
continue;
Maybe it should check the Uris for all the network interfaces?(I have
no idea on how to do that).
___
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] (WCF) Possible bug in ChannelFactoryBase.cs
Hi,
You're right. I've tried this simple testing on .NET, and it threw
ArgumentNullException on
via parameter, so it is expected as non-null.
[Test]
public void BuildChannelFactoryXXX ()
{
var ctx = new BindingContext (new CustomBinding (), empty_params);
var cf = new HttpTransportBindingElement
().BuildChannelFactoryIRequestChannel (ctx);
Assert.IsTrue (cf is ChannelFactoryBaseIRequestChannel, #1);
cf.Open ();
cf.CreateChannel (new EndpointAddress (http://localhost:8080;), null);
}
A fix should go into svn soon. Thanks.
Atsushi Eno
On 2010/07/06 10:26, Thiago Padilha wrote:
Hi,
I'm not sure about this, but maybe there's a small bug in the
'CreateChannel(EndpointAddress)' method :
public TChannel CreateChannel (
EndpointAddress remoteAddress)
{
return CreateChannel (remoteAddress, null);
}
The MSDN sample
http://msdn.microsoft.com/en-us/library/ms751494.aspx makes use of the
via parameter(which I don't understand what it's purpose is) on the
OnCreateChannel implementation in UdpOutputChannel class. Maybe
the passing remoteAddress.Uri instead of null would make it work as
expected? Here is how it would look :
public TChannel CreateChannel (
EndpointAddress remoteAddress)
{
return CreateChannel (remoteAddress, remoteAddress.Uri);
}
___
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] (WCF) Binding elements order
Hello Thiago,
In what kind of situation does this bring an issue? Is it like, a
binding element after a
TransportBindingElement should not be ignored under certain usage?
For reference, there is a test named
BuildChannelFactoryIgnoresRemaining() in HttpTransportBindingElementTest
in our nunit test that confirms that InvalidBindingElement is ignored
after a transport binding element. (If it is not ignored and called
BuildChannelFactoryT(), then it throws NotSupportedException.)
[Test]
public void BuildChannelFactoryIgnoresRemaining ()
{
BindingContext ctx = new BindingContext (
new CustomBinding (
new HttpTransportBindingElement (),
new InvalidBindingElement ()),
empty_params);
ctx.BuildInnerChannelFactoryIRequestChannel ();
}
Atsushi Eno
On 2010/07/06 21:34, Thiago Padilha wrote:
Hi Atsushi,
While examining the file Binding.cs I found the following comment
on the two overloads of CreateContext method :
// FIXME: it seems that binding elements are
// validated so that the last item is a transport.
If you were unsure about where the binding elements should be
ordered take a look at this :
http://msdn.microsoft.com/en-us/library/system.servicemodel.channels.binding.createbindingelements.aspx
According to this document, the ordering should be done inside the
CreateBindingElements method for any class that inherits from
Binding. This could be fixed by using the following code in
CustomBinding.cs :
public override BindingElementCollection CreateBindingElements ()
{
return new BindingElementCollection (elements.OrderBy
(be =
{
Type t = be.GetType ();
if
(typeof(TransportBindingElement).IsAssignableFrom (t))
return 2;
if
(typeof(MessageEncodingBindingElement).IsAssignableFrom (t))
return 1;
return 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] Fwd: [Mono-patches] r160111 - trunk/mono/mono/mini
Hey Rolf, Doesn't this change affect on all of those who build mono --with-moonlight=yes, even if they after all use the runtime as non-moonlight profile with this buffering? IMO, if the change is not harmful, this should be enabled regardless of the profile. If it in fact is, then there should be another approach to be taken e.g. run-time platform detection, or build different object for libmono and libmono-moon. Oh, and it doesn't build on Windows. I disabled it so far. Atsushi Eno Original Message Subject:[Mono-patches] r160111 - trunk/mono/mono/mini Date: Fri, 9 Jul 2010 05:44:32 -0400 (EDT) From: Rolf Bjarne Kvinge (rolfkvi...@ya.com) mono-patches-l...@lists.ximian.com To: mono-patc...@lists.ximian.com, ximian.monol...@gmail.com, mono-svn-patches-garchive-20...@googlegroups.com Author: rolf Date: 2010-07-09 05:44:32 -0400 (Fri, 09 Jul 2010) New Revision: 160111 Modified: trunk/mono/mono/mini/ChangeLog trunk/mono/mono/mini/driver.c Log: 2010-07-09 Rolf Bjarne Kvingerkvi...@novell.com * driver.c: Moonlight: Force line buffering for stdout. Modified: trunk/mono/mono/mini/ChangeLog === --- trunk/mono/mono/mini/ChangeLog 2010-07-09 09:40:59 UTC (rev 160110) +++ trunk/mono/mono/mini/ChangeLog 2010-07-09 09:44:32 UTC (rev 160111) @@ -1,3 +1,7 @@ +2010-07-09 Rolf Bjarne Kvingerkvi...@novell.com + + * driver.c: Moonlight: Force line buffering for stdout. + 2010-07-09 Zoltan Vargavar...@gmail.com * mini-llvm.c (emit_load): Revert the last changes, the load/store intrinsics Modified: trunk/mono/mono/mini/driver.c === --- trunk/mono/mono/mini/driver.c 2010-07-09 09:40:59 UTC (rev 160110) +++ trunk/mono/mono/mini/driver.c 2010-07-09 09:44:32 UTC (rev 160111) @@ -1316,6 +1316,13 @@ int test_jit_info_table = FALSE; #endif +#ifdef MOONLIGHT + /* stdout defaults to block buffering if it's not writing to a terminal, which +* happens with our test harness: we redirect stdout to capture it. Force line +* buffering in all cases. */ + setlinebuf (stdout); +#endif + setlocale (LC_ALL, ); vm_config = getenv (MONO_VM_CONFIG); ___ Mono-patches maillist - mono-patc...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-patches ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Ambiguity between SoapTypeAttribute and SoapAttribute
According to the build bots, trunk should build fine (and it's all about class lib). Try svn up? http://wrench.mono-project.com/builds Atsushi Eno On 2010/07/13 15:41, KISHIMOTO, Makoto wrote: Hello, In my amd64 FreeBSD box, make check of mono svn trunk failed with error. When compiling Test/System.Runtime.Remoting/SoapServicesTest.cs, errors, CS0229: Ambiguity between `System.Runtime.Remoting.Metadata.SoapTypeAttribute.XmlNamespace' and `System.Runtime.Remoting.Metadata.SoapAttribute.XmlNamespace', occured. Log is following. $ gmake check Making check in po gmake[1]: Entering directory `/export/home/ksmakoto/Mono/BUILD/po' Making check in mcs gmake[2]: Entering directory `/export/home/ksmakoto/Mono/BUILD/po/mcs' gmake[2]: Leaving directory `/export/home/ksmakoto/Mono/BUILD/po/mcs' gmake[2]: Entering directory `/export/home/ksmakoto/Mono/BUILD/po' gmake[2]: Nothing to be done for `check-am'. gmake[2]: Leaving directory `/export/home/ksmakoto/Mono/BUILD/po' (snip) gmake test-local gmake[7]: Entering directory `/export/home/ksmakoto/Mono/mcs/mcs' Makefile:51: warning: overriding commands for target `csproj-local' ../build/executable.make:134: warning: ignoring old commands for target `csproj-local' gmake[7]: Leaving directory `/export/home/ksmakoto/Mono/mcs/mcs' gmake[6]: Leaving directory `/export/home/ksmakoto/Mono/mcs/mcs' gmake[6]: Entering directory `/export/home/ksmakoto/Mono/mcs/class' gmake[7]: Entering directory `/export/home/ksmakoto/Mono/mcs/class/corlib' gmake test-local gmake[8]: Entering directory `/export/home/ksmakoto/Mono/mcs/class/corlib' MCS [net_2_0] corlib_test_net_2_0.dll Test/System.Resources/ResourceManagerTest.cs(1016,39): warning CS0108: `MonoTests.System.Resources.ResourceManagerTest.MockResourceManager.BaseNameField' hides inherited member `System.Resources.ResourceManager.BaseNameField'. Use the new keyword if hiding was intended /export/home/ksmakoto/Mono/mcs/class/lib/net_2_0/mscorlib.dll (Location of the symbol related to previous warning) Test/System.Resources/ResourceManagerTest.cs(1020,41): warning CS0108: `MonoTests.System.Resources.ResourceManagerTest.MockResourceManager.MainAssembly' hides inherited member `System.Resources.ResourceManager.MainAssembly'. Use the new keyword if hiding was intended /export/home/ksmakoto/Mono/mcs/class/lib/net_2_0/mscorlib.dll (Location of the symbol related to previous warning) Test/System.Resources/ResourceManagerTest.cs(1024,42): warning CS0108: `MonoTests.System.Resources.ResourceManagerTest.MockResourceManager.ResourceSets' hides inherited member `System.Resources.ResourceManager.ResourceSets'. Use the new keyword if hiding was intended /export/home/ksmakoto/Mono/mcs/class/lib/net_2_0/mscorlib.dll (Location of the symbol related to previous warning) Test/System.Runtime.Remoting/SoapServicesTest.cs(17,10): error CS0229: Ambiguity between `System.Runtime.Remoting.Metadata.SoapTypeAttribute.XmlNamespace' and `System.Runtime.Remoting.Metadata.SoapAttribute.XmlNamespace' /export/home/ksmakoto/Mono/mcs/class/lib/net_2_0/mscorlib.dll (Location of the symbol related to previous error) Test/System.Runtime.Remoting/SoapServicesTest.cs(52,10): error CS0229: Ambiguity between `System.Runtime.Remoting.Metadata.SoapTypeAttribute.XmlNamespace' and `System.Runtime.Remoting.Metadata.SoapAttribute.XmlNamespace' /export/home/ksmakoto/Mono/mcs/class/lib/net_2_0/mscorlib.dll (Location of the symbol related to previous error) Compilation failed: 2 error(s), 3 warnings gmake[8]: *** [corlib_test_net_2_0.dll] Error 1 gmake[8]: Leaving directory `/export/home/ksmakoto/Mono/mcs/class/corlib' gmake[7]: *** [do-test] Error 2 gmake[7]: Leaving directory `/export/home/ksmakoto/Mono/mcs/class/corlib' gmake[6]: *** [test-recursive] Error 1 gmake[6]: Leaving directory `/export/home/ksmakoto/Mono/mcs/class' gmake[5]: *** [test-recursive] Error 1 gmake[5]: Leaving directory `/export/home/ksmakoto/Mono/mcs' gmake[4]: *** [profile-do--net_2_0--test] Error 2 gmake[4]: Leaving directory `/export/home/ksmakoto/Mono/mcs' gmake[3]: *** [profiles-do--test] Error 2 gmake[3]: Leaving directory `/export/home/ksmakoto/Mono/mcs' gmake[2]: *** [mcs-do-test-profiles] Error 2 gmake[2]: Leaving directory `/export/home/ksmakoto/Mono/BUILD/runtime' gmake[1]: *** [check-am] Error 2 gmake[1]: Leaving directory `/export/home/ksmakoto/Mono/BUILD/runtime' gmake: *** [check-recursive] Error 1 ___ 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] Ambiguity between SoapTypeAttribute and SoapAttribute
OK, I found this is not in System.Runtime.Remoting but in corlib (without more build log lines we can only partially guess). http://build.mono-project.com/WebServices/Download.aspx?workfile_id=3626757 Atsushi Eno On 2010/07/13 15:59, Atsushi Eno wrote: According to the build bots, trunk should build fine (and it's all about class lib). Try svn up? http://wrench.mono-project.com/builds Atsushi Eno On 2010/07/13 15:41, KISHIMOTO, Makoto wrote: Hello, In my amd64 FreeBSD box, make check of mono svn trunk failed with error. When compiling Test/System.Runtime.Remoting/SoapServicesTest.cs, errors, CS0229: Ambiguity between `System.Runtime.Remoting.Metadata.SoapTypeAttribute.XmlNamespace' and `System.Runtime.Remoting.Metadata.SoapAttribute.XmlNamespace', occured. Log is following. $ gmake check Making check in po gmake[1]: Entering directory `/export/home/ksmakoto/Mono/BUILD/po' Making check in mcs gmake[2]: Entering directory `/export/home/ksmakoto/Mono/BUILD/po/mcs' gmake[2]: Leaving directory `/export/home/ksmakoto/Mono/BUILD/po/mcs' gmake[2]: Entering directory `/export/home/ksmakoto/Mono/BUILD/po' gmake[2]: Nothing to be done for `check-am'. gmake[2]: Leaving directory `/export/home/ksmakoto/Mono/BUILD/po' (snip) gmake test-local gmake[7]: Entering directory `/export/home/ksmakoto/Mono/mcs/mcs' Makefile:51: warning: overriding commands for target `csproj-local' ../build/executable.make:134: warning: ignoring old commands for target `csproj-local' gmake[7]: Leaving directory `/export/home/ksmakoto/Mono/mcs/mcs' gmake[6]: Leaving directory `/export/home/ksmakoto/Mono/mcs/mcs' gmake[6]: Entering directory `/export/home/ksmakoto/Mono/mcs/class' gmake[7]: Entering directory `/export/home/ksmakoto/Mono/mcs/class/corlib' gmake test-local gmake[8]: Entering directory `/export/home/ksmakoto/Mono/mcs/class/corlib' MCS [net_2_0] corlib_test_net_2_0.dll Test/System.Resources/ResourceManagerTest.cs(1016,39): warning CS0108: `MonoTests.System.Resources.ResourceManagerTest.MockResourceManager.BaseNameField' hides inherited member `System.Resources.ResourceManager.BaseNameField'. Use the new keyword if hiding was intended /export/home/ksmakoto/Mono/mcs/class/lib/net_2_0/mscorlib.dll (Location of the symbol related to previous warning) Test/System.Resources/ResourceManagerTest.cs(1020,41): warning CS0108: `MonoTests.System.Resources.ResourceManagerTest.MockResourceManager.MainAssembly' hides inherited member `System.Resources.ResourceManager.MainAssembly'. Use the new keyword if hiding was intended /export/home/ksmakoto/Mono/mcs/class/lib/net_2_0/mscorlib.dll (Location of the symbol related to previous warning) Test/System.Resources/ResourceManagerTest.cs(1024,42): warning CS0108: `MonoTests.System.Resources.ResourceManagerTest.MockResourceManager.ResourceSets' hides inherited member `System.Resources.ResourceManager.ResourceSets'. Use the new keyword if hiding was intended /export/home/ksmakoto/Mono/mcs/class/lib/net_2_0/mscorlib.dll (Location of the symbol related to previous warning) Test/System.Runtime.Remoting/SoapServicesTest.cs(17,10): error CS0229: Ambiguity between `System.Runtime.Remoting.Metadata.SoapTypeAttribute.XmlNamespace' and `System.Runtime.Remoting.Metadata.SoapAttribute.XmlNamespace' /export/home/ksmakoto/Mono/mcs/class/lib/net_2_0/mscorlib.dll (Location of the symbol related to previous error) Test/System.Runtime.Remoting/SoapServicesTest.cs(52,10): error CS0229: Ambiguity between `System.Runtime.Remoting.Metadata.SoapTypeAttribute.XmlNamespace' and `System.Runtime.Remoting.Metadata.SoapAttribute.XmlNamespace' /export/home/ksmakoto/Mono/mcs/class/lib/net_2_0/mscorlib.dll (Location of the symbol related to previous error) Compilation failed: 2 error(s), 3 warnings gmake[8]: *** [corlib_test_net_2_0.dll] Error 1 gmake[8]: Leaving directory `/export/home/ksmakoto/Mono/mcs/class/corlib' gmake[7]: *** [do-test] Error 2 gmake[7]: Leaving directory `/export/home/ksmakoto/Mono/mcs/class/corlib' gmake[6]: *** [test-recursive] Error 1 gmake[6]: Leaving directory `/export/home/ksmakoto/Mono/mcs/class' gmake[5]: *** [test-recursive] Error 1 gmake[5]: Leaving directory `/export/home/ksmakoto/Mono/mcs' gmake[4]: *** [profile-do--net_2_0--test] Error 2 gmake[4]: Leaving directory `/export/home/ksmakoto/Mono/mcs' gmake[3]: *** [profiles-do--test] Error 2 gmake[3]: Leaving directory `/export/home/ksmakoto/Mono/mcs' gmake[2]: *** [mcs-do-test-profiles] Error 2 gmake[2]: Leaving directory `/export/home/ksmakoto/Mono/BUILD/runtime' gmake[1]: *** [check-am] Error 2 gmake[1]: Leaving directory `/export/home/ksmakoto/Mono/BUILD/runtime' gmake: *** [check-recursive] Error 1 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono
Re: [Mono-dev] explicit conversion to bool and bool? on XElement
Hello,
I don't see such a problem.
$ cat x.cs
using System;
using System.Xml.Linq;
public class Test
{
public static void Main ()
{
XName n = XName.Get (x);
Console.WriteLine ((bool?) new XElement (n, true));
Console.WriteLine ((bool?) new XElement (n, True));
Console.WriteLine ((bool?) new XElement (n, false));
Console.WriteLine ((bool?) new XElement (n, False));
}
}
$ gmcs x.cs -r:System.Xml.Linq.dll
$ ./x.exe
True
True
False
False
$ mono ./x.exe
True
True
False
False
Atsushi Eno
On 2010/07/15 5:53, David Mitchell wrote:
Currently (or at least as of revision 147679), the explicit conversion to
bool for XElement calls System.Xml.XmlConvert.ToBoolean(), which is case
sensitive. However, Microsoft's implementation of the explicit conversion is
case insensitive.
Attached is a patch that corrects this issue by converting the convent of the
XElement to lower case before sending it to XmlConvert.ToBoolean().
I would very much appreciate it if someone would review/apply this patch (or
fix the issue in some other way).
Thanks!
-- Dave
___
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] certmgr patch to support password-protected pkcs file
Hello,
I wanted to import a password-protected pfx certificate, but it was not
supported in our certmgr. So I have created a small patch to enable it.
If it's looking good I'll push it in git (or feel free to do instead).
Atsushi Eno
diff --git a/mcs/tools/security/certmgr.cs b/mcs/tools/security/certmgr.cs
index 5799fcf..20e1427 100644
--- a/mcs/tools/security/certmgr.cs
+++ b/mcs/tools/security/certmgr.cs
@@ -137,6 +137,12 @@ namespace Mono.Tools {
return type;
}
+ static bool GetPasswordArg (string arg)
+ {
+ Action action = Action.None;
+ return GetCommand (arg) == PASS;
+ }
+
static X509Store GetStoreFromName (string storeName, bool
machine)
{
X509Stores stores = ((machine) ?
X509StoreManager.LocalMachine : X509StoreManager.CurrentUser);
@@ -168,7 +174,7 @@ namespace Mono.Tools {
return Convert.FromBase64String (base64);
}
- static X509CertificateCollection LoadCertificates (string
filename)
+ static X509CertificateCollection LoadCertificates (string
filename, string password)
{
X509Certificate x509 = null;
X509CertificateCollection coll = new
X509CertificateCollection ();
@@ -196,8 +202,11 @@ namespace Mono.Tools {
break;
case .P12:
case .PFX:
- // TODO - support PKCS12 with passwords
- PKCS12 p12 = PKCS12.LoadFromFile
(filename);
+ PKCS12 p12;
+ if (password != null)
+ p12 = PKCS12.LoadFromFile
(filename, password);
+ else
+ p12 = PKCS12.LoadFromFile
(filename);
coll.AddRange (p12.Certificates);
p12 = null;
break;
@@ -236,11 +245,11 @@ namespace Mono.Tools {
return list;
}
- static void Add (ObjectType type, X509Store store, string file,
bool verbose)
+ static void Add (ObjectType type, X509Store store, string file,
string password, bool verbose)
{
switch (type) {
case ObjectType.Certificate:
- X509CertificateCollection coll =
LoadCertificates (file);
+ X509CertificateCollection coll =
LoadCertificates (file, password);
foreach (X509Certificate x509 in coll) {
store.Import (x509);
}
@@ -531,13 +540,19 @@ namespace Mono.Tools {
}
}
+ // --pass yourpassword
+ bool hasPwd = n + 1 args.Length GetPasswordArg
(args [n]);
+ string password = hasPwd ? args [++n] : null;
+ if (hasPwd)
+ n++;
+
string file = (n args.Length) ? args [n] : null;
// now action!
try {
switch (action) {
case Action.Add:
- Add (type, store, file, verbose);
+ Add (type, store, file, password,
verbose);
break;
case Action.Delete:
Delete (type, store, file, verbose);
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] mono.security/certmgr patch to support TrustedPeople
Hello again,
This patch adds support for X509Store.TrustedPeople in Mono.Security
and certmgr.
Sorry for that this patch includes the previous change, I was lazy :|
Atsushi Eno
diff --git a/mcs/class/Mono.Security/Mono.Security.X509/X509Stores.cs
b/mcs/class/Mono.Security/Mono.Security.X509/X509Stores.cs
index bfe7451..eab4eae 100644
--- a/mcs/class/Mono.Security/Mono.Security.X509/X509Stores.cs
+++ b/mcs/class/Mono.Security/Mono.Security.X509/X509Stores.cs
@@ -47,6 +47,7 @@ namespace Mono.Security.X509 {
private X509Store _personal;
private X509Store _other;
private X509Store _intermediate;
+ private X509Store _trusted_people;
private X509Store _trusted;
private X509Store _untrusted;
@@ -87,6 +88,16 @@ namespace Mono.Security.X509 {
}
}
+ public X509Store TrustedPeople {
+ get {
+ if (_trusted_people == null) {
+ string path = Path.Combine (_storePath,
Names.TrustedPeople);
+ _trusted_people = new X509Store (path,
true);
+ }
+ return _trusted_people;
+ }
+ }
+
public X509Store TrustedRoot {
get {
if (_trusted == null) {
@@ -121,6 +132,9 @@ namespace Mono.Security.X509 {
if (_intermediate != null)
_intermediate.Clear ();
_intermediate = null;
+ if (_trusted_people != null)
+ _trusted_people.Clear ();
+ _trusted_people = null;
if (_trusted != null)
_trusted.Clear ();
_trusted = null;
@@ -149,6 +163,7 @@ namespace Mono.Security.X509 {
public const string Personal = My;
public const string OtherPeople = AddressBook;
public const string IntermediateCA = CA;
+ public const string TrustedPeople = TrustedPeople;
public const string TrustedRoot = Trust;
public const string Untrusted = Disallowed;
diff --git a/mcs/tools/security/certmgr.cs b/mcs/tools/security/certmgr.cs
index 5799fcf..f73cd54 100644
--- a/mcs/tools/security/certmgr.cs
+++ b/mcs/tools/security/certmgr.cs
@@ -137,6 +137,12 @@ namespace Mono.Tools {
return type;
}
+ static bool GetPasswordArg (string arg)
+ {
+ Action action = Action.None;
+ return GetCommand (arg) == PASS;
+ }
+
static X509Store GetStoreFromName (string storeName, bool
machine)
{
X509Stores stores = ((machine) ?
X509StoreManager.LocalMachine : X509StoreManager.CurrentUser);
@@ -151,6 +157,8 @@ namespace Mono.Tools {
case Root: // special case (same as trusted
root)
case X509Stores.Names.TrustedRoot:
return stores.TrustedRoot;
+ case X509Stores.Names.TrustedPeople:
+ return stores.TrustedPeople;
case X509Stores.Names.Untrusted:
return stores.Untrusted;
}
@@ -168,7 +176,7 @@ namespace Mono.Tools {
return Convert.FromBase64String (base64);
}
- static X509CertificateCollection LoadCertificates (string
filename)
+ static X509CertificateCollection LoadCertificates (string
filename, string password)
{
X509Certificate x509 = null;
X509CertificateCollection coll = new
X509CertificateCollection ();
@@ -196,8 +204,11 @@ namespace Mono.Tools {
break;
case .P12:
case .PFX:
- // TODO - support PKCS12 with passwords
- PKCS12 p12 = PKCS12.LoadFromFile
(filename);
+ PKCS12 p12;
+ if (password != null)
+ p12 = PKCS12.LoadFromFile
(filename, password);
+ else
+ p12 = PKCS12.LoadFromFile
(filename);
coll.AddRange (p12.Certificates
Re: [Mono-dev] [Mono-list] Mono 2.8 release plan. Developers: please read.
Hello, From what I know of: - System.Xaml is still experimental, with no practical use (there is no library that we can dogfood it, such as WPF or WF4 xaml). - I don't think System.Data.Services.Client has been in real use; it was just added to the libs. Anyone tried it? Atsushi Eno On 10/08/04 1:27, Miguel de Icaza wrote: Hello guys, The time to release Mono 2.8 to the world if quickly approaching. It is a feature packed release that changes many of the things that we have been doing in the past. The changes are significant and have the potential to impact many applications, please familiarize yourself with the current release notes draft here: http://mono-project.com/Release_Notes_Mono_2.8 Mono 2.6 continues to be our long-term support release, so we will continue to backport fixes here until we approach Mono 3.0. This frees our hands a little bit, so instead of branching Mono 2.8 and backporting changes from HEAD to 2.8.xx and releasing bug fixes every few months, we are going to get more aggressive with Mono 2.8 and we will merely snapshot trunk and release 2.8.xx versions as merely snapshots that have been tested.This means that we will not be backporting fixes to the 2.8 branch. We will just fix, and a couple of months later, do a new release from trunk. The idea is to reduce the amount of upfront QA that we will need to do for the 3.0 release. Ideally, 3.0 will just be a small incremental update from the last 2.8.x release that we do, and it should have received more day-to-day testing than nine months of behind the scenes development. We will be doing a preview of Mono 2.8 called Mono 2.7 in the next few days, and we will revise this rapidly so we should have Mono 2.8 finalized sometime in September. Miguel ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Serialization problem in WCF
Hello,
If you provide a complete (i.e. runnable) code example, I can try if it
runs fine on WCF in trunk which is far better than 2.6. Or you can try
daily snapshot by yourself.
http://mono.ximian.com/daily/
Atsushi Eno
On 2010/08/06 23:14, SuperCiccio wrote:
I'm using Mono 2.6.7/MS .NET 3.5SP1
I have a serialization problem trying to make Mono WCF interact with MS WCF.
The service is defined as the following:
[OperationContract]
ServiceResultstring TestMethod(string varA, int varB);
where ServiceResultT is a generic class for returning results, so defined:
[Serializable]
public class ServiceResultT : ServiceResult
{
public T Value { get; set; }
}
where ServiceResult is in turn roughly
[Serializable]
public class ServiceResult
{
public bool Error { get; set; }
public ListResultInfo ResultInfoList { get; set; }
}
and so on..
When talking Mono- Mono or MS- MS all goes well, but when trying to
make them interact problems arise.
In particular, with Mono server, when the message returns to client (the
call terminates correctly on server) there are deserialization errors:
1) using netTcpBinding
System.ServiceModel.Dispatcher.NetDispatcherFaultException: The formatter
threw an exception while trying to deserialize the message: There was an
error while trying to deserialize parameter
http://tempuri.org/:TestMethodResult. The InnerException message was
''EndElement' 'TestMethodResult' from namespace 'http://tempuri.org/' is not
expected. Expecting element '_x003C_Error_x003E_k__BackingField'.'. Please
see InnerException for more details. ---
System.Runtime.Serialization.SerializationException: ...
at
System.Runtime.Serialization.XmlObjectSerializerReadContext.ThrowRequiredMemberMissingException(XmlReaderDelegator
xmlReader, Int32 memberIndex, Int32 requiredIndex, XmlDictionaryString[]
memberNames)
at ReadServiceResultOfstringFromXml(XmlReaderDelegator ,
XmlObjectSerializerReadContext , XmlDictionaryString[] ,
XmlDictionaryString[] )
at
System.Runtime.Serialization.ClassDataContract.ReadXmlValue(XmlReaderDelegator
xmlReader, XmlObjectSerializerReadContext context)
at
System.Runtime.Serialization.XmlObjectSerializerReadContext.InternalDeserialize(XmlReaderDelegator
reader, String name, String ns, DataContract dataContract)
2) using basicHttpBinding
System.ServiceModel.Dispatcher.NetDispatcherFaultException: The formatter
threw an exception while trying to deserialize the message: There was an
error while trying to deserialize parameter
http://tempuri.org/:TestMethodResult. The InnerException message was 'There
was an error deserializing the object of type
myApp.ServiceResult`1[[System.String, mscorlib, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089]]. The '' character,
hexadecimal value 0x3C, cannot be included in a name. Line 1, position
304.'. Please see InnerException for more details. ---
System.Runtime.Serialization.SerializationException: ... ---
System.Xml.XmlException: ...
at System.Xml.XmlExceptionHelper.ThrowXmlException(XmlDictionaryReader
reader, XmlException exception)
at System.Xml.XmlUTF8TextReader.VerifyNCName(String s)
at System.Xml.XmlUTF8TextReader.ReadQualifiedName(PrefixHandle prefix,
StringHandle localName)
at System.Xml.XmlUTF8TextReader.ReadStartElement()
at System.Xml.XmlUTF8TextReader.Read()
at System.Runtime.Serialization.XmlReaderDelegator.Read()
at
System.Runtime.Serialization.ClassDataContract.ReadXmlValue(XmlReaderDelegator
xmlReader, XmlObjectSerializerReadContext context)
at
System.Runtime.Serialization.XmlObjectSerializerReadContext.InternalDeserialize(XmlReaderDelegator
reader, String name, String ns, DataContract dataContract)
Bugs in Mono serialization?
Can I do anything as a workaround?
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] BasicHttpBinding issues
Hello, This is sort of a correct list (mono-list may be better unless mono development is involved). I have no idea on from which this list addition occurs. This might not happen in the latest git head or daily builds (but I doubt that). If you can provide the runnable example code, I can test it on the latest code. Atsushi Eno On 2010/08/12 12:21, Matthew Fanto wrote: Forgive me if this is the wrong list. I checked the descriptions of the various lists, and this one seemed to be the most relevant, as I'm seeing a difference between running under .NET 3.5 and Mono 2.6.7. I am attempting to create a WCF service. I've been unable to get either NetTcpBinding or BasicHttpBinding working, yet both work fine if I run under .NET. Running under Mono 2.6.7 on Windows 7 x64, I occasionally get an exception Exception during finishing channel acceptance with a System.IndexOutofRangeException: Array index is out of range. This happens half the time that I run the service. I never get these exceptions if I am running under .NET. The end of the stack trace looks like: at (wrapper stelemref) object:stelemref (object,intptr,object) at System.Collections.Generic.List`1[System.ServiceModel.Channels.IChannel].Add (IChannel item) [0x0001a] in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.6.7\mcs\class\corlib\System.Collections.Generic\List.cs:89 at System.ServiceModel.Dispatcher.ListenerLoopManager.ChannelAccepted (IChannel ch) [0x0004c] in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.6.7\mcs\class\System.ServiceModel\System.ServiceModel.Dispatcher\ChannelDispatcher.cs:499 at System.ServiceModel.Dispatcher.ListenerLoopManager+CreateAcceptorc__AnonStorey1C`1[System.ServiceModel.Channels.IReplyChannel].m__1F (IAsyncResult result) [0x0] in C:\cygwin\tmp\monobuild\build\BUILD\mono-2.6.7\mcs\class\System.ServiceModel\System.ServiceModel.Dispatcher\ChannelDispatcher.cs:373 I can provide the full stack trace if needed. When the service does start, any clients that attempt to connect get an Error 400. I create the ServiceHost with: var host = new ServiceHost(typeof(TestService)); host.AddServiceEndpoint(typeof(ITestService), new BasicHttpBinding(), http://127.0.0.1:/test;); host.Open(); I have also attempted to run the service under OpenSuSE 11.3, and get the same Error 400. Everything works fine under .NET 3.5 however. I have set all the buffer sizes to their max value. I'd appreciate any help or direction (or if I should be sending this to another list). Best, Matt ___ 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] BasicHttpBinding issues
Hello, For random results, it is rather likely that 2.6 HttpTransport listener confuses between the contract service endpoint and WSDL/debug endpoint (i.e. WSDL endpoint could try to process the contract messages, or the contract endpoint may try to process WSDL requests). Explicitly disabling ServiceDebugBehavior and ServiceMetadataBehavior (serviceDebug and serviceMetadata in config) might fix this specific issue. And if you still gets failures occasionally (or consistently), it may be time to have some doubts on Tools for VS. Anyways you can feel free to send me your code and try it at my side if you want :) Atsushi Eno On 2010/08/12 15:17, Matthew Fanto wrote: On Thu, Aug 12, 2010 at 2:06 AM, Atsushi Eno atsushi...@veritas-vos-liberabit.com mailto:atsushi...@veritas-vos-liberabit.com wrote: I have no idea on from which this list addition occurs. This might not happen in the latest git head or daily builds (but I doubt that). If you can provide the runnable example code, I can test it on the latest code. I might have been quick with my initial email before checking everything. I also apologize for being vague on details, but everytime it ran, I had different results. Nothing was predictable. I've played with this down further and it seems to be caused by Mono Tools for Visual Studio. If I run the application from cmd.exe with mono.exe test.exe, the WCF service listens, and responds to requests as it should. If I run from within Visual Studio, I am unable to get anything to run. If I use Run in Mono, I get an error that the assembly is too large. Using Debug in Mono, sometimes the service starts but rejects any request. Other times, the application crashes with unhandled exceptions. Also, if I kill the debugger, mono.exe still hangs and does not terminate. I have to manually terminate it. cmd.exe runs as the same privileges as Visual Studio. Best, Matt ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Strange Casting bug in .net 4 profile
Hello, We don't have Microsoft.Transactions.Bridge.dll, so you are very likely using System.ServiceModel.dll from .NET Framework, not ours. We don't support MS assemblies (no point of doing that as you are not supposed to be allowed to use it on non-Windows environment). BTW what exactly are some similar looking bugs ? I'm not aware of such ones. Atsushi Eno On 2010/08/19 0:05, Gary Thomas wrote: A little more digging using reflector on the binary shows the path to the dependency as follows: CastBug 0.0.0.0 depends on System.ServiceModel 4.0.0 which depends on Microsoft.Transactions.Bridge 3.0.0 which depends on System.ServiceModel 3.0.0.0 -Original Message- From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Gary Thomas Sent: 18 August 2010 15:42 To: Robert Jordan; mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Strange Casting bug in .net 4 profile There are some similar looking bugs on bugzilla but it is still happening in trunk now. I just deleted /opt/mono ran: make clean git pull ./autogen.sh --prefix=/opt/mono make sudo make install then recompiled the test app, ran it and still get the same results. Below is a trace of the application run with --debug. It seems to show that System.Configuration 2.0.0.0 assembly load is redirected to 4.0.0.0 However I see that two versions of System.ServiceModel are being loaded (the class I am trying to cast to is in System.ServiceModel) so perhaps this is the problem after all. Any idea how to fix? Is it a binding redirect in the mono config file or something simple like that? Thanks, Gary [mono] ~/Projects/CastBug @ MONO_LOG_LEVEL=debug MONO_LOG_MASK=asm mono --debug CastBug.exe Mono: Assembly Loader probing location: '/opt/mono/lib/mono/4.0/mscorlib.dll'. Mono: Image addref mscorlib 0x86f5088 - /opt/mono/lib/mono/4.0/mscorlib.dll 0x86f4710: 2 Mono: Assembly Loader loaded assembly from location: '/opt/mono/lib/mono/4.0/mscorlib.dll'. Mono: Assembly Ref addref mscorlib 0x86f5088 - mscorlib 0x86f5088: 1 Mono: Assembly mscorlib 0x86f5088 added to domain CastBug.exe, ref_count=2 Mono: Assembly Loader probing location: 'CastBug.exe'. Mono: Image addref CastBug 0x87443a0 - /home/garyt/Projects/CastBug/CastBug.exe 0x86f3c00: 3 Mono: Assembly CastBug 0x87443a0 added to domain CastBug.exe, ref_count=1 Mono: Assembly Loader loaded assembly from location: 'CastBug.exe'. Mono: Assembly Loader probing location: 'CastBug.exe'. Mono: Assembly Ref addref CastBug 0x87443a0 - mscorlib 0x86f5088: 3 Mono: Assembly Loader probing location: '/opt/mono/lib/mono/gac/System.ServiceModel/4.0.0.0__b77a5c561934e089/System.ServiceModel.dll'. Mono: Image addref System.ServiceModel 0x874c5d8 - /opt/mono/lib/mono/gac/System.ServiceModel/4.0.0.0__b77a5c561934e089/System.ServiceModel.dll 0x874bd20: 2 Mono: Assembly System.ServiceModel 0x874c5d8 added to domain CastBug.exe, ref_count=1 Mono: Assembly Loader loaded assembly from location: '/opt/mono/lib/mono/gac/System.ServiceModel/4.0.0.0__b77a5c561934e089/System.ServiceModel.dll'. Mono: Assembly Ref addref CastBug 0x87443a0 - System.ServiceModel 0x874c5d8: 2 Mono: Assembly Loader probing location: '/opt/mono/lib/mono/gac/System.Configuration/4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll'. Mono: Image addref System.Configuration 0x87579d8 - /opt/mono/lib/mono/gac/System.Configuration/4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll 0x8757020: 2 Mono: Assembly System.Configuration 0x87579d8 added to domain CastBug.exe, ref_count=1 Mono: Assembly Loader loaded assembly from location: '/opt/mono/lib/mono/gac/System.Configuration/4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll'. Mono: Assembly Ref addref System.ServiceModel 0x874c5d8 - System.Configuration 0x87579d8: 2 Mono: Assembly Ref addref System.Configuration 0x87579d8 - mscorlib 0x86f5088: 4 Mono: Assembly Ref addref CastBug 0x87443a0 - System.Configuration 0x87579d8: 3 Mono: Assembly Loader probing location: '/opt/mono/lib/mono/gac/System/4.0.0.0__b77a5c561934e089/System.dll'. Mono: Image addref System 0x87615f8 - /opt/mono/lib/mono/gac/System/4.0.0.0__b77a5c561934e089/System.dll 0x8760c10: 2 Mono: Assembly System 0x87615f8 added to domain CastBug.exe, ref_count=1 Mono: Assembly Loader loaded assembly from location: '/opt/mono/lib/mono/gac/System/4.0.0.0__b77a5c561934e089/System.dll'. Mono: Assembly Ref addref System.Configuration 0x87579d8 - System 0x87615f8: 2 Mono: Assembly Loader probing location: '/opt/mono/lib/mono/gac/System.Xml/4.0.0.0__b77a5c561934e089/System.Xml.dll'. Mono: Image addref System.Xml 0x876fbb0 - /opt/mono/lib/mono/gac/System.Xml/4.0.0.0__b77a5c561934e089/System.Xml.dll 0x876f5c0: 2 Mono: Assembly System.Xml 0x876fbb0 added to domain CastBug.exe, ref_count=1 Mono: Assembly Loader loaded assembly from location: '/opt
[Mono-dev] [PATCH] unify thread id format in trace
Hello,
This tiny patch unifies the format of thread IDs in our stack traces.
That is, they used to look like this:
[16D8: 2.11659 1] LEAVE: (wrapper remoting-invoke-with-check)
System.Net.HttpWebRequest:get_Aborted ()FALSE
[16d8:] EXCEPTION handling: System.Net.Sockets.SocketException
After the patch, they would look like:
[16D8: 2.11659 1] LEAVE: (wrapper remoting-invoke-with-check)
System.Net.HttpWebRequest:get_Aborted ()FALSE
[16D8:] EXCEPTION handling: System.Net.Sockets.SocketException
The patch actually just changes g_print() with printf(), which seem to
have different hexadecimal formatting (upper/lower).
I felt a bit awkward to bring printf() than g_print(), but printf() is
used a lot in trace.c so I took easier path.
Atsushi Eno
diff --git a/mono/mini/mini-exceptions.c b/mono/mini/mini-exceptions.c
index ce67a2f..6bd09fd 100644
--- a/mono/mini/mini-exceptions.c
+++ b/mono/mini/mini-exceptions.c
@@ -1213,7 +1213,7 @@ mono_handle_exception_internal (MonoContext *ctx,
gpointer obj, gpointer origina
if (msg == NULL) {
msg = message ? mono_string_to_utf8
((MonoString *) message) : g_strdup ((System.Exception.Message property not
available));
}
- g_print ([%p:] EXCEPTION handling: %s.%s: %s\n,
(void*)GetCurrentThreadId (), mono_object_class (obj)-name_space,
mono_object_class (obj)-name, msg);
+ printf ([%p:] EXCEPTION handling: %s.%s: %s\n,
(void*)GetCurrentThreadId (), mono_object_class (obj)-name_space,
mono_object_class (obj)-name, msg);
g_free (msg);
if (mono_ex mono_trace_eval_exception
(mono_object_class (mono_ex)))
mono_print_thread_dump_from_ctx (ctx);
@@ -1412,7 +1412,7 @@ mono_handle_exception_internal (MonoContext *ctx,
gpointer obj, gpointer origina
}
if
(mono_trace_is_enabled () mono_trace_eval (ji-method))
- g_print
(EXCEPTION: catch found at clause %d of %s\n, i, mono_method_full_name
(ji-method, TRUE));
+ printf
(EXCEPTION: catch found at clause %d of %s\n, i, mono_method_full_name
(ji-method, TRUE));
mono_profiler_exception_clause_handler (ji-method, ei-flags, i);
mono_debugger_call_exception_handler (ei-handler_start, MONO_CONTEXT_GET_SP
(ctx), obj);
MONO_CONTEXT_SET_IP
(ctx, ei-handler_start);
@@ -1426,7 +1426,7 @@ mono_handle_exception_internal (MonoContext *ctx,
gpointer obj, gpointer origina
if (!test_only
is_address_protected (ji, ei, MONO_CONTEXT_GET_IP (ctx))
(ei-flags ==
MONO_EXCEPTION_CLAUSE_FAULT)) {
if
(mono_trace_is_enabled () mono_trace_eval (ji-method))
- g_print
(EXCEPTION: fault clause %d of %s\n, i, mono_method_full_name (ji-method,
TRUE));
+ printf
(EXCEPTION: fault clause %d of %s\n, i, mono_method_full_name (ji-method,
TRUE));
mono_profiler_exception_clause_handler (ji-method, ei-flags, i);
mono_debugger_call_exception_handler (ei-handler_start, MONO_CONTEXT_GET_SP
(ctx), obj);
call_filter (ctx,
ei-handler_start);
@@ -1434,7 +1434,7 @@ mono_handle_exception_internal (MonoContext *ctx,
gpointer obj, gpointer origina
if (!test_only
is_address_protected (ji, ei, MONO_CONTEXT_GET_IP (ctx))
(ei-flags ==
MONO_EXCEPTION_CLAUSE_FINALLY)) {
if
(mono_trace_is_enabled () mono_trace_eval (ji-method))
- g_print
(EXCEPTION: finally clause %d of %s\n, i, mono_method_full_name (ji-method,
TRUE));
+ printf
(EXCEPTION: finally clause %d of %s\n, i, mono_method_full_name (ji-method,
TRUE));
mono_profiler_exception_clause_handler (ji-method, ei-flags, i);
mono_debugger_call_exception_handler (ei-handler_start, MONO_CONTEXT_GET_SP
(ctx), obj
Re: [Mono-dev] Serialization problem in WCF
Thanks, looks like there's indeed some problem even in the latest git head. I'll try some fixes. Atsushi Eno On 2010年08月25日 01:02, SuperCiccio wrote: Complete code example attached. Try running mono MyApp.Server.exe ina prompt and MyApp.Client.exe or mono http://mono.1490590.n4.nabble.com/file/n2336928/WCFtest.zip WCFtest.zip MyApp.Client.exe in another prompt. Cheers ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Serialization problem in WCF
This is now fixed in git head. Atsushi Eno On 2010/08/27 21:10, Atsushi Eno wrote: Thanks, looks like there's indeed some problem even in the latest git head. I'll try some fixes. Atsushi Eno On 2010年08月25日 01:02, SuperCiccio wrote: Complete code example attached. Try running mono MyApp.Server.exe ina prompt and MyApp.Client.exe or mono http://mono.1490590.n4.nabble.com/file/n2336928/WCFtest.zip WCFtest.zip MyApp.Client.exe in another prompt. Cheers ___ 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] Serialization problem in WCF
Using data contract solves the issue. It was due to that (1) it was not picking base type members in ISerializable, so do not use ISerializable (e.g. use data contract), and (2) fields with special members were not encoded in valid xml name, which happens only to automatically generated fields for auto properties. For the fix details, see (1) http://github.com/mono/mono/commit/c893d9c638f9b2e86c71779165d508fddfc875a3 (2) http://github.com/mono/mono/commit/57c4337d79ace6f27903b2f896806263a71870bf mono 2.8 is rumored to be released soon, but it won't include this specific fix (the branching was done earlier last week). In current plan, 2.8.2 will include it (as it will be branched from git head), but I can't say the release plan is stable yet. Atsushi Eno On 2010/08/29 22:55, SuperCiccio wrote: Thanks for your attention. Are there any workaround? Or, when will a version be avaiable? Cheers ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Possible Bug in Mono?
(In general, avoid using such ambiguous email subject; it makes
searching relevant messages difficult.)
It correctly works for me. Make sure that you don't have your source
encoding and compiler -codepage argument or default encoding
mismatching. The default encoding is platform dependent.
You can avoid such a problem by avoiding non-ASCII characters in your
source code. In this case, use ¥u0083 instead of raw POUND SIGN.
Atsushi Eno
(10/09/06 18:10), anidotnet wrote:
I have the following functions to get the Unicode representation of a string
-
public static string ToUnicode(this string strA)
{
var writer = new StringWriter();
try
{
foreach (char c in strA)
{
char h1 = IntToHex((c 12) '\x000f');
char h2 = IntToHex((c 8) '\x000f');
char h3 = IntToHex((c 4) '\x000f');
char h4 = IntToHex(c '\x000f');
writer.Write('\\');
writer.Write('u');
writer.Write(h1);
writer.Write(h2);
writer.Write(h3);
writer.Write(h4);
}
string str = writer.ToString();
writer.Dispose();
return str;
}
catch (Exception)
{
writer.Dispose();
throw;
}
}
private static char IntToHex(int n)
{
if (n= 9)
{
return (char) (n + 48);
}
return (char) ((n - 10) + 97);
}
While unit testing the above code from Nunit
for .Net framework 3.5 I got
Assert.AreEqual(£.ToUnicode(), @\u00a3);
working, but in Mono it is failing. It says
Expected: \\ufffd, But was: \\u00a3
Why Mono is giving different result than .Net for a same piece of code? Is
it a bug or am I missing something?
Regards,
Anindya Chatterjee
http://abstractclass.org
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Possible Bug in Mono?
Hello, source code encoding can be specified when you save a source file on MonoDevelop (there is a combobox for encoding option). On compilation, monodevelop takes compiler options from the project properties. I don't know which encoding MonoDevelop on Windows uses by default (I don't have Windows machine now), but adding -codepage:utf8 to additional options line on the Compiler node on the Build menu tree would work. (-codepage option is common to .NET csc.exe) Atsushi Eno (10/09/06 21:38), anidotnet wrote: Atsushi Eno-2 wrote: (In general, avoid using such ambiguous email subject; it makes searching relevant messages difficult.) First of all sorry for the inconvenience caused due to short ambiguous subject of the email. Atsushi Eno-2 wrote: You can avoid such a problem by avoiding non-ASCII characters in your source code. In this case, use ¥u0083 instead of raw POUND SIGN. Secondly, I don't want to avoid Unicode char in the source code as the sole intention of the function I used is to get the Unicode representation of a string. That's why I want to specify the unicode char in the source code for unit testing. Atsushi Eno-2 wrote: Make sure that you don't have your source encoding and compiler -codepage argument or default encoding mismatching. The default encoding is platform dependent. Can you please tell me how to do that? I am using Mono v2.6.7 with Monodevelop v2.4 on Windows XP. Any help would be highly appreciated. Thanks for your reply and time. Regards, Anindya Chatterjee http://abstractclass.org ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] how to get MonoDroid download password?
Probably you haven't subscribed yourself to the beta signup (linked from http://monodroid.net/ ). It is only for beta subscribers so far. Note that you won't receive beta tester download information. It is queued (I'm not sure if it will be all dequeued until the final release comes out). Atsushi Eno (10/09/06 23:59), Barry Song wrote: Hi All, According to http://monodroid.net/Installation, we can download the MonoDroid for Visual Studio 2010 Plugin at http://go-mono.com/monodroid-download. But I wonder how to get a password for the download. Can anyone tell me? Thanks Barry ___ 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] merge web.config regression to 2.8
Hi Andrew, We need this patch to get WCF on ASP.NET (xsp4) working as we used to do. (web.config was somehow updated to exclude .svc handler at some stage, which was wrong.) Atsushi Eno diff --git a/data/net_4_0/web.config b/data/net_4_0/web.config index db1c2b8..2a7dfd2 100644 --- a/data/net_4_0/web.config +++ b/data/net_4_0/web.config @@ -76,6 +76,7 @@ !-- add path=*.svc verb=* type=System.ServiceModel.Activation.HttpHandler, System.ServiceModel.Activation, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 validate=False/ -- + add verb=* path=*.svc type=System.ServiceModel.Channels.SvcHttpHandlerFactory, System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 / add path=*.rules verb=* type=System.Web.HttpForbiddenHandler validate=True/ !-- add path=*.xoml verb=* type=System.ServiceModel.Activation.HttpHandler, System.ServiceModel.Activation, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 validate=False/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 3.0 Roadmap: IKVM-powered C# compiler
It is about IKVM Reflection, not about Java at all. Atsushi Eno On 2010/09/19 22:57, Brad Jones wrote: Hi, Can someone explain/elaborate on what “IKVM-powered C# compiler” this means? How will this benefit Java apps etc.? Cheers, Brad ___ 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] WCF: Contracts with Interface hierarchy
Hi Karsten,
Thanks for nice bug analysis. On building System.ServiceModel on
MonoDevelop, you can just open Makefile to treat it as a class lib
project (valid only in our mcs classes). The .csproj file there was from
the past era, used by Mainsoft team. It is ambiguous like this time and
I'd rather remove it unless the Mainsoft guys object.
We welcome your patch and/or bug report. I'll visit the issue once I
have finished ongoing work.
Atsushi Eno
On 2010/09/26 19:20, KarstenF wrote:
Hi,
I'm new to Mono and new to this list so let's hope my post doesn't contain
too many newbie's errors...
I've got a large WCF-heavy .NET project. With upcoming mono 2.8 I'd try to
give it a shot and make it run on mono. Here's an issue I've found when
using contract interfaces with a hierarchy. Consider this:
[ServiceContract]
interface ServiceInterface : Foo
{
}
[ServiceContract]
interface Foo : Bar
{
[OperationContract] void Foo();
}
[ServiceContract]
interface Bar {
[OperationContract] void FooBar();
}
class DummyService : ServiceInterface
{
public void FooBar() { }
public void Foo() { }
public static ServiceHost Create() {
return new ServiceHost(typeof(DummyService)); // fine in MS, fails in
Mono
with A contract cannot have two operations that have the identical names
and different set of parameters
}
}
What happens is this:
1.
System.ServiceModel.Description.ContractDescriptionGenerator.GetAllInterfaceTypes(ServiceInterface)
returns 4 interfaces: bar is yielded twice to some recursion logic glitch.
2.
System.ServiceModel.Description.ContractDescriptionGenerator.GetServiceContractAttribute
returns 3 service contracts: ServiceInterface, Foo and Bar. This is due to
Foo and Bar needing the [ServiceContract] attribute: According to Microsoft
interfaces without that attribute are not allowed to have
[OperationContract] methods.
Ultimately both 1. and 2. result in method FooBar beeing added multiple time
to
System.ServiceModel.Description.ContractDescriptionGenerator.GetOrCreateOperation()
This then throws an cannot have two operations that have the identical
names and different set of parameters.
This is obviously wrong as the methods have the very same set of parameters.
imho neither 1 nor 2 need fixes. It's rather GetOrCreateOperation which
should check if the existing method in the contract has the same signature
and if so then just ignore it. After all it's perfectly valid to have a
method declared at different points in an interface hierarchy as long as the
signature remains the same.
I tried to create a patch myself but I'm having trouble to build
System.ServiceModel.csproj of the mono-2-8 branch using monodevelop (or
xbuild from mono-2-8p5 on windows): there are quite a files in the project
that are not there (i think obsolete and moved to old code but I'm not sure)
and I get lots of compiler errors. Any ideas what I do wrong?
Shall I post a bug (Component: WCF?)
Thank you for making mono such a great thing!
Karsten
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WCF: Contracts with Interface hierarchy
This should be fixed now in git master.
Atsushi Eno
On 2010/09/29 15:37, Atsushi Eno wrote:
Hi Karsten,
Thanks for nice bug analysis. On building System.ServiceModel on
MonoDevelop, you can just open Makefile to treat it as a class lib
project (valid only in our mcs classes). The .csproj file there was from
the past era, used by Mainsoft team. It is ambiguous like this time and
I'd rather remove it unless the Mainsoft guys object.
We welcome your patch and/or bug report. I'll visit the issue once I
have finished ongoing work.
Atsushi Eno
On 2010/09/26 19:20, KarstenF wrote:
Hi,
I'm new to Mono and new to this list so let's hope my post doesn't contain
too many newbie's errors...
I've got a large WCF-heavy .NET project. With upcoming mono 2.8 I'd try to
give it a shot and make it run on mono. Here's an issue I've found when
using contract interfaces with a hierarchy. Consider this:
[ServiceContract]
interface ServiceInterface : Foo
{
}
[ServiceContract]
interface Foo : Bar
{
[OperationContract] void Foo();
}
[ServiceContract]
interface Bar {
[OperationContract] void FooBar();
}
class DummyService : ServiceInterface
{
public void FooBar() { }
public void Foo() { }
public static ServiceHost Create() {
return new ServiceHost(typeof(DummyService)); // fine in MS, fails in
Mono
with A contract cannot have two operations that have the identical names
and different set of parameters
}
}
What happens is this:
1.
System.ServiceModel.Description.ContractDescriptionGenerator.GetAllInterfaceTypes(ServiceInterface)
returns 4 interfaces: bar is yielded twice to some recursion logic glitch.
2.
System.ServiceModel.Description.ContractDescriptionGenerator.GetServiceContractAttribute
returns 3 service contracts: ServiceInterface, Foo and Bar. This is due to
Foo and Bar needing the [ServiceContract] attribute: According to Microsoft
interfaces without that attribute are not allowed to have
[OperationContract] methods.
Ultimately both 1. and 2. result in method FooBar beeing added multiple time
to
System.ServiceModel.Description.ContractDescriptionGenerator.GetOrCreateOperation()
This then throws an cannot have two operations that have the identical
names and different set of parameters.
This is obviously wrong as the methods have the very same set of parameters.
imho neither 1 nor 2 need fixes. It's rather GetOrCreateOperation which
should check if the existing method in the contract has the same signature
and if so then just ignore it. After all it's perfectly valid to have a
method declared at different points in an interface hierarchy as long as the
signature remains the same.
I tried to create a patch myself but I'm having trouble to build
System.ServiceModel.csproj of the mono-2-8 branch using monodevelop (or
xbuild from mono-2-8p5 on windows): there are quite a files in the project
that are not there (i think obsolete and moved to old code but I'm not sure)
and I get lots of compiler errors. Any ideas what I do wrong?
Shall I post a bug (Component: WCF?)
Thank you for making mono such a great thing!
Karsten
___
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 and WCF support
As the immediately next sentense to Nowadays WCF is part of the core Mono. mentions, historically it used to be in different module (olive). Atsushi Eno On 2010/10/09 3:27, Chakotey STME wrote: Hi mailing list, I have a question about the wcf support in mono. at http://www.mono-project.com/Roadmap I get the information that in mono 2.6 there is wcf support. and here (http://www.mono-project.com/WCF) I get the information that Nowadays WCF is part of the core Mono. And I have to know what nowadays means. Is there wcf support in mono 2.4 for example? And is there an overview which parts of the wcf is supported by mono in which version? I hope you can answer my questions. thanks ___ 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] Problems with System.ServiceModel.Web
Hello,
Thanks for the patch, I very much appreciate it. Though there were some
problems in your patch.
- your implementation had an assumptiopn that WebGetAttribute and
WebInvokeAttribute has non-null UriTemplate. They can indeed be null.
- Your change broke RejectTwoParametersWhenNotWrapped() in
WebInvokeAttributeTest. It is because, in your
WebHttpBehavior.Validate()
change you just removed existing code that checked what this test
exactly
verifies i.e. invalid multiple arguments. You might think it is
very strange
and wrong but that's what .NET indeed does (looks like it is
done in
GetClientMessageFormatter() in current version of .NET though).
- There was a couple of coding style fixage needed. You had right
and wrong
style, so I assume you might have already known the style, but in
case you
haven't, have a look at http://mono-project.com/Coding_Guidelines
(I found this page was not linked from our Contributing page,
which was
our bad, just fixed it.)
I'm attaching the modified fix here. It includes some additional tests.
I'll commit the changes unless you have further comments.
(As a cosmetic excuse, WebMessageBodyStyle.Bare was new in 3.5 SP1
AFAIR, so it was left ignorant in our implementation from 3.5 era.)
Atsushi Eno
On 2010/10/09 18:27, Frank Wilhelm wrote:
Hello Mono devs,
I tried running my web service on Mono and ran into several issues. I
use the WebHttpBinding to create REST web services by hosting that
with the ServiceHost class. This works fine on .NET but the Mono
implementation of System.ServiceModel.Web shows very different, and
very limiting, behavior. So I decided instead of waiting for a fix I
try to track down the issues. Here is the first I discovered.
The Validation of WebHttpBehavior is very limiting. If a POST
operation has several parameters it will only host them if you define
'wrapped' body format. But this isn't required if the parameters are
passed in the UriTemplate. Also the requirements for WrappedRequest
and WrappedResponse look very strange. I have to wrap my response if I
have multiple input parameters? That looks wrong.
I looked up in the MSDN what the Validate method does for .NET, and
then I tried to make the .NET implementation fail. It just doesn't
behave like specified in the documentation, it never fails no matter
what.
I attach a patch that will make the Validate method less picky. It
will look for placeholders in the URI template and only after that
decides whether wrapping is needed or not. That is still more
restrictive than the .NET implementation but for me it looks like the
right thing to do. I also added a test that reproduces the problem.
Please accept the patch and give me some feedback on what I can
improve for further contributions.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
diff --git
a/mcs/class/System.ServiceModel.Web/System.ServiceModel.Description/WebHttpBehavior.cs
b/mcs/class/System.ServiceModel.Web/System.ServiceModel.Description/WebHttpBehavior.cs
index 38b804f..90241d0 100644
---
a/mcs/class/System.ServiceModel.Web/System.ServiceModel.Description/WebHttpBehavior.cs
+++
b/mcs/class/System.ServiceModel.Web/System.ServiceModel.Description/WebHttpBehavior.cs
@@ -200,30 +200,38 @@ namespace System.ServiceModel.Description
protected virtual IClientMessageFormatter
GetReplyClientFormatter (OperationDescription operationDescription,
ServiceEndpoint endpoint)
{
+ ValidateStyleForMessageFormatter (endpoint);
return new WebMessageFormatter.ReplyClientFormatter
(operationDescription, endpoint, GetQueryStringConverter
(operationDescription), this);
}
#if !NET_2_1
protected virtual IDispatchMessageFormatter
GetReplyDispatchFormatter (OperationDescription operationDescription,
ServiceEndpoint endpoint)
{
+ ValidateStyleForMessageFormatter (endpoint);
return new WebMessageFormatter.ReplyDispatchFormatter
(operationDescription, endpoint, GetQueryStringConverter
(operationDescription), this);
}
#endif
protected virtual IClientMessageFormatter
GetRequestClientFormatter (OperationDescription operationDescription,
ServiceEndpoint endpoint)
{
+ ValidateStyleForMessageFormatter (endpoint);
return new WebMessageFormatter.RequestClientFormatter
(operationDescription, endpoint, GetQueryStringConverter
(operationDescription), this);
}
#if !NET_2_1
protected virtual IDispatchMessageFormatter
GetRequestDispatchFormatter (OperationDescription operationDescription,
ServiceEndpoint endpoint
Re: [Mono-dev] Mono and WCF support
Hello, On 2010/10/10 18:33, Chakotey STME wrote: Hello, thanks for your answer. But I don't know in which version wcf is implemented in mono. Is it for example implemented in mono 2.4 or only in 2.6 and 2.8? You cannot identify which version of mono implements WCF as it is too huge to have implemented within a single version. and I am looking for an overview in which mono version which wcf functionality is. is there such an overview? There isn't. thanks 2010/10/8 Atsushi Enoatsushi...@veritas-vos-liberabit.com: As the immediately next sentense to Nowadays WCF is part of the core Mono. mentions, historically it used to be in different module (olive). Atsushi Eno On 2010/10/09 3:27, Chakotey STME wrote: Hi mailing list, I have a question about the wcf support in mono. at http://www.mono-project.com/Roadmap I get the information that in mono 2.6 there is wcf support. and here (http://www.mono-project.com/WCF) I get the information that Nowadays WCF is part of the core Mono. And I have to know what nowadays means. Is there wcf support in mono 2.4 for example? And is there an overview which parts of the wcf is supported by mono in which version? I hope you can answer my questions. thanks ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Though, I can describe a rough history: - At mono 2.4, we had very primitive HTTP client and service working. And there was a lot of fragment of code such as TCP binding that partially worked. - At mono 2.6, it had polished code that served moonlight's HTTP client usage scenarios, as well as improved HTTP service and several non-WS-* stack such as NetTcp and NetPeer. Though they needed significant amount of bugfixes. WebHttpBinding was also there. - At mono 2.8, stability on lots of non-WS-* stack are in, as well as some new stuff such as WCF Routing. Actually WS-Security has been improved too, though I was stuck at .NET's hidden WS-Trust implementation (sslnego/spnego). Atsushi Eno ___ 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 System.ServiceModel.Web
Hello,
OK, I have checked in your patch in almost identical form in git master.
I found that GET operation does not pass on .NET when
GetRequestClientFormatter() is invoked, so I split it into another contract
and marked the test as NotWorking (it haven't passed earlier anyways).
Thanks a lot for the patch :)
Atsushi Eno
On 2010/10/13 23:34, Frank Wilhelm wrote:
Hello,
thank you for your review. I tried to use the style of the existing
code but I guess I missed some spaces.
The problem with your modifications is that it defeats the purpose of
my patch. In .NET I can host a method with a definition like:
[OperationContract]
[WebInvoke(UriTemplate=set?name={name}value={value})]
void Set(string name, string value);
In Mono I couldn't. This is why I created the patch. With your
modifications the problem still exists, but now in a different place.
ValidateStyleForMessageFormatter shouldn't reject a method like the
one above. Like the modified Validate method it should consider the
UriTemplate. In the method above there is no need to wrap because
everything is passed in the URI. That works for .NET and also works
for Mono if the validation is less restrictive. I think the major
problem with my patch is that it doesn't work if the UriTemplate is
null. With only that fixed the test RejectTwoParametersWhenNotWrapped
will not break and it also works for my purpose.
I also checked the .NET behavior for WrappedRequest and
WrappedResponse. In .NET the BodyStyle WrappedRequest resolves
problems with multiple inputs and WrappedResponse with multiple
outputs. That is what I expected and it is the opposite to what is
done in ValidateStyleForMessageFormatter.
So I created a new version that hopefully resolves all issues.
On 12.10.2010 13:30, Atsushi Eno wrote:
Hello,
Thanks for the patch, I very much appreciate it. Though there were
some problems in your patch.
- your implementation had an assumptiopn that WebGetAttribute and
WebInvokeAttribute has non-null UriTemplate. They can indeed be
null.
- Your change broke RejectTwoParametersWhenNotWrapped() in
WebInvokeAttributeTest. It is because, in your
WebHttpBehavior.Validate()
change you just removed existing code that checked what this
test exactly
verifies i.e. invalid multiple arguments. You might think it is
very strange
and wrong but that's what .NET indeed does (looks like it is
done in
GetClientMessageFormatter() in current version of .NET though).
- There was a couple of coding style fixage needed. You had right
and wrong
style, so I assume you might have already known the style, but
in case you
haven't, have a look at http://mono-project.com/Coding_Guidelines
(I found this page was not linked from our Contributing page,
which was
our bad, just fixed it.)
I'm attaching the modified fix here. It includes some additional
tests. I'll commit the changes unless you have further comments.
(As a cosmetic excuse, WebMessageBodyStyle.Bare was new in 3.5 SP1
AFAIR, so it was left ignorant in our implementation from 3.5 era.)
Atsushi Eno
On 2010/10/09 18:27, Frank Wilhelm wrote:
Hello Mono devs,
I tried running my web service on Mono and ran into several issues.
I use the WebHttpBinding to create REST web services by hosting that
with the ServiceHost class. This works fine on .NET but the Mono
implementation of System.ServiceModel.Web shows very different, and
very limiting, behavior. So I decided instead of waiting for a fix I
try to track down the issues. Here is the first I discovered.
The Validation of WebHttpBehavior is very limiting. If a POST
operation has several parameters it will only host them if you
define 'wrapped' body format. But this isn't required if the
parameters are passed in the UriTemplate. Also the requirements for
WrappedRequest and WrappedResponse look very strange. I have to wrap
my response if I have multiple input parameters? That looks wrong.
I looked up in the MSDN what the Validate method does for .NET, and
then I tried to make the .NET implementation fail. It just doesn't
behave like specified in the documentation, it never fails no matter
what.
I attach a patch that will make the Validate method less picky. It
will look for placeholders in the URI template and only after that
decides whether wrapping is needed or not. That is still more
restrictive than the .NET implementation but for me it looks like
the right thing to do. I also added a test that reproduces the problem.
Please accept the patch and give me some feedback on what I can
improve for further contributions.
___
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
Re: [Mono-dev] Fwd: [Mono-patches] [mono/mono] [3 commits] 894b26fe: Warnings cleanup
Well, it is just that I often have to leave some code that is not in used yet, or had to disable and then find references that should be actually used, modified, or replaced. For example, Marek changed the code like this: this.root = instance; sctx = schemaContext; - this.settings = settings; +// this.settings = settings; This kind of changes cause overlook where the relevant types or members should be supported when it is being implemented. Or if you are asking about any specific regression in this case, there isn't except that it simply blocked ongoing work. I don't think asking to not make such changes much later when I am actually faced problems is better though. Atsushi Eno On 2010/10/16 23:51, Miguel de Icaza wrote: Hello, Can you please don't randomly make cosmetic code changes that does not only prevent active hacking but also removes variable/member references that we can find by IDEs? There are very often reason we have such extra code. Let us also take this opportunity to learn exactly what this feature about variable/members that are used by IDEs is. What was the regression in this case Atsushi, I tried figuring it out, but I could not from your short email? Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WCF in Mono 2.8 ( What all mono supports and what not)
Hello, Check out: http://go-mono.com/status/ System.ServiceModel Atsushi Eno would be able to give you a more detailed answer. srinin wrote: Can any one help me in whether mono supports following bindings, - WSHttpBinding Practically no, as we have only limited set of WS-Security implementation yet. - BasicHttpBinding Yes. - NetNamedPipeBinding No. - NetTcpBinding It probably works, but it may not. As compared to BasicHttpBinding it is not heavily used like in moonlight. Also any security feature must be turned off (they are on by default on .NET). Or any links related bindings in Mono?? Thanks in advance Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Need Help on Commons.Xml.Relaxng.dll
Hello, That's an interesting page. I didn't know that and am pretty glad to see it :) Hmm, but that sounds weird. I tried some of the samples on that page with mono --profile (simpler one), but cannot see such huge memory consumption. Can you show me the --profile result (or any profiling stuff) ? Commons.Xml.Relaxng is based on James Clark's derivative algorithm[*1] and I have implemented all the optimization trick such as avoiding exponential blowup and memoization. There could be of course bugs that prevents them though. [*1] http://www.thaiopensource.com/relaxng/derivative.html Atsushi Eno On 2010/10/22 15:38, Panop Suvaphrom wrote: Hi, I am not sure if this is the right place to ask. Now I have project to develop and validate RNC file that I have read from http://www.xs4all.nl/~wrb/Articles/Article_XML_RelaxNG_01.htm http://www.xs4all.nl/%7Ewrb/Articles/Article_XML_RelaxNG_01.htm. My problem is the memory consumption continues increasing more and more, and then the machine is quite slow. I try to search on the web but no discussion on this issue. Has anyone known about this and any suggestion would be appreciate. And also when I turn the validation off from code, memory consumption is in normal. Big ThanksJ, Panop S. ___ 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] Need Help on Commons.Xml.Relaxng.dll
You said you run the examples on the web page you mentioned earlier, right? Which code did you run? How did you confirm profiling numbers? How much was the memory consumption? There should be exact information here and there. Commons.Xml.Relaxng.Derivative objects are created a lot, and lots of them are linked to the same objects so they don't consume more memory. You won't be able to see that if you're just looking at VS debugger though. Atsushi Eno On 2010/10/26 10:24, Panop Suvaphrom wrote: Hi, I have used the Commons.Xml.Relaxng.dll in VS2010. I also think that the memory is going up especially when validation exception occurred. When profiling on .net memory profiler, I can see many of Commons.Xml.Relaxng.Derivative. Not sure about this, Do I miss something ? Thank You, Panop S. -Original Message- From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com] Sent: Saturday, October 23, 2010 1:57 PM To: Panop Suvaphrom Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Need Help on Commons.Xml.Relaxng.dll Hello, That's an interesting page. I didn't know that and am pretty glad to see it :) Hmm, but that sounds weird. I tried some of the samples on that page with mono --profile (simpler one), but cannot see such huge memory consumption. Can you show me the --profile result (or any profiling stuff) ? Commons.Xml.Relaxng is based on James Clark's derivative algorithm[*1] and I have implemented all the optimization trick such as avoiding exponential blowup and memoization. There could be of course bugs that prevents them though. [*1] http://www.thaiopensource.com/relaxng/derivative.html Atsushi Eno On 2010/10/22 15:38, Panop Suvaphrom wrote: Hi, I am not sure if this is the right place to ask. Now I have project to develop and validate RNC file that I have read from http://www.xs4all.nl/~wrb/Articles/Article_XML_RelaxNG_01.htm http://www.xs4all.nl/%7Ewrb/Articles/Article_XML_RelaxNG_01.htm. My problem is the memory consumption continues increasing more and more, and then the machine is quite slow. I try to search on the web but no discussion on this issue. Has anyone known about this and any suggestion would be appreciate. And also when I turn the validation off from code, memory consumption is in normal. Big ThanksJ, Panop S. ___ 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] Need Help on Commons.Xml.Relaxng.dll
Your code lacks relevant document and schema files. Also it is not
really runnable as it involves several external dependencies e.g. it
retrieves resources from your assembly.
If you post a *runnable* code that has static void Main(), as well as
the exact doc resources, then I'll try it on our profiler and tell the
result.
I cannot run the profiler tool which you gave the link. My guess is that
the profiling tool itself dives into the target code and thus consumes
more memory than the target code itself consumes, but I cannot confirm that.
Atsushi Eno
On 2010/10/26 12:15, Panop Suvaphrom wrote:
-Original Message-
From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com]
Sent: Tuesday, October 26, 2010 9:34 AM
To: Panop Suvaphrom
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Need Help on Commons.Xml.Relaxng.dll
You said you run the examples on the web page you mentioned earlier, right?
Not exactly the same and my code look something like this ...
public static class XmlRncValidation
{
public static void CheckValidAgainstRncResourcePrintingErrors(
string xmlDoc, string rncName)
{
var xmlReader = new XmlTextReader(new StringReader(xmlDoc));
try
{
CheckValidAgainstRncResource(rncName, xmlReader);
}
catch (RelaxngException)
{
Console.WriteLine(Invalid XML:\n + xmlDoc);
throw;
}
catch (Exception ex)
{
Console.WriteLine(Invalid :\n + ex.Message);
throw;
}
finally
{
xmlReader.Close();
}
}
public static void CheckValidAgainstRncResource(string rncName,
XmlReader xmlReader)
{
var a = Assembly.GetExecutingAssembly();
var rncStream = a.GetManifestResourceStream(rncName);
var sr = new StreamReader(rncStream);
RelaxngValidatingReader vr = null;
try
{
RelaxngPattern p;
using (sr)
{
p = RncParser.ParseRnc(sr);
}
vr = new RelaxngValidatingReader(xmlReader, p);
while (!vr.EOF)
{
vr.Read();
}
if (rncStream == null)
{
throw new ArgumentException(Resource not in assembly,
rncName);
}
}
finally
{
rncStream.Close();
sr.Close();
vr.Close();
}
}
Which code did you run? How did you confirm profiling numbers? How much was
the memory consumption? There should be exact information here and there.
I saw in task manager about 500-600 MB.
Commons.Xml.Relaxng.Derivative objects are created a lot, and lots of them
are linked to the same objects so they don't consume more memory.
You won't be able to see that if you're just looking at VS debugger though.
I see it by using http://memprofiler.com/
However, I don't know much about profiling if you need more info. , please
let me know.
Atsushi Eno
On 2010/10/26 10:24, Panop Suvaphrom wrote:
Hi,
I have used the Commons.Xml.Relaxng.dll in VS2010.
I also think that the memory is going up especially when
validation exception occurred.
When profiling on .net memory profiler, I can see many of
Commons.Xml.Relaxng.Derivative.
Not sure about this, Do I miss something ?
Thank You,
Panop S.
-Original Message-
From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com]
Sent: Saturday, October 23, 2010 1:57 PM
To: Panop Suvaphrom
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Need Help on Commons.Xml.Relaxng.dll
Hello,
That's an interesting page. I didn't know that and am pretty glad to
see it :)
Hmm, but that sounds weird. I tried some of the samples on that page with
mono --profile (simpler one), but cannot see such huge memory consumption.
Can you show me the --profile result (or any profiling stuff) ?
Commons.Xml.Relaxng is based on James Clark's derivative algorithm[*1] and I
have implemented all the optimization trick such as avoiding exponential
blowup and memoization. There could be of course bugs that prevents them
though.
[*1] http://www.thaiopensource.com/relaxng/derivative.html
Atsushi Eno
On 2010/10/22 15:38, Panop Suvaphrom wrote:
Hi,
I am not sure if this is the right place to ask.
Now I have project to develop and validate RNC file that I
have read from
http://www.xs4all.nl/~wrb/Articles/Article_XML_RelaxNG_01.htm
http://www.xs4all.nl/%7Ewrb/Articles
Re: [Mono-dev] WCF and parallel client-execution
Hello, Not sure what is exactly happening, but if you are using mono 2.6 then I limited service throttling the maximum concurrent sessions (and thus calls) to 1 for stable processing (and you cannot change it through ServiceThrottlingBehavior, as it is hard coded). So you won't get two clients run in parallel. Atsushi Eno (2010/11/21 8:10), Chakotey STME wrote: Hello, I have a problem with WCF. I have a service: ServiceBehavior(ConcurrencyMode:=ServiceModel.ConcurrencyMode.Multiple, InstanceContextMode:=InstanceContextMode.Single) _ Public Class HelloService Implements IHelloService Private Shared thisInstance As HelloService Protected Sub New() Console.WriteLine(Service erzeugt!) End Sub 'singleton Public Shared Function GetSingleton() As HelloService If (thisInstance Is Nothing) Then thisInstance = New HelloService End If Return thisInstance End Function Public Function Greet(ByVal name As String) As IList(Of Objekt) Implements IHelloService.Greet Console.WriteLine(greet aufgerufen! DateTime.Now.Ticks) Dim myObjekt As Objekt = New Objekt Dim myObjekt2 As Objekt = New Objekt Console.WriteLine(Service macht etwas lang dauerndes) Dim i As UInteger = 0 For i = 0 To UInteger.MaxValue / 2 Next Console.WriteLine(dauert lange fertig) Dim list As List(Of Objekt) = New List(Of Objekt) list.Add(myObjekt) list.Add(myObjekt2) Return list End Function Public Function Greet2(ByVal name As String) As System.Collections.Generic.IList(Of Contracts.Objekt) Implements Contracts.IHelloService.Greet2 Console.WriteLine(greet2 aufgerufen! DateTime.Now.Ticks) Dim myObjekt As Objekt = New Objekt Dim myObjekt2 As Objekt = New Objekt Console.WriteLine(Service2 macht etwas lang dauerndes) Dim i As UInteger = 0 For i = 0 To UInteger.MaxValue / 2 Next Console.WriteLine(dauert lange fertig) Dim list As List(Of Objekt) = New List(Of Objekt) list.Add(myObjekt) list.Add(myObjekt2) Return list End Function End Class And I have a Client: Imports System.ServiceModel Imports Contracts Module Module1 Sub Main() Dim binding = New BasicHttpBinding() Dim address = New EndpointAddress(http://192.168.100.110:8080;) Dim client = New HelloClient(binding, address) Dim myObjekt = client.Greet(name) End Sub End Module If I execute the client I get a answer from the host and all is perfect. But I want that more than one client can connect to the service and use the methods from the singleton service. If I execute two clients - one client has to wait until the other client has his return value. I don't know why, because I used the attribute ConcurrencyMode:=ServiceModel.ConcurrencyMode.Multiple I use a basicHttpBinding and the service is hosted via a windows-service with mono-service2. So can you help me? I use vb.net 3.5 Thanks, ___ 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] WCF and parallel client-execution
I can't give a definite answer, but at least the throttling limitation will go away ;-) Atsushi Eno (2010/11/22 15:41), Chakotey STME wrote: hello, thanks for your answer. That's correct. I am using mono 2.6 If I change to mono 2.8 - will die clients run parallel? chakoteystme 2010/11/22 Atsushi Enoatsushi...@veritas-vos-liberabit.com: Hello, Not sure what is exactly happening, but if you are using mono 2.6 then I limited service throttling the maximum concurrent sessions (and thus calls) to 1 for stable processing (and you cannot change it through ServiceThrottlingBehavior, as it is hard coded). So you won't get two clients run in parallel. Atsushi Eno (2010/11/21 8:10), Chakotey STME wrote: Hello, I have a problem with WCF. I have a service: ServiceBehavior(ConcurrencyMode:=ServiceModel.ConcurrencyMode.Multiple, InstanceContextMode:=InstanceContextMode.Single)_ Public Class HelloService Implements IHelloService Private Shared thisInstance As HelloService Protected Sub New() Console.WriteLine(Service erzeugt!) End Sub 'singleton Public Shared Function GetSingleton() As HelloService If (thisInstance Is Nothing) Then thisInstance = New HelloService End If Return thisInstance End Function Public Function Greet(ByVal name As String) As IList(Of Objekt) Implements IHelloService.Greet Console.WriteLine(greet aufgerufen! DateTime.Now.Ticks) Dim myObjekt As Objekt = New Objekt Dim myObjekt2 As Objekt = New Objekt Console.WriteLine(Service macht etwas lang dauerndes) Dim i As UInteger = 0 For i = 0 To UInteger.MaxValue / 2 Next Console.WriteLine(dauert lange fertig) Dim list As List(Of Objekt) = New List(Of Objekt) list.Add(myObjekt) list.Add(myObjekt2) Return list End Function Public Function Greet2(ByVal name As String) As System.Collections.Generic.IList(Of Contracts.Objekt) Implements Contracts.IHelloService.Greet2 Console.WriteLine(greet2 aufgerufen! DateTime.Now.Ticks) Dim myObjekt As Objekt = New Objekt Dim myObjekt2 As Objekt = New Objekt Console.WriteLine(Service2 macht etwas lang dauerndes) Dim i As UInteger = 0 For i = 0 To UInteger.MaxValue / 2 Next Console.WriteLine(dauert lange fertig) Dim list As List(Of Objekt) = New List(Of Objekt) list.Add(myObjekt) list.Add(myObjekt2) Return list End Function End Class And I have a Client: Imports System.ServiceModel Imports Contracts Module Module1 Sub Main() Dim binding = New BasicHttpBinding() Dim address = New EndpointAddress(http://192.168.100.110:8080;) Dim client = New HelloClient(binding, address) Dim myObjekt = client.Greet(name) End Sub End Module If I execute the client I get a answer from the host and all is perfect. But I want that more than one client can connect to the service and use the methods from the singleton service. If I execute two clients - one client has to wait until the other client has his return value. I don't know why, because I used the attribute ConcurrencyMode:=ServiceModel.ConcurrencyMode.Multiple I use a basicHttpBinding and the service is hosted via a windows-service with mono-service2. So can you help me? I use vb.net 3.5 Thanks, ___ 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] WCF REST POST POCO, and null value
Hello, (2010/11/25 5:42), Joe Dluzen wrote: Hi all, I've recently been familiarizing myself with the System.ServiceModel.Web namespace, as I'm looking to do some WCF REST style development. I've found 2 things that appear to be bugs, and am wondering if there are workarounds, or if I can [attempt to] patch it. 1. When passing an object in the body of a POST call, I get Unhandled Exception: System.NotImplementedException: parameter user is not contained in the URI template blah 0 0. IHello.SayHi2 in the included code. Interesting. Look like (the latest?) .NET allows such a URI template that ignores the user parameter. 2. When passing null in the URI to a GET call with a named value, I get Unhandled Exception: System.ArgumentException: The argument name value collection does not contain non-null value for 'BLAH'. However, when I GET in the browser, http://localhost:1337/Joe?age=1337 leaving off the blah, it works fine. IHello.SayHi in the included code. On Win7 64, Mono 2.8.1. The code works without issue on MS.NET. I couldn't reproduce this with our git master. It might be fixed between 2.8 and master, but it rather looks like the request is sent to the SayHi (not SayHi2) and hence blah isn't involved, so, is it really what you intended? Code: Shared library: http://pastebin.com/WSfiaj63 Server: http://pastebin.com/veJ9JubX Client: http://pastebin.com/jniuHsiz Can you please file a bug on bugzilla and attach them? Thanks, Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Validate xml file with schema file
You can't use moma report result to assume it *must* work if it does not
report anything. It is explicitly stated on the first page when you ran
moma:
http://www.mono-project.com/Using_MoMA_Guide
It won't report things that internally/indirectly use other types and/or
members that throws NIE.
Atsushi Eno
(2010/11/29 18:55), Chakotey STME wrote:
Hi,
I have a problem with this code under mono 2.6:
Dim xsdMarkup As XDocument =
XDocument.Load(/home/stefan/xml/PluginConfigSchema.xsd)
Dim schemas As XmlSchemaSet = New XmlSchemaSet()
schemas.Add(, xsdMarkup.CreateReader)
Dim doc1 As XDocument = XDocument.Load(/home/stefan/xml/Total
Processes.xml)
doc1.Validate(schemas, AddressOf XSDErrors)
Private Sub XSDErrors(ByVal o As Object, ByVal e As ValidationEventArgs)
Console.WriteLine({0}, e.Message)
errors = True
End Sub
If I execute this program I get the following Exception:
Unhandled Exception: System.NotImplementedException: The requested
feature is not implemented.
at XMLReader4.Module1.Main () [0x0] infilename unknown:0
But the mono migration analyzer says that this code is ok.
So what can I do that this code works under mono 2.6?
Thanks
chakoteystme
___
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] Validate xml file with schema file
XDocument.Validate() is not implemented in git master.
BTW I tried MoMA with a simple test code that uses XDocument.Validate()
against 2.6 profile, and it correctly reported 1 call to
NotImplementedException:
http://f.hatena.ne.jp/atsushieno/20101129214124
I wonder how you got such OK report from moma.
Atsushi Eno
(2010/11/29 19:17), Atsushi Eno wrote:
You can't use moma report result to assume it *must* work if it does not
report anything. It is explicitly stated on the first page when you ran
moma:
http://www.mono-project.com/Using_MoMA_Guide
It won't report things that internally/indirectly use other types and/or
members that throws NIE.
Atsushi Eno
(2010/11/29 18:55), Chakotey STME wrote:
Hi,
I have a problem with this code under mono 2.6:
Dim xsdMarkup As XDocument =
XDocument.Load(/home/stefan/xml/PluginConfigSchema.xsd)
Dim schemas As XmlSchemaSet = New XmlSchemaSet()
schemas.Add(, xsdMarkup.CreateReader)
Dim doc1 As XDocument = XDocument.Load(/home/stefan/xml/Total
Processes.xml)
doc1.Validate(schemas, AddressOf XSDErrors)
Private Sub XSDErrors(ByVal o As Object, ByVal e As
ValidationEventArgs)
Console.WriteLine({0}, e.Message)
errors = True
End Sub
If I execute this program I get the following Exception:
Unhandled Exception: System.NotImplementedException: The requested
feature is not implemented.
at XMLReader4.Module1.Main () [0x0] infilename unknown:0
But the mono migration analyzer says that this code is ok.
So what can I do that this code works under mono 2.6?
Thanks
chakoteystme
___
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] Validate xml file with schema file
Ahh, ok. No worries then.
BTW I mistyped: XDocument.Validate() is *now* implemented in git master ;)
Atsushi Eno
(2010/11/30 0:23), Chakotey STME wrote:
Thats correct.
The Mono analyzer says that it won't work.
Sorry.
Maybe I checked note the correct project with the mono analyzer.
Thanks for your answer.
chakoteystme
2010/11/29 Atsushi Enoatsushi...@veritas-vos-liberabit.com:
XDocument.Validate() is not implemented in git master.
BTW I tried MoMA with a simple test code that uses XDocument.Validate()
against 2.6 profile, and it correctly reported 1 call to
NotImplementedException:
http://f.hatena.ne.jp/atsushieno/20101129214124
I wonder how you got such OK report from moma.
Atsushi Eno
(2010/11/29 19:17), Atsushi Eno wrote:
You can't use moma report result to assume it *must* work if it does not
report anything. It is explicitly stated on the first page when you ran
moma:
http://www.mono-project.com/Using_MoMA_Guide
It won't report things that internally/indirectly use other types and/or
members that throws NIE.
Atsushi Eno
(2010/11/29 18:55), Chakotey STME wrote:
Hi,
I have a problem with this code under mono 2.6:
Dim xsdMarkup As XDocument =
XDocument.Load(/home/stefan/xml/PluginConfigSchema.xsd)
Dim schemas As XmlSchemaSet = New XmlSchemaSet()
schemas.Add(, xsdMarkup.CreateReader)
Dim doc1 As XDocument = XDocument.Load(/home/stefan/xml/Total
Processes.xml)
doc1.Validate(schemas, AddressOf XSDErrors)
Private Sub XSDErrors(ByVal o As Object, ByVal e As
ValidationEventArgs)
Console.WriteLine({0}, e.Message)
errors = True
End Sub
If I execute this program I get the following Exception:
Unhandled Exception: System.NotImplementedException: The requested
feature is not implemented.
at XMLReader4.Module1.Main () [0x0] infilename unknown:0
But the mono migration analyzer says that this code is ok.
So what can I do that this code works under mono 2.6?
Thanks
chakoteystme
___
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] Fwd: Problem with WCF and IEnumerable as return type
Please file a bug (C# is much better). Atsushi Eno (2010/12/07 16:14), Chakotey STME wrote: This problem still exists. Does anyone have an idea? -- Forwarded message -- From: Chakotey STMEchakoteys...@gmail.com Date: 2010/11/30 Subject: Problem with WCF and IEnumerable as return type To: mono-devel-list@lists.ximian.com Hello, I have a problem with WCF. If I have this service contract: ServiceContract() _ Public Interface IHelloService OperationContract() _ Function Greet(ByVal name As String) As IEnumerable(Of Objekt) End Interface This Service: Imports System.ServiceModel Module Module1 Sub Main() Dim host As ServiceHost = New ServiceHost(GetType(HelloService)) host.Open() End Sub End Module The implementaion of HelloService of the Service: Imports Contracts Public Class HelloService Implements IHelloService Public Function Greet(ByVal name As String) As IEnumerable(Of Objekt) Implements IHelloService.Greet Dim myObjekt As Objekt = New Objekt Dim myObjekt2 As Objekt = New Objekt myObjekt.text = Hallo myObjekt.number = 3 + name.Length Dim list As IList(Of Objekt) = New List(Of Objekt) list.Add(myObjekt) list.Add(myObjekt2) Return list End Function End Class And this client: Imports System.ServiceModel Imports Contracts Module Module1 Sub Main() Dim binding = New BasicHttpBinding() Dim address = New EndpointAddress(http://192.168.100.110:8080;) Dim client = New HelloClient(binding, address) Dim myObjekt = client.Greet(name) Console.ReadLine() End Sub End Module The implementation of HelloService from the client: Imports System.ServiceModel Imports System.ServiceModel.Channels Imports System.Runtime.Serialization Imports Contracts Public Class HelloClient Inherits ClientBase(Of IHelloService) Implements IHelloService Public Sub New(ByVal binding As Binding, ByVal address As EndpointAddress) MyBase.New(binding, address) End Sub Public Function Greet(ByVal name As String) As IEnumerable(Of Objekt) Implements IHelloService.Greet Return Channel.Greet(name) End Function End Class I execute the service and execute the client. I get this Exception: Exception Non-empty prefix must be mapped to non-empty namespace URI. at System.Xml.XmlTextWriter.WriteEndAttribute () [0x0] in filename unknown:0 at System.Xml.XmlSimpleDictionaryWriter.WriteEndAttribute () [0x0] infilename unknown:0 at System.Xml.XmlWriter.WriteAttributeString (System.String prefix, System.String localName, System.String ns, System.String value) [0x0] infilename unknown:0 at System.Xml.XmlDictionaryWriter.WriteXmlnsAttribute (System.String prefix, System.String namespaceUri) [0x0] infilename unknown:0 at System.Runtime.Serialization.DataContractSerializer.WriteStartObject (System.Xml.XmlDictionaryWriter writer, System.Object graph) [0x0] infilename unknown:0 at System.Runtime.Serialization.XmlObjectSerializer.WriteObject (System.Xml.XmlDictionaryWriter writer, System.Object graph) [0x0] infilename unknown:0 at System.ServiceModel.Dispatcher.DataContractMessagesFormatter+DataContractBodyWriter.WriteMessagePart (System.Xml.XmlDictionaryWriter writer, System.ServiceModel.Description.MessageBodyDescription desc, System.ServiceModel.Description.MessagePartDescription partDesc, System.Object obj) [0x0] infilename unknown:0 at System.ServiceModel.Dispatcher.DataContractMessagesFormatter+DataContractBodyWriter.OnWriteBodyContents (System.Xml.XmlDictionaryWriter writer) [0x0] infilename unknown:0 at System.ServiceModel.Channels.BodyWriter.WriteBodyContents (System.Xml.XmlDictionaryWriter writer) [0x0] infilename unknown:0 at System.ServiceModel.Channels.SimpleMessage.OnWriteBodyContents (System.Xml.XmlDictionaryWriter writer) [0x0] infilename unknown:0 at System.ServiceModel.Channels.Message.WriteBodyContents (System.Xml.XmlDictionaryWriter writer) [0x0] infilename unknown:0 at System.ServiceModel.Channels.Message.WriteBody (System.Xml.XmlDictionaryWriter writer) [0x0] infilename unknown:0 at System.ServiceModel.Channels.Message.OnWriteMessage (System.Xml.XmlDictionaryWriter writer) [0x0] infilename unknown:0 at System.ServiceModel.Channels.Message.WriteMessage (System.Xml.XmlDictionaryWriter writer) [0x0] infilename unknown:0 at System.ServiceModel.Channels.TextMessageEncoder.WriteMessage (System.ServiceModel.Channels.Message message, System.IO.Stream stream) [0x0] infilename unknown:0 at System.ServiceModel.Channels.HttpRequestContext.ProcessReply (System.ServiceModel.Channels.Message msg, TimeSpan timeout) [0x0] infilename unknown:0 at System.ServiceModel.Channels.HttpRequestContextBase.Reply
Re: [Mono-dev] Olive Status
The mono-olive mailing list was shut down to migrate to here (I posted about that as the last message there), so you are welcome here in the right place now to discuss WF or Messaging :) Atsushi Eno (2010/12/14 11:52), Travis Smith wrote: Miguel- I figured contributing to an area I work with would be easier. I was looking at WF or System.Messaging and was interested in finding out the status of those 'areas' to see what love they need. Failing that, I'm open to other suggestions that need more immediate love. -Travis On Mon, Dec 13, 2010 at 9:15 PM, Miguel de Icazamig...@novell.com wrote: Hello Travis, Most of the libraries graduate into regular Mono, and with it, most of the discussions. This is the new home of the discussion. Is there a particular area that you are interested in contributing to? On Mon, Dec 13, 2010 at 7:25 PM, Travis Smithtra...@legomaster.net wrote: I was looking at possible ways to provide value for mono, saw Olive on the site (http://mono-project.com/Olive). I went over to the mailing list but it's just filled with spam. Anyone know what the status of that is? Is the page just out of date? Thanks, -Travis ___ 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] Olive Status
Oh, ok. It is indeed outdated (it has been unchanged for 3 years). We indeed have stubs for WF4 in olive module since it is smaller than WF3 and easier, but right now the mono team has no plan to work on it. So it is left as contribution welcome area. https://github.com/mono/olive/tree/master/class/System.Activities IMO I don't think we should dare explicitly state that the wiki page is outdated on that page itself (since there are indeed some code that used to work and some people might want to continue hacking these old stuff). It could be done after someone actually started WF4 hacking as an alternative effort. Atsushi Eno (2010/12/14 12:07), Travis Smith wrote: http://mono-project.com/Workflow could use to be updated on the location of the mailing list then. What's the status of these sections? Are there portions that need love that I could look at digging into? Thanks, -Travis On Mon, Dec 13, 2010 at 10:00 PM, Atsushi Eno atsushi...@veritas-vos-liberabit.com wrote: The mono-olive mailing list was shut down to migrate to here (I posted about that as the last message there), so you are welcome here in the right place now to discuss WF or Messaging :) Atsushi Eno (2010/12/14 11:52), Travis Smith wrote: Miguel- I figured contributing to an area I work with would be easier. I was looking at WF or System.Messaging and was interested in finding out the status of those 'areas' to see what love they need. Failing that, I'm open to other suggestions that need more immediate love. -Travis On Mon, Dec 13, 2010 at 9:15 PM, Miguel de Icazamig...@novell.com wrote: Hello Travis, Most of the libraries graduate into regular Mono, and with it, most of the discussions. This is the new home of the discussion. Is there a particular area that you are interested in contributing to? On Mon, Dec 13, 2010 at 7:25 PM, Travis Smithtra...@legomaster.net wrote: I was looking at possible ways to provide value for mono, saw Olive on the site (http://mono-project.com/Olive). I went over to the mailing list but it's just filled with spam. Anyone know what the status of that is? Is the page just out of date? Thanks, -Travis ___ 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 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] DateTime Serialization
Well, date and time information can sure be locale independent, but NET's DateTime values aren't. It also contains DateTimeKind flag and ToBinary() adds that information within the 64 bit return value in addition to UTC time ticks. So, Karsten is right and that is indeed a good point. I'll visit bug #660424 tomorrow. Atsushi Eno (2010/12/19 4:19), CodeSlinger wrote: Just a thought - if using WCF, the client and server could be in different zones so why would you want anything other than UTC time to be passed around in the first place which is always what should be stored and only converted when displayed using the local conventions. The zone is not part of the datetime data but rather the machine. Dave ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WCF: netTcpBinding
Hi Karsten, (2010/12/22 5:44), Karsten Fourmont wrote: Hi, thanks to the quick fix for the Datetime serialisation issue (thank you Atsushi!), I'm getting closer to moving my WCF heavy project over to Mono. (Well the server side actually, client's WPF...) Thanks for the nice bug report :) But now I think I hit the biggest barrier: security netTcpBinding. Here are my requirements for the WCF communication: 1. I need a duplex service 2. A NATed/firewalled client must be able to initiate the connection. 3. secure session with username/password authentication. 4. Low overhead (performance message size) for big chunks of binary data So imho netTcpBinding (or even customBinding) is the way to go. In .NET s.th. like this works fine (server side config): netTcpBinding binding name=serverTcp security mode =TransportWithMessageCredential message clientCredentialType=UserName/ transport clientCredentialType=None/ /security /binding /netTcpBinding ... behavior name=serverBehaviour serviceCredentials serviceCertificate findValue=myCert storeLocation=LocalMachine storeName=My x509FindType=FindBySubjectName / userNameAuthentication userNamePasswordValidationMode=Custom customUserNamePasswordValidatorType=My.Validator, MyDll / /serviceCredentials /behavior The Security Mode is TransportWithMessageCredential as Transport encryption via ssl has a lower performance overhead (afaik) but for some MS only knows reason it doesn't offer Username credentials. So Message security is used for auth with a custom validator class. I didn't manage to get this config running on Mono: for starters I don't know how to let the server know about the certificate's private key which it needs for the ssl connection. I can provide the certificate by using Mono's certmgr, but this is only the public key part, suitable for the client. If I run it anyway I hit a NotImplementedException I have no idea on where you get the exception, but TcpTransport security support is not there yet. I guess it is documented in [MC-NMF] as SSL protocol upgrades though. So I fear even with the private key worked out, getting this kind of advanced configuration (or s.th. similar) up and running is not something that can be done with Mono right now. Or can it? Is there something I can do to help? One (slightly) better approach is to avoid configuration. It is extraneous stack to the actual code implementation for us and often left not-implemented. I'm not sure if we can spend time on implementing it in the near future. Any input and getting Mono WCF up to a configuration that meets the 4 requirments above as good as possible is highly welcome. Other options might be to go over Http Bindings and maybe do duplex by some clever polling. There's a interesting looking thing at http://code.msdn.microsoft.com/duplexhttp Indeed. I tried MoMA on it and found that most of the warnings are about missing configuration support. It might be worth trying. Our HTTP stack supports HTTP-based authentication and should work on https too, and should work with binary MessageEncoder. If the above resolves duplex requirement, then it's likely an answer. Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
