Re: [Mono-dev] Behavior change in XmlWriterSettings/XmlTextWriter
And that brings incompatiblity with .NET Core. That makes things just
worse. You cannot force other people to change their sanity just to
match your existing code that premises the wrong behavior that Microsoft
doesn't agree.
Atsushi Eno
On 2015年09月29日 14:58, Martin Thwaites wrote:
I'd have to agree with Martin here. The output of 2 functions should
surely match. The fact that the referencesource uses something that
defaults to something different per platform should be irrelevant.
The only point to consider is, should the output of a method be able to
differ per platform and still be valid. For this situation I imagine
that the xaml that is being produced is invalid, and therefore the
behaviour for the xaml writer is incorrect.
On 29 Sep 2015 05:55, "Atsushi Eno"
<atsushi...@veritas-vos-liberabit.com
<mailto:atsushi...@veritas-vos-liberabit.com>> wrote:
You have no reason to be afraid of asking Microsoft to change the
behavior. I cannot find any justification to just ask Mono to change
things against Microsoft code behavior without asking Microsoft
about it.
Atsushi Eno
On 2015年09月29日 01:15, Martin Potter wrote:
> I wasn’t aware that the MSDN .NET documentation was viewed as being
> platform specific documentation.
>
> I am not sure how this is a Microsoft bug so much as an issue
with the
> fact they did not consider it being run on other platforms. Given
that
> Mono is cross-platform, whereas Microsoft’s implementation is
not, and
> Mono has made other changes to the reference source (which is
very Windows
> specific) to provide consistency across platforms it is unclear
as to why
> the previous behavior of using \r\n (prior to the switch to the
reference
> source) is incorrect.
>
> ― Martin
>
> On 9/28/15, 9:58 AM, "Atsushi Eno"
<atsushi...@veritas-vos-liberabit.com
<mailto:atsushi...@veritas-vos-liberabit.com>>
> wrote:
>
>> MSDN documentation describes the behavior how .NET Framework
works on
>> Windows, hence it says \r\n. As the referencesource is explicitly
>> implemented, it is NOT the case on non-Windows platform.
>>
>> If you are unhappy about Microsoft behavior, you should file a
bug to
>> Microsoft. referencesource is not for reporting issues though
(as its
>> README explicitly says so).
>>
>> Atsushi Eno
>>
>> On 2015年09月28日 23:15, Martin Potter wrote:
>>> The default for XamlWriterSettings NewLineChars was changed
from "\r\n"
>>> to
>>> "\n" when you imported the reference source and is what is
present on
>>> the
>>> 4.2 branch. This is not what the previous behavior was, nor
what the
>>> documentation on MSDN,
>>>
>>>
https://msdn.microsoft.com/en-us/library/system.xml.xmlwritersettings.new
>>> li
>>> nechars(v=vs.110).aspx, states.
>>>
>>> "The character string to use for line breaks. This can be set
to any
>>> string value. However, to ensure valid XML, you should specify only
>>> valid
>>> white space characters, such as space characters, tabs, carriage
>>> returns,
>>> or line feeds. The default is \r\n (carriage return, new line)."
>>>
>>> ― Martin
>>>
>>> On 9/28/15, 8:08 AM, "Atsushi Eno"
>>> <atsushi...@veritas-vos-liberabit.com
<mailto:atsushi...@veritas-vos-liberabit.com>>
>>> wrote:
>>>
>>>> Current Microsoft-based implementation is the correct one and
it's been
>>>> there in post-4.0 versions.
>>>>
>>>> Atsushi Eno
>>>>
>>>> On 2015年09月28日 22:46, Martin Potter wrote:
>>>>> Atsushi,
>>>>>
>>>>> Were you (or someone else) going to get this fixed before 4.2
is ready
>>>>> to
>>>>> ship?
>>>>>
>>>>> Thank you,
>>>>> Martin
>>>>>
>>>>> On 9/8/15, 8:03 PM, "Atsushi Eno"
>>>>> <atsushi...@veritas-vos-liberabit.com
<mailto:atsushi...@veritas-vos-liberabit.com>>
>>>>> wrote:
>>>>>
>>>>>> I had no idea when that commit was made, but that change was
wrong.
>>>>>&
Re: [Mono-dev] Behavior change in XmlWriterSettings/XmlTextWriter
You have no reason to be afraid of asking Microsoft to change the behavior. I cannot find any justification to just ask Mono to change things against Microsoft code behavior without asking Microsoft about it. Atsushi Eno On 2015年09月29日 01:15, Martin Potter wrote: > I wasn’t aware that the MSDN .NET documentation was viewed as being > platform specific documentation. > > I am not sure how this is a Microsoft bug so much as an issue with the > fact they did not consider it being run on other platforms. Given that > Mono is cross-platform, whereas Microsoft’s implementation is not, and > Mono has made other changes to the reference source (which is very Windows > specific) to provide consistency across platforms it is unclear as to why > the previous behavior of using \r\n (prior to the switch to the reference > source) is incorrect. > > ― Martin > > On 9/28/15, 9:58 AM, "Atsushi Eno" <atsushi...@veritas-vos-liberabit.com> > wrote: > >> MSDN documentation describes the behavior how .NET Framework works on >> Windows, hence it says \r\n. As the referencesource is explicitly >> implemented, it is NOT the case on non-Windows platform. >> >> If you are unhappy about Microsoft behavior, you should file a bug to >> Microsoft. referencesource is not for reporting issues though (as its >> README explicitly says so). >> >> Atsushi Eno >> >> On 2015年09月28日 23:15, Martin Potter wrote: >>> The default for XamlWriterSettings NewLineChars was changed from "\r\n" >>> to >>> "\n" when you imported the reference source and is what is present on >>> the >>> 4.2 branch. This is not what the previous behavior was, nor what the >>> documentation on MSDN, >>> >>> https://msdn.microsoft.com/en-us/library/system.xml.xmlwritersettings.new >>> li >>> nechars(v=vs.110).aspx, states. >>> >>> "The character string to use for line breaks. This can be set to any >>> string value. However, to ensure valid XML, you should specify only >>> valid >>> white space characters, such as space characters, tabs, carriage >>> returns, >>> or line feeds. The default is \r\n (carriage return, new line)." >>> >>> ― Martin >>> >>> On 9/28/15, 8:08 AM, "Atsushi Eno" >>> <atsushi...@veritas-vos-liberabit.com> >>> wrote: >>> >>>> Current Microsoft-based implementation is the correct one and it's been >>>> there in post-4.0 versions. >>>> >>>> Atsushi Eno >>>> >>>> On 2015年09月28日 22:46, Martin Potter wrote: >>>>> Atsushi, >>>>> >>>>> Were you (or someone else) going to get this fixed before 4.2 is ready >>>>> to >>>>> ship? >>>>> >>>>> Thank you, >>>>> Martin >>>>> >>>>> On 9/8/15, 8:03 PM, "Atsushi Eno" >>>>> <atsushi...@veritas-vos-liberabit.com> >>>>> wrote: >>>>> >>>>>> I had no idea when that commit was made, but that change was wrong. >>>>>> Microsoft behavior is the one we should use in that case. >>>>>> >>>>>> Atsushi Eno >>>>>> >>>>>> On 2015年09月09日 01:50, Martin Potter wrote: >>>>>>> Way back in 2012, this commit >>>>>>> >>>>>>> >>>>>>> >>>>>>> https://github.com/mono/mono/commit/9215ddf7ade5f0f0f54c2adb7b165e4e3 >>>>>>> e7 >>>>>>> 74 >>>>>>> 33b >>>>>>> >>>>>>> >>>>>>> >>>>>>> <https://github.com/LogosBible/mono/commit/9215ddf7ade5f0f0f54c2adb7b >>>>>>> 16 >>>>>>> 5e >>>>>>> 4e3e77433b> changed >>>>>>> the default newline in XmlWriterSettings to be "\r\n” to be >>>>>>> compatible >>>>>>> with MS (which some of our tests rely on). It appears that when the >>>>>>> reference source was imported in >>>>>>> >>>>>>> >>>>>>> >>>>>>> https://github.com/mono/mono/commit/4990b4c47b8fe1b219c64884fad98d586 >>>>>>> 15 >>>>>>> 46 >>>>>>> a05#diff-5561e6ab8de20ec168dcb1f7b415b353, >>>>>>> it was changed back to be platform specific. Was this an intentional >>>>>>> change? >>>>>>> >>>>>>> Thank you, >>>>>>> Martin >>>>>>> >>>>>>> >>>>>>> >>>>>>> ___ >>>>>>> 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] Behavior change in XmlWriterSettings/XmlTextWriter
MSDN documentation describes the behavior how .NET Framework works on Windows, hence it says \r\n. As the referencesource is explicitly implemented, it is NOT the case on non-Windows platform. If you are unhappy about Microsoft behavior, you should file a bug to Microsoft. referencesource is not for reporting issues though (as its README explicitly says so). Atsushi Eno On 2015年09月28日 23:15, Martin Potter wrote: > The default for XamlWriterSettings NewLineChars was changed from "\r\n" to > "\n" when you imported the reference source and is what is present on the > 4.2 branch. This is not what the previous behavior was, nor what the > documentation on MSDN, > https://msdn.microsoft.com/en-us/library/system.xml.xmlwritersettings.newli > nechars(v=vs.110).aspx, states. > > "The character string to use for line breaks. This can be set to any > string value. However, to ensure valid XML, you should specify only valid > white space characters, such as space characters, tabs, carriage returns, > or line feeds. The default is \r\n (carriage return, new line)." > > ― Martin > > On 9/28/15, 8:08 AM, "Atsushi Eno" <atsushi...@veritas-vos-liberabit.com> > wrote: > >> Current Microsoft-based implementation is the correct one and it's been >> there in post-4.0 versions. >> >> Atsushi Eno >> >> On 2015年09月28日 22:46, Martin Potter wrote: >>> Atsushi, >>> >>> Were you (or someone else) going to get this fixed before 4.2 is ready >>> to >>> ship? >>> >>> Thank you, >>> Martin >>> >>> On 9/8/15, 8:03 PM, "Atsushi Eno" <atsushi...@veritas-vos-liberabit.com> >>> wrote: >>> >>>> I had no idea when that commit was made, but that change was wrong. >>>> Microsoft behavior is the one we should use in that case. >>>> >>>> Atsushi Eno >>>> >>>> On 2015年09月09日 01:50, Martin Potter wrote: >>>>> Way back in 2012, this commit >>>>> >>>>> >>>>> https://github.com/mono/mono/commit/9215ddf7ade5f0f0f54c2adb7b165e4e3e7 >>>>> 74 >>>>> 33b >>>>> >>>>> >>>>> <https://github.com/LogosBible/mono/commit/9215ddf7ade5f0f0f54c2adb7b16 >>>>> 5e >>>>> 4e3e77433b> changed >>>>> the default newline in XmlWriterSettings to be "\r\n” to be compatible >>>>> with MS (which some of our tests rely on). It appears that when the >>>>> reference source was imported in >>>>> >>>>> >>>>> https://github.com/mono/mono/commit/4990b4c47b8fe1b219c64884fad98d58615 >>>>> 46 >>>>> a05#diff-5561e6ab8de20ec168dcb1f7b415b353, >>>>> it was changed back to be platform specific. Was this an intentional >>>>> change? >>>>> >>>>> Thank you, >>>>> Martin >>>>> >>>>> >>>>> >>>>> ___ >>>>> 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] Behavior change in XmlWriterSettings/XmlTextWriter
Current Microsoft-based implementation is the correct one and it's been there in post-4.0 versions. Atsushi Eno On 2015年09月28日 22:46, Martin Potter wrote: > Atsushi, > > Were you (or someone else) going to get this fixed before 4.2 is ready to > ship? > > Thank you, > Martin > > On 9/8/15, 8:03 PM, "Atsushi Eno" <atsushi...@veritas-vos-liberabit.com> > wrote: > >> I had no idea when that commit was made, but that change was wrong. >> Microsoft behavior is the one we should use in that case. >> >> Atsushi Eno >> >> On 2015年09月09日 01:50, Martin Potter wrote: >>> Way back in 2012, this commit >>> >>> https://github.com/mono/mono/commit/9215ddf7ade5f0f0f54c2adb7b165e4e3e774 >>> 33b >>> >>> <https://github.com/LogosBible/mono/commit/9215ddf7ade5f0f0f54c2adb7b165e >>> 4e3e77433b> changed >>> the default newline in XmlWriterSettings to be "\r\n” to be compatible >>> with MS (which some of our tests rely on). It appears that when the >>> reference source was imported in >>> >>> https://github.com/mono/mono/commit/4990b4c47b8fe1b219c64884fad98d5861546 >>> a05#diff-5561e6ab8de20ec168dcb1f7b415b353, >>> it was changed back to be platform specific. Was this an intentional >>> change? >>> >>> Thank you, >>> Martin >>> >>> >>> >>> ___ >>> 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] Behavior change in XmlWriterSettings/XmlTextWriter
I had no idea when that commit was made, but that change was wrong. Microsoft behavior is the one we should use in that case. Atsushi Eno On 2015年09月09日 01:50, Martin Potter wrote: Way back in 2012, this commit https://github.com/mono/mono/commit/9215ddf7ade5f0f0f54c2adb7b165e4e3e77433b <https://github.com/LogosBible/mono/commit/9215ddf7ade5f0f0f54c2adb7b165e4e3e77433b> changed the default newline in XmlWriterSettings to be "\r\n” to be compatible with MS (which some of our tests rely on). It appears that when the reference source was imported in https://github.com/mono/mono/commit/4990b4c47b8fe1b219c64884fad98d5861546a05#diff-5561e6ab8de20ec168dcb1f7b415b353, it was changed back to be platform specific. Was this an intentional change? Thank you, Martin ___ 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] Running .NET on (OpenSUSE) Linux (13.2) still crashes with thread overload...
I have no idea what kind of issue you are talking about, but anyways mono 3.8.0 is too old. Try newer versions. There should be even packaged ones: https://build.opensuse.org/search?utf8=%E2%9C%93_text=mono=Submit+Query_tracker=bnc==0=1=0=1=0=1=0=0_type_id= Atsushi Eno On 2015年09月02日 02:45, André Verwijs wrote: OS: Linux 3.16.7-24-desktop - openSUSE 13.2 (Harlequin) (x86_64) KDE 4.14.9 Mono version 3.8.0 (tarball Fri Oct 10 15:00:11 UTC 2014) when running Windows .NET code on (OpenSUSE)Linux (13.2) still crashes with thread overload. tips on fixes or performance settings are welcome view stacktrace online here: https://drive.google.com/file/d/0B4_TSVggahj8MDFOMVR1V2dUc3M/view?usp=drivesdk ___ 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 4.0.0 xbuild won't build project
Wait, you are building mono _on_ Android? I don't think mono supports
custom Android build. Things WON'T work and it is quite as expected.
That's not a bug at all.
We Xamarin don't even use full mono stack. xbuild is totally out of
mobile scope.
Atsushi Eno
On 2015年06月06日 00:26, Cyd Haselton wrote:
Additionally there's this
csharp System.DateTime.Now
System.TimeZoneNotFoundException: Exception of type
'System.TimeZoneNotFoundException' was thrown.
at System.TimeZoneInfo.get_Local () [0x0] in filename unknown:0
at System.TimeZoneInfo.GetDateTimeNowUtcOffsetFromUtc (DateTime time,
System.Boolean isAmbiguousLocalDst) [0x0] in filename unknown:0
at System.DateTime.get_Now () [0x0] in filename unknown:0
at InteractiveExpressionClass.Host (System.Object $retval) [0x0]
in filename unknown:0
at Mono.CSharp.Evaluator.Evaluate (System.String input, System.Object
result, System.Boolean result_set) [0x0] in filename unknown:0
at Mono.CSharpShell.Evaluate (System.String input) [0x0] in
filename unknown:0
Android's native support for locale is notoriously broken. I used
-DNO-LOCALE when building mono, hoping that it would be taken into account
On June 5, 2015 10:16:34 AM CDT, Alexander Köplinger
alex.koeplin...@outlook.com wrote:
It's just a simple helloworld as well, but with datetime output:
using System;
namespace HelloWorld {
public class Program {
public static void Main(string[] args) {
Console.WriteLine(Hello World + DateTime.Now);
}
}
}
If this doesn't work, then there's no point trying to get xbuild
working as the code above is as basic as it gets.
-- Alex
Subject: RE: [Mono-dev] mono 4.0.0 xbuild won't build project
From: chasel...@gmail.com
Date: Fri, 5 Jun 2015 09:43:07 -0500
To: alex.koeplin...@outlook.com; mono-devel-list@lists.ximian.com
Unfortunately the latest build...with ncurses this time...didn't
change anything. Same output for xbuild.
Alexander, could you send the code for the Project.exe you sent me?
On June 5, 2015 3:25:42 AM CDT, Alexander Köplinger
alex.koeplin...@outlook.com wrote:
Can you try this simple Hello World exe to confirm basic Mono is
working and it's something specific to xbuild:
https://dl.dropboxusercontent.com/u/21102229/Program.zip (it
just prints the current date).
I believe there's some terminal requirements, but not sure.
Redirecting output to a file might work.
From: chasel...@gmail.com
Date: Thu, 4 Jun 2015 19:56:01 -0500
To: sushihango...@outlook.com; mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] mono 4.0.0 xbuild won't build project
I tried it just now and I get the same result as before,
unfortunately.
Is there a terminfo/ncurses requirement for xbuild? Or for mono
in general? The rebuild I mentioned earlier was done in order to
make sure -lncurses and all related headers and libs were
included but it's possible I left something out and need to
re-build again.
Additionally, is there a terminal tyoe requirement for xbuild?
The android environment i'm using only comes with two types but
I;ve got a working tic and sources so I can always install more.
On June 4, 2015 6:51:00 PM CDT, Robert N
sushihango...@outlook.com wrote:
I realized that my other mail was hosed, outlook in a
browser does blow at times...
So I was wondering if you were able to run xbuild using the
mono option -v, since xbuild /verbosity:diagnostic never
spills even the first line of the diag text: Loading default
tasks for ToolsVersion
Using mono_options -v 'should' dump about 6500 lines before
even getting to the version/copyright notice... assuming
something in there is causing a silent fault(?) and exit.
Win81Pro:Pash administrator$ MONO_OPTIONS=-v xbuild
Pash.proj |more
converting method System.OutOfMemoryException:.ctor (string)
Method System.OutOfMemoryException:.ctor (string) emitted at
0x4f7d20 to 0x4f7d44 (code length 36) [xbuild.exe]
converting method (wrapper runtime-invoke)
Module:runtime_invoke_void__this___object
(object,intptr,intptr,intptr)
Method (wrapper runtime-invoke)
Module:runtime_invoke_void__this___object
(object,intptr,intptr,intptr) emitted at 0x4f7d60 to
0x4f7e38 (code length 216) [xbuild.exe]
converting method System.SystemException:.ctor (string)
Method System.SystemException
Re: [Mono-dev] mono 4.0.0 xbuild won't build project
I tried xbuild from mono master as well as mono 3.2.8, and it *did* complain about the syntax error you made. The output from master is: - atsushi:~/Desktop$ xbuild x.proj XBuild Engine Version 12.0 Mono, Version 4.3.0.0 Copyright (C) 2005-2013 Various Mono authors Build started 6/5/2015 2:08:48 AM. __ x.proj: error : /home/atsushi/Desktop/x.proj: Name cannot begin with the ' ' character, hexadecimal value 0x20. Line 1, position 2. Build FAILED. Errors: x.proj: error : /home/atsushi/Desktop/x.proj: Name cannot begin with the ' ' character, hexadecimal value 0x20. Line 1, position 2. 0 Warning(s) 1 Error(s) Time Elapsed 00:00:00.0105090 - Once I fixed the extraneous space between '' and Project, it printed Hello world as expected: atsushi:~/Desktop$ /usr/bin/xbuild x.proj XBuild Engine Version 12.0 Mono, Version 3.2.8.0 Copyright (C) 2005-2013 Various Mono authors Build started 6/5/2015 2:11:17 AM. __ Project /home/atsushi/Desktop/x.proj (default target(s)): Target Build: Hello, World! Done building project /home/atsushi/Desktop/x.proj. Build succeeded. 0 Warning(s) 0 Error(s) Time Elapsed 00:00:00.0708910 A precise repro steps would help inspecting possible bugs. Atsushi Eno On 2015年06月03日 19:31, Cyd Haselton wrote: Thing is xbuild doesn't even complain about the syntax errors in that project. It doesn't do anything except for output version info then exit. I'll pastebin the file ifthe rebuild I;m working on doesn;t resolve the issue. Thanks! On June 3, 2015 6:18:11 AM CDT, Alan alan.mcgov...@gmail.com wrote: Can you use a pastebin to attach the actual file you're trying to build? The text you attached has two syntax errors in it and would not work as-is. A slightly modified file works as expected for me: https://gist.github.com/alanmcgovern/c2772a9cafd0d6a5b5ee Hope that helps! Alan On 3 June 2015 at 11:54, Cyd Haselton chasel...@gmail.com mailto:chasel...@gmail.com wrote: I did try xbuild /t:Build Pash.proj. Same result. I will try the --trace xbuild after I rebuild mono again. On June 3, 2015 3:18:34 AM CDT, Alan alan.mcgov...@gmail.com mailto:alan.mcgov...@gmail.com wrote: You didn't tell xbuild to build anything and you didn't set a default target in your proj file. Try `xbuild /t:Build Pash.proj` On 2 June 2015 at 23:29, Alexander Köplinger alex.koeplin...@outlook.com mailto:alex.koeplin...@outlook.com wrote: Yeah, but it's much easier on another machine since we got the official packages for Mono there :) Try running xbuild with MONO_OPTIONS=--trace xbuild to show if/what it does before it exits. Subject: RE: [Mono-dev] mono 4.0.0 xbuild won't build project From: chasel...@gmail.com mailto:chasel...@gmail.com Date: Tue, 2 Jun 2015 17:15:14 -0500 To: alex.koeplin...@outlook.com mailto:alex.koeplin...@outlook.com; mono-devel-list@lists.ximian.com mailto:mono-devel-list@lists.ximian.com Excellent point. Then again...i'd have to install mono on another machine. Also, I kinda would like to figure out why xbuild is misbehaving on this one... On June 2, 2015 5:04:07 PM CDT, Alexander Köplinger alex.koeplin...@outlook.com mailto:alex.koeplin...@outlook.com wrote: No idea about the xbuild issue, but you should be able to build Pash on another machine and just copy over the .exe, it is managed code after all ;) From: chasel...@gmail.com mailto:chasel...@gmail.com Date: Tue, 2 Jun 2015 16:54:19 -0500 To: mono-devel-list@lists.ximian.com mailto:mono-devel-list@lists.ximian.com Subject: [Mono-dev] mono 4.0.0 xbuild won't build project Just built and installed mono 4.0 from sources. Basic Hello World console program builds and runs successfully but basic Hello World project (hello.proj) won't build; xbuild displays the banner and then exits with no errors and without building the project. Here's the hello.proj Project xmlns=http
Re: [Mono-dev] MDAC missing error on CentOS
Hello, I disabled the version check for MDAC on mono master. Could you check if it works now? Thanks, Atsushi Eno On 2015年05月09日 15:03, Atsushi Eno wrote: Hello, It seems that referencesource Odbc implementation has extra check [*1] that does not match unixodbc behavior. I will disable those checks next week. [*1] https://github.com/mono/referencesource/blob/mono/System.Data/System/Data/Odbc/OdbcEnvironment.cs#L25 Atsushi Eno On 2015年05月08日 01:33, knd775 wrote: I have an application that uses the OdbcConnection class. When I try to open the connection with .Open() I receive the following error: The .Net Framework Data Providers require Microsoft Data Access Components(MDAC). Please install Microsoft Data Access Components(MDAC) version 2.6 or later. I have tried up to the latest commit (currently 251ee4c04e955b8d21453dbf08315ea9914eff80) and still have this same issue. This did not happen on release 4.0.1. This is on CentOS 6.5. -- View this message in context: http://mono.1490590.n4.nabble.com/MDAC-missing-error-on-CentOS-tp4665876.html Sent from the Mono - Dev mailing list archive at Nabble.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] MDAC missing error on CentOS
Hello, It seems that referencesource Odbc implementation has extra check [*1] that does not match unixodbc behavior. I will disable those checks next week. [*1] https://github.com/mono/referencesource/blob/mono/System.Data/System/Data/Odbc/OdbcEnvironment.cs#L25 Atsushi Eno On 2015年05月08日 01:33, knd775 wrote: I have an application that uses the OdbcConnection class. When I try to open the connection with .Open() I receive the following error: The .Net Framework Data Providers require Microsoft Data Access Components(MDAC). Please install Microsoft Data Access Components(MDAC) version 2.6 or later. I have tried up to the latest commit (currently 251ee4c04e955b8d21453dbf08315ea9914eff80) and still have this same issue. This did not happen on release 4.0.1. This is on CentOS 6.5. -- View this message in context: http://mono.1490590.n4.nabble.com/MDAC-missing-error-on-CentOS-tp4665876.html Sent from the Mono - Dev mailing list archive at Nabble.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] ReferenceSource of System.Text.UnicodeEncoding breaks System.Data.Odbc.OdbcDataReader.GetColumn(int)
On 2015年05月05日 01:29, Marek Safar wrote: Hi, We use the attached patch for Mono 4.0.1 which changes the implementation of System.Data.Odbc.OdbcDataReader.GetColumn(int) to make it work with either implementation of System.Text.UnicodeEncoding.GetString. Could you please send a pull request with the change? Does it make sense to bring in patches like this or will System.Data.Odbc be replaced by ReferenceSource in the (near) future? That's not very likely, reference sources code has quite few hard windows dependencies and I don't think we'll replace it or at least not very soon. Usually that's correct, but for System.Data.Odbc we use unixodbc that PInvokes odbc32.dll compatible library. We already imported it. 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] Endian Question
I believe that the serialized bytes should not depend on the CPU
architecture that ran the program.
UnicodeEncoding (which means UTF-16) has endianness information (i.e.
UTF-16LE vs. UTF-16BE) which is specified at constructor or
Unicode/BigEndianUnicode differencein Encoding static properties.
So probably those classes generates bytes in some unexpected order?
Though some of those crypto stuff is regressing (regardless of CPU arch)
in recent referencesource porting, so that problem might just be temporary.
Atsushi Eno
On 2015年04月29日 03:40, Neale Ferguson wrote:
The following test fails on s390x as the string that is encoded from the
decrypted block ends is in little endian order:
public void FullRoundtripRead ()
{
byte[] encrypted;
using (DebugStream mem1 = new DebugStream ()) {
byte[] toEncrypt =
Encoding.Unicode.GetBytes (Please encode me!);
using (CryptoStream crypt = new
CryptoStream (mem1, aes.CreateEncryptor (), CryptoStreamMode.Write)) {
crypt.Write (toEncrypt, 0,
toEncrypt.Length);
crypt.FlushFinalBlock ();
}
encrypted = mem1.ToArray ();
}
using (DebugStream mem2 = new DebugStream
(encrypted)) {
byte[] buffer = new byte [1024];
CryptoStream cr = new CryptoStream (mem2,
aes.CreateDecryptor (), CryptoStreamMode.Read);
int len = cr.Read (buffer, 0,
buffer.Length);
cr.Close ();
Assert.AreEqual (34, len, Full Length
Read);
Assert.AreEqual (Please encode me!,
Encoding.Unicode.GetString (buffer, 0, len), Full Block Read);
}
}
The question is at what point should byte swapping be performed? Should
all Encoding.Unicode.GetBytes(string) do the swap to little ending and
Encoding.Unicode.GetString(bytes) do the reverse?
Neale
___
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] ODBC GetSchema failing
If you haven't, you might want to try the latest mono master which
replaced System.Data implementation with Microsoft's referencesource.
System.Data.Odbc implementation depends on native ODBC, and on
non-Windows platform it relies on libodbc which might bring
implementation glitch. That applies to any of mono versions (even with
referencesource).
Atsushi Eno
On 2015年04月28日 11:16, discofire wrote:
Ok, so it looks as though there is a problem with the System.Data.Odbc
library... a pretty major and glaring problem that I can't believe was even
allowed to be checked into the repository.
Here is the code for the GetSchema calls:
public override DataTable GetSchema ()
{
if (State == ConnectionState.Closed)
throw ExceptionHelper.ConnectionClosed ();
return MetaDataCollections.Instance;
}
public override DataTable GetSchema (string collectionName)
{
return GetSchema (collectionName, null);
}
public override DataTable GetSchema (string collectionName,
string []
restrictionValues)
{
if (State == ConnectionState.Closed)
throw ExceptionHelper.ConnectionClosed ();
return GetSchema (collectionName, null);
}
Seems pretty obvious to me that GetSchema(string, string[]) is designed
specifically to blow up memory until the VM decides to stop it. It would
have been more useful if it just threw a not implemented exception and not
actually pretend to do something... It would have been even more useful if
any of the resources associated with this library would have even indicated
in the slightest that these functions not only do nothing, they actually
kill your call stack. Maybe they were testing the StackOverflowException?
Does anyone know how to go about fixing this? Is there any way to either
contribute to the project, or contact someone who is contributing? Also,
does anyone know how to find the dev that checked in this crap so I can
punch him in the throat? :)
--
View this message in context:
http://mono.1490590.n4.nabble.com/ODBC-GetSchema-failing-tp4665832p4665833.html
Sent from the Mono - Dev mailing list archive at Nabble.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] WCF WebServiceHost crashes mono if client disconnects early
There is no test, so I don't know if it's good. Atsushi Eno On 2015年02月22日 03:32, Alexander Grep wrote: Hello, Miguel, thanks for implementing the fix! Sorry to bother you once more: I'd be grateful if you could also have a look at https://bugzilla.xamarin.com/show_bug.cgi?id=20764 While it's not a crashing bug, it causes any OperationContract with a return type of void to return status code 500 Internal Server Error, which can cause undesirable effects in client applications. The proposed patch would work, though I'm not sure if it's the right way to do it. Are you looking into this? Thanks for the great project, you're doing very important work. Alex ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WCF WebServiceHost crashes mono if client disconnects early
Console output for debugging is done in very limited, IIRC in only one or two [*1] locations and not supposed to be done everywhere. They should be actually replaced by something like WCF logging feature that can be enabled by some configuration. IIRC it partly works. Nothing will be logged by default and people won't notice they can log things though. Atsushi Eno On 2015年02月15日 22:38, Miguel de Icaza wrote: Hello, [ I am CCing Atsushi so he can eyeball the patch ] Thanks for the background research and for pointing me to that long-standing bug. It seems like a pull request was created, but that the author closed the pull request. I have updated the patch, can you try this and report back? https://gist.github.com/migueldeicaza/01aaf064b1bf626f8cc0 Atsushi, does the above look correct? And is Console.WriteLine the right thing to do there, or should we use some other mechanism? Miguel On Sat, Feb 14, 2015 at 6:24 PM, Horst Müller alexhg...@gmail.com mailto:alexhg...@gmail.com wrote: Greetings! I've stumbled upon what I believe to be a rather serious problem in mono's WCF implementation. When a client disconnects during a transmission from a WebServiceHost, an exception is thrown: Exception Write failure at System.Net.Sockets.NetworkStream.Write (System.Byte[] buffer, Int32 offset, Int32 size) [0x0008e] in /build/mono/src/mono-3.12.0/mcs/class/System/System.Net.Sockets/NetworkStream.cs:418 at System.Net.ResponseStream.InternalWrite (System.Byte[] buffer, Int32 offset, Int32 count) [0x00029] in /build/mono/src/mono-3.12.0/mcs/class/System/System.Net/ResponseStream.cs:132 at System.Net.ResponseStream.Write (System.Byte[] buffer, Int32 offset, Int32 count) [0x000dd] in /build/mono/src/mono-3.12.0/mcs/class/System/System.Net/ResponseStream.cs:165 at System.ServiceModel.Channels.Http.HttpRequestContext.InternalReply (System.ServiceModel.Channels.Message msg, TimeSpan timeout) [0x00157] in /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpRequestContext.cs:160 at System.ServiceModel.Channels.Http.HttpRequestContext.Reply (System.ServiceModel.Channels.Message msg, TimeSpan timeout) [0x0] in /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Channels.Http/HttpRequestContext.cs:101 at System.ServiceModel.Dispatcher.MessageProcessingContext.Reply (Boolean useTimeout) [0x00026] in /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/MessageProcessingContext.cs:96 at System.ServiceModel.Dispatcher.OperationInvokerHandler.Reply (System.ServiceModel.Dispatcher.MessageProcessingContext mrc, Boolean useTimeout) [0x0001d] in /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/OperationInvokerHandler.cs:69 at System.ServiceModel.Dispatcher.OperationInvokerHandler.ProcessRequest (System.ServiceModel.Dispatcher.MessageProcessingContext mrc) [0x00044] in /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/OperationInvokerHandler.cs:29 at System.ServiceModel.Dispatcher.BaseRequestProcessorHandler.ProcessRequestChain (System.ServiceModel.Dispatcher.MessageProcessingContext mrc) [0x0] in /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseRequestProcessorHandler.cs:15 at System.ServiceModel.Dispatcher.BaseRequestProcessorHandler.ProcessRequestChain (System.ServiceModel.Dispatcher.MessageProcessingContext mrc) [0x00017] in /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseRequestProcessorHandler.cs:16 at System.ServiceModel.Dispatcher.HandlersChain.ProcessRequestChain (System.ServiceModel.Dispatcher.MessageProcessingContext mrc) [0xb] in /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseRequestProcessor.cs:72 at System.ServiceModel.Dispatcher.BaseRequestProcessor.ProcessRequest (System.ServiceModel.Dispatcher.MessageProcessingContext mrc) [0x00018] in /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/BaseRequestProcessor.cs:26 This exception gets caught and rethrown until it ends up at /build/mono/src/mono-3.12.0/mcs/class/System.ServiceModel/System.ServiceModel.Dispatcher/ChannelDispatcher.cs:596, where ProcessErrorWithHandlers returns false and we reply to the RequestContext with an error message. This then generates a second
Re: [Mono-dev] Custom messaging provider doesn't seem to work
Not really; changes that make it to load other assemblies are also good (but _if_ that's too much, then it'd be still okay to hard code others). Atsushi Eno On 2015年01月28日 08:51, Philip Garrett wrote: On Jan 27, 2015, at 3:22 AM, Atsushi Eno atsushi...@veritas-vos-liberabit.com mailto:atsushi...@veritas-vos-liberabit.com wrote: Hard-coded, run-time resolution to assemblies that don't exist in mono itself would be fine Are you saying that _only_ hard-coded resolution is acceptable? My intent was to allow the user to specify any type that can be resolved using an assembly-qualified name (via Type.GetType(string)). - Philip ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Custom messaging provider doesn't seem to work
Hi, It is not intended to limit to rabbitmq. Patches are welcome to make it to work with other providers :-) It just shouldn't be too extensive to add another MQ binding or implementation in mono repo either as sources or submodule. Hard-coded, run-time resolution to assemblies that don't exist in mono itself would be fine (as long as it works, when those assemblies can be resolved). Thanks, Atsushi Eno On 2015年01月25日 06:40, Philip Garrett wrote: Mono.Messaging allows you to specify a custom messaging provider in the MONO_MESSAGING_PROVIDER appsetting. But it appears only to work with the RabbitMQ provider that’s packaged with Mono. Any value other than the pre-approved provider class name (or its alias) makes MessagingProviderLocator throw an exception in the static constructor. (1) Is this intentional or is it a bug/missing feature? Would a patch to allow any custom IMessagingProvider be welcomed? Thanks, Philip (1) https://github.com/mono/mono/blob/effa4c07ba850bedbe1ff54b2a5df281c058ebcb/mcs/class/Mono.Messaging/Mono.Messaging/MessagingProviderLocator.cs#L90 ___ 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] After an initial investigation of porting WCF to mono, this is what I've found so far
Note that WCF assemblies would depend on System.Xml internals because MS System.Xml.dll has [InternalsVisibeTo (System.ServiceModel, ...)] etc. So without finishing System.Xml porting, WCF-only port would not work as expected. Though the porting does not have to be perfect until we land everything in mono master, so your effort is welcome :-) I had been working on porting System.Xml but we have handful of issues to sort out (as it must not depend on code generator for iOS and MS XmlSerializer, unlike ours, is totally based on that). Atsushi Eno On 2014年12月17日 05:35, Bernie Schoch wrote: References to XAML configuration #if XAML out References to COM #if COM out There are references to Transaction processing in Microsoft namespace is this something we need to support or #if it out? There is a ton of stuff missing from System.IdentityModel: This is where the majority of the errors lie. 100+ items; Should I just back port this into existing Mono code or use reference source versions? I ask because I don't have much history on mono project and don't really know status of System.IdentiyModel. What is the strategy to deal with SR messages? Right now I've just created an internal SR and InternalsSR class Thanks, Bernie Schoch ___ 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] List of cleanup candidates for Mono 4.0
Hello, On 2014年11月28日 02:19, Alexander Köplinger wrote: Hey, * gmcs/dmcs - they just redirect to mcs now and without the 2.0 etc profiles it doesn't make sense to still have them I like to keep them, to avoid breaking third party build scripts. Good point, however aren't they gonna break anyway when they rely on 2.0 SDK which is no longer there anymore? Maybe now is the time to make people aware they should update the scripts :) * aspnetwebstack (i.e. MVC+WebApi) - same reasons as for EF, open-source and on NuGet, should be used from there I am actually not sure about this one, is that really the case? The latest XamarinStudio/MonoDevelop MVC template installs it from NuGet, so I think it should be fine to remove. It might not work perfectly until the System.Web from referencesource is integrated, but the same applies to the existing (outdated) copy we ship currently. * Rx - I'm not really familiar with this one, but I think it's also on NuGet+open source This one I know contains patches that make it work on Mono. Without these, they wont work. So this might have to wait. Interesting. I had a look at the NuGet package and it ships a portable-net45 version, I always thought this was compatible with Mono? If not, we could maybe look at upstreaming the patches. Basically I agree that we could remove Rx. Yet some works need to be done. Rx imports can be taken in two different parts: desktop and mobile. For desktop, there is no difference (or almost no difference) in the sources. There could be some not-implemented paths in the dependencies, but IIRC I didn't #ifdef-ed out anything for that. For mobiles there are many changes to build and run. - Rx solution/project structure is quite complicated (most likely manually edited) to share several MSBuild targets fragments, as well as using some features that we don't (or maybe didn't) support. So we generate different project files for mobiles, from within mcs/class. (The same xbuild problem applies to desktop, but within mono we build from dll.sources and our own Makefiles just like other assemblies. And for NuGet packages we wouldn't worry about that anyways.) - We use NUnit for tests. Fortunately Rx tests use MSTest which were mostly compatible with NUnit syntax, we reuse that. Yet we needed several changes to the sources (e.g. using NUnit.Framework;). - And the changes are not committed but rather patched at build time (mcs/class/* has some C# script for that). - To make it build, we had to disable some parts by adding #if-s for iOS and Android, which are only for Xamarin. - I'm actually quite unsure how much of the existing Observables work fine on iOS (due to AOT limitation). For Android it worked almost perfectly. The resulting diffs were already too much at that state, so I didn't send them back to the original project. (For example, new tests could easily miss #if MONO use NUnit.Framework; and it won't just build.) Some changes would make sense to send back. IIRC there were some code paths that depend on WinRT or WPF that always exist on MS platforms but not on mono, and I #ifdef-ed out. All those changes are in rx-oss-v2.2 branch in mono/rx so that anyone can review. Anyways, basically we need patched version for mobiles. And some of those reside in mono tree, so before nuking them out they have to be rewritten to become independent of mono tree. Atsushi Eno -- Alex ___ 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] List of cleanup candidates for Mono 4.0
Let's remove my Commons.Xml.Relaxng. It is really isolated work. Atsushi Eno On 2014年11月28日 00:01, Alexander Köplinger wrote: Judging from the recent version bump in git to 3.99 it looks like the next release after 3.12 will be Mono 4.0. As this is a major release it'll allow us to remove some cruft that is no longer needed, so I thought I'd start a list of things I'd like to see removed: * net2.0/4.0 profiles - this is already in progress * gmcs/dmcs - they just redirect to mcs now and without the 2.0 etc profiles it doesn't make sense to still have them * EntityFramework - apart from the fact that we ship a horribly outdated version right now, I see no reason to include this hefty 5+MB DLL in Mono given that EF is open-source and available on NuGet * aspnetwebstack (i.e. MVC+WebApi) - same reasons as for EF, open-source and on NuGet, should be used from there * Rx - I'm not really familiar with this one, but I think it's also on NuGet+open source I'd love to hear your comments/thoughts on this :) -- Alex ___ 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 .Net difference - handling xs:extension please help
Actually the mono runtime team at Xamarin seems to be working on it, so you should ask them, not me. But anyways current System.Xml code in referencesource is still incomplete to actually replace things. It will be done only after Microsoft's open-sourcing process is done. Atsushi Eno On 2014年11月15日 19:37, MarLOne wrote: Hello Atsushi Eno, When will Mono be replacing its library with the MS's contribution? MarL -- View this message in context: http://mono.1490590.n4.nabble.com/Mono-Net-difference-handling-xs-extension-please-help-tp4664552p4664621.html Sent from the Mono - Dev mailing list archive at Nabble.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] Mono .Net difference - handling xs:extension please help
Hello,
If you believe xs:complexType/xs:extension is that superficial, could
you explain why the validation result is wrong?
Dealing with xs:complexType is one of the most complicated XML schema
validation technology, which involved handful of ambiguity, which may be
fixed in later specifications, after we have implemented this feature
mostly in 2003-2004.
Atsushi Eno
On 2014年11月12日 15:15, MarLOne wrote:
Hello,
Not sure if this issue has been raised as it is driving me nuts as another
Mono/.Net runtime behavior differences.
I have a xml schema called FamilyTree2.xsd FamilyTree2.xsd
http://mono.1490590.n4.nabble.com/file/n4664552/FamilyTree2.xsd . This
has been validate in Eclipse's Xsd Editor.
Then I have an instance document created using this schema and is called
FamilyTree2SimplePerson.xml FamilyTree2SimplePerson.xml
http://mono.1490590.n4.nabble.com/file/n4664552/FamilyTree2SimplePerson.xml
I then use xsd.exe in Mono runtime 2.10.8.1 to generate a C# class from the
schema. I then use the following code to deserialize the instance document
into an person object:
[Test]
public void TestSimplePerson ()
{
const String testFile = FamilyTree2SimplePerson.xml;
String fileName = Path.Combine( Constants.DataFilesDirectory,
testFile );
Assert.IsTrue( File.Exists( fileName ) );
LMar.Demo.person p = null;
using( Stream input = File.OpenRead( fileName ) )
{
XmlReaderSettings rs = new XmlReaderSettings();
rs.Schemas = new XmlSchemaSet();
rs.Schemas.Add( SchemaLoaders.FamilyTree2 );
rs.ValidationType = ValidationType.Schema;
using( XmlReader reader = XmlReader.Create( input, rs ) )
{
XmlSerializer ser = new XmlSerializer( typeof(
LMar.Demo.person ) );
p = ser.Deserialize( reader ) as LMar.Demo.person; //
XmlSchemaValiationException
Assert.IsNotNull( p );
}
}
The schema is embedded into the assembly as embedded resource,
The exception message is as follows:
System.Xml.Schema.XmlSchemaValiationException: XmlSchema error: Attribute
declaration was not found for name XML Line 6, Position 12.
person is the base class of spouse which uses the xs:extension to define it
in the schema. This error message points to the name for the spouse object.
I believe this is a Mono MS .Net incompatibility runtime error for the
following reasons:
1) The instance document has been validated by Eclipse xsd/xml editor as
well as online validator. In fact the instance document was created by
Eclipse xml editor.
2) The same code ( the xsd generated code produced in .Net and Mono appear
to be the same) shown above runs without error in MS .Net and retrieving all
the values.
Has anyone discovered this error? It is a simple usage of xs:extension, a
very commonly used construct and should not cause any incompatibility.
It is so disheartening to see superficial compatibility while beneath the
surface so much differences. Is there a site that lists this kind of runtime
incompatibility for people wanting to use Mono as serious tool? Every time I
push Mono, I end up in a hole like this as I have encountered time and time
again incompatibilities.
Is there some quirky flags in the XmlReaderSettings to get this going in
Mono?
Thanks.
MarL
--
View this message in context:
http://mono.1490590.n4.nabble.com/Mono-Net-difference-handling-xs-extension-please-help-tp4664552.html
Sent from the Mono - Dev mailing list archive at Nabble.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] Mono .Net difference - handling xs:extension please help
Actually I was wrong, it's already there:
https://github.com/Microsoft/referencesource/tree/master/System.Xml/System/Xml/Schema
Atsushi Eno
On 2014年11月13日 00:05, Atsushi Eno wrote:
And Microsoft has announced open-sourcing .NET! So you don't have to
spread your hate speech on bugs, we will take their good code.
https://github.com/dotnet/corefx/tree/master/src
(No XML Schema implementation yet, but I assume that would happen at
some stage.)
Atsushi Eno
On 2014年11月12日 22:44, Atsushi Eno wrote:
Hello,
If you believe xs:complexType/xs:extension is that superficial, could
you explain why the validation result is wrong?
Dealing with xs:complexType is one of the most complicated XML schema
validation technology, which involved handful of ambiguity, which may
be fixed in later specifications, after we have implemented this
feature mostly in 2003-2004.
Atsushi Eno
On 2014年11月12日 15:15, MarLOne wrote:
Hello,
Not sure if this issue has been raised as it is driving me nuts as
another
Mono/.Net runtime behavior differences.
I have a xml schema called FamilyTree2.xsd FamilyTree2.xsd
http://mono.1490590.n4.nabble.com/file/n4664552/FamilyTree2.xsd .
This
has been validate in Eclipse's Xsd Editor.
Then I have an instance document created using this schema and is
called
FamilyTree2SimplePerson.xml FamilyTree2SimplePerson.xml
http://mono.1490590.n4.nabble.com/file/n4664552/FamilyTree2SimplePerson.xml
I then use xsd.exe in Mono runtime 2.10.8.1 to generate a C# class
from the
schema. I then use the following code to deserialize the instance
document
into an person object:
[Test]
public void TestSimplePerson ()
{
const String testFile = FamilyTree2SimplePerson.xml;
String fileName = Path.Combine(
Constants.DataFilesDirectory,
testFile );
Assert.IsTrue( File.Exists( fileName ) );
LMar.Demo.person p = null;
using( Stream input = File.OpenRead( fileName ) )
{
XmlReaderSettings rs = new XmlReaderSettings();
rs.Schemas = new XmlSchemaSet();
rs.Schemas.Add( SchemaLoaders.FamilyTree2 );
rs.ValidationType = ValidationType.Schema;
using( XmlReader reader =
XmlReader.Create( input, rs ) )
{
XmlSerializer ser = new XmlSerializer( typeof(
LMar.Demo.person ) );
p = ser.Deserialize( reader ) as
LMar.Demo.person; //
XmlSchemaValiationException
Assert.IsNotNull( p );
}
}
The schema is embedded into the assembly as embedded resource,
The exception message is as follows:
System.Xml.Schema.XmlSchemaValiationException: XmlSchema error:
Attribute
declaration was not found for name XML Line 6, Position 12.
person is the base class of spouse which uses the xs:extension to
define it
in the schema. This error message points to the name for the spouse
object.
I believe this is a Mono MS .Net incompatibility runtime error for
the
following reasons:
1) The instance document has been validated by Eclipse xsd/xml
editor as
well as online validator. In fact the instance document was created by
Eclipse xml editor.
2) The same code ( the xsd generated code produced in .Net and Mono
appear
to be the same) shown above runs without error in MS .Net and
retrieving all
the values.
Has anyone discovered this error? It is a simple usage of
xs:extension, a
very commonly used construct and should not cause any incompatibility.
It is so disheartening to see superficial compatibility while
beneath the
surface so much differences. Is there a site that lists this kind of
runtime
incompatibility for people wanting to use Mono as serious tool?
Every time I
push Mono, I end up in a hole like this as I have encountered time
and time
again incompatibilities.
Is there some quirky flags in the XmlReaderSettings to get this
going in
Mono?
Thanks.
MarL
--
View this message in context:
http://mono.1490590.n4.nabble.com/Mono-Net-difference-handling-xs-extension-please-help-tp4664552.html
Sent from the Mono - Dev mailing list archive at Nabble.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
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono .Net difference - handling xs:extension please help
And Microsoft has announced open-sourcing .NET! So you don't have to
spread your hate speech on bugs, we will take their good code.
https://github.com/dotnet/corefx/tree/master/src
(No XML Schema implementation yet, but I assume that would happen at
some stage.)
Atsushi Eno
On 2014年11月12日 22:44, Atsushi Eno wrote:
Hello,
If you believe xs:complexType/xs:extension is that superficial, could
you explain why the validation result is wrong?
Dealing with xs:complexType is one of the most complicated XML schema
validation technology, which involved handful of ambiguity, which may
be fixed in later specifications, after we have implemented this
feature mostly in 2003-2004.
Atsushi Eno
On 2014年11月12日 15:15, MarLOne wrote:
Hello,
Not sure if this issue has been raised as it is driving me nuts as
another
Mono/.Net runtime behavior differences.
I have a xml schema called FamilyTree2.xsd FamilyTree2.xsd
http://mono.1490590.n4.nabble.com/file/n4664552/FamilyTree2.xsd . This
has been validate in Eclipse's Xsd Editor.
Then I have an instance document created using this schema and is called
FamilyTree2SimplePerson.xml FamilyTree2SimplePerson.xml
http://mono.1490590.n4.nabble.com/file/n4664552/FamilyTree2SimplePerson.xml
I then use xsd.exe in Mono runtime 2.10.8.1 to generate a C# class
from the
schema. I then use the following code to deserialize the instance
document
into an person object:
[Test]
public void TestSimplePerson ()
{
const String testFile = FamilyTree2SimplePerson.xml;
String fileName = Path.Combine(
Constants.DataFilesDirectory,
testFile );
Assert.IsTrue( File.Exists( fileName ) );
LMar.Demo.person p = null;
using( Stream input = File.OpenRead( fileName ) )
{
XmlReaderSettings rs = new XmlReaderSettings();
rs.Schemas = new XmlSchemaSet();
rs.Schemas.Add( SchemaLoaders.FamilyTree2 );
rs.ValidationType = ValidationType.Schema;
using( XmlReader reader =
XmlReader.Create( input, rs ) )
{
XmlSerializer ser = new XmlSerializer( typeof(
LMar.Demo.person ) );
p = ser.Deserialize( reader ) as
LMar.Demo.person; //
XmlSchemaValiationException
Assert.IsNotNull( p );
}
}
The schema is embedded into the assembly as embedded resource,
The exception message is as follows:
System.Xml.Schema.XmlSchemaValiationException: XmlSchema error:
Attribute
declaration was not found for name XML Line 6, Position 12.
person is the base class of spouse which uses the xs:extension to
define it
in the schema. This error message points to the name for the spouse
object.
I believe this is a Mono MS .Net incompatibility runtime error for the
following reasons:
1) The instance document has been validated by Eclipse xsd/xml editor as
well as online validator. In fact the instance document was created by
Eclipse xml editor.
2) The same code ( the xsd generated code produced in .Net and Mono
appear
to be the same) shown above runs without error in MS .Net and
retrieving all
the values.
Has anyone discovered this error? It is a simple usage of
xs:extension, a
very commonly used construct and should not cause any incompatibility.
It is so disheartening to see superficial compatibility while beneath
the
surface so much differences. Is there a site that lists this kind of
runtime
incompatibility for people wanting to use Mono as serious tool? Every
time I
push Mono, I end up in a hole like this as I have encountered time
and time
again incompatibilities.
Is there some quirky flags in the XmlReaderSettings to get this going in
Mono?
Thanks.
MarL
--
View this message in context:
http://mono.1490590.n4.nabble.com/Mono-Net-difference-handling-xs-extension-please-help-tp4664552.html
Sent from the Mono - Dev mailing list archive at Nabble.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] Hi System.xml.parse error in compiling mono
Your mcs/class/System.XML/System.Xml.XPath/Parser.cs should look like this: https://gist.github.com/atsushieno/b2290bc1162e42848cb3 If it doesn't there is some problem in your build regarding 'jay' output. You can share your build log in mcs/class/System.XML : make V=1 clean all and some people might have some comments. Atsushi Eno morteza adi wrote: I'm getting crazy :) I removed my cloned source and get a new clone from git repo. nothing changed, again same problem. I also tried to make the code in another pc - ubuntu 12.04 I got a new error: make[2]: Entering directory `/home/morteza/git/mono/runtime' if test -w /home/morteza/git/mono/mcs; then :; else chmod -R +w /home/morteza/git/mono/mcs; fi cd /home/morteza/git/mono/mcs make --no-print-directory -s NO_DIR_CHECK=1 PROFILES='net_2_0 net_3_5 net_4_0 net_4_5 xbuild_12 ' CC='gcc' all-profiles Bootstrap compiler: Mono C# compiler version 2.10.8.1 MCS [secxml/basic] System.dll System.Security.AccessControl/SemaphoreSecurity.cs(136,35): warning CS0109: The member `System.Security.AccessControl.SemaphoreSecurity.PersistModifications(System.Runtime.InteropServices.SafeHandle)' does not hide an inherited member. The new keyword is not required Mono.Http/NtlmClient.cs(99,54): error CS1502: The best overloaded method match for `Mono.Security.Protocol.Ntlm.Type3Message.Type3Message(byte[])' has some invalid arguments /usr/lib/mono/gac/Mono.Security/2.0.0.0__0738eb9f132ed756/Mono.Security.dll (Location of the symbol related to previous error) Mono.Http/NtlmClient.cs(99,54): error CS1503: Argument `#1' cannot convert `Mono.Security.Protocol.Ntlm.Type2Message' expression to type `byte[]' Compilation failed: 2 error(s), 1 warnings make[9]: *** [../../class/lib/basic/secxml/System.dll] Error 1 make[8]: *** [../../class/lib/basic/secxml/System.dll] Error 2 make[7]: *** [do-all] Error 2 make[6]: *** [all-recursive] Error 1 make[5]: *** [all-recursive] Error 1 make[4]: *** [profile-do--basic--all] Error 2 make[3]: *** [profiles-do--all] Error 2 make[2]: *** [all-local] Error 2 make[2]: Leaving directory `/home/morteza/git/mono/runtime' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/morteza/git/mono' make: *** [all] Error 2 I wonder how the same code gets built and installed in my virtual ubuntu machine!! On Wed, Jul 16, 2014 at 9:51 PM, Marek Safar marek.sa...@gmail.com mailto:marek.sa...@gmail.com wrote: Hello, No i didn't build in parallel. just a simple make command with no parameter. when i ran the Make command for the first time i got an error said Perl XML:Parser wasn't installed. so i installed XML::Parser by apt-get libexpat1-dev then i ran into this error. That's probably it. Try to clean your code and rebuild again. Marek On Wed, Jul 16, 2014 at 8:26 PM, Marek Safar marek.sa...@gmail.com mailto:marek.sa...@gmail.com wrote: Hello, * * *I successfully make install the mono code in ubuntu 12.04 * *when i do the same steps in ubuntu 14.04 i get this error* Bootstrap compiler: Mono C# compiler version 3.2.8.0 MCS [build] System.Xml.dll System.Xml.XPath/Parser.jay(12,0): error CS1525: Unexpected symbol `using' This is weird error. Did you try to build in parallel ? Also showing what is actually in file System.Xml.XPath/Parser.jay around reports lines would help too. Marek ___ 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] Editing mono in IDE?
You would most likely like to create your own solution from existing sources... These days I've been working on Microsoft.Build.dll these days with my own solution and projects [*1] because the centralized msvc/scripts/net_4_5.sln is quite useless (too big). And I can't think of any generalized way of generating appropriate set of projects for each classlib assembly. [*1] https://github.com/atsushieno/mono/blob/msbuilddll2/msvc/scripts/net_4_5_msbuild.sln Atsushi Eno Hüning, Christian wrote: Hi, I wondered if there is a way to efficiently and effectively develop mono with an IDE like Xamarin Studio / Visual Studio? I couldn’t find a central .sln file or something (did find quite a lot .sln files, but none that seemed to be THE solution file, if there is any). Is that even intended? Cheers Christian ___ 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] why does DateTime.Now.IsDaylightSavingTime() returns false when it should be true.
Let's get this patch in and fix any possible issue later. Thanks!
Atsushi Eno
(2013年11月07日 18:07), Alistair Bush wrote:
Hi guys,
Please note that I have cleaned this up and bit and submitted a pull request
https://github.com/mono/mono/pull/800
Feedback welcome.
On Wed, Oct 30, 2013 at 11:51 PM, Alistair Bush alistair.b...@gmail.com wrote:
Ok so firstly this is like the MOST C ive ever written in my life..
and it looks ugly and ive only vagely checked that it doesn't break
the northern hemisphere.
But isn't this a better patch of the method?
(https://github.com/alistair/mono/commit/6912202aab5a424e98bc44d7b988c2791f91)
Any help turning this into an acceptable pull request would be really
appreciated.
diff --git a/mono/metadata/icall.c b/mono/metadata/icall.c
index 618e4da..7f47624 100644
--- a/mono/metadata/icall.c
+++ b/mono/metadata/icall.c
@@ -5930,10 +5930,12 @@
ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData (guint32 year,
MonoArray
struct tm start, tt;
time_t t;
- long int gmtoff;
- int is_daylight = 0, day;
+ long int gmtoff, gmtoff_st, gmtoff_ds;
+ int day, transitioned;
char tzone [64];
+ gmtoff_st = gmtoff_ds = transitioned = 0;
+
MONO_ARCH_SAVE_REGS;
MONO_CHECK_ARG_NULL (data);
@@ -5974,8 +5976,10 @@
ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData (guint32 year,
MonoArray
t += 3600*24;
tt = *localtime (t);
+long int gmtoff_after = gmt_offset(tt, t);
+
/* Daylight saving starts or ends here. */
- if (gmt_offset (tt, t) != gmtoff) {
+ if (gmtoff_after != gmtoff) {
struct tm tt1;
time_t t1;
@@ -5995,36 +5999,37 @@
ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData (guint32 year,
MonoArray
strftime (tzone, sizeof (tzone), %Z, tt);
/* Write data, if we're already in daylight saving, we're done. */
- if (is_daylight) {
- mono_array_setref ((*names), 0, mono_string_new (domain, tzone));
- mono_array_set ((*data), gint64, 1, ((gint64)t1 + EPOCH_ADJUST) * 1000L);
- return 1;
+ if (tt.tm_isdst) {
+ mono_array_setref ((*names), 1, mono_string_new (domain, tzone));
+ mono_array_set ((*data), gint64, 0, ((gint64)t1 + EPOCH_ADJUST) * 1000L);
+ if (gmtoff_ds == 0) {
+ gmtoff_st = gmtoff;
+ gmtoff_ds = gmtoff_after;
+ }
+ transitioned++;
} else {
- struct tm end;
time_t te;
+ te = mktime (tt);
- memset (end, 0, sizeof (end));
- end.tm_year = year-1900 + 1;
- end.tm_mday = 1;
-
- te = mktime (end);
-
- mono_array_setref ((*names), 1, mono_string_new (domain, tzone));
- mono_array_set ((*data), gint64, 0, ((gint64)t1 + EPOCH_ADJUST) * 1000L);
mono_array_setref ((*names), 0, mono_string_new (domain, tzone));
mono_array_set ((*data), gint64, 1, ((gint64)te + EPOCH_ADJUST) * 1000L);
- is_daylight = 1;
+ if (gmtoff_ds == 0) {
+ gmtoff_st = gmtoff_after;
+ gmtoff_ds = gmtoff;
+ }
+ transitioned++;
}
/* This is only set once when we enter daylight saving. */
- mono_array_set ((*data), gint64, 2, (gint64)gmtoff * 1000L);
- mono_array_set ((*data), gint64, 3, (gint64)(gmt_offset (tt, t) -
gmtoff) * 1000L);
-
+ if (tt1.tm_isdst) {
+ mono_array_set ((*data), gint64, 2, (gint64)gmtoff_st * 1000L);
+ mono_array_set ((*data), gint64, 3, (gint64)(gmtoff_ds - gmtoff_st)
* 1000L);
+ }
gmtoff = gmt_offset (tt, t);
}
}
- if (!is_daylight) {
+ if (transitioned 2) {
strftime (tzone, sizeof (tzone), %Z, tt);
mono_array_setref ((*names), 0, mono_string_new (domain, tzone));
mono_array_setref ((*names), 1, mono_string_new (domain, tzone));
On Tue, Oct 29, 2013 at 9:13 AM, Alistair Bush alistair.b...@gmail.com wrote:
Well that certainly sucks.
On Tue, Oct 29, 2013 at 3:03 AM, Robert Jordan robe...@gmx.net wrote:
On 28.10.2013 07:35, Alistair Bush wrote:
I am trying to figure out why exactly running
DateTime.Now.IsDaylightSavingTIme() returns false.
I live in the Auckland/Pacific timezone and pretty much everywhere I
look it confirms that yes it is daylight saving time.
Unfortunately, I don't remember the details, but I'm pretty
sure that ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData
has a bug w/ respect to the Southern Hemisphere.
The code assumes that a year always begins outside a DST zone,
and this is obviously incorrect for the Southern Hemisphere.
To fix this, the local var is_daylight must be properly
initialized. Currently, it's always 0 at start, but it must
be initialized with 1 when January, 1st is inside a DST
zone.
Maybe this:
is_daylight = start.tm_isdst 0;
just before
/* For each day of the year, calculate the tm_gmtoff. */
for (day = 0; day 365; day++) {
Robert
___
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] New Property on System.Web.Hosting.HostingEnvironment
From your message I assume you think you can wait for someone to implement it, but there is no one working on ASP.NET stack. So you are the most likely one who understand what it is and who is most able to implement it. Atsushi Eno Martin Thwaites wrote: I'm not sure of the best place to raise this, it's not a bug really, but a property that seems to be new to the framework. System.Web.Hosting.HostingEnvironment has the property InClientBuildManager and it looks like it was added in 3.5. The reason I think it's an important thing to get added soon is the fact that WebActivatorEx uses it, and it's part of just about every NuGet package for MVC. So if people want to move over to mono, this could be a major issue. On the plus side, WebActivatorEx handles it well, so you just get an exception on first run. http://msdn.microsoft.com/en-us/library/system.web.hosting.hostingenvironment.inclientbuildmanager(v=vs.100).aspx http://msdn.microsoft.com/en-us/library/system.web.hosting.hostingenvironment.inclientbuildmanager%28v=vs.100%29.aspx ___ 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] Bug in SignedXml.GetIdElement
Jonathan Gagnon wrote: On Fri, Jul 19, 2013 at 1:05 PM, Atsushi Eno atsushi...@veritas-vos-liberabit.com mailto:atsushi...@veritas-vos-liberabit.com wrote: (2013年07月17日 21:25), Jonathan Gagnon wrote: On Tue, Jul 16, 2013 at 12:16 PM, 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: Jonathan Gagnon wrote: It does not work when the SAML document is not referring to any DTD. In my case, I receive the following exception when I call the CheckSignature method : System.Security.Cryptography.CryptographicException: Malformed reference object: [referenceId] at System.Security.Cryptography.Xml.SignedXml.GetReferenceHash (System.Security.Cryptography.Xml.Reference r, Boolean check_hmac) [0x0] in filename unknown:0 at System.Security.Cryptography.Xml.SignedXml.CheckReferenceIntegrity (System.Collections.ArrayList referenceList) [0x0] in filename unknown:0 at System.Security.Cryptography.Xml.SignedXml.CheckSignatureInternal (System.Security.Cryptography.AsymmetricAlgorithm key) [0x0] in filename unknown:0 at System.Security.Cryptography.Xml.SignedXml.CheckSignature (System.Security.Cryptography.AsymmetricAlgorithm key) [0x0] in filename unknown:0 at TestSAML.Program.Main (System.String[] args) [0x0] in filename unknown:0 Of course it happens because you should be processing corresponding DTD or XML Schema. The same code works in .NET and it does work if I modify the GetIdElement method to check for ID. So in your opinion, I should create a class that derives from SignedXml and override GetIdElement? I'm not sure I would like to answer yes (if you want to have ID being processed) or no (you should actually process DTD or XSD). I added references to the corresponding XSDs but it doesn't seem to help. I'm still getting the same exception. Because you didn't set up XmlDocument properly to process XSDs. (You're discussing you're doing right without showing code.) You're probably right that I didn't set it up properly. It seems to be a poorly documented part of .NET. Do you have a link to a good example? Basically, I tried adding a reference to the xsd inside the SAML document but it didn't help. Then I tried the following example without success : http://msdn.microsoft.com/en-us/library/ms162371.aspx I also noticed that calling the Schemas.Add method is very slow (several seconds each time), and didn't want that overhead in our application. I have no idea why your code doesn't work as you don't show us the exact code, but for the slowness issue I guess you are loading the relevant resources (xml schemas and DTDs) every time. Some caching XmlResolver would save that (use XmlReaderSettings.XmlResolver). XmlSchema processing itself should not take several seconds. You can partially verify your code only with XmlDocument by calling GetElementById() and see if your SAML ID is found. If it's not found, then SignedXml won't work for you either. It does fix the problem for me. But wouldn't it be better to modify SignedXml.GetIdElement() to behave more like .NET so that other users don't encounter the same problem? I don't support any use of API that violates W3C specification. From what I understand, the W3C specification is only about the signature part of a signed xml. There is nothing regarding other parts of the signed XML, and the SAML standard defines the id differently. So I'm not sure that supporting SAML ids would violate the W3C specification. I don't understand your discussion. Any additional local attributes that do not conform to the XML Schema defined in xmldsig specification violates XML schema validation. What I'm saying is that the XML Schema defined in xmldsig specification is often applied to a subpart of an XML document. Here is an example : samlp:Response saml:Assertion ID=abc ds:Signature xmlns:ds=http://www.w3.org/2000/09/xmldsig#; /ds:Signature ... /saml:Assertion /samlp:Response So the XML Schema defined by the W3C specification only applies to what is inside the ds:Signature tags
Re: [Mono-dev] Bug in SignedXml.GetIdElement
(2013年07月17日 21:25), Jonathan Gagnon wrote: On Tue, Jul 16, 2013 at 12:16 PM, Atsushi Eno atsushi...@veritas-vos-liberabit.com mailto:atsushi...@veritas-vos-liberabit.com wrote: Jonathan Gagnon wrote: It does not work when the SAML document is not referring to any DTD. In my case, I receive the following exception when I call the CheckSignature method : System.Security.Cryptography.CryptographicException: Malformed reference object: [referenceId] at System.Security.Cryptography.Xml.SignedXml.GetReferenceHash (System.Security.Cryptography.Xml.Reference r, Boolean check_hmac) [0x0] in filename unknown:0 at System.Security.Cryptography.Xml.SignedXml.CheckReferenceIntegrity (System.Collections.ArrayList referenceList) [0x0] in filename unknown:0 at System.Security.Cryptography.Xml.SignedXml.CheckSignatureInternal (System.Security.Cryptography.AsymmetricAlgorithm key) [0x0] in filename unknown:0 at System.Security.Cryptography.Xml.SignedXml.CheckSignature (System.Security.Cryptography.AsymmetricAlgorithm key) [0x0] in filename unknown:0 at TestSAML.Program.Main (System.String[] args) [0x0] in filename unknown:0 Of course it happens because you should be processing corresponding DTD or XML Schema. The same code works in .NET and it does work if I modify the GetIdElement method to check for ID. So in your opinion, I should create a class that derives from SignedXml and override GetIdElement? I'm not sure I would like to answer yes (if you want to have ID being processed) or no (you should actually process DTD or XSD). I added references to the corresponding XSDs but it doesn't seem to help. I'm still getting the same exception. Because you didn't set up XmlDocument properly to process XSDs. (You're discussing you're doing right without showing code.) It does fix the problem for me. But wouldn't it be better to modify SignedXml.GetIdElement() to behave more like .NET so that other users don't encounter the same problem? I don't support any use of API that violates W3C specification. From what I understand, the W3C specification is only about the signature part of a signed xml. There is nothing regarding other parts of the signed XML, and the SAML standard defines the id differently. So I'm not sure that supporting SAML ids would violate the W3C specification. I don't understand your discussion. Any additional local attributes that do not conform to the XML Schema defined in xmldsig specification violates XML schema validation. Atsushi Eno Though I'm just pointing out the facts. There may be people who want to take responsibility on the entire XML Signature stuff and go ahead to apply the changes. Atsushi Eno Thanks, Jonathan On Tue, Jul 16, 2013 at 10:24 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: Whenever SAML document instance refers to its schema or DTD that will validate ID attribute as expected, since SignedXml internally uses XmlDocument.GetElementById () which is expected to collect IDs where IDs means a validated ID by XmlValidatingReader or any XmlReader that has XmlReaderSettings to consider XmlSchema or DTD. Hence that does not cause any problem for SAML. (Also note that SignedXml implementation could override SignedXml.GetIdElement(). Mono's WCF implementation makes use of it to support WS-Security ID attribute.) Atsushi Eno Jonathan Gagnon wrote: This is true for the signature, but not true for SAML assertions, where ids are defined as ID : http://schemas.stylusstudio.com/saml/nea261b70/complexType_AssertionType.html I don't know in which case we would need id in lowercase, but since .NET supports it, there is probably a valid reason for it too. *Jonathan Gagnon* Responsable des architectures systèmes 600, boulevard Armand-Frappier, bureau 200 Laval (Québec) H7V 4B4 Canada T : 450-662-6101 tel:450-662-6101 tel:450-662-6101 tel:450-662-6101 poste 234 http://www.croesus.com http://www.facebook.com/pages/Croesus-Finansoft/345020305606240http://www.linkedin.com/company/croesus-finansoft?trk=hb_tab_compy_id_26141https
Re: [Mono-dev] Bug in SignedXml.GetIdElement
W3C XML Signature specification explicitly Id as the valid attribute
name for referencing an element, by its XML Schema and DTD:
http://www.w3.org/TR/xmldsig-core/#sec-Signature
http://www.w3.org/TR/xmldsig-core/#sec-SignatureValue
http://www.w3.org/TR/xmldsig-core/#sec-SignedInfo
http://www.w3.org/TR/xmldsig-core/#sec-Reference
http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo
http://www.w3.org/TR/xmldsig-core/#sec-Object
http://www.w3.org/TR/xmldsig-core/#sec-Manifest
http://www.w3.org/TR/xmldsig-core/#sec-SignatureProperties
If Microsoft treats id or ID attributes as if they were ID (and not
iD ?), they will have to fix their bug.
Atsushi Eno
(2013年07月12日 23:58), Jonathan Gagnon wrote:
I have encountered a bug similar to 4938
https://bugzilla.xamarin.com/show_bug.cgi?id=4938.
My problem is that mono does not find the reference id because the id
is in uppercase ('ID' instead of 'Id'). This works correctly on .NET.
As stated in the bug description, the problem is in the SignedXml
class, GetIdElement method.
I wrote a very simple patch that fixes the problem by looking for id
and ID. Should I do a pull request with that fix?
*Jonathan Gagnon*
Responsable des architectures systèmes
600, boulevard Armand-Frappier, bureau 200
Laval (Québec) H7V 4B4
Canada
T : 450-662-6101 poste 234
http://www.croesus.com
http://www.facebook.com/pages/Croesus-Finansoft/345020305606240http://www.linkedin.com/company/croesus-finansoft?trk=hb_tab_compy_id_26141https://twitter.com/CroesusFin
___
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.Configuration.SettingValueElement
Hi, In general, NotImplementedException means that it is not implemented (literally!). It is to indicate on our class status page to explicitly indicate that it is not implemented and have some code build and load just fine. (Not having override does not cause compilation error on mono, but such resulting assemblies would not run on .NET without problem.) According to our class status pages, you are (or I should say, the MSDN documentation is) wrong - SettingValueElement class actually has override for Unmerge() method. I have no idea what .NET does, but for mono it is not implemented. (I won't believe that this override does not do anything, at least without certain experiment shown.) No one works on System.Configuration stuff nowadays but if you have some patch to implement it, that would be welcomed, reviewed and merged if good :) Atsushi Eno Torben H. Nielsen wrote: Hi I was wondering why mono has an override implementation of System.Configuration.SettingValueElement :: Unmerge() (https://github.com/mono/mono/blob/master/mcs/class/System/System.Configuration/SettingValueElement.cs line 115) which only throws a NotImplementedException when the .net implementation of the same class relies on the base implementation and does NOT try to override it ? Kind regards Torben ___ 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] Bug in SignedXml.GetIdElement
Whenever SAML document instance refers to its schema or DTD that will
validate ID attribute as expected, since SignedXml internally uses
XmlDocument.GetElementById () which is expected to collect IDs where
IDs means a validated ID by XmlValidatingReader or any XmlReader that
has XmlReaderSettings to consider XmlSchema or DTD. Hence that does not
cause any problem for SAML.
(Also note that SignedXml implementation could override
SignedXml.GetIdElement(). Mono's WCF implementation makes use of it to
support WS-Security ID attribute.)
Atsushi Eno
Jonathan Gagnon wrote:
This is true for the signature, but not true for SAML assertions,
where ids are defined as ID :
http://schemas.stylusstudio.com/saml/nea261b70/complexType_AssertionType.html
I don't know in which case we would need id in lowercase, but since
.NET supports it, there is probably a valid reason for it too.
*Jonathan Gagnon*
Responsable des architectures systèmes
600, boulevard Armand-Frappier, bureau 200
Laval (Québec) H7V 4B4
Canada
T : 450-662-6101 poste 234
http://www.croesus.com
http://www.facebook.com/pages/Croesus-Finansoft/345020305606240http://www.linkedin.com/company/croesus-finansoft?trk=hb_tab_compy_id_26141https://twitter.com/CroesusFin
On Tue, Jul 16, 2013 at 2:30 AM, Atsushi Eno
atsushi...@veritas-vos-liberabit.com
mailto:atsushi...@veritas-vos-liberabit.com wrote:
W3C XML Signature specification explicitly Id as the valid
attribute name for referencing an element, by its XML Schema and DTD:
http://www.w3.org/TR/xmldsig-core/#sec-Signature
http://www.w3.org/TR/xmldsig-core/#sec-SignatureValue
http://www.w3.org/TR/xmldsig-core/#sec-SignedInfo
http://www.w3.org/TR/xmldsig-core/#sec-Reference
http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo
http://www.w3.org/TR/xmldsig-core/#sec-Object
http://www.w3.org/TR/xmldsig-core/#sec-Manifest
http://www.w3.org/TR/xmldsig-core/#sec-SignatureProperties
If Microsoft treats id or ID attributes as if they were ID
(and not iD ?), they will have to fix their bug.
Atsushi Eno
(2013年07月12日 23:58), Jonathan Gagnon wrote:
I have encountered a bug similar to 4938
https://bugzilla.xamarin.com/show_bug.cgi?id=4938.
My problem is that mono does not find the reference id because
the id is in uppercase ('ID' instead of 'Id'). This works
correctly on .NET.
As stated in the bug description, the problem is in the
SignedXml class, GetIdElement method.
I wrote a very simple patch that fixes the problem by looking
for id and ID. Should I do a pull request with that fix?
*Jonathan Gagnon*
Responsable des architectures systèmes
600, boulevard Armand-Frappier, bureau 200
Laval (Québec) H7V 4B4
Canada
T : 450-662-6101 tel:450-662-6101 poste 234
http://www.croesus.com
http://www.facebook.com/pages/Croesus-Finansoft/345020305606240http://www.linkedin.com/company/croesus-finansoft?trk=hb_tab_compy_id_26141https://twitter.com/CroesusFin
___
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
Re: [Mono-dev] Bug in SignedXml.GetIdElement
Jonathan Gagnon wrote:
It does not work when the SAML document is not referring to any DTD.
In my case, I receive the following exception when I call the
CheckSignature method :
System.Security.Cryptography.CryptographicException: Malformed
reference object: [referenceId]
at System.Security.Cryptography.Xml.SignedXml.GetReferenceHash
(System.Security.Cryptography.Xml.Reference r, Boolean check_hmac)
[0x0] in filename unknown:0
at
System.Security.Cryptography.Xml.SignedXml.CheckReferenceIntegrity
(System.Collections.ArrayList referenceList) [0x0] in filename
unknown:0
at System.Security.Cryptography.Xml.SignedXml.CheckSignatureInternal
(System.Security.Cryptography.AsymmetricAlgorithm key) [0x0] in
filename unknown:0
at System.Security.Cryptography.Xml.SignedXml.CheckSignature
(System.Security.Cryptography.AsymmetricAlgorithm key) [0x0] in
filename unknown:0
at TestSAML.Program.Main (System.String[] args) [0x0] in
filename unknown:0
Of course it happens because you should be processing corresponding DTD
or XML Schema.
The same code works in .NET and it does work if I modify the
GetIdElement method to check for ID.
So in your opinion, I should create a class that derives from
SignedXml and override GetIdElement?
I'm not sure I would like to answer yes (if you want to have ID being
processed) or no (you should actually process DTD or XSD).
It does fix the problem for me. But wouldn't it be better to modify
SignedXml.GetIdElement() to behave more like .NET so that other users
don't encounter the same problem?
I don't support any use of API that violates W3C specification.
Though I'm just pointing out the facts. There may be people who want to
take responsibility on the entire XML Signature stuff and go ahead to
apply the changes.
Atsushi Eno
Thanks,
Jonathan
On Tue, Jul 16, 2013 at 10:24 AM, Atsushi Eno
atsushi...@veritas-vos-liberabit.com
mailto:atsushi...@veritas-vos-liberabit.com wrote:
Whenever SAML document instance refers to its schema or DTD that
will validate ID attribute as expected, since SignedXml
internally uses XmlDocument.GetElementById () which is expected to
collect IDs where IDs means a validated ID by
XmlValidatingReader or any XmlReader that has XmlReaderSettings to
consider XmlSchema or DTD. Hence that does not cause any problem
for SAML.
(Also note that SignedXml implementation could override
SignedXml.GetIdElement(). Mono's WCF implementation makes use of
it to support WS-Security ID attribute.)
Atsushi Eno
Jonathan Gagnon wrote:
This is true for the signature, but not true for SAML
assertions, where ids are defined as ID :
http://schemas.stylusstudio.com/saml/nea261b70/complexType_AssertionType.html
I don't know in which case we would need id in lowercase,
but since .NET supports it, there is probably a valid reason
for it too.
*Jonathan Gagnon*
Responsable des architectures systèmes
600, boulevard Armand-Frappier, bureau 200
Laval (Québec) H7V 4B4
Canada
T : 450-662-6101 tel:450-662-6101 poste 234
http://www.croesus.com
http://www.facebook.com/pages/Croesus-Finansoft/345020305606240http://www.linkedin.com/company/croesus-finansoft?trk=hb_tab_compy_id_26141https://twitter.com/CroesusFin
On Tue, Jul 16, 2013 at 2:30 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:
W3C XML Signature specification explicitly Id as the valid
attribute name for referencing an element, by its XML
Schema and DTD:
http://www.w3.org/TR/xmldsig-core/#sec-Signature
http://www.w3.org/TR/xmldsig-core/#sec-SignatureValue
http://www.w3.org/TR/xmldsig-core/#sec-SignedInfo
http://www.w3.org/TR/xmldsig-core/#sec-Reference
http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo
http://www.w3.org/TR/xmldsig-core/#sec-Object
http://www.w3.org/TR/xmldsig-core/#sec-Manifest
http://www.w3.org/TR/xmldsig-core/#sec-SignatureProperties
If Microsoft treats id or ID attributes as if they were ID
(and not iD ?), they will have to fix their bug.
Atsushi Eno
(2013年07月12日 23:58), Jonathan Gagnon wrote:
I have encountered a bug similar to 4938
https://bugzilla.xamarin.com/show_bug.cgi?id=4938.
My problem is that mono does not find the reference id
because
the id is in uppercase ('ID' instead of 'Id'). This works
correctly on .NET.
As stated in the bug description, the problem is in the
SignedXml class, GetIdElement method.
I wrote
Re: [Mono-dev] Anonymous Pipe Stream Implementation
let me know! That method can return totally different string than what .NET returns. It's weird that if an application totally depends on certain format of the return values of it and I believe we can ignore them. Compatibility - I can create pipes and manipulate them without adding any new library references but i do depend on using the poll(3) function more heavily than it seems to be presently (it's only exposed for Network Sockets presently). Are there any portability / compatibility considerations with poll(3) that might need to be addressed? I guess Mono.Posix.dll has a lot more bound API that you want to use (it is already referenced by System.Core.dll for desktop CLR_PROFILE in System.Core/Makefile). If that still needs to touch our runtime (io-layer) then it is of our concern yes, as we are building runtime not only for desktop. Yet we have couple of defs (PLATFORM_ANDROID etc.), so as long as things can be easily conditioned out it would work. Versioning - I'm not familiar with how versioning between .NET 1/2/3/etc... is being handled. Anonymous pipes are introduced in .NET 3.5. Do these classes need to be hidden to older versions, etc... Maybe there is a wiki page i haven't found discussing some of this? Our least supported Framework API is 2.0 runtime, which covers 2.0, 3.0, 3.5 and 3.5 SP1 API. So, you don't need to add any condition. For 4.0 specific types and members, use #if NET_4_0 for all of them (you can hide them by changing them as internal for !NET_4_0). I have added several new internal calls to the MonoIO utility, specifically for poll(3) and pipe handle manipulation. Does adding internal calls require any versioning considerations? Testing - In order to write a test suite for anonymous pipes i need to start new processes and i will need to use some sort of IPC mechanism to communicate certain errors back to the test process. This seems like a rather unique challenge compared to most of the testing needed for mono. Has any of this multi-process unit testing been done before in mono, or are there any considerations that might be relevant? Not everything has to be in our existing NUnit test style. We have a couple of standalone tests (e.g. in System.Web.Services or System.Xml). Probably you can create your own test runner to deal with multiple processes. Please do not hesitate to show us your ongoing changes. I'm sure that almost no one cared this API (at least no one contributed to the implementation), so you're most likely the one at best knowledge here :) And with code people can talk better. 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] Entity framework in mono
I believe we only have EntityFramework.dll (dll name has changed when it went to codeplex). Atsushi Eno Rafael Teixeira wrote: Seems like the Entity Framework is not properly installed, or is not being referenced (System.Data.Entity.dll). Rafael Teixeira O..:.) On Tue, Jun 4, 2013 at 2:39 AM, Sharique uddin Ahmed Farooqui saf...@gmail.com wrote: Hi, I build pretty basic application using entity framework5 and MVC3 using VS2012 Express, it works well. I open this application on Linux (OpenSuse 12.3, Mono 3.0.7). It gives error /home/sharique/Projects/my projects/dot net/MvcApplication1/MvcApplication1/Controllers/CustomerController.cs(44,44): Error CS0103: The name `EntityState' does not exist in the current context (CS0103) (MvcApplication1) -- Sharique uddin Ahmed Farooqui http://safknw.blogspot.com/ Peace is the Ultimate desire of mankind. ___ 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] Processing XML atomic values in XML Schema
Hi, Could you file a bug on bugzilla.xamarin.com? Unless someone else goes ahead and fix, I'll take care of that obsolete technology at some stage. Thanks, Atsushi Eno Tobias Kiertscher wrote: Hi, I tried to run code with XML schema based validation on mono 2.10.8 and 3.0.10 that works fine on mono 2.6.7. But the processing of atomic datatypes like (unsignedInt, duration, gYear, hexBinary, anyURI, ...) seems to be broken after 2.6.7. And the datatype gMonth seems to be buggy in all versions. The code to verify the behavior is: http://github.com/mastersign/mono-xml-schema-bug/blob/master/Program.cs The output for mono 2.6.7, 2.10.8, 3.0.10 and MS .NET 3.5 is: http://github.com/mastersign/mono-xml-schema-bug/blob/master/results.txt Please give me feedback if you can verify the bug. In my opinion this issue renders the XML schema support unusable for now. Best regards, Tobias Kiertscher d...@mastersign.de ___ 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] Observable.GetAwaiter()
No you didn't, or yes we did ;-) I made some changes to Rx assemblies builds in git master so that they are now included too. Atsushi Eno sebastian wrote: We noticed that Observable.GetAwaiter is missing in the 4.5 Rx framework bundled with mono. Did we build mono incorrectly? Or is this method missing for another reason? Thanks, Sebastian ___ 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] Entity Framework - new issues
yw - it still seems like some xml schema issue, namely PSVI handling in XmlSchemaValidatingReader (ok, less than 0.1% of people understand it). In case you don't mind patching EF, here is mine that goes beyond that issue. Atsushi Eno Олег wrote: Many thanks to Atsushi Eno for a solution for previous defect in System.Xml. But there are new issues with EF. I tried to create simplest console application (file Test.zip attached to this letter, contains MonoDevelop project), it fails with following exception: System.ArgumentException: An element with the same key already exists in the dictionary. at System.Collections.Generic.Dictionary`2[System.String,System.Object].Add (System.String key, System.Object value) [0x0007e] in /usr/ports/lang/mono/work/mono-3.0.3/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:423 at System.Data.Entity.Core.EntityModel.SchemaObjectModel.TypeUsageBuilder.HandleNullableAttribute (System.Xml.XmlReader reader) [0x00015] in /usr/ports/lang/mono/work/mono-3.0.3/external/entityframework/src/EntityFramework/Core/EntityModel/SchemaObjectModel/TypeUsageBuilder.cs:605 at System.Data.Entity.Core.EntityModel.SchemaObjectModel.TypeUsageBuilder.InternalHandleAttribute (System.Xml.XmlReader reader) [0x00010] in /usr/ports/lang/mono/work/mono-3.0.3/external/entityframework/src/EntityFramework/Core/EntityModel/SchemaObjectModel/TypeUsageBuilder.cs:300 at System.Data.Entity.Core.EntityModel.SchemaObjectModel.TypeUsageBuilder.HandleAttribute (System.Xml.XmlReader reader) [0x0] in /usr/ports/lang/mono/work/mono-3.0.3/external/entityframework/src/EntityFramework/Core/EntityModel/SchemaObjectModel/TypeUsageBuilder.cs:291 at System.Data.Entity.Core.EntityModel.SchemaObjectModel.StructuredProperty.HandleAttribute (System.Xml.XmlReader reader) [0x00040] in /usr/ports/lang/mono/work/mono-3.0.3/external/entityframework/src/EntityFramework/Core/EntityModel/SchemaObjectModel/StructuredProperty.cs:227 at System.Data.Entity.Core.EntityModel.SchemaObjectModel.SchemaElement.ParseAttribute (System.Xml.XmlReader reader) [0x0006a] in /usr/ports/lang/mono/work/mono-3.0.3/external/entityframework/src/EntityFramework/Core/EntityModel/SchemaObjectModel/SchemaElement.cs:592 at System.Data.Entity.Core.EntityModel.SchemaObjectModel.SchemaElement.Parse (System.Xml.XmlReader reader) [0x0001d] in /usr/ports/lang/mono/work/mono-3.0.3/external/entityframework/src/EntityFramework/Core/EntityModel/SchemaObjectModel/SchemaElement.cs:193 at System.Data.Entity.Core.EntityModel.SchemaObjectModel.StructuredType.HandlePropertyElement (System.Xml.XmlReader reader) [0x7] in /usr/ports/lang/mono/work/mono-3.0.3/external/entityframework/src/EntityFramework/Core/EntityModel/SchemaObjectModel/StructuredType.cs:387 at System.Data.Entity.Core.EntityModel.SchemaObjectModel.StructuredType.HandleElement (System.Xml.XmlReader reader) [0x0001f] in /usr/ports/lang/mono/work/mono-3.0.3/external/entityframework/src/EntityFramework/Core/EntityModel/SchemaObjectModel/StructuredType.cs:267 at System.Data.Entity.Core.EntityModel.SchemaObjectModel.SchemaEntityType.HandleElement (System.Xml.XmlReader reader) [0x0] in /usr/ports/lang/mono/work/mono-3.0.3/external/entityframework/src/EntityFramework/Core/EntityModel/SchemaObjectModel/ItemType.cs:198 at System.Data.Entity.Core.EntityModel.SchemaObjectModel.SchemaElement.ParseElement (System.Xml.XmlReader reader) [0x0002c] in /usr/ports/lang/mono/work/mono-3.0.3/external/entityframework/src/EntityFramework/Core/EntityModel/SchemaObjectModel/SchemaElement.cs:746 at System.Data.Entity.Core.EntityModel.SchemaObjectModel.SchemaElement.Parse (System.Xml.XmlReader reader) [0x000d0] in /usr/ports/lang/mono/work/mono-3.0.3/external/entityframework/src/EntityFramework/Core/EntityModel/SchemaObjectModel/SchemaElement.cs:220 at System.Data.Entity.Core.EntityModel.SchemaObjectModel.Schema.HandleEntityTypeElement (System.Xml.XmlReader reader) [0x7] in /usr/ports/lang/mono/work/mono-3.0.3/external/entityframework/src/EntityFramework/Core/EntityModel/SchemaObjectModel/Schema.cs:1023 at System.Data.Entity.Core.EntityModel.SchemaObjectModel.Schema.HandleElement (System.Xml.XmlReader reader) [0x0001f] in /usr/ports/lang/mono/work/mono-3.0.3/external/entityframework/src/EntityFramework/Core/EntityModel/SchemaObjectModel/Schema.cs:592 at System.Data.Entity.Core.EntityModel.SchemaObjectModel.SchemaElement.ParseElement (System.Xml.XmlReader reader) [0x0002c] in /usr/ports/lang/mono/work/mono-3.0.3/external/entityframework/src/EntityFramework/Core/EntityModel/SchemaObjectModel/SchemaElement.cs:746 at System.Data.Entity.Core.EntityModel.SchemaObjectModel.SchemaElement.Parse (System.Xml.XmlReader reader) [0x000d0] in /usr/ports/lang/mono/work/mono-3.0.3/external/entityframework/src/EntityFramework/Core/EntityModel/SchemaObjectModel/SchemaElement.cs:220
Re: [Mono-dev] A bug in System.Xml blocking Entity Framework usage, #6653.
Thanks for the heads up. Yes there was. The problem with that bug report is that it does not bother to try to minimize the schema. It is actually so annoying task. Now I've trimmed down to 35 lines out from 1000. how to do it There are many extraneous schema components and type definitions that are irrelevant to the actual bug. Fortunately there is repro code that is useful to see if your attempt to reduce extraneous components works or not. Removing huge type definitions likely fails to keep broken schema. I'd start with cosmetic parts that however enable further type removal, which are: - remove attribute and attributeGroupRef : they end up to free some simpleTypes and attributeGroups. - remove particles in sequence, choice, all and group : similarly, but they could also free some complexTypes too. Then you can start trimming simpleType, complexType, group and attributeGroup elements, which will significantly reduce the lines of schema. I'll have another look when I got another spare time (it took a while to do this reduction, so I stop it here so far), but now that the repro is smaller, anyone could also try to fix System.Xml.dll from mono source, namely mcs/class/System.XML/System.Xml.Schema. It is likely that some part of it need to resolve recursive reference nicely. But it also seems very complicated that I can't say if it's fixable easily or anytime soon. Making changes in the schema itself or disabling schema validation somewhere should be much easier. Atsushi Eno Oleg wrote: Hello, There is a 5 months old bug #6653 https://bugzilla.xamarin.com/show_bug.cgi?id=6653 and discussions on StackOverflow about troubles with Entity Framework when it loads metadata from xml model: * How to setup Entity Framework / SQL Server with Mono http://stackoverflow.com/questions/13624065/how-to-setup-entity-framework-sql-server-with-mono * NullReferenceException with EF6 on Mono 3.0.3 http://stackoverflow.com/questions/14582318/nullreferenceexception-with-ef6-on-mono-3-0-3 Could anyone say, is a date when it will be fixed predictable? It would be very helpful to know it and plan own migration work. Now it looks like this defect blocks most of real life cases of Entity Framework usage and this way blocks number of migration initiatives. P.S. What can I do to contribute to this issue resolution? Does it makes sense to create separate bug about Entity Framework or attach sample not working project to existing one? View this message in context: A bug in System.Xml blocking Entity Framework usage, #6653. http://mono.1490590.n4.nabble.com/A-bug-in-System-Xml-blocking-Entity-Framework-usage-6653-tp4658345.html Sent from the Mono - Dev mailing list archive http://mono.1490590.n4.nabble.com/Mono-Dev-f1517221.html at Nabble.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] XML Schema compatibility
Hi, That rather sounds like a bug. Could you file a bug with relavant schema (maybe link to that, as it sounds like something you can't share publicly) and something like stack trace if available? (Without the actual program, I'm not sure if it is about System.Xml.dll implementation. If it is about XmlSchema, there are still two ways to parse it - XmlSchema.Read() and XmlSerializer.Deserialize() which are different.) Atsushi Eno Alistair Leslie-Hughes wrote: Hi, I'm using WINE+Mono to install a Microsoft product. However, when it tries to validate the Schema (during the installer) it fails. The cause is a single whitespace when parsing the attribute use, e.g. use='required . Note the space after required. What would be the best solution to ensure compatibility between mono and .NET? Best Regards, Alistair Leslie-Hughes ___ 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 head build problem: System.Reactive.Interfaces.dll strong name problem
I've been fixing the build. Sorry for inconvenience. You can check https://wrench.mono-project.com/Wrench/ for ongoing fixes. In the end of this fixage, Reactive Extensions will be available in mono. Atsushi Eno Jonathan Shore wrote: Mono installation problem. Looks like the System.Reactive assemblies are not signed properly: Failure adding assembly ./../../class/lib/net_4_5/System.Reactive.Interfaces.dll to the cache: Strong name cannot be verified for delay-signed assembly Can someone check in the fix, 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] Presentation Framework
Hi, We wouldn't bring WPF into mono tree unless it becomes usable and solid to some extent. There may be incomplete libraries but that does not justify bringing extraneous components into mcs build. Actually I don't think there is considerable difference between mono and olive to create patches. But if you really have reason, share it, I'm personally all ears :) Atsushi Eno Alistair Leslie-Hughes wrote: Hi, This framework is constantly appearing as an issue when using WINE+mono. What would it take, to get the current implementation of the Presentation Framework from the Olive git repository to be part of the main stream mono repository? Mono currently has classes that aren't implemented completely (or at all), couldn't this be treated the same? Having it part of main repository would make it easier to create patches for. Best Regards, Alistair Leslie-Hughes ___ 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] workflow foundation 4
Cool :) I left my stubs for WF4 in our old olive module which used to be for new API. It could be reused if you want. https://github.com/mono/olive/tree/master/class/System.Activities Atsushi Eno Charles Benassaya wrote: Hi, I'm ceo of Natan, software development company in France. We are interesting in contributing. What is the first step we need to take to get started ? Thanks a lot ___ 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] Handling UTF8 strings containing nul
Hello, I'm not really a runtime hacker, but I think this sort of function could be placed in some file (either existing or new) under mono/utils/ directory. Your glib-incomplatible function could not be tested within eglib tests. Atsushi Eno Weeble wrote: Having diagnosed this bug (when an attribute has a string argument and the string contains nul, it gets truncated), I've been trying to find a way to fix it: https://bugzilla.xamarin.com/show_bug.cgi?id=5732 My first attempt just tried to use the available functions in glib, but it wasn't acceptable because it involved potentially a great many inefficient reallocs: https://github.com/mono/mono/pull/346 In that pull request, Rodrigo Kumpera recommends that since mono has its own implementation of glib, it would be better to introduce a new version of g_utf8_to_utf16 that can handle embedded nuls, which will probably be useful in other places as well. Perhaps naively, I have had a go at implementing this. However, when I tried to add tests for my new function in the eglib test suite, I realised that the tests are compiled and built against the native glib as well, so introducing new tests against a new API results in build failures. You can see what I've tried to do here: https://github.com/weeble/mono/commit/f545596052125b90ebdd0a302fa3473d768f9d52 I'm willing to keep trying at this if anyone is able to give me some pointers. Does eglib's API already diverge from glib? If so, are there any conditional #defines to allow the tests for eglib-specific functions to run only against eglib and not glib? If not, is it definitely okay to introduce divergence? Regards, Weeble. ___ 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 Maintainers list
Here's my list, as far as I can recall now: - System.Xml - System.Xml.Schema - System.Xml.XPath - System.Xml.Xsl - System.Xml.Linq - Relaxng (and co.) - System.Xaml - Unicode related stuff (CompareInfo, Normalization) I may help these too: - i18n, g11n - System.Security.Cryprography.Xml - System.Json Atsushi Eno Alex Rønne Petersen wrote: Hello folks! I'm planning to write and maintain a page listing maintainers of specific parts of Mono. When you have a patch that you wish to contribute, it is usually easier to go directly to the maintainer of the part of the code that you are modifying in order to have it reviewed, rather than posting to the mailing list or #monodev and waiting for someone to notice it. However, it is not currently clear who to go to for the various parts of Mono's source. I'm planning to improve this situation by creating a Maintainers page on the wiki, which I am also committing to keeping up to date. So, in order to put together an initial list, I'm writing to the various dev lists. If you are willing to take maintainership of a particular part of Mono's source base, please reply to this email with a description of the parts of Mono you wish to take maintainership of and your IRC nickname (if any). Essentially, doing this just means that people will be able to go to you when they need patch reviews. Thanks! Regards, Alex ___ 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] Incomplete Microsoft.VisualBasic.Strings.StrConv - Is there any future plan to fullfill this?
Just curious, what's blocking you from implementing those methods by yourself? I'm sure they are taking patches. Atsushi Eno HI All: I noticed that Microsoft.VisualBasic.Strings.StrConv method is not completely implemented, it does not support: VbStrConv.Wide VbStrConv.Narrow VbStrConv.Katakana VbStrConv.Hiragana VbStrConv.SimplifiedChinese VbStrConv.TraditionalChinese That is, Microsoft.VisualBasic.Stirng.StrConv only supports conversion between common string cases (Lower / Upper) but doesn't support any culture specified conversion. Since these culture or region specified conversion are very important when implementing a culture related Analyzer and Tokenizer for Lucene or other full-text search engine, so I'm wondering if there is any future possibility mono team would provide a full implement on this method. Thanks. -- View this message in context: http://mono.1490590.n4.nabble.com/Incomplete-Microsoft-VisualBasic-Strings-StrConv-Is-there-any-future-plan-to-fullfill-this-tp4516089p4516089.html Sent from the Mono - Dev mailing list archive at Nabble.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-dev] System.Json is ready to be replaced
Hello, As many of you guys already know, Microsoft did a huge ASP.NET source release at codeplex[*1]. Since this includes System.Json, I ported this to our class libs to replace existing stuff. There are only a few concerns. - There was some weird test that expects *invalid* JSON syntax. I'm totally inclined to kill it, but since this says as if .NET allowed such broken JSON (this actually fails with this Microsoft implementation), I'd wait for inputs regarding this one for a few days. Looks like it was from Miguel [*2] - I haven't verified builds other than net_2_0, net_4_0 and net_4_5. I have excluded DLR stuff with NET_4_0 so this should build on other profiles though. - The new dll is binary incompatible. I believe that in general Microsoft implementation makes more sense though (lots of explicit operators instead of implicit, Save() only on JsonValue, no TimeSpan support). The new sources are in mcs/class/System.Json-new so the existing System.Jsoncan be easily replaced with it. [*1] http://aspnetwebstack.codeplex.com [*2] https://github.com/mono/mono/blame/master/mcs/class/System.Json/Test/System.Json/JsonValueTest.cs 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] bug 3860 - DirectoryInfo.GetFileSystemInfos returns a subdirectory that has unicode chars with the incorrect name
I'm not very familiar with Macs but maybe because file names under OSX file system are based on Unicode NFD variant? Atsushi Eno Jared Watts wrote: I opened bug 3860 https://bugzilla.xamarin.com/show_bug.cgi?id=3860 earlier today, but I’m curious if anyone on the dev list has run into a similar issue or knows of a workaround. https://bugzilla.xamarin.com/show_bug.cgi?id=3860 Basically, on Mac OS X, Directory.CreateDirectory is used to create a sub directory with Unicode chars in the path (ベー トーヴェン). When that directory is retrieved with DirectoryInfo.GetFileSystemInfos, the Name property is different than what it was created with. The attached .out file has the output from the sample repro program after it was run on Mac OS X. If you want to build the attached repro program: csc /t:exe /out:UnicodeFileRepro.exe Program.cs Thanks for any debugging ideas/workarounds! - jared ___ 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] XPath and Mono
I have never tried but this might be a good starter for those interested
in implementing such enhancements.
http://mvp-xml.sourceforge.net/exslt/
Atsushi Eno
Miguel de Icaza wrote:
Hey guys,
The current XPath stack on Mono is tied up to 1.0 because this is what
.NET had.
Every once in a while we run into useful features from XPath 2.0 that
would be useful to have. And although a complete XPath implementation is
not something that we want to jump into with both feet, it would be useful
to introduce some of the simpler new functions that were part of XPath
2.0,
like the convenience ends-with method instead of the alternative mess:
substring(/myXml/data,
string-length(/myXml/data) - string-length('World') +1
)
Or:
stylesheet or transform : msxsl:script language=C#
implements-prefix=x
xmlns:msxsl=urn:schemas-microsoft-com:xsltpublic bool ends_with
(string s, string target) { return s.EndsWith (target);
}/msxsl:script
and use x:ends_with(foo, bar) instead
___
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] Error using xsd
Yes without the actual xsd we can't do anything. Atsushi Eno Dear all, I'm trying to generate a .cs based on an xsd but I get following error: [s.canepa@proj13 VectorGraphicAnimation]$ xsd Vga.xsd /classes /namespace:VectorGraphicAnimation /language:CS System.InvalidCastException: Cannot cast from source type to destination type. at System.Xml.Serialization.XmlSchemaImporter.CollectAttributeUsesNonOverlap (System.Xml.Schema.XmlSchemaObjectCollection src, System.Xml.Serialization.ClassMap map) [0x0] infilename unknown:0 at System.Xml.Serialization.XmlSchemaImporter.ImportAttributes (System.Xml.XmlQualifiedName typeQName, System.Xml.Serialization.ClassMap cmap, System.Xml.Schema.XmlSchemaObjectCollection atts, System.Xml.Schema.XmlSchemaAnyAttribute anyat, System.Xml.Serialization.CodeIdentifiers classIds) [0x0] in filename unknown:0 at System.Xml.Serialization.XmlSchemaImporter.BuildClassMap (System.Xml.Serialization.XmlTypeMapping map, System.Xml.XmlQualifiedName typeQName, System.Xml.Schema.XmlSchemaComplexType stype) [0x0] infilename unknown:0 at System.Xml.Serialization.XmlSchemaImporter.BuildPendingMaps () [0x0] infilename unknown:0 at System.Xml.Serialization.XmlSchemaImporter.ImportTypeCommon (System.Xml.XmlQualifiedName name, System.Xml.XmlQualifiedName qname, System.Xml.Schema.XmlSchemaType stype, Boolean isNullable) [0x0] in filename unknown:0 at System.Xml.Serialization.XmlSchemaImporter.ImportTypeMapping (System.Xml.XmlQualifiedName name) [0x0] infilename unknown:0 at Mono.Util.Driver.GenerateClasses () [0x0] infilename unknown:0 at Mono.Util.Driver.Run (System.String[] args) [0x0] infilename unknown:0 at Mono.Util.Driver.Main (System.String[] args) [0x0] infilename unknown:0 [s.canepa@proj13 VectorGraphicAnimation]$ What's going wrong? If you need I can provide the XSD. Microsoft xsd utility generates a correct cs I can use with mono but I would like to develop on Linux with mono. Bye Stefano ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WCF Error Deserializing SOAP Reply
Hello, Without code, we cannot give any thoughts. Atsushi Eno On 2011/08/26 6:49, blaynebayer wrote: I get the following error when performing a wcf client request to a third party web service using soap: Read by order only possible for encoded/bare format : at System.Xml.Serialization.ClassMap.GetElement (Int32 index) I have tried adding the web reference both in visual studio and in MonoDevelop with the same results. I am using the latest version of Mono (2.10.4) Has anyone seen this before? I have been banging my head against the wall for hours on this one and haven't got a clue. Thanks in advance -- View this message in context: http://mono.1490590.n4.nabble.com/WCF-Error-Deserializing-SOAP-Reply-tp3770895p3770895.html Sent from the Mono - Dev mailing list archive at Nabble.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] ASM within C# fails in mono, runs in .NET
Exactly. Though if there is .NET documentation, JIT hackers can read them and it might be still able to consider possible implementation. I doubt that could happen though. Calling conventions differ in each platform, compiler toolschains etc. Maybe not completely impossible, but too fruitless. Atsushi Eno On 2011/08/23 1:32, Jb Evain wrote: What Atsushi means is that this piece of code is exploiting a private implementation detail of the .net framework, so no wonder it doesn't «work» on Mono. On Tue, Aug 23, 2011 at 10:28 AM, Stefanos A.stapos...@gmail.com wrote: 2011/8/23 Atsushi Enoatsushi...@veritas-vos-liberabit.com I wonder where the corresponding sections in ECMA CLI specification or .NET documentation that mentions those functions shown in the code are. Atsushi Eno On 2011/08/22 19:21, Brandon Perry wrote: Hi, The following link contains code that runs just fine in .NET on win 7. However, when run in mono from the same win 7 machine, it crashes. It also crashes in 2.6.7 on ubuntu. http://www.atrevido.net/blog/PermaLink.aspx?guid=ac03f447-d487-45a6-8119-dc4fa1e932e1 Are you running in x86 or x64 mode? IIRC, Mono always runs as AnyCPU, so it will default to x64 if your OS is x64. VS2010 defaults to x86. ___ 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] ASM within C# fails in mono, runs in .NET
I wonder where the corresponding sections in ECMA CLI specification or .NET documentation that mentions those functions shown in the code are. Atsushi Eno On 2011/08/22 19:21, Brandon Perry wrote: Hi, The following link contains code that runs just fine in .NET on win 7. However, when run in mono from the same win 7 machine, it crashes. It also crashes in 2.6.7 on ubuntu. http://www.atrevido.net/blog/PermaLink.aspx?guid=ac03f447-d487-45a6-8119-dc4fa1e932e1 ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] XmlTextReader problems in mono 2.10.2
I just confirmed that it does not reproduce (I am pretty sure it must not, as such problematic error would have flooded this list). If you still think there is bug, come up with the problematic test xml stream and corresponding code that creates the actual IFXstream. Atsushi Eno Hi, I'm having problems reading UTF-8 encoded XML files, only in mono on Linux and MacOSX (2.10.2 and 2.10.1 respectively). 2.10.2 on Windows 7 64 bit runs just fine, as does .NET The issue is that the XmlTextReader can't open an XML file with UTF-8 encoding, it comes up with an old error, '?' is Expected as Mono.Xml2.XmlTextReader.Expect. This seems true of any Xml file, as long as it is UTF-8 encoded, which I need for multiple language support, as I need translations inside the single XMl file. I am using the following code to initialise the XmlTextReader: XmlReaderSettings settings = new XmlReaderSettings(); settings.ConformanceLevel = ConformanceLevel.Auto; settings.IgnoreWhitespace = true; settings.IgnoreComments = true; settings.ValidationType = ValidationType.None; XmlReader reader = XmlReader.Create(IFXstream, settings); XmlDocument IFXmodel = new XmlDocument(); IFXmodel.Load(reader); Setting the ConformanceLevel.Auto fixed it running in Mono on Windows, but still left it broken on Linux and MacOSX. I tried converting the files to UTF-32, but then I just get a NullReferenceException. Converting to Western ISO won't work as gedit reports there are characters in the file that will be lost in the conversion. Any thoughts? Cheers, Euan. ___ 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 NUnit test upgrade task force
Hi, That spreadsheet is, well, obsoleted. Sorry I should have updated it with some comments. The latest effort is beyond that phase. We can successfully compile our unit tests using nunit 2.6 preview, but turned out that there are lots of new nunit test failures. For details, read this: http://mono.1490590.n4.nabble.com/incomplete-nunit26-migration-patch-td3430831.html The situation has not been changed since that email (sadly... ;) Atsushi Eno Hi, I'd like to see Monodevelop to integrate NUnit 2.5, but I was told (on monodevelop irc channel) that a requirement for such a transition is to complete the porting of the mono unit tests. I've found this spreadsheet (https://spreadsheets.google.com/a/tesio.it/pub?key=0ArFcR9McaFqmcmtXbC1aUUhKdmN1NnRrSk9lRkZnM0Ehl=enoutput=htmlcid=1304800261064-137 https://spreadsheets.google.com/a/tesio.it/pub?key=0ArFcR9McaFqmcmtXbC1aUUhKdmN1NnRrSk9lRkZnM0Ehl=enoutput=htmlcid=1304800261064-137) but I can't find where progressions are tracked. Does someone has more informations? I tried to open mcs\class\corlib\Test\Mscorlib.Test20.sln on Monodevelop (master from github) and it doesn't work (due to an unknown ProjectTypeGuid). The same for VS2010 express. Giacomo ___ 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 NUnit test upgrade task force
Hi, That spreadsheet is, well, obsoleted. Sorry I should have updated it with some comments. The latest effort is beyond that phase. We can successfully compile our unit tests using nunit 2.6 preview, but turned out that there are lots of new nunit test failures. For details, read this: http://mono.1490590.n4.nabble.com/incomplete-nunit26-migration-patch-td3430831.html The situation has not been changed since that email (sadly... ;) Atsushi Eno Hi, I'd like to see Monodevelop to integrate NUnit 2.5, but I was told (on monodevelop irc channel) that a requirement for such a transition is to complete the porting of the mono unit tests. I've found this spreadsheet (https://spreadsheets.google.com/a/tesio.it/pub?key=0ArFcR9McaFqmcmtXbC1aUUhKdmN1NnRrSk9lRkZnM0Ehl=enoutput=htmlcid=1304800261064-137 https://spreadsheets.google.com/a/tesio.it/pub?key=0ArFcR9McaFqmcmtXbC1aUUhKdmN1NnRrSk9lRkZnM0Ehl=enoutput=htmlcid=1304800261064-137) but I can't find where progressions are tracked. Does someone has more informations? I tried to open mcs\class\corlib\Test\Mscorlib.Test20.sln on Monodevelop (master from github) and it doesn't work (due to an unknown ProjectTypeGuid). The same for VS2010 express. Giacomo ___ 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 NUnit test upgrade task force
Hi, That spreadsheet is, well, obsoleted. Sorry I should have updated it with some comments. The latest effort is beyond that phase. We can successfully compile our unit tests using nunit 2.6 preview, but turned out that there are lots of new nunit test failures. For details, read this: http://mono.1490590.n4.nabble.com/incomplete-nunit26-migration-patch-td3430831.html The situation has not been changed since that email (sadly... ;) Atsushi Eno Hi, I'd like to see Monodevelop to integrate NUnit 2.5, but I was told (on monodevelop irc channel) that a requirement for such a transition is to complete the porting of the mono unit tests. I've found this spreadsheet (https://spreadsheets.google.com/a/tesio.it/pub?key=0ArFcR9McaFqmcmtXbC1aUUhKdmN1NnRrSk9lRkZnM0Ehl=enoutput=htmlcid=1304800261064-137 https://spreadsheets.google.com/a/tesio.it/pub?key=0ArFcR9McaFqmcmtXbC1aUUhKdmN1NnRrSk9lRkZnM0Ehl=enoutput=htmlcid=1304800261064-137) but I can't find where progressions are tracked. Does someone has more informations? I tried to open mcs\class\corlib\Test\Mscorlib.Test20.sln on Monodevelop (master from github) and it doesn't work (due to an unknown ProjectTypeGuid). The same for VS2010 express. Giacomo ___ 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 NUnit test upgrade task force
Hi, That spreadsheet is, well, obsoleted. Sorry I should have updated it with some comments. The latest effort is beyond that phase. We can successfully compile our unit tests using nunit 2.6 preview, but turned out that there are lots of new nunit test failures. For details, read this: http://mono.1490590.n4.nabble.com/incomplete-nunit26-migration-patch-td3430831.html The situation has not been changed since that email (sadly... ;) Atsushi Eno Hi, I'd like to see Monodevelop to integrate NUnit 2.5, but I was told (on monodevelop irc channel) that a requirement for such a transition is to complete the porting of the mono unit tests. I've found this spreadsheet (https://spreadsheets.google.com/a/tesio.it/pub?key=0ArFcR9McaFqmcmtXbC1aUUhKdmN1NnRrSk9lRkZnM0Ehl=enoutput=htmlcid=1304800261064-137 https://spreadsheets.google.com/a/tesio.it/pub?key=0ArFcR9McaFqmcmtXbC1aUUhKdmN1NnRrSk9lRkZnM0Ehl=enoutput=htmlcid=1304800261064-137) but I can't find where progressions are tracked. Does someone has more informations? I tried to open mcs\class\corlib\Test\Mscorlib.Test20.sln on Monodevelop (master from github) and it doesn't work (due to an unknown ProjectTypeGuid). The same for VS2010 express. Giacomo ___ 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] XmlException : DocumentType cannot be imported.
Hello, importNode() on DocumentType is invalid in DOM Level 2 Core specification[*1], that's why it had been rejected. It can be now imported in git (master and mono-2-10). [*1] http://www.w3.org/TR/DOM-Level-2-Core/core.html#i-Document Atsushi Eno (2011/05/18 21:05), Vincent DARON wrote: HI all, I've problem while cloning XmlDocument containing a DocumentType. Code to reproduce the error : //Sample file can be found at : http://www.recordare.com/sites/default/files/MozaVeilSample.xml XmlDocument doc = new XmlDocument(); doc.Load(MozaVeilSample.xml); XmlNode d2 = doc.CloneNode(true); It works under MS Framework.NET 4. My mono setup: Mono JIT compiler version 2.10.2 (tarball Wed Apr 27 09:16:42 UTC 2011) Copyright (C) 2002-2011 Novell, Inc and Contributors. www.mono-project.com TLS: __thread SIGSEGV: altstack Notifications: epoll Architecture: amd64 Disabled: none Misc: softdebug LLVM: supported, not enabled. GC:Included Boehm (with typed GC and Parallel Mark) Any help welcome ! Regards, Vincent ___ 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] MessageHeader.GetUntypedHeader throw exception
It's just a bug, so please file one on https://bugzilla.novell.com.
Atsushi Eno
(2011/04/21 18:26), Cocai wrote:
In a simple service like
[ServiceContract]
public interface IMyService
{
[OperationContract]
void Request(Message msg);
}
if is added a System.ServiceModel.MessageHeader to the
System.ServiceModel.Channels.Message by typed header in this way:
var msg = Message.CreateMessage(MessageVersion.Default,
http://tempuri.org/IService/Request;, My Body);
var value = TestHeader1;
var header = new MessageHeaderstring(value);
var h2 = header.GetUntypedHeader(HeaderName, http://tempuri.org/;);
msg.Headers.Add(h2);
when calling the service method Request(msg) in mono is throw an exception,
but if the header is added by:
var h2 = MessageHeader.CreateHeader(HeaderName, http://tempuri.org/;,
value );
without the use of typed header, all goes right.
The exception throw is:
System.ArgumentNullException has been thrown
Argument cannot be null.
Parameter name: text
at System.Xml.XmlBinaryDictionaryWriter.WriteString (System.String text)
[0x6] in
/usr/src/packages/BUILD/mono-2.10.1/mcs/class/System.Runtime.Serialization/System.Xml/XmlBinaryDictionaryWriter.cs:719
at System.Xml.XmlDictionaryWriter.WriteAttributeString (System.String
prefix, System.Xml.XmlDictionaryString localName,
System.Xml.XmlDictionaryString namespaceUri, System.String value) [0x9]
in
/usr/src/packages/BUILD/mono-2.10.1/mcs/class/System.Runtime.Serialization/System.Xml/XmlDictionaryWriter.cs:166
at System.ServiceModel.Channels.MessageHeader.WriteHeaderAttributes
(System.Xml.XmlDictionaryWriter writer,
System.ServiceModel.Channels.MessageVersion version) [0x0009a] in
/usr/src/packages/BUILD/mono-2.10.1/mcs/class/System.ServiceModel/System.ServiceModel.Channels/MessageHeader.cs:178
at System.ServiceModel.Channels.MessageHeader.OnWriteStartHeader
(System.Xml.XmlDictionaryWriter writer,
System.ServiceModel.Channels.MessageVersion version) [0x00082] in
/usr/src/packages/BUILD/mono-2.10.1/mcs/class/System.ServiceModel/System.ServiceModel.Channels/MessageHeader.cs:131
at System.ServiceModel.Channels.MessageHeader.WriteStartHeader
(System.Xml.XmlDictionaryWriter writer,
System.ServiceModel.Channels.MessageVersion version) [0x0] in
/usr/src/packages/BUILD/mono-2.10.1/mcs/class/System.ServiceModel/System.ServiceModel.Channels/MessageHeader.cs:197
at System.ServiceModel.Channels.MessageHeaders.WriteStartHeader (Int32
index, System.Xml.XmlDictionaryWriter writer) [0x0003e] in
/usr/src/packages/BUILD/mono-2.10.1/mcs/class/System.ServiceModel/System.ServiceModel.Channels/MessageHeaders.cs:300
at System.ServiceModel.Channels.MessageHeaders.WriteHeader (Int32 index,
System.Xml.XmlDictionaryWriter writer) [0x00016] in
/usr/src/packages/BUILD/mono-2.10.1/mcs/class/System.ServiceModel/System.ServiceModel.Channels/MessageHeaders.cs:268
at System.ServiceModel.Channels.Message.OnWriteMessage
(System.Xml.XmlDictionaryWriter writer) [0x00047] in
/usr/src/packages/BUILD/mono-2.10.1/mcs/class/System.ServiceModel/System.ServiceModel.Channels/Message.cs:256
at System.ServiceModel.Channels.Message.WriteMessage
(System.Xml.XmlDictionaryWriter writer) [0x00026] in
/usr/src/packages/BUILD/mono-2.10.1/mcs/class/System.ServiceModel/System.ServiceModel.Channels/Message.cs:170
at System.ServiceModel.Channels.BinaryMessageEncoder.WriteMessage
(System.ServiceModel.Channels.Message message, System.IO.Stream stream)
[0x0002a] in
/usr/src/packages/BUILD/mono-2.10.1/mcs/class/System.ServiceModel/System.ServiceModel.Channels/BinaryMessageEncoder.cs:118
at System.ServiceModel.Channels.TcpBinaryFrameManager.WriteSizedMessage
(System.ServiceModel.Channels.Message message) [0x00093] in
/usr/src/packages/BUILD/mono-2.10.1/mcs/class/System.ServiceModel/System.ServiceModel.Channels/TcpBinaryFrameManager.cs:389
at System.ServiceModel.Channels.TcpDuplexSessionChannel.Send
(System.ServiceModel.Channels.Message message, TimeSpan timeout) [0x00076]
in
/usr/src/packages/BUILD/mono-2.10.1/mcs/class/System.ServiceModel/System.ServiceModel.Channels/TcpDuplexSessionChannel.cs:150
at System.ServiceModel.MonoInternal.ClientRuntimeChannel.RequestCorrelated
(System.ServiceModel.Channels.Message msg, TimeSpan timeout, IOutputChannel
channel) [0x6] in
/usr/src/packages/BUILD/mono-2.10.1/mcs/class/System.ServiceModel/System.ServiceModel/ClientRuntimeChannel.cs:587
at System.ServiceModel.MonoInternal.ClientRuntimeChannel.Request
(System.ServiceModel.Channels.Message msg, TimeSpan timeout) [0x00019] in
/usr/src/packages/BUILD/mono-2.10.1/mcs/class/System.ServiceModel/System.ServiceModel/ClientRuntimeChannel.cs:581
at System.ServiceModel.MonoInternal.ClientRuntimeChannel.Request
(System.ServiceModel.Description.OperationDescription od, System.Object[]
parameters) [0x00066] in
/usr/src/packages/BUILD/mono-2.10.1/mcs/class/System.ServiceModel/System.ServiceModel/ClientRuntimeChannel.cs:534
Re: [Mono-dev] String.Compare bug
It is now fixed in git. If you would like to see what's inside the sausage: https://github.com/mono/mono/commit/8277f4a NET is too inconsistent on how to process \0 in Compare(), IndexOf() and LastIndexOf(). IMO We should totally switch to .NET 4's strategy to eliminate extraneous misuse of CompareInfo. Atsushi Eno (2011/04/14 16:02), Nicklas Overgaard wrote: Hi, It's now filed as bug #687444 /Nicklas On Wed, 2011-04-13 at 17:56 -0300, Rodrigo Kumpera wrote: Please file a bug report so this bug isn't forgotten. On Wed, Apr 13, 2011 at 3:52 PM, Nicklas Overgaardnick...@isharp.dk wrote: Hi again, The previously attached patch does not apply for some reason. A new one is attached here. Sorry about that. /Nicklas On Wed, 2011-04-13 at 18:05 +0200, Nicklas Overgaard wrote: Hi mono devers! I discovered a bug in String.Compare when using a UTF8 string created from a byte array with a zero-byte at the end. It's converted to the same string on both .net and mono, however, String.Compare on .net is different from String.Compare on mono. The issue is the following: Mono reports 1 on the string compare, signaling that the converted string is larger than the hard-coded string I compare it to. And it kinda is - the byte array is converted to %EOF\0 and the hardcoded string is just %EOF - but .net manages to ignore the '\0' when doing the compare, which results in 0 (equal strings). Attached is a patch, which adds a test-case to 'mcs/class/corlib/Test/System' which shows the issue - CompareNotWorking3 to follow the lingo :) I have tried to track the issue down myself in String.Compare, but I gave up due to the complexity of the underlying code. As a final note, I'm running with UTF8 culture on my Linux box, where the issue is showing up. Best regards, Nicklas Overgaard ___ 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 ___ 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 fix TextWriterTraceListener disposal problem
Hey, (2011/04/15 6:31), Jonathan Pryor wrote: On Apr 13, 2011, at 4:06 AM, Atsushi Eno wrote: Do you have any ideas how to solve this problem? Is it actually a problem? :-) Sadly yes... it blocks us from creating useful WCF diagnostic xml logs. The reason I ask is that I vaguely recall testing the same behavior under .NET at the time (circa 2002?), and .NET behaved the same way -- the stream was not flushed. I've never seen such a problem in .NET 3.0, 3.5 and 4.0. MS probably fixed it. Furthermore, the only solution I know of to fix this (or knew of circa 2002), was to use a finalizer on TraceListener, which MSDN states TraceListener does not provide. As mentioned in my first post, the finalizer approach doesn't work. The Stream object could be already finalized before the TextWriter is disposed. Consequently, I believe that TraceListener is not supposed to flush the stream at all, and if you really want the stream to be flushed you should set Trace.AutoFlush=true, either programmatically or via .config file; MSDN kindly provides the .config file snippet here: http://msdn.microsoft.com/en-us/library/system.diagnostics.tracelistener.aspx Autoflush does not work for XmlWriterTraceListener, because its Dispose() calls XmlWriter.Close() which gives additional outputs (enclosing EndElements) to the TextWriter. Here again, the TextWriter could be GC-ed before XmlWriter is being disposed. Though if there is no viable approach, I'd take another approach, to create my own critical-finalizable Stream, TextWriter and XmlWriter which refers each other. I wanted to confirm there is no easier way, as it is messy :/ 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] how to fix TextWriterTraceListener disposal problem
Ah, nm, there actually wasn't any wrapper element to single log entry. I thought they were wrapped by an element for each running process. So, Flush() would mostly work. That does not solve custom trace listener, but I don't care :P Atsushi Eno (2011/04/15 12:36), Atsushi Eno wrote: Hey, (2011/04/15 6:31), Jonathan Pryor wrote: On Apr 13, 2011, at 4:06 AM, Atsushi Eno wrote: Do you have any ideas how to solve this problem? Is it actually a problem? :-) Sadly yes... it blocks us from creating useful WCF diagnostic xml logs. The reason I ask is that I vaguely recall testing the same behavior under .NET at the time (circa 2002?), and .NET behaved the same way -- the stream was not flushed. I've never seen such a problem in .NET 3.0, 3.5 and 4.0. MS probably fixed it. Furthermore, the only solution I know of to fix this (or knew of circa 2002), was to use a finalizer on TraceListener, which MSDN states TraceListener does not provide. As mentioned in my first post, the finalizer approach doesn't work. The Stream object could be already finalized before the TextWriter is disposed. Consequently, I believe that TraceListener is not supposed to flush the stream at all, and if you really want the stream to be flushed you should set Trace.AutoFlush=true, either programmatically or via .config file; MSDN kindly provides the .config file snippet here: http://msdn.microsoft.com/en-us/library/system.diagnostics.tracelistener.aspx Autoflush does not work for XmlWriterTraceListener, because its Dispose() calls XmlWriter.Close() which gives additional outputs (enclosing EndElements) to the TextWriter. Here again, the TextWriter could be GC-ed before XmlWriter is being disposed. Though if there is no viable approach, I'd take another approach, to create my own critical-finalizable Stream, TextWriter and XmlWriter which refers each other. I wanted to confirm there is no easier way, as it is messy :/ Atsushi Eno ___ 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] how to fix TextWriterTraceListener disposal problem
Hello, I'm asking for some advice. I was debugging some System.Diagnostics.Trace stuff and noticed that our TextWriterTraceListener does not flush the stream correctly when our program terminates. It is because the TextWriter's Flush or Close is never called while Stream is closed (typical forgot to dispose issue). But I couldn't find how to safely invoke this close method while the stream is alive. Do you have any ideas how to solve this problem? (I already tried to use AppDomain.DomainUnload on the default appdomain, which was wrong, and tried to create CriticalFinalizerObject-based wrapper for the TraceListener, which was wrong too as the stream could be already GC-ed). Atsushi Eno ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] (incomplete) nunit26 migration patch
Hello, Today I was trying to see how many of our corlib tests fail on .NET 4, and after seeing couple of blockers I (again) tried to migrate our nunit from 2.4.8 to the latest 2.6 snapshot build. This time I added Assertion.cs to our tests (as Charlie suggested earlier) and make test NO_DIR_CHECK=1 was successfully done at mono/mcs only with small changes. I have already committed a couple of changes in our tests in git master. Here are the files to try out: - http://dl.dropbox.com/u/493047/2011/04/Assertion.cs Put this under mono/mcs/build/common directory. - http://dl.dropbox.com/u/493047/2011/04/mono-nunit26.tar.bz2 Extract this under mono/mcs. Like we have nunit24, there will be nunit26. - http://dl.dropbox.com/u/493047/2011/04/migrate-nunit-2.6.patch Apply this patch in mono master tree. - http://dl.dropbox.com/u/493047/2011/04/notes.txt Some notes (you don't really need it). Now, it cannot be applies to our tree as this nunit26 brought some regressions. So far I tried only corlib and Mono.Security (which had some test changes and I wanted to make sure to not regress as an example). It does not seem to be very simple to fix all of those and test every assembly in our class libs, but if anyone can try and come up with fixes that makes tests pass on both 2.6 and 2.4, that would be great :) To switch to nunit24, just revert mcs/Makefile and mcs/build/tests.make and make sure to rebuild mcs/nunit24. BTW after marking some blocking tests as NotDotNet, make run-test-ondotnet now passes in corlib (with tons of failures...) I posted my results to monobin: http://monobin.com/__m20041c31 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] Fix contract description for contracts with deep inheritance hierarchy
Thanks for the patch. I have locally applied it to not forget it, and will examine and commit if it does not regress. (As I posted earlier WCF work is suspended until build gets fixed.) Atsushi Eno (2011/03/25 18:46), Peter Gerbrandt wrote: Hello everyone, ContractDescriptionGeneratior currently adds operations multiple times to the ContractDescription if the contract inheritance hierarchy is deeper than one level. My pragmatic solution is to check if the operation has already been added to the ContractDescription. Attached a patch containing unit test and code. Peter ___ 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] WCF work has been stopped due to some reflection regression
I have almost explained in the subject, but any WCF effort has been stopped for weeks due to repeating regressions in base stack. Current one is related to some assembly loader issue I reported to the team earlier on 18th. So please don't expect any bugfixes until it gets fixed. Atsushi Eno Guys, After having Gonzalo's threadpool fix, Windows build is *still* broken regarding NUnit tests. It is rather new regression happened on Mar. 10th or 11th. The error is like: 170) MonoTests.System.ServiceModel.ServiceHostTest.InstanceWithSingletonMode : System.MissingMethodException : Method not found: 'System.Configuration.IConfigurationSectionHandler.Create'. (Gonzalo guessed it is because it somehow loads 2.0 library instead of 4.0.) It is not only about WCF. I found the same error at System.Transaction: http://build.mono-project.com/ViewWorkTable.aspx?lane_id=40host_id=8command_id=409 System.ServiceModel had been broken too long so I couldn't narrow down the regression point, but from System.Transaction this happened between 5167cc3d and 25e2b767. I don't want to spend my whole hacking days again. This sort of regressions always caused significant delay on WCF work. Someone else, not always me, should cost binary searching this sort of Windows build regression every time. 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] Faster
Agreed, though the suggestion may still work if the type has
op_Equality() overload.
Atsushi Eno
(2011/03/25 1:31), Stifu wrote:
From my experience, null checks are really, really cheap, to the point I've
had troubles measuring any difference between code paths with and without
null checks. So, to me, this sounds like more troubles than it's worth, and
time better spent elsewhere. But for the hell of it, it could be measured to
check what the possible gains are.
Steve Bjorg wrote:
Is the cost of the if-null check greater than setting up an exception
catch handler?
- Steve
-
Steve G. Bjorg
MindTouch
San Diego, CA
619.795.8459 office
425.891.5913 mobile
http://twitter.com/bjorg
On Mar 24, 2011, at 9:00 AM, Miguel de Icaza wrote:
gt; Hello guys,
gt;
gt; Today in the shower I had an idea that I believe we could use to
gt; improve the performance of our class library code.
gt;
gt; Plenty of our class library code has code like this:
gt;
gt; void Foo (Something x)
gt; {
gt;if (x == null)
gt;throw new ArgumentNullException (quot;xquot;);
gt;x.DoSomething ();
gt;x.AndThenMore ();
gt; }
gt;
gt; Arguably, if this could be inlined, and the JIT could prove that x is
gt; not null, we would skip the first test, for example:
gt;
gt; Foo (new Something ());
gt;
gt; But this is the exception, in general, the JIT would not be able to
gt; know this kind of information for even trivial uses like:
gt;
gt; Foo (Bar.GetSomething ());
gt;
gt; Rendering the optimization not very effective.
gt;
gt; But what if we changed our code in Foo across our class libraries to
gt; do this instead:
gt;
gt; void Foo (Something x)
gt; {
gt;try {
gt;x.DoSomething ();
gt;} catch (NullReferenceException e){
gt;if (x == null)
gt; throw new ArgumentNullException (quot;xquot;);
gt;else
gt; throw;
gt;}
gt;x.AndThenMore ();
gt; }
gt;
gt; This has the advantage that the test for the value ofquot;xquot;
being null
gt; is delayed until we actually need it.The downside of course is
gt; that DoSomething could actually take other forms and might end up
gt; running code that we do not need before it touches x, for example,
gt; this would be a problem:
gt;
gt; // We should never add null values.
gt; void AddToCache (Something x)
gt; {
gt;cache.Add (x);
gt; }
gt;
gt; void Foo (Something x)
gt; {
gt; if (x == null)
gt; throw new ArgumentNullException (quot;xquot;);
gt; AddToCache (x);
gt; }
gt;
gt; If we rewrite the above code, we would end up with a bug like the one
gt; I described.
gt;
gt; Miguel
gt; ___
gt; Mono-devel-list mailing list
gt; Mono-devel-list@lists.ximian.com
gt; 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
--
View this message in context:
http://mono.1490590.n4.nabble.com/Faster-tp3402943p3403041.html
Sent from the Mono - Dev mailing list archive at Nabble.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-dev] threadpool win32 breakage, getting worse
Gonzalo, Can you please fix Windows threadpool issue first before it becomes worse than the previous state that we could only revert it to 32b3b31? Now we cannot even revert it to that revision: threadpool.c:2025: error: too few arguments to function `mono_thread_create_internal' threadpool.c:2027: error: too few arguments to function `mono_thread_create_internal' threadpool.c: In function `ves_icall_System_Threading_ThreadPool_SetMaxThreads': threadpool.c:2048: warning: passing arg 1 of `InterlockedExchange' from incompatible pointer type threadpool.c:2049: warning: passing arg 1 of `InterlockedExchange' from incompatible pointer type make[3]: *** [libmonoruntime_la-threadpool.lo] Error 1 make[3]: Leaving directory `/home/atsushi/svn/mono/mono/metadata' Now WCF is not hackable state again. 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] Named Pipes in Mono
This Windows-specific API is not implemented (note that there are some
*not working* code).
Atsushi Eno
(2011/03/11 8:08), Ondrej wrote:
Hello,
I am trying to port my .Net application to Mono 2.6.4.
The problem I am facing is, that I am not able to send data via the named
pipe by using NamedPipeClientStream.
If I write to the pipe from the .Net application, the message is received
under Mono running service (using NamedPipeServerStream).
If I write to the pipe from the Mono application, the connection is open,
then the message is sent, but it is never received.
The sending part is like this:
using (NamedPipeClientStream aNamedPipeClientStream = new
NamedPipeClientStream(myServerName, myPipeName, PipeDirection.Out))
{
aNamedPipeClientStream.Connect(myTimeOut);
aNamedPipeClientStream.Write(aBufferedMessage, 0,
aBufferedMessage.Length);
}
Does anybody has any idea?
--
View this message in context:
http://mono.1490590.n4.nabble.com/Named-Pipes-in-Mono-tp3347043p3347043.html
Sent from the Mono - Dev mailing list archive at Nabble.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] Use DCS OperationBehavior to create serializers in WCF
Hi Peter, Thanks again for the patch. I fixed a bit for moonlight build (you can also assure that by running configure --with-moonlight=yes on topdir and make PROFILE=moonlight_raw at mcs/class/System.ServiceModel) and pushed it into git master and 2-10 branch. Atsushi Eno (2011/03/11 20:49), Peter Gerbrandt wrote: Hello, if I want to use a custom DataContractResolver I need to customize the creation of DataContractSerializer. This is done by applying a DataContractSerializerOperationBehavior. Currently, the OperationBehaviors are not used for creating the actual serializer. I think the right place to do this would be in BaseMessagesFormatter.GetSerializer(). I've tested the attached patch on client and server side. Peter ___ 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] gtkhtml-sharp
Isn't it now part of gnome-desktop-sharp? Atsushi Eno (2011/03/10 7:09), Paul Johnson wrote: Hi, Not sure why, but gtkhtml-sharp seems to be missing from gtk-sharp-2.12.10 Has it been moved elsewhere or is there a missed dependency somewhere that the config file is not picking up on? Paul ___ 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] XmlBinaryDictionaryReader support for value type QNameIndex in attributes
Thanks for the nice patch :) I have checked it in git (with some minor fixes). Atsushi Eno (2011/03/08 17:55), Peter Gerbrandt wrote: Hello, .NET WCF occasionally transmits value type QNameIndex (0xBC) in attribute nodes. I've created a small patch to support this. The unit tests are tested on Mono 2.10 and Microsoft .NET 4. Peter ___ 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] Symmetric contracts in WCF
Thanks for the nice patch :) I have checked it in master and 2.10 branch with cosmetic code formatting fixes. Atsushi Eno (2011/03/04 19:17), Peter Gerbrandt wrote: Hello, I want to use the same interface as service contract and as callback contract. Currently this is not supported by mono while .NET supports it. I've created some unit tests and made two changes to ContractDescriptionGenereation.cs to support symmetric contracts. The unit tests are tested on mono and .NET and the changes seemed not to have caused any regressions. I'm new to mono and git, so I hope my patches work for you. The patches are against mono 2.10.1. Peter ___ 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 2.8.2 - WCF netTcpBinding System.NotImplementedException: UpgradeRequetRecord
Your client is likely .NET and tries to use transport security feature. Turn it off. Note that MoMA is not helpful for WCF very often because it is impossible to examine *.config files and which features those config sections require. Atsushi Eno (2011/03/01 12:58), Compy234 wrote: Hey guys, I am running Mono 2.8.2 on Ubuntu Server 10.10. I have a self-hosted WCF service that communicates with clients over netTcpBinding (no security, very vanilla). The service comes up and establishes a listener just fine. When a client connects this is the error I get: Exception during finishing channel acceptance. System.NotImplementedException: UpgradeRequetRecord at System.ServiceModel.Channels.TcpBinaryFrameManager.ProcessPreambleRecipient (Int32 initialByte) [0x0] infilename unknown:0 at System.ServiceModel.Channels.TcpBinaryFrameManager.ProcessPreambleRecipient () [0x0] infilename unknown:0 at System.ServiceModel.Channels.TcpDuplexSessionChannel.OnOpen (TimeSpan timeout) [0x0] infilename unknown:0 at System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan timeout) [0x0] infilename unknown:0 at System.ServiceModel.Channels.CommunicationObject.Open () [0x0] in filename unknown:0 at System.ServiceModel.Dispatcher.ListenerLoopManager.ChannelAccepted (IChannel ch) [0x0] infilename unknown:0 at System.ServiceModel.Dispatcher.ListenerLoopManager+CreateAcceptorc__AnonStorey1D`1[System.ServiceModel.Channels.IDuplexSessionChannel].m__23 (IAsyncResult result) [0x0] infilename unknown:0 How can I fix this? I am not doing anything fancy in my implementation. This is just a simple netTcpBinding listening for connections with some basic methods (all primitive types). This works fine on Windows and MoMA doesn't see any issues with it (but I know it doesn't drill down that far). Any help is appreciated! ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WCF breakage and Windows build breakage
Some updates: - Thanks to Rodrigo, the PE verifier feature is temporarily disabled. I'm working on the real fixage, but WCF on git master should work now. - I found the cause of the Windows failure. To get WCF working again on Windows, run: git checkout 2670761ee7 mono/metadata/threadpool.c Gonzalo is working on it. Atsushi Eno (2011/02/25 11:32), Atsushi Eno wrote: I forgot a couple of notes: - It should affect only on master, as the verifier fix is only in there. - A quick remedy would be to temporarily revert the verifier fix, if fixing Windows build is not very easy (and fun) task. Atsushi Eno (2011/02/25 11:26), Atsushi Eno wrote: Hello, This message is to alert people that WCF will be broken on git master until Windows build gets fixed enough to run WCF NUnit tests. It had been broken since Feb. 18th as shown in [*1] (snapshot). I'm sure it is not an issue in WCF itself as I had been writing WCF code with older revision of the runtime and other classlibs. Second part is the one that affects all git master users: WCF client proxy generation got broken due to the recent verifier changes as shown in [*2] (snapshot). We internally had discussion and Rodrigo and Marek gave me solution, which needs not a small work to be done. To not abandon interoperability with Windows clients and services, I kept running tests on Windows, so it is essential to get the build working fine. I'll wait for Windows build fix and *then* write new proxy stuff. It won't be done very soon and WCF will be kept broken. [*1] http://dl.dropbox.com/u/493047/2011/02/x2/ViewWorkTable.aspx.htm [*2] http://dl.dropbox.com/u/493047/2011/02/x1/ViewWorkTable.aspx.htm Atsushi Eno ___ 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] WCF and TransportCredentialOnly
Hello, I don't think you really read my message. Atsushi Eno (2011/02/17 0:36), rjhdakota wrote: I am having what I believe is the same problem. You say basic authentication is working, any examples? Our project needs the ability to authorize a connection, and currently we cannot. Here is the code that works on Windows but allows anyone to connect on MONO: Public Sub WCFStartService() ' http service, one-way Dim binding = New BasicHttpBinding(System.ServiceModel.BasicHttpSecurityMode.TransportCredentialOnly) binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Basic Dim address = New Uri(http://192.168.1.129:8080;) ServiceHost = New ServiceHost(GetType(HelloService)) ServiceHost.Credentials.UserNameAuthentication.UserNamePasswordValidationMode = Security.UserNamePasswordValidationMode.Custom ServiceHost.Credentials.UserNameAuthentication.CustomUserNamePasswordValidator = New CustomUserNameValidator ServiceHost.AddServiceEndpoint(GetType(IHelloService), binding, address) ServiceHost.Open() End Sub Public Class CustomUserNameValidator Inherits IdentityModel.Selectors.UserNamePasswordValidator Public Overrides Sub Validate(ByVal userName As String, ByVal password As String) If Nothing = userName OrElse Nothing = password Then Throw New ArgumentNullException() End If If Not (userName = user AndAlso password = pass) Then ' This throws an informative fault to the client. Throw New FaultException(Unknown Username or Incorrect Password) ' When you do not want to throw an infomative fault to the client, ' throw the following exception. ' Throw New SecurityTokenException(Unknown Username or Incorrect Password) End If End Sub End Class ___ 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 TransportCredentialOnly
This is not for general mono users list but for those who hack mono itself. Check mono-list instead and you'll find very similar question there (unless you are the same person who posted that in fact). Atsushi Eno (2011/02/16 5:07), rjhdakota wrote: I am working on a WCF service in MONO and currently testing it under MAC OS. I had 2.8 but updated to the latest in SVN. My service is allowing connections no matter how I set it up. Is user authentication supported? Here is my service, note that it works fine in Windows and I can validate user/pass with my custom validation function. On the MAC, my client always connects, no challenge to the user/pass. Am I missing a property? Public Sub WCFStartService() ' http service, one-way Dim binding = New BasicHttpBinding(System.ServiceModel.BasicHttpSecurityMode.TransportCredentialOnly) binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Basic Dim address = New Uri(http://192.168.1.129:8080;) ServiceHost = New ServiceHost(GetType(HelloService)) ServiceHost.Credentials.UserNameAuthentication.UserNamePasswordValidationMode = Security.UserNamePasswordValidationMode.Custom ServiceHost.Credentials.UserNameAuthentication.CustomUserNamePasswordValidator = New CustomUserNameValidator ServiceHost.AddServiceEndpoint(GetType(IHelloService), binding, address) ServiceHost.Open() End Sub ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] csproj files for Mono's class libraries.
The newer system should be as convenient as dll.sources model. Without as easy step as to add just one line for new Foo.cs in Bar.dll.sources (or more importantly for contribution, FooTest.cs in Bar_test.dll.sources), I'm not likely enthusiastic to contribute new code. So far *.dll.sources could be created like this: ls ../../build/common/*.cs */*.cs | grep -v *-check.cs Foo.dll.sources cd Test; ls */*.cs ../Foo_test.dll.sources; cd .. Atsushi Eno (2011/02/13 12:11), Miguel de Icaza wrote: Hello guys, I have resumed my work on creating visual studio project files for our assemblies. I have checked the solutions, currently these solutions are intended to be used by developers that want to build their code with Visual Studio. Although currently you must invoke msbuild/xbuild or virtual studio on a project-by-project basis, the idea would be to do use these files to drive the entire build process on Windows. Since this is a weekend, I do not have a Windows machine handy to test the process there. Ideally, we can turn this into building Mono entirely using msbuild, which should be a lot faster than using the cygwin/makefile setup. The solution files are generated from the actual configuration data used in the Makefiles, so it should be easy to keep the visual studio solutions in sync with any changes that happens to the makefiles. Currently the process works by extracting the arguments list from an actual build of Mono and this produces the flags in the file mono/msvc/scripts/order.xml. Then the genproj tool in mono/msvc/scripts is used to populate all of the solution files from this input.This means that either a cygwin or Unix system is required to maintain the order.xml file, but with an up-to-date order.xml file, we should be able to keep the build in sync. Would love to hear your feedback Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] csproj files for Mono's class libraries.
I noticed another issue: the project does not support tests. Test project will require NUnit addin (am not sure if it exists for 2010) and thus excludes Express users. But that should not mean that it's okay for Windows-based hackers to totally ignore those NUnit tests. It might be still possible to not be based on nunit adding but rather include a standalone test runner project (executable) that includes all nunit stuff. Atsushi Eno (2011/02/14 18:52), Atsushi Eno wrote: The newer system should be as convenient as dll.sources model. Without as easy step as to add just one line for new Foo.cs in Bar.dll.sources (or more importantly for contribution, FooTest.cs in Bar_test.dll.sources), I'm not likely enthusiastic to contribute new code. So far *.dll.sources could be created like this: ls ../../build/common/*.cs */*.cs | grep -v *-check.cs Foo.dll.sources cd Test; ls */*.cs ../Foo_test.dll.sources; cd .. Atsushi Eno (2011/02/13 12:11), Miguel de Icaza wrote: Hello guys, I have resumed my work on creating visual studio project files for our assemblies. I have checked the solutions, currently these solutions are intended to be used by developers that want to build their code with Visual Studio. Although currently you must invoke msbuild/xbuild or virtual studio on a project-by-project basis, the idea would be to do use these files to drive the entire build process on Windows. Since this is a weekend, I do not have a Windows machine handy to test the process there. Ideally, we can turn this into building Mono entirely using msbuild, which should be a lot faster than using the cygwin/makefile setup. The solution files are generated from the actual configuration data used in the Makefiles, so it should be easy to keep the visual studio solutions in sync with any changes that happens to the makefiles. Currently the process works by extracting the arguments list from an actual build of Mono and this produces the flags in the file mono/msvc/scripts/order.xml. Then the genproj tool in mono/msvc/scripts is used to populate all of the solution files from this input.This means that either a cygwin or Unix system is required to maintain the order.xml file, but with an up-to-date order.xml file, we should be able to keep the build in sync. Would love to hear your feedback Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] build failure on processing NpgsqlState.resx
The latest Windows build is broken at Npgsql in net_2_0 profile. Looks like the build change that switched to use mcs/class/lib/build did it. $ make make all-local make[1]: Entering directory `/home/atsushi/svn/mono/mcs/class/Npgsql' MONO_PATH=./../../class/lib/build;$MONO_PATH /home/atsushi/svn/mono/runtime/mono-wrapper /../../class/lib/build/resgen.exe `echo Npgsql/NpgsqlState.resx | tr '/' ''` Error: Cannot load support for ResX format: Could not load file or assembly 'System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified. make[1]: *** [Npgsql/NpgsqlState.resources] Error 1 make[1]: Leaving directory `/home/atsushi/svn/mono/mcs/class/Npgsql' make: *** [do-all] Error 2 The breakage also appears on wrench (windows-5.1-i586 http://build.mono-project.com/ViewTable.aspx?lane_id=40host_id=8). 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] Broken Linq to XSD managed provider in .Net 4.
Sounds like it's just that those marked as MonoTODO members have cosmetic reasons for those attributes. You should not expect too much on those attributes that they reflect what you think. They are rather used wild-guessing guidelines. There is no toolchain (moma) bug when they are indeed marked. And I won't remove those attributes when there are reasons. Why don't you just *run* it and see if it works or not instead? Atsushi Eno (2011/01/20 22:30), Bob PS Watson wrote: Hi, I tested the xml.schema.linq which is the managed provider for Linq to XSD, has a 3.5 profile dependency. The other dll's pass fine in Moma. How do I go about fixing. Can you give me a path to follow. Is it bug, that Moma is report TODO, when implementation is complete. Thanks. -Original Message- From: Leszek Ciesielski [mailto:skol...@gmail.com] Sent: 20 January 2011 07:34 To: Bob PS Watson Cc: Atsushi Eno; mono-devel-list Subject: Re: [Mono-dev] Broken Linq to XSD managed provider in .Net 4. The NET2 conditional is defined for all build above 1.1 profile (which has now been removed), i.e. 2.0, 3.5 (which is really not a separate profile - just additional libraries) and 4.0. On Thu, Jan 20, 2011 at 3:28 AM, Bob PS Watson scope_cr...@hotmail.com wrote: Hi Atsushi, Thanks for the help. Much appreciated dude. I checked the true, all these calls are surrounded by #if .NET2 conditional. I suspect when the trunk was being coded up to .NET 2 from 1.1 needed it for some reason?; But has been forgotten about from the update to 3.5. See of I raised bug report, to remove the conditionals in .NET 4. Would it sit in Devlopment hell for donkey, or is their any good chance it would get done in a reasonable time frame. Bob. -Original Message- From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com] Sent: 19 January 2011 20:17 To: Bob Watson Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Broken Linq to XSD managed provider in .Net 4. Hi, To get your patches ready, this page would be a good starter. http://mono-project.com/Contributing I'm not sure what you meant on XmlSchemaType.BaseXmlSchemaType, but those 3 members are implemented AFAIK. Atsushi Eno (2011/01/20 3:05), Bob Watson wrote: Hello, I’m developing a multithreaded crossplatform file reader as part of a log management solution. We use linq to XSD to generate IDMEF xml on the fly, as it’s perfomant, and allows positional updates to schema before its serialized. Programing away for 2+ months ran Mona and found these 3 calls which break the provider. I know you probably get a bundle of missing method call emails every day but….. I checked the status page for .Net 4 and they look fairly simple but perhaps not. XmlSchemaType.GetBuiltInSimpleType() in System.Xml.Schema has not been coded and has been flagged as TODO. Also in .NET 2 implemented XmlSchemaType.BaseXmlSchemaType () still not coded for .Mono 4.0 which also Linq to XSD. Same with XmlSchemaDatatype.ChangeType(). I’m also getting this message “We should parse basetype from right to left in 2.0 profile.” Applied on the CodeTypeReference .ctor in System.CodeDom assembly. How do I go about getting these 3 assemblies full patched, to complete implementation. Is there a well defined process for doing it. I just need to get the process to get these calls created. Thanks for the help. Bob. ___ 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] Broken Linq to XSD managed provider in .Net 4.
Hi, To get your patches ready, this page would be a good starter. http://mono-project.com/Contributing I'm not sure what you meant on XmlSchemaType.BaseXmlSchemaType, but those 3 members are implemented AFAIK. Atsushi Eno (2011/01/20 3:05), Bob Watson wrote: Hello, I’m developing a multithreaded crossplatform file reader as part of a log management solution. We use linq to XSD to generate IDMEF xml on the fly, as it’s perfomant, and allows positional updates to schema before its serialized. Programing away for 2+ months ran Mona and found these 3 calls which break the provider. I know you probably get a bundle of missing method call emails every day but….. I checked the status page for .Net 4 and they look fairly simple but perhaps not. XmlSchemaType.GetBuiltInSimpleType() in System.Xml.Schema has not been coded and has been flagged as TODO. Also in .NET 2 implemented XmlSchemaType.BaseXmlSchemaType () still not coded for .Mono 4.0 which also Linq to XSD. Same with XmlSchemaDatatype.ChangeType(). I’m also getting this message “We should parse basetype from right to left in 2.0 profile.” Applied on the CodeTypeReference .ctor in System.CodeDom assembly. How do I go about getting these 3 assemblies full patched, to complete implementation. Is there a well defined process for doing it. I just need to get the process to get these calls created. Thanks for the help. Bob. ___ 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.6.7
You might want to read this:
http://nirajrules.wordpress.com/2009/08/03/mtom-vs-streaming-vs-compression-%E2%80%93-large-attachments-over-wcf/
Atsushi Eno
(2011/01/15 22:19), Joel Caner wrote:
Thank you for your reply. Can you tell me if there is another way to send
large data/file then?..can you provide an example of a client and service?
Thank you again for your time.
Cheers,
-Original Message-
From: Atsushi Eno [mailto:atsushi...@veritas-vos-liberabit.com]
Sent: Saturday, January 15, 2011 3:11 AM
To: joelcaner
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] WCF in Mono 2.6.7
Not sure where the actual error occurs without stack trace, but 2.6 is
too old
for WCF to try anyways.
And Mtom is almost untested so it will cause any kind of problem (never
expected that there are actually people who use it).
Atsushi Eno
(2011/01/14 23:37), joelcaner wrote:
I am having trouble getting WCF working on Mono in Suse Linux 11.3
I have the client as follow:
BasicHttpBinding binding = new BasicHttpBinding();
binding.Security.Mode = BasicHttpSecurityMode.None;
binding.TransferMode = TransferMode.Streamed;
binding.MessageEncoding = WSMessageEncoding.Mtom;
binding.MaxReceivedMessageSize = int.MaxValue;
EndpointAddress address = new
EndpointAddress(http://localhost:5800/DataUploader;);
ChannelFactoryIDataUploader channel = new
ChannelFactoryIDataUploader(binding, address);
IDataUploader uploader = channel.CreateChannel();
try
{
uploader.Upload(File.Open(@G:\anthem-1.5.2.zip,
FileMode.Open, FileAccess.Read));
Console.WriteLine(File uploaded to the server);
Console.ReadLine();
}
catch (Exception ex)
{
Console.Write(ex.Message);
Console.ReadLine();
}
finally
{
((IClientChannel)uploader).Close();
}
I have the following interface:
[ServiceContract]
interface IDataUploader
{
[OperationContract]
void Upload(Stream data);
}
Now the service is as follow on DataUploader.cs:
class DataUploader : IDataUploader
{
#region IDataUploader Members
public void Upload(Stream data)
{
string xmlFile = @c:\temp\uploadedfile + .zip;
using (FileStream fs = new FileStream(xmlFile,
FileMode.Create))
{
int bufferSize = 1 * 1024 * 1024; // 1MB buffer
byte[] buffer = new byte[bufferSize];
int bytes;
while ((bytes = data.Read(buffer, 0, bufferSize)) 0)
{
fs.Write(buffer, 0, bytes);
fs.Flush();
}
}
}
#endregion
}
Now on IDataUploader.cs:
[ServiceContract]
interface IDataUploader
{
[OperationContract]
void Upload(Stream data);
}
On the main.cs I have:
public static void Main (string[] args)
{
ServiceHost host = new
ServiceHost(typeof(DataUploader));
BasicHttpBinding binding = new BasicHttpBinding();
binding.Security.Mode = BasicHttpSecurityMode.None;
binding.TransferMode = TransferMode.Streamed;
binding.MessageEncoding = WSMessageEncoding.Mtom;
binding.MaxReceivedMessageSize = int.MaxValue;
host.AddServiceEndpoint(typeof(IDataUploader), binding, new
Uri(http://localhost:5800/DataUploader;));
ServiceBehaviorAttribute attribute =
(ServiceBehaviorAttribute)host.Description.Behaviors[typeof(ServiceBehaviorA
ttribute)];
attribute.ConcurrencyMode = ConcurrencyMode.Multiple;
attribute.InstanceContextMode = InstanceContextMode.Single;
attribute.IncludeExceptionDetailInFaults = true;
ServiceThrottlingBehavior throttling = new
ServiceThrottlingBehavior();
throttling.MaxConcurrentSessions = 24;
throttling.MaxConcurrentCalls = 24;
host.Description.Behaviors.Add(throttling);
host.Open();
Console.WriteLine(Service Hosted ...);
Console.ReadKey();
host.Close();
}
I have both client and service running on the same system. I get an error:
Object reference not set to an instance of an object error. When I run a
client on a windows system and the service on the linux system I get bad
request(400) error. Can someone help me understand what I am missing
Re: [Mono-dev] WCF in Mono 2.6.7
Not sure where the actual error occurs without stack trace, but 2.6 is
too old
for WCF to try anyways.
And Mtom is almost untested so it will cause any kind of problem (never
expected that there are actually people who use it).
Atsushi Eno
(2011/01/14 23:37), joelcaner wrote:
I am having trouble getting WCF working on Mono in Suse Linux 11.3
I have the client as follow:
BasicHttpBinding binding = new BasicHttpBinding();
binding.Security.Mode = BasicHttpSecurityMode.None;
binding.TransferMode = TransferMode.Streamed;
binding.MessageEncoding = WSMessageEncoding.Mtom;
binding.MaxReceivedMessageSize = int.MaxValue;
EndpointAddress address = new
EndpointAddress(http://localhost:5800/DataUploader;);
ChannelFactoryIDataUploader channel = new
ChannelFactoryIDataUploader(binding, address);
IDataUploader uploader = channel.CreateChannel();
try
{
uploader.Upload(File.Open(@G:\anthem-1.5.2.zip,
FileMode.Open, FileAccess.Read));
Console.WriteLine(File uploaded to the server);
Console.ReadLine();
}
catch (Exception ex)
{
Console.Write(ex.Message);
Console.ReadLine();
}
finally
{
((IClientChannel)uploader).Close();
}
I have the following interface:
[ServiceContract]
interface IDataUploader
{
[OperationContract]
void Upload(Stream data);
}
Now the service is as follow on DataUploader.cs:
class DataUploader : IDataUploader
{
#region IDataUploader Members
public void Upload(Stream data)
{
string xmlFile = @c:\temp\uploadedfile + .zip;
using (FileStream fs = new FileStream(xmlFile, FileMode.Create))
{
int bufferSize = 1 * 1024 * 1024; // 1MB buffer
byte[] buffer = new byte[bufferSize];
int bytes;
while ((bytes = data.Read(buffer, 0, bufferSize)) 0)
{
fs.Write(buffer, 0, bytes);
fs.Flush();
}
}
}
#endregion
}
Now on IDataUploader.cs:
[ServiceContract]
interface IDataUploader
{
[OperationContract]
void Upload(Stream data);
}
On the main.cs I have:
public static void Main (string[] args)
{
ServiceHost host = new
ServiceHost(typeof(DataUploader));
BasicHttpBinding binding = new BasicHttpBinding();
binding.Security.Mode = BasicHttpSecurityMode.None;
binding.TransferMode = TransferMode.Streamed;
binding.MessageEncoding = WSMessageEncoding.Mtom;
binding.MaxReceivedMessageSize = int.MaxValue;
host.AddServiceEndpoint(typeof(IDataUploader), binding, new
Uri(http://localhost:5800/DataUploader;));
ServiceBehaviorAttribute attribute =
(ServiceBehaviorAttribute)host.Description.Behaviors[typeof(ServiceBehaviorAttribute)];
attribute.ConcurrencyMode = ConcurrencyMode.Multiple;
attribute.InstanceContextMode = InstanceContextMode.Single;
attribute.IncludeExceptionDetailInFaults = true;
ServiceThrottlingBehavior throttling = new
ServiceThrottlingBehavior();
throttling.MaxConcurrentSessions = 24;
throttling.MaxConcurrentCalls = 24;
host.Description.Behaviors.Add(throttling);
host.Open();
Console.WriteLine(Service Hosted ...);
Console.ReadKey();
host.Close();
}
I have both client and service running on the same system. I get an error:
Object reference not set to an instance of an object error. When I run a
client on a windows system and the service on the linux system I get bad
request(400) error. Can someone help me understand what I am missing?
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] WCF: InstanceContextMode.PerSession
Ah, thanks, forgot about that ReleaseInstanceMode property ;-) Atsushi Eno (2011/01/11 19:17), Adar Wesley wrote: Hi, I was reading this thread and just by chance was reading up on WCF Services Session instantiation and release today. I thought the following links might be useful to clear up the MS.NET http://MS.NET behavior: Sessions, Instancing, and Concurrency http://msdn.microsoft.com/en-us/library/ms731193.aspx system.servicemodel.operationbehaviorattribute.releaseinstancemode http://msdn.microsoft.com/en-us/library/system.servicemodel.operationbehaviorattribute.releaseinstancemode.aspx system.servicemodel.servicebehaviorattribute.releaseserviceinstanceontransactioncomplete http://msdn.microsoft.com/en-us/library/system.servicemodel.servicebehaviorattribute.releaseserviceinstanceontransactioncomplete.aspx Hope this helps. --- Adar Wesley On Tue, Jan 11, 2011 at 8:07 AM, Atsushi Eno atsushi...@veritas-vos-liberabit.com mailto:atsushi...@veritas-vos-liberabit.com wrote: Hi again, To my understanding, a session (ISession) is usually member of ISessionChannel types, its lifecycle is bound to the channel, and we indeed have such implementation in TcpDuplexSessionChannel. If we got to know .NET behaviors we'll do the same in WCF ;) Atsushi Eno (2011/01/10 0:03), Karsten Fourmont wrote: sigh: it seems no matter how long I wait before making a post to get the details right, still every time something comes up minutes after I hit the send button. So here's a small addition: It doesn't seem very well defined in the WCF documentation if an when Dispose should be called on a service instance. Service classes don't have to be IDisposable. But if they are, .NET invokes Dispose and I think mono should do the same. However exactly when this dispose is supposed to happen is not perfectly clear: http://msdn.microsoft.com/en-us/library/ms733040.aspx states: In the default case, WCF recycles the service object and its context after the session with which the service was associated is closed. So Dispose doesn't have to be called on session termination, but (maybe?) on service channel termination on the server side. Whatever. The service instance just has to be able to find out when it should free the session's resources once the session is closed either by the client or by the server (like due to an inactivity timeout). Atsushi, I definitely don't envy you (or any of the mono team) for having to implement something which is not properly specified. Only Perl's the implementation is the specification seems worse ;-) Great work! Cheers, Karsten ___ 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
Re: [Mono-dev] WCF: InstanceContextMode.PerSession
Hello Karsten, (2011/01/09 23:15), Karsten Fourmont wrote: Hi Atsushi, One (slightly) better approach is to avoid configuration. It is extraneous stack to the actual code implementation for us and often left not-implemented. OK, understood. After changing to configuration in code and tinkering some more I came to the next hurdle: session instance handling. Thanks for the investigation. Well, yes, session instance handling is far from perfect in mono yet (considering that it is server side feature). Currently Mono creates a new instance of the service object for every method call. That's not what's usually desired for sessions. I'm not fully remember about them, but it is probably rather that we lack checks session starts/ends in operation behaviors. We have some basic session management support, but it is only limited to manage TCP channels (as no other supported bindings support sessions). And things were always either tied to Close() at client side, or session shutdown message from client at server side, so it basically worked. On instancing, we take InsntaceContextMode into consideration, and AFAIR at least singleton worked. So, I less doubt lacking support for per-session instancing. from http://msdn.microsoft.com/en-us/library/ms733040.aspx: quote If you use the default instancing behavior in WCF, all calls between a WCF client object are handled by the same service instance. Therefore, at the application level, you can think of a session as enabling application behavior similar to local call behavior. For example, when you create a local object: - A constructor is called. - All subsequent calls made to the WCF client object reference are processed by the same object instance. - A destructor is called when the object reference is destroyed. /quote As usual the details are even more complex as WCF is highly customizable. A helpful read is http://www.pluralsight-training.net/community/blogs/aaron/archive/2006/02/27/19253.aspx But it comes down to this: if you set [ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)] on a service, all client calls in one session should go to the same service instance and the service instance should be disposed when the session ends. Right, that's the expected behavior. I created a Nunit Test (passes on .net fails on mono 2.8.1) for this and filed bug https://bugzilla.novell.com/show_bug.cgi?id=663278 If there's anything I can do to help, just let me know. It's been of great helps. Thanks a lot Karsten :) I'm back on this WCF work this January to complete things like this in the basic WCF stack. This issue is one of good starters. 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: InstanceContextMode.PerSession
Hi again, To my understanding, a session (ISession) is usually member of ISessionChannel types, its lifecycle is bound to the channel, and we indeed have such implementation in TcpDuplexSessionChannel. If we got to know .NET behaviors we'll do the same in WCF ;) Atsushi Eno (2011/01/10 0:03), Karsten Fourmont wrote: sigh: it seems no matter how long I wait before making a post to get the details right, still every time something comes up minutes after I hit the send button. So here's a small addition: It doesn't seem very well defined in the WCF documentation if an when Dispose should be called on a service instance. Service classes don't have to be IDisposable. But if they are, .NET invokes Dispose and I think mono should do the same. However exactly when this dispose is supposed to happen is not perfectly clear: http://msdn.microsoft.com/en-us/library/ms733040.aspx states: In the default case, WCF recycles the service object and its context after the session with which the service was associated is closed. So Dispose doesn't have to be called on session termination, but (maybe?) on service channel termination on the server side. Whatever. The service instance just has to be able to find out when it should free the session's resources once the session is closed either by the client or by the server (like due to an inactivity timeout). Atsushi, I definitely don't envy you (or any of the mono team) for having to implement something which is not properly specified. Only Perl's the implementation is the specification seems worse ;-) Great work! Cheers, Karsten ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] svcutil - assemblyPath support
Thanks, your patch is applied in git master. Atsushi Eno (2011/01/03 2:41), Michel Foucault wrote: Hi, I'm trying to use svcutils (mono 2.8.1). Since it fails with metadataUrl I've try assemblyPath method. It doesn't work either I've modified the code of mcs/tools/svcutil/Driver.cs, it seem working well for assemblyPath. see attachment for the patch. Michel ___ 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: 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
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] 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] 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] 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] 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] 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
