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

[Eberhard Beilharz]

If you check the Mono status page 
(http://go-mono.com/status/status.aspx?reference=4.5&profile=4.5&assembly=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] Debugging Mono applications under GDB

[Eberhard Beilharz]

You might be able to run monodevelop on your desktop machine and then
remote debug on the headless server (see
https://ebsteblog.wordpress.com/2013/12/04/remote-debugging-with-monodevelop/
for some instructions).


Chris
Swiedler  wrote on 2015-11-15 at 17:03 +0100:
> Do you mean for development, or for debugging? The application is running on 
> a headless server and I can’t run monodevelop or Xamarin on it. I’m building 
> the exes with the mono toolchain under Windows, by installing it as a .net 
> profile.
>
> chris
>
>> On Nov 14, 2015, at 6:32 PM, Edward Ned Harvey (mono) 
>>  wrote:
>>
>>> From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
>>> boun...@lists.ximian.com] On Behalf Of Chris Swiedler
>>>
>>> We have a server application that's being developed under Visual Studio and
>>> run under Mono 3.12. We're generating .mdb files from the .pdbs that VS
>>> creates. With those deployed next to the executable, mono will give full
>>> callstacks with source and line information when logging exceptions, so I
>>> believe the .mdbs are correct.
>> Have you considered monodevelop or Xamarin Studio?
> ___
> 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] Newtonsoft.Json build in mono

[Eberhard Beilharz]

Newtonsoft.Json is a separate repo that is included as a submodule in
mono. You can find the version that Mono uses at
https://github.com/mono/Newtonsoft.Json, or the original at
https://github.com/JamesNK/Newtonsoft.Json.

HTH,
Eberhard

On 10/08/2015 10:44 AM, techi eth wrote:
> Hi,
>
> How do i get Newtonsoft.Json get build out of mono/external source
> folder on Linux.
>
> Techi
>
>
>
> ___
> 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] [SIGNAL] Segfault in native function called by managed code

[Eberhard Beilharz]

Making it configurable would seem like a good option to me. Currently if
the app gets a SEGFAULT it simply disappears for the user without
leaving a trace, so I as a developer can't easily see what happened on
the user's machine nor can I implement code that would give the user a
chance to report what happened.

If it would be configurable then we could catch the exception, let the
user send in an error report, and then try to reproduce it, possibly
with the other configuration set so that we see the SEGFAULT.

Or am I missing something how the SEGFAULT could currently be handled in
a mono app?

Thanks
Eberhard
 

Miguel De Icaza  wrote on 2015-09-05 at 03:32 +0200:
> It is an implementation choice.
>
> Perhaps we could make this configurable, but more often than not, this
> indicates a serious issue, and surfacing something so useful as a
> AccessViolationException reduces the usefulness of the feature.
>
> On Fri, Sep 4, 2015 at 6:15 AM, Raphael Boissel
> mailto:raphael.bois...@gmail.com>> wrote:
>
> Hello,
>
>
> I have one little question on the way mono currently handles/uses the
> SEGFAULT signal on Unix OSes.
>
> Currently, and correct me if I'm wrong, either the segfault has been
> raised by a managed function and in this case it is handled as a
> genuine exception for instance a nullRefException or if it is
> triggered
> by native code the entire program is stopped and a stacktrace is
> displayed.
>
> However it seems that mono also follow the second behavior for
> native code that has been invoked inside managed code,
> where I would have expected an AccessViolationException.
>
> Is there any specific reasons why this behavior is followed, or is it
> just an implementation choice ?
>
> (sorry about the potential double post I sent it first with a
> non-whitelisted
> e-mail address)
>
> Thanks,
>
> -- 
> Raphaël 'Shugo' Boissel
>
> ___
> 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] PR-977 updated

[Eberhard Beilharz]

Just wanted to bring pull request #977 to attention since it got
recently updated. It basically already got improved almost a year ago,
and the last outstanding thing was a squash of two commits and a rebase.
This is done now. It would be great it that PR could be merged soon.

Thanks,
Eberhard

https://github.com/mono/mono/pull/977

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] If you accept pull requests on Mono's github

