Re: [Mono-dev] Configuration.HasFile returning wrong value in Mono

[MarLOne]

Hi Eberhard 

Thanks for that very useful link. However, I went there to check the
Configuration.HasFile, the very property that is in question and finding it
has a tick mark next to it which to me means that it is implemented and
tested.

But in my unit test HasFile is true while File.Exists(
configuration.FilePath ) is false confused me. Is there some subtle reason
why Mono in Mint producing this difference? Or Mono has changed the meaning
of HasFile?

Architecturally System.Configuration.DefaultSection seems to be different
too. In Windows the SectionInformation property is part of DefaultSection
class while in Mono it is in its base class.

As a result, the 
http://go-mono.com/status/status.aspx?reference=4.5&profile=4.5&assembly=System.Configuration
<http://go-mono.com/status/status.aspx?reference=4.5&profile=4.5&assembly=System.Configuration>
  
does not show the presence of SectionInformation property. The MonoDevelop
disassembler seems to be unable to disassemble System.Configuration.dll and
hence I can't make much sense of the implementation.

Then System.Configuration.SectionInformation.SectionName is in yet TODO when
it is the name of the section that the section information is referred to.
So it is an intrinsic part of it and should be implemented. In my test
SectionInformation.Type returning null while the web site says it is
implemented. I guess someone in that class has failed to call Type to set
the section's type string. Hence one can't rely too much on that site and
one should produce learning test to ensure they operate correctly at
runtime.

Is there a better disassembler one can recommend?

It is very frustrating moving .Net code to Mono when it was touted as a
cross platform development language. Code compiles but I often encounter
this kind of runtime inconsistency. It wastes so much time.

Is it just me that is having this kind of anomaly/inconsistency when porting
code from CLR to Mono? What are other's experience? I struck problem in just
about every namespace I have tried. 

MarLOne



--
View this message in context: 
http://mono.1490590.n4.nabble.com/Configuration-HasFile-returning-wrong-value-in-Mono-tp4667959p4667968.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

Re: [Mono-dev] Configuration.HasFile returning wrong value in Mono

[MarLOne]

I am wondering how well tested is the System.Configuration namespace is in
Mono. I am targetting .Net 2.0 and the construct I am using are available as
far back as .Net 2 (or even 1.1)

I was comparing results between CLR and MONO for ConfigurationSection and
the results surprised me. 
Configuration.GetSection returns an object of type 
System.Configuration.DefaultSection
<https://msdn.microsoft.com/en-us/library/system.configuration.defaultsection%28v=vs.110%29.aspx>
  
. But inspecting this object, particularly its property  SectionInformation
<https://msdn.microsoft.com/en-us/library/system.configuration.sectioninformation%28v=vs.110%29.aspx>
  
at runtime reveals this:
1) DefaultSection.SectionInformation.IsDeclarationRequired throws an
NotImplemented exception in Mono while in CLR it is set to true.
2) In Mono, DefaultSection.SectionInformation.IsDeclared is set to false
while in CLR it is set to true.
3) In Mono, DefaultSection.SectionInformation.Name is null while in CLR it
contains the correct section name.
4) In Mono, OverrideMode, OverrideModeDefault, OverrideModeEffective
properties of SectionInformation are not implemented.
5) In Mono DefaultSection.SectionInformation.RequiredPermission is false
while in CLR it is true.
6) The most alarming ones in Mono
DefaultSection.SectionInformation.SectionName and
DefaultSection.SectionInformation.Type are null while in CLR they contains
the correct information.

This is a worry and does not seem to instill much faith in porting code to
Mono. Is Xamarin being part of Microsoft going to provide consistency in the
framework across platforms?

MarLOne



--
View this message in context: 
http://mono.1490590.n4.nabble.com/Configuration-HasFile-returning-wrong-value-in-Mono-tp4667959p4667963.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

Re: [Mono-dev] Configuration.HasFile returning wrong value in Mono

[MarLOne]

Yes, that behavior is identical to CLR and Mono - the operation simply append
the .config to the exePath, which in this case is actually the path name to
the .config file.

But what is not right is the value of Configuration.HasFile. Why
File.Exists( config.FilePath) == false and config.HasFile == true in Mono?

That does not seem logical isn't it?

MarLOne




--
View this message in context: 
http://mono.1490590.n4.nabble.com/Configuration-HasFile-returning-wrong-value-in-Mono-tp4667959p4667962.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-dev] Configuration.HasFile returning wrong value in Mono

[MarLOne]

Hi,

