[EditorBrowsable(EditorBrowsableState.Never)] does not hide System.Object members from types in Nuget packages

[dotfede]

Version Used:

Visual Studio 17.2.4
.NET SDK 6.0.301

Steps to Reproduce:

1 - dotnet new console
2 - dotnet add package FluentInterfaceExample
3 - Open the newly created project in Visual Studio
4 - Inside program.cs, paste the following code:

FluentInterfaceExample.FluentExample1 e1;
FluentInterfaceExample.FluentExample2 e2;

5 - Below that, type e1. to bring up Intellisense for e1 and e2. to bring up Intellisense for e2

6 - Observe the following:

Note that these types are defined in FluentInterfaceExample Nuget package (source), and implement IFluentInterface (source), which shadows the following System.Object members as follows:

        [EditorBrowsable(EditorBrowsableState.Never)]
        Type GetType();

        [EditorBrowsable(EditorBrowsableState.Never)]
        int GetHashCode();

        [EditorBrowsable(EditorBrowsableState.Never)]
        string ToString();

        [EditorBrowsable(EditorBrowsableState.Never)]
        bool Equals(object obj);

Also note that methods FluentExample1.HiddenMethod1() and FluentExample2.HiddenMethod2(), both marked with [EditorBrowsable(EditorBrowsableState.Never)] are properly hidden from Intellisense.

Expected Behavior:

System.Object members mentioned above should not be visible in Intellisense.

Actual Behavior:

System.Object members mentioned above are visible in Intellisense.

[CyrusNajmabadi]

The members of IFluentInterface are indeed hidden (you're not seeing IFluentInterface.Equals in the list). Having one member's attributes hide another member from intellisense has never been supported afaict.

[dotfede]

@CyrusNajmabadi that is exactly what IFluentInterface was designed for.

See the screenshot in their readme which shows precisely that all 4 members of System.Object aren't shown in Intellisense.

Also see this issue that states that this worked properly in older VS versions and is no longer working in newer versions.

[CyrusNajmabadi]

@fberasategui for the linked issue, we would be open to taking a community contribution here.

[ichthus1604]

@CyrusNajmabadi to clarify, is all the information discussed in #4434 relevant to this particular problem?

This problem is affecting us as well since long ago.

From your comment:

Specifically, it was intentional, and based on enough feedback, that the EditorBrowable attribute have different behavior for your current project versus references. This was because there were many teams that effectively wanted to have members that they would see, but that they wanted to hide from others.

It seems that current behavior in the case of Nuget references does not match your description.

I would be willing to contribute, but please help me clarify the situation here because I'm not sure the code by proposed @sharwell would fix this particular situation, and if it does, what's missing or expected (other than that code) in a PR that would get merged to fix this.

[CyrusNajmabadi]

It seems that current behavior in the case of Nuget references does not match your description.

Can you clarify this? Code from a nuget package should be considered to be external and we should hide items from them when referenced from a project. We should not do the same if the attribute is on a source member that you are referencing as a source-project. This was an intentional change made based on lots of feedback from teams that only wanted hiding from external consumers, not hiding from themselves.

[ichthus1604]

@CyrusNajmabadi

We should not do the same if the attribute is on a source member that you are referencing as a source-project

That's correct. I don't think anyone can argue against that. But the current behavior is not what you describe in the other case:

Code from a nuget package should be considered to be external and we should hide items from them when referenced from a project

As shown above, types from a Nuget package are currently not hiding shadowed members (specifically) marked with the attribute. I assume this is a more general problem (not specifically related to System.Object), but that is by far the greatest offender.

How would a PR have to look, and what would it have to include in order to get merged to fix this? What else apart from @sharwell's code is required?

[CyrusNajmabadi]

How would a PR have to look, and what would it have to include in order to get merged to fix this?

It would likely need to implement the acceptable behavior (as specified in that linked issue), and come with reasonable (e.g. not insanely complex) code to implement that logic, as well as tests to demonstrate the new behavior and how it works for non-source references vs source references.

[sharwell]

Duplicate of #4434

[sharwell]

The information in 4434 should still be relevant. The reason why this was difficult in the past is we didn't have a good way in the compiler API to access the symbols which a symbol hides (as opposed to overrides, which does have an API).