[Eberhard Beilharz]

 

Andres G. Aragoneses  wrote on 2015-01-03 at 21:51 +0100:
> On 03/01/15 21:42, Edward Ned Harvey (mono) wrote:
>> I don't know if you want tests that are known to fail.
>
> If it fails, you can decorate it with the attribute
> [Category("NotWorking")], but AFAICT contributing a failing test
> doesn't increase the chances of finding a contributor that has the
> time to fix it.
IMO it might still be helpful to submit the test even if it doesn't
increase the chance of somebody fixing it in the near future - creating
a unit test is often half of the work.

Eberhard
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Mono bug related to TLS certificate validation

[Eberhard Beilharz]

I just reported a mono bug:
https://bugzilla.xamarin.com/show_bug.cgi?id=25524

What it looks like is that mono chooses the wrong parent certificate in
some circumstances, probably in X509Chain. SelectBestFromCollection() .
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Open source .Net, and TLS 1.1 & 1.2

[Eberhard Beilharz]

Wouldn't

#if __MonoCS__

do what you want?
 

Mono  wrote on 2014-12-14 at 18:44 +0100:
>> From: Alexander Köplinger [mailto:alex.koeplin...@outlook.com]
>>
>> You can find out if you run on Mono by checking if Type.GetType
>> ("Mono.Runtime") != null.
> That's helpful, but doesn't quite solve it, because compilation will fail on 
> windows ...
>
> I'm looking for something like this...
>
> #ifdef MONO
> 
> Mono.Security.X509.X509StoreManager.CurrentUser.TrustedRoot.Import(junkRootCert);
> try
> {
> #endif
> DoStuff();
> #ifdef MONO
> }
> finally
> {
> 
> Mono.Security.X509.X509StoreManager.CurrentUser.TrustedRoot.Remove(junkRootCert);
> }
> #endif
> ___
> 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] PR #1449 - [MWF] Fix crash in multi-selection list view (bug #23591)

[Eberhard Beilharz]

This change improves the fix for Xamarin bug #23591: updating a
multi-selection can also change the selected item, so it also needs to
check for the selected item being now null.

https://github.com/mono/mono/pull/1449

Thanks,
Eberhard
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] PR #1448 - [MWF] Don't truncate text on ToolStripButton

[Eberhard Beilharz]

The pull request fixes a problem where the text on toolstrip buttons
gets truncated.

https://github.com/mono/mono/pull/1448

Thanks,   
Eberhard
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] PR #1442 - [MWF] Fix problem when button text overlaps image

[Eberhard Beilharz]

In some circumstances the text on a button gets drawn in the wrong
position. When the button has ImageAboveText.ImageAboveText set and the
text is too long to fit under the image it might get drawn at the top
instead overlapping the image from the bottom. Note that I couldn't
reproduce this problem with a stock mono, only on a mono that includes
patched versions of libgdiplus and gtksharp, but that the code I changed
looks clearly wrong and fixes the problem.

https://github.com/mono/mono/pull/1442

Thanks,
Eberhard
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Review of PR #1407 - [MWF] Fix focus issue when removing last item in ListView

[Eberhard Beilharz]

 Forwarded Message 
Subject:Fwd: Review of PR #1407 - [MWF] Fix focus issue when removing
last item in ListView
Date:   Wed, 19 Nov 2014 14:23:57 -0500



Can you send this message to the mono-devel-list?  Mine hasn't been
moderated yet.  Maybe if you send it, then it will get reviewed.

Chris


 Forwarded Message 
Subject:Review of PR #1407 - [MWF] Fix focus issue when removing last
item in ListView
Date:   Tue, 18 Nov 2014 09:28:55 -0500
From:   Chris Hubbard 
To: mono-devel-list@lists.ximian.com



Hello,

We found an issue while testing a form that uses
System.Windows.Forms.ListView.

If the last item in a ListView has focus and it is removed by
an another action on the form (i.e. push a button to remove the
current item), then the focused_item_index is not updated when
the VirtualListSize changes, even though that item doesn't exist
anymore. When the ListView receives focus again, it tries to
invalidate the current focused item which causes an
ArgumentOutOfRangeException.