I am using C# in Mono in Mint17 - Mono JIT compiler version 4.2.3 (Stable
4.2.3.4/832de4b Wed Mar 16 13:19:08 UTC 2016)
 and come across this problem picked up by my NUnit code when I am moving
code from Windows/CLR to Mono.

I obtain the *Configuration* object by using
*ConfigurationManager.OpenExeConfiguration( string exePath )*. When I pass
to it a path like this: /home/testapp/MyApp.exe.config, the method returns a
non-null object, same as in CLR.

However the Config.FilePath becomes /home/testapp/MyApp.exe.config.config
which clearly is not a conventional config file name for an executable.
File.Exists() with this path returning false, as expected.

However, Config.HasFile returning true in Mono while it is false in CLR.
Clearly this value should be false in view of File.Exists() returning false. 

Can someone explains why this anomaly between CLR and Mono?

Here is my Unit test code:


L5 fails in Mono while it does not fail in Windows/CLR. Why?

MarLOne



--
View this message in context: 
http://mono.1490590.n4.nabble.com/Configuration-HasFile-returning-wrong-value-in-Mono-tp4667959.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

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

[MarLOne]

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

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

[MarLOne]

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@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

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

[MarLOne]

Hello Timotheus,

Thanks and will try. Perhaps you can give me some assistance with
MonoDevelop/Mono.

In MS .Net, I can stay in say XP (even it has reached end of life) and still
can run VS2010 with .Net 4. But in Mint, I seem to be stuck in the version
of Mono I can get, hence that old version you are seeing. Is there a
trustworthy PPA that allows me to use the latest Mono/MonoDevelop without
having to upgrade the OS?

I am new to this kind of behavour where I have get a new OS just to get a
new version of application.

Thanks.

MarL



--
View this message in context: 
http://mono.1490590.n4.nabble.com/Mono-Net-difference-handling-xs-extension-please-help-tp4664552p4664556.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-dev] Mono & .Net difference - handling xs:extension please help

[MarLOne]

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
  . 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
  

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-dev] Inconsistent value in System.Diagnostics.DefaultTraceListener.AssertUiEnabled

[MarLOne]

Hi,

I am running "Mono JIT compiler version 2.10.8.1 (Debian 2.10.8.1-5ubuntu1)"
in Mint-15 Cinnamon (64-bits) and also in Ubuntu 12.04 LTS (32-bits). My
development is using MonoDevelop 4.2.2 and obtained from PPA
(https://launchpad.net/~ermshiperete/+archive/monodevelop)

The problem is frequently reported in the Mono-forum complaining
Debug.Assert( false ) never stop and and warn user when the assertion fails.

The function System.Diagnostics.Debug.Assert(bool, string) is not at fault
as I have disassembled the Mono code. The fault lies in the property value
of *System.Diagnostics.DefaultTraceListener.AssertUiEnabled* which is
default to *false* in *Mono* while in *CLR's runtime code* it is default to
*true*.

Here is the way to check cross-platform consistency:
1) Create a console application Windows/CLR containing the following code
#if DEBUG
if( (System.Diagnostics.Debug.Listeners["Default"] as
DefaultTraceListener).AssertUiEnabled == false )
  throw new Exception( "Wrong Default Value" );
#endif

Do not use NUnit to perform this test as NUnit automatically setting this
value to false so that user's Debug.Assert() does not interfere with the
NUnit.Framework.Assert class' operations. By default, it is written to
console in NUnit.

Attached is the MonoDevelop project called VerifyAssertUiEnabled.zip
VerifyAssertUiEnabled.zip
  

2) Run the console application in Windows and you should see *NO* exception.

3) Take the console application to Linux with Mono runtime installed and run
it, you will see the Exception telling the property value is different.

You can restore the consistency between CLR and Mono so that
Debug.Assert(false) will not be silenced  in Mono in the following way:
1) In Code
#if DEBUG
DefaultTraceListener defListener = Debug.Listeners["Default"] as
DefaultTraceListener;
if( defListener != null )
{
   // available
   defListener.AssertUiEnabled = true;
}
#endif

2) Using a configuration file with the following contents (this is harmless
in CLR)


  
   
   
  


Clearly the default value in DefaultTraceListener.AssertUiEnabled is
producing inconsistent run time behaviour between CLR and Mono. Perhaps it
is due to the fact the developer has forgotten to initialise the
DefaultTraceListener.AssertUiEnabled value.

MarL




--
View this message in context: 
http://mono.1490590.n4.nabble.com/Inconsistent-value-in-System-Diagnostics-DefaultTraceListener-AssertUiEnabled-tp4662230.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