[Mono-dev] Mono & .Net difference - handling xs:extension please help

Wed Nov 12 12:15:48 UTC 2014

For completeness sake I tested it on Mono 3.10 and latest master, it throws the same error there too, so it's definitely a bug in Mono :)
-- Alex

Date: Wed, 12 Nov 2014 09:49:34 -0200
From: monoman at gmail.com
To: InfoSeeker002 at gmail.com
CC: mono-devel-list at lists.ximian.com
Subject: Re: [Mono-dev] Mono & .Net difference - handling xs:extension	please help

Probably is the core System.Xml class library assembly that misses some functionality. It is kind of lower priority these days as most people is moving to schema-less serialization with either Xml or JSON.Surely nobody needed to exercise the extension mechanism before, so that's is why it is still broken, that is characteristic of any Open Source project.If you really need it please open an issue, and help pinpoint the real cause for the behavior, better yet, if you can: fix it and send a Pull Request.
Best regards,
Rafael Teixeira
O..:.)oooo

On Wed, Nov 12, 2014 at 8:51 AM, MarLOne <InfoSeeker002 at gmail.com> wrote:
Hello Timotheus,

I have the answer for you.

I have a VM with Mint17 which has Mono runtime 3.2.8 which is one major

version that I reported earlier. So I build a console application to test

using this schema (embedded resource) with this sample instance document.

This also gives me a good test of compatibility that Mono has been

promoting. I then took this console application and run it in my Windows 7

with the most up to date .Net installed. It ran perfectly as expected

verbatim without recompilation.

This therefore indicates the IL code thus generated is not at fault.

I then took this console application and xml document to my Mint 17 and ran

it. As expected, it failed with the same message produced by the old version

of Mono runtime.

Therefore I would dare to claim that the problem exists much further back

and is in the Mono runtime. What I am using is nothing new or even edge

case. In fact, the construct is as old as .Net2.

So what next? If I stay with Mono, to get around this gotcha I have to

abandon a perfectly valid schema (data model). This is placing the cart in

front of the horse.

I opened the instance document in MonoDevelop ver 4.2.2 (yes it is old and

it is because Linux/Mint does not allow me to move to newer version) and

then hit Tools > Xml > Validate. Well the screen lights up like a Christmas

tree and pointing to the same place as I have found.

Even more worryingly, that tool does not even handle the xsi:schemaLocation

hint while Eclipse did that flawlessly.

I appreciate the great work of Open Source in bringing Mono to something

workable. But after falling into holes so many times believing this

"cross-platform development tool", Mono has lost my trust particularly not

knowing where is the next incompatible gotcha! This is no different than a

calculator produces erroneous result with certain expression kind and one

does not know which expression pattern. This problem plus the others that I

have unearthed are seriously matters. I would rather prefer Mono fails to

compile or supporting MS .Net construct (fail early and fail loud) than

slipping in minefield silently like this wasting people's time.

Has this simple scenario been tested?

MarL

--

View this message in context: http://mono.1490590.n4.nabble.com/Mono-Net-difference-handling-xs-extension-please-help-tp4664552p4664559.html

Sent from the Mono - Dev mailing list archive at Nabble.com.

_______________________________________________

Mono-devel-list mailing list

Mono-devel-list at lists.ximian.com

http://lists.ximian.com/mailman/listinfo/mono-devel-list

_______________________________________________
Mono-devel-list mailing list
Mono-devel-list at lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20141112/ac6dcabf/attachment.html>