When the VirtualListSize changes, the focus_item_index should
be reset (similar to how it currently resets the selected indices).

https://github.com/mono/mono/pull/1407

Thanks,

Chris Hubbard





___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] PR #1415: [MWF] Fix bug that truncates button text

[Eberhard Beilharz]

A recent change of mine introduced a bug that might truncate the text of
a button. The change in PR #1415 fixes this bug.

https://github.com/mono/mono/pull/1415
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Review of PR 964: Improvements to ApplicationsSettingsBase class

[Eberhard Beilharz]

PR 964 contains various changes and fixes for ApplicationsSettingsBase
class to behave more like .NET. This fixes Xamarin bugs #15818 and #2315.

https://github.com/mono/mono/pull/964

Thanks,
Eberhard
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] PR #960: [MWF] Partially implement Help.ShowHelp

[Eberhard Beilharz]

The change in PR #960 partially implements the ability to show a help
file by calling chmsee or whatever the environment variable
MONO_HELP_VIEWER is set to. This is still a partial implementation in
that it probably only works on Linux, but at least IMO it's an
improvement over the existing do-nothing implementation.

This change increases the compatibility with Windows by allowing to use
the same chm file and help calling code in the application on both
Windows and Linux. While this might not be optimal and it might be
better to use a more native format on Linux it allows to port a Windows
application more quickly to Linux.

https://github.com/mono/mono/pull/960

Thanks,
Eberhard
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] PR944 - Improve COM error handling

[Eberhard Beilharz]

> The code in your pull request is windows specific so it won't work on
> unix.
>
No, it isn't. It's possible to build a Unix library that emulates the
Windows COM implementation - as we did it in our projects
(https://github.com/sillsdev/libcom), and a mapping of oleaut32.dll to
that library.

The code in the pull request deals with the possibility that there is no
suitable COM implementation available, but if there is it'll make use of it.

Rodrigo Kumpera  wrote on 2014-10-30 at 04:46 +0100:
> The code in your pull request is windows specific so it won't work on
> unix.
>
> Mono works with unix com implementations such as xpcom.
>
> On Wed, Oct 29, 2014 at 3:06 PM, Eberhard Beilharz  <mailto:e...@sil.org>> wrote:
>
> Hi,
>
> To revive one of my old pull requests: #944 implements some missing
> pieces related to COM error handling. Namely it sets the error info in
> GetHRForException() and converts the HRESULT values to managed
> exceptions.
>
> https://github.com/mono/mono/pull/944
>
> Thanks,
> Eberhard
> ___
> 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

[Mono-dev] PR944 - Improve COM error handling

[Eberhard Beilharz]

Hi,

To revive one of my old pull requests: #944 implements some missing
pieces related to COM error handling. Namely it sets the error info in
GetHRForException() and converts the HRESULT values to managed exceptions.

https://github.com/mono/mono/pull/944

Thanks,
Eberhard
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Review of PR #1348 - [MWF] Improve button text layout

[Eberhard Beilharz]

Hi,

I'm working on some improvements on the experimental Pango rendering
support (see my pull request
 in libgdiplus for details).

In doing so I came across some deficiencies in the MWF code that aren't
noticeable with the current Cairo rendering.

The changes in PR #1348 improve the measuring and layout of button texts
by not applying padding twice and using the full available height for
button texts in the case where we have to reduce the width.

The changes won't make much of a difference with the current Cairo
rendering but make things work right with the experimental Pango renderer.

https://github.com/mono/mono/pull/1348

Thanks,
Eberhard
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Review of PR #1347 - [MWF] Improve ellipsis handling on button

[Eberhard Beilharz]

Hi,

I'm working on some improvements on the experimental Pango rendering
support (see my pull request
 in libgdiplus for details).

In doing so I came across some deficiencies in the MWF code that aren't
noticeable with the current Cairo rendering.

The changes in PR #1347 improve the handling of the ellipsis on buttons:

  * Don't subtract room for ellipsis. Ellipsis should be handled by the
renderer so we shouldn't reserve space for it. Otherwise we end up
not getting ellipsis (because the renderer thinks there is enough
space available), or we don't use up the available space.
  * Don't allow text to go below button if we want to show ellipsis.

This change won't improve things with the Cairo renderer - I guess there
are other bugs in the Cairo renderer so that the ellipsis doesn't show.
But it also doesn't make things worse for the Cairo renderer. With the
experimental Pango renderer the ellipsis on buttons will show correctly
with this change and will match the behavior of .NET on Windows.

https://github.com/mono/mono/pull/1347

Thanks,
Eberhard
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] Review needed for PR #1346 - [MWF] Display visual feedback on pressed button (#23869)

