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

2016-06-10 Thread 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=4.5=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

2016-06-10 Thread Eberhard Beilharz 
If you check the Mono status page 
(http://go-mono.com/status/status.aspx?reference=4.5=4.5=System.Configuration) 
you'll see that the implementation for SectionInformation in Mono isn't 
complete.


Eberhard

Marlone  wrote on 2016-06-10 at 16:58 +0200:

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

. But inspecting this object, particularly its property  SectionInformation

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


___
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

2016-06-10 Thread 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

  
. But inspecting this object, particularly its property  SectionInformation

  
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

2016-06-10 Thread 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

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

2016-06-10 Thread Greg Young 
Looks like its appending the .config (note it takes an exeFile parameter).

On Fri, Jun 10, 2016 at 2:20 PM, MarLOne  wrote:
> 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



-- 
Studying for the Turing test
___
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

2016-06-10 Thread 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