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

MarLOne InfoSeeker002 at gmail.com
Wed Nov 12 10:51:27 UTC 2014

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?


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.

More information about the Mono-devel-list mailing list