[Eberhard Beilharz]

Hi,

I submitted a pull request that fixes a problem in MWF, reported as
https://bugzilla.xamarin.com/show_bug.cgi?id=23869: when
TextImageRelation is set to anything other than Overlay the image moves
correctly when the button is pressed but the text doesn't move. If there
is no image at all then this makes it really hard to see if the button
is pressed.

This change fixes this problem.

https://github.com/mono/mono/pull/1346

Thanks,
Eberhard
___
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

[Eberhard Beilharz]

Your output "looks" the same to me.

I'd think you need to normalize the strings before comparing them,
something like:

 if (!infos[0].Name.Normalize().Equals(UnicodeDirName.Normalize(), 
StringComparison.OrdinalIgnoreCase))
 {


Eberhard

Jared Watts wrote on 2012-03-12 at 20:11 +0100:
>
> I opened bug 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] Build fails: name `AllowReversePInvokeCallsAttribute' does not exist

[Eberhard Beilharz]

Did you have a look at the README file? In section "c. Building the
software from GIT" it lists several options. The recommended way is to
install the latest released packages for your distribution for building
mono from git, but there are also instructions if you don't  have a
working Mono installation.

Eberhard


On 01/31/2012 07:34 AM, Markku Tavasti wrote:
> I'm trying to build mono from git sources
> ./autogen.sh --prefix=/usr/local && make && sudo make install
>
> , but unfortunately it fails like this:
>
> make[6]: Entering directory `/home/tavasti/build/mono/mcs'
> build/common/basic-profile-check.cs(13,67): error CS0234: The type or
> namespace name `AllowReversePInvokeCallsAttribute' does not exist in
> the namespace `System.Runtime.InteropServices'. Are you missing an
> assembly reference?
> Compilation failed: 1 error(s), 0 warnings
> make[6]: *** [build/deps/basic-profile-check.exe] Error 1
> make[6]: Leaving directory `/home/tavasti/build/mono/mcs'
> *** The compiler 'gmcs' doesn't appear to be usable.
> *** You need Mono version 2.4 or better installed to build MCS
> *** Read INSTALL.txt for information on how to bootstrap a Mono
> installation.
> make[5]: *** [do-profile-check] Error 1
> make[5]: Leaving directory `/home/tavasti/build/mono/mcs'
> make[4]: *** [profile-do--basic--all] Error 2
> make[4]: Leaving directory `/home/tavasti/build/mono/mcs'
> make[3]: *** [profiles-do--all] Error 2
>
> Any hints?
>
> --Tavasti
>
> ___
> 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] [PATCH] Fix for Type.GetMember returning private property of base class

[Eberhard Beilharz]

Bump!

On 01/28/2010 03:13 PM, Eberhard Beilharz wrote:
The patch adds a fix and a unit test for bug #574696 
<https://bugzilla.novell.com/attachment.cgi?bugid=574696&action=enter> 
where Type.GetMember returned a private property of the base class 
instead of nothing.


For a property Type.GetMember also checked the base classes for the 
desired property. It didn't do that for all the other cases like 
methods, events..., so I removed that recursion for the property case.


Please review and commit.

Thanks!
Eberhard


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
   
Index: mcs/class/corlib/System/Type.cs
===
--- mcs/class/corlib/System/Type.cs	(revision 149903)
+++ mcs/class/corlib/System/Type.cs	(working copy)
@@ -1050,18 +1050,11 @@
 }
 			}
 			if ((memberType & MemberTypes.Property) != 0) {
-PropertyInfo[] c;
-int count = l.Count;
-Type ptype;
+PropertyInfo[] c = GetProperties (bindingAttr);
 if (filter != null) {
-	ptype = this;
-	while ((l.Count == count) && (ptype != null)) {
-		c = ptype.GetProperties (bindingAttr);
-		foreach (MemberInfo m in c) {
-			if (filter (m, filterCriteria))
-l.Add (m);
-		}
-		ptype = ptype.BaseType;
+	foreach (MemberInfo m in c) {
+		if (filter (m, filterCriteria))
+			l.Add (m);
 	}
 } else {
 	c = GetProperties (bindingAttr);
Index: mcs/class/corlib/ChangeLog
===
--- mcs/class/corlib/ChangeLog	(revision 149903)
+++ mcs/class/corlib/ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2010-01-28  Eberhard Beilharz 
+
+	* TypeTest.cs : Added test for bug #574696	
+	* Type.cs : Fix for bug #574696: don't recurse into base types in GetMember when
+	getting properties.
+	
 2009-12-03  Marek Habersack  
 
 	* corlib.dll.sources: added
Index: mcs/class/corlib/Test/System/TypeTest.cs
===
--- mcs/class/corlib/Test/System/TypeTest.cs	(revision 149903)
+++ mcs/class/corlib/Test/System/TypeTest.cs	(working copy)
@@ -3205,6 +3205,14 @@
 ++id;
 			}
 		}
+		
+		[Test] // Bug #574696
+		public void GetMember_DoesntReturnPrivatePropOfParent ()
+		{
+			Assert.AreEqual (1, typeof (Bar).GetMember ("PrivInst", BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance).Length);
+			Assert.AreEqual (0, typeof (Bar).GetMember ("PrivInstBase", BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance).Length);
+			Assert.AreEqual (1, typeof (Foo).GetMember ("PrivInstBase", BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance).Length);
+		}
 
 #if NET_4_0
 		interface IGetInterfaceMap
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] [PATCH] Fix for Type.GetMember returning private property of base class

[Eberhard Beilharz]

The patch adds a fix and a unit test for bug #574696 
<https://bugzilla.novell.com/attachment.cgi?bugid=574696&action=enter> 
where Type.GetMember returned a private property of the base class 
instead of nothing.


For a property Type.GetMember also checked the base classes for the 
desired property. It didn't do that for all the other cases like 
methods, events..., so I removed that recursion for the property case.


Please review and commit.

Thanks!
Eberhard
Index: mcs/class/corlib/System/Type.cs
===
--- mcs/class/corlib/System/Type.cs	(revision 149903)
+++ mcs/class/corlib/System/Type.cs	(working copy)
@@ -1050,18 +1050,11 @@
 }
 			}
 			if ((memberType & MemberTypes.Property) != 0) {
-PropertyInfo[] c;
-int count = l.Count;
-Type ptype;
+PropertyInfo[] c = GetProperties (bindingAttr);
 if (filter != null) {
-	ptype = this;
-	while ((l.Count == count) && (ptype != null)) {
-		c = ptype.GetProperties (bindingAttr);
-		foreach (MemberInfo m in c) {
-			if (filter (m, filterCriteria))
-l.Add (m);
-		}
-		ptype = ptype.BaseType;
+	foreach (MemberInfo m in c) {
+		if (filter (m, filterCriteria))
+			l.Add (m);
 	}
 } else {
 	c = GetProperties (bindingAttr);
Index: mcs/class/corlib/ChangeLog
===
--- mcs/class/corlib/ChangeLog	(revision 149903)
+++ mcs/class/corlib/ChangeLog	(working copy)
@@ -1,3 +1,9 @@
+2010-01-28  Eberhard Beilharz 
+
+	* TypeTest.cs : Added test for bug #574696	
+	* Type.cs : Fix for bug #574696: don't recurse into base types in GetMember when
+	getting properties.
+	
 2009-12-03  Marek Habersack  
 
 	* corlib.dll.sources: added
Index: mcs/class/corlib/Test/System/TypeTest.cs
===
--- mcs/class/corlib/Test/System/TypeTest.cs	(revision 149903)
+++ mcs/class/corlib/Test/System/TypeTest.cs	(working copy)
@@ -3205,6 +3205,14 @@
 ++id;
 			}
 		}
+		
+		[Test] // Bug #574696
+		public void GetMember_DoesntReturnPrivatePropOfParent ()
+		{
+			Assert.AreEqual (1, typeof (Bar).GetMember ("PrivInst", BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance).Length);
+			Assert.AreEqual (0, typeof (Bar).GetMember ("PrivInstBase", BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance).Length);
+			Assert.AreEqual (1, typeof (Foo).GetMember ("PrivInstBase", BindingFlags.NonPublic | BindingFlags.Public | BindingFlags.Instance).Length);
+		}
 
 #if NET_4_0
 		interface IGetInterfaceMap
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] [PATCH] Wrong warning CS0109 with protected field that hides field from base class

[Eberhard Beilharz]

Hi,

Attached is a patch for bug #501775 where gmcs outputs warning CS0109
("The member `Derived.Foo' does not hide
an inherited member. The new keyword is not required.") when a protected
field hides a field from the base class if the base class is defined in
a referenced assembly.

Please review and submit.

Thanks,
Eberhard Beilharz

Index: mcs/mcs/decl.cs
===
--- mcs/mcs/decl.cs	(revision 134759)
+++ mcs/mcs/decl.cs	(working copy)
@@ -1895,12 +1895,24 @@
 			foreach (MemberInfo member in members) {
 string name = member.Name;
 
-AddMember (mt, bf, container, name, member);
+// Workaround for bug #501775. BindingFlags don't distinguish between private and protected, so we treat a protected
+// field in a class from a referenced assembly as private which causes warning CS0109. If the class is defined
+// in the current assembly we get the binding flags from GetBindingFlags(mc.ModFlags) which already contains the correct
+// information.
+BindingFlags bfToUse = bf;
+if (member is FieldInfo) {
+	FieldInfo fi = (FieldInfo)member;
+	if (fi.IsPublic || fi.IsFamilyOrAssembly || fi.IsFamily) {
+		bfToUse |= BindingFlags.Public;
+	}
+}
 
+AddMember (mt, bfToUse, container, name, member);
+
 if (member is MethodInfo) {
 	string gname = TypeManager.GetMethodName ((MethodInfo) member);
 	if (gname != name)
-		AddMember (mt, bf, container, gname, member);
+		AddMember (mt, bfToUse, container, gname, member);
 }
 			}
 		}
@@ -2519,7 +2531,7 @@
  			if (applicable != null) {
  for (int i = applicable.Count - 1; i >= 0; i--) {
  	CacheEntry entry = (CacheEntry) applicable [i];
- 	if ((entry.EntryType & EntryType.Public) != 0 & entry.Member != ignore_member) {
+ 	if ((entry.EntryType & EntryType.Public) != 0 && entry.Member != ignore_member) {
  		if (ignore_complex_types) {
  			if ((entry.EntryType & EntryType.Method) != 0)
  continue;

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] [Patch] gmcs considers bla and bla{T} as illegal in a cref

[Eberhard Beilharz]

I agree that it's a workaround, not a real fix. Doing real syntax 
checking would be better.


However, it matches the way the 'working' variant is treated. I can write:

/// 

or

/// 


and don't get any warning or error.

.. and optionally worse, error generation in the output xml such as

  

I don't understand what you mean with that. If I write in my code:

/// 

I get 




in the output xml file. And if I write in my code:

/// 

I get



in the output xml file.


Since the current behavior of not accepting Bla{T} or Bla<T> 
breaks compatibility with csc I'd really like to see this patch applied 
to the code - maybe add a FIXME comment to check the syntax later.


Thanks,
   Eberhard Beilharz
  
Atsushi Eno


Eberhard Beilharz wrote:
  
gmcs gives warning CS1584 if you have an XML comment referencing a 
generic type like cref="Bla" or cref="Bla{T}". Those two variants 
work with Microsoft's csc. The only variant that makes gmcs happy is 
cref="T:Bla`1" which gives a warning with Microsoft's csc (it used to be 
the way to do it with older versions of csc).


Would someone please review and commit my patch attached to bug #480862 
(<https://bugzilla.novell.com/show_bug.cgi?id=480862>) which treats 
Bla and Bla{T} as being equal to T:Bla`1 in a cref.


Thanks,
Eberhard Beilharz
___
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] [Patch] gmcs considers bla and bla{T} as illegal in a cref

[Eberhard Beilharz]

Andreas Färber wrote:
>
> Am 16.05.2009 um 22:33 schrieb Eberhard Beilharz:
>
>> gmcs gives warning CS1584 if you have an XML comment referencing a
>> generic type like cref="Bla" or cref="Bla{T}". Those two variants
>> work with Microsoft's csc. The only variant that makes gmcs happy is
>> cref="T:Bla`1" which gives a warning with Microsoft's csc (it used to be
>> the way to do it with older versions of csc).
>
> cref="Bla" is invalid XML and shouldn't be encouraged imo.
> To be valid, that would need to be written as cref="Bla<T>". How 
> does csc handle that variant?
>
Of course you're right. You have to write cref="Bla<T>" in the XML 
comment; cref="Bla" (correctly) gives an error in both csc and gmcs.

In doc.cs however "<" and ">" are already parsed to '<' resp. '>' 
that's why I confused it in my example.

See <http://msdn.microsoft.com/en-us/library/2d6dt3kf.aspx> for an 
example of all three valid variants.

> The cref="Bla{T}" part of the patch looks okay and would seem to fix 
> the reported bug already, no?
While that is true the cref="Bla<T>" is also a problem which is 
hitting me at the moment so I'd prefer to have both versions fixed at 
once rather than filing another bug report...
> Andreas
>
>> Would someone please review and commit my patch attached to bug #480862
>> (<https://bugzilla.novell.com/show_bug.cgi?id=480862>) which treats
>> Bla and Bla{T} as being equal to T:Bla`1 in a cref.
>>
>> Thanks,
>>Eberhard Beilharz
>> ___
>> 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] [Patch] gmcs considers bla and bla{T} as illegal in a cref

[Eberhard Beilharz]

gmcs gives warning CS1584 if you have an XML comment referencing a 
generic type like cref="Bla" or cref="Bla{T}". Those two variants 
work with Microsoft's csc. The only variant that makes gmcs happy is 
cref="T:Bla`1" which gives a warning with Microsoft's csc (it used to be 
the way to do it with older versions of csc).

Would someone please review and commit my patch attached to bug #480862 
(<https://bugzilla.novell.com/show_bug.cgi?id=480862>) which treats 
Bla and Bla{T} as being equal to T:Bla`1 in a cref.

Thanks,
Eberhard Beilharz
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Fwd: Ideas for Mono on Windows

[Eberhard Beilharz]

Kornél Pál wrote:
>
> The other things all could be fixed by a proper build environment.
Is there any up-to-date info on how set up a proper build environment 
for building with Cygwin? I found several, but they were contradicting 
and didn't work completely...

Thanks,
Eberhard

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Fwd: Ideas for Mono on Windows

[Eberhard Beilharz]

Leszek Ciesielski wrote:
> So how's the progress with getting Mono easy to compile on Windows
> going? I'm getting stuck on exception that's been already mentioned on
> the list ( 
> http://n2.nabble.com/Re:-Mono-devel-list-Digest,-Vol-44,-Issue-48-td1757065.html
> ) and can't find any solution for this.
>   
I just managed to compile from SVN on Windows - doesn't run though 
(crashes as soon as I start it), but at least it compiled :)

Here's what I had to do:

1) make sure the installed Mono is in the front of your path variable

2) I had to call autogen.sh with --enable-nls=no

3) the build process hang when building mono/docs, so I looked in the 
Makefile of that directory and did a touch on the files it tried to 
create (some *.tree and *.zip files). I figured since it's only 
documentation it doesn't matter if I have those files or not.

Eberhard
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

[Mono-dev] [PATCH] Lookup of type names in config files

[Eberhard Beilharz]

Hi,

Attached is a regression test for bug #324153 and a fix for it.

This makes reading of .config files more compatible with MS.NET: if a
simple type name is specified in a config file, MS.NET looks in mscorlib
and System for the type (I'm not so sure about System.Configuration
mentioned in the bug report).

Thanks,
Eberhard

Index: mcs/class/System.Configuration/System.Configuration/InternalConfigurationHost.cs
===
--- mcs/class/System.Configuration/System.Configuration/InternalConfigurationHost.cs	(revision 123023)
+++ mcs/class/System.Configuration/System.Configuration/InternalConfigurationHost.cs	(working copy)
@@ -71,6 +71,8 @@
 		public virtual Type GetConfigType (string typeName, bool throwOnError)
 		{
 			Type type = Type.GetType (typeName);
+			if (type == null && typeName.Split(',').Length == 1) // try System.dll if nothing else specified
+type = Type.GetType (typeName + ",System");
 			if (type == null && throwOnError)
 throw new ConfigurationErrorsException ("Type '" + typeName + "' not found.");
 			return type;

Index: mcs/class/System.Configuration/Test/standalone/bug-324153.exe.expected
===
--- mcs/class/System.Configuration/Test/standalone/bug-324153.exe.expected	(revision 0)
+++ mcs/class/System.Configuration/Test/standalone/bug-324153.exe.expected	(revision 0)
@@ -0,0 +1 @@
+value
Index: mcs/class/System.Configuration/Test/standalone/bug-324153.exe.config
===
--- mcs/class/System.Configuration/Test/standalone/bug-324153.exe.config	(revision 0)
+++ mcs/class/System.Configuration/Test/standalone/bug-324153.exe.config	(revision 0)
@@ -0,0 +1,16 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Index: mcs/class/System.Configuration/Test/standalone/Makefile
===
--- mcs/class/System.Configuration/Test/standalone/Makefile	(revision 123023)
+++ mcs/class/System.Configuration/Test/standalone/Makefile	(working copy)
@@ -1,4 +1,4 @@
-TESTS = t1.exe t2.exe t3.exe t4.exe t5.exe t6.exe t7.exe t8.exe t9.exe t10.exe t11.exe t12.exe t15.exe t16.exe t17.exe t18.exe t19.exe t20.exe t21.exe t22.exe t23.exe t24.exe t25.exe t26.exe t27.exe t28.exe t29.exe t30.exe t31.exe t32.exe t33.exe t34.exe t35.exe t36.exe t37.exe t38.exe t39.exe t40.exe t41.exe t42.exe t43.exe t44.exe t45.exe t46.exe t47.exe
+TESTS = t1.exe t2.exe t3.exe t4.exe t5.exe t6.exe t7.exe t8.exe t9.exe t10.exe t11.exe t12.exe t15.exe t16.exe t17.exe t18.exe t19.exe t20.exe t21.exe t22.exe t23.exe t24.exe t25.exe t26.exe t27.exe t28.exe t29.exe t30.exe t31.exe t32.exe t33.exe t34.exe t35.exe t36.exe t37.exe t38.exe t39.exe t40.exe t41.exe t42.exe t43.exe t44.exe t45.exe t46.exe t47.exe bug-324153.exe
 # t13.exe t14.exe
 
 check:	local compare
Index: mcs/class/System.Configuration/Test/standalone/bug-324153.cs
===
--- mcs/class/System.Configuration/Test/standalone/bug-324153.cs	(revision 0)
+++ mcs/class/System.Configuration/Test/standalone/bug-324153.cs	(revision 0)
@@ -0,0 +1,15 @@
+using System;
+using System.Collections.Specialized;
+using System.Configuration;
+
+class Test
+{
+static int Main ()
+{
+NameValueCollection c = (NameValueCollection)
+ConfigurationSettings.GetConfig("Group/Section");
+Console.WriteLine (c ["key"]);
+return 0;
+}
+}
+

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list