-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EditorBrowsable(EditorBrowsableState.Never) in VS 2015 does not work as well as it does in VS 2013 #4434
Comments
Is this fixed? I can still see this bug on VS 2015 Professional Update 1 build 14.0.24720.00 |
The NUnit team is suffering from this issue when developing our Assert.Equals(a, b);
Assert.That(a, Is.Equals... When they should have entered: Assert.AreEqual(a, b);
Assert.That(a, Is.EqualTo(b)); The following appears to work fine in Visual Studio 2013: [EditorBrowsable(EditorBrowsableState.Never)]
new public static bool Equals(object ob1, object ob2)
{
throw new NotImplementedException("I'm afraid I can't do that");
}
[EditorBrowsable(EditorBrowsableState.Never)]
new public static bool ReferenceEquals(object ob1, object ob2)
{
throw new NotImplementedException("I'm afraid I can't do that");
} But no longer works in Visual Studio 2015: You can find the issue here: See also: |
I don't understand why this is so hard to fix? Is this a VS thing, or Roslyn? Which system is responsible for Intellisense population? |
So that's up with this? It was added to the 2.0 milestone but appears to still be an issue. Is there any work for a fix going on regarding this bug? |
Any update? |
@ryo0ka PRs welcome :) |
@dpoeschl and I are interested in seeing this completed, but it doesn't currently fix into our scheduling. I'm hoping a community user picks it up so it can ship in 15.5. Requirements
Time requirementThis will probably take a new user up to a week or more, or an experienced user a few days. Work would need to start within the next week to ensure time for this to ship in 15.5 (the earliest release where it would currently be possible). Interested?If you are interested, please let us know. If more than one person is interested, that would be acceptable for this issue. In particular, it will be good to have more than one person test the intended behavior in Visual Studio 2013, and more than one person review the test cases to ensure they accurately represent the intended behavior so we do not regress in the future. |
@kzu everyone is chock full of a ton of work to do. If you could help out, it would be very valuable and appreciated. |
The problem here is the implementations we want are in the compiler and do not have any public API surface. |
Totally understood @CyrusNajmabadi, as a maintainer of oss myself, I know that's pretty much always the case 😢 . @sharwell I suppose that makes it a plus rather than a problem? 😉 |
Source generators are making this more painful. Mentioned in #44929 and a community member was asking about it on Gitter. |
I am the surprised community member :) In my case the EditorBrowsable.Never properties were As I suppose (For context, this is inside generated code, marked with |
@jods4 The |
My bad, I didn't realize the in-same-project vs in-same-solution distinction was important. |
@sharwell I am not sure why you say this isn't the right issue and why the attribute was never designed to handle that case. The MSDN doc says this about the attribute:
And that's what I'm using it for: I wanted to hide a member from Intellisense. This issue seems to be about the fact that VS doesn't respect This is what I experimented: I was surprised the member was showing in Intellisense, then found out that it's because it was in the same solution. (Admittedly MSDN does point out this limitation, I just didn't read everything thoroughly:)
I can still open a new spin-off issue if you think it's worth it. |
@jods4 This issue tracks fixing a bug where the behavior of the attribute changed in Visual Studio 2015 relative to Visual Studio 2013. The cause of the behavior change, and the resulting behavior after the bug is fixed are both well understood. However, the behavior change requested in #4434 (comment) does not align with the behavior of the feature in any previous version of Visual Studio, making it a separate request; if it isn't tracked as a separate issue it's likely to be lost once this issue is fixed. |
Note that this behavior is very intentional and is explicitly what we have been asked to deliver in the past. At one point we did actually hide these items (even in the same project), but the feedback was overwhelming that this is not what teams wanted. They wanted a way to have apis they could see and use, but which their external consumers would not see. Changing this behavior would not be acceptable as this would regress this feature for all teams currently using it in this fashion. |
It said does not suppress members from a class in the same ``assembly``. This must be ``solution``. This changed from VS2013 to VS2015. See dotnet/roslyn#4434
The proposal that hides Equals and ReferenceEquals for all static types: #59333 |
@YegorStepanov that does not seem to be related to this issue. |
@CyrusNajmabadi My suggestion closes some cases of this problem without writing [EditorBrowsable] 2/4 cases will be automatically closed: The third comment will closed too: #4434 (comment) |
This is still an issue in VS 2022 :-( |
Remove also rather useless IFluentInterface since it's not really working as pre-VS2013 (see dotnet/roslyn#4434)
What is the status of this issue? Is there any progress or PR? |
I didn't understand, is this something that will not be implemented? In that comments, there are some requirements, but I am not seeing any PR and the issue is still opened |
We would take a contribution to apply the design if a motivated party were to provide it. |
Problem
Consider the following projects and classes:
ProjectA
is not included in the solution
ProjectB
is included in the solution; has a binary reference to ProjectA
ProjectC
is included in the solution; has a binary reference to ProjectA; has a project reference to ProjectB
In Visual Studio 2013 the
EditorBrowsable
attribute is honored correctly for members of types defined in assemblies that are included using a binary reference. However, in Visual Studio 2015, some of the methods defined on theSystem.Object
[static Equals, static ReferenceEquals, and GetType] appear in the Intellisense menu despite being marked with theEditorBrowsable
attribute with theEditorBrowsableState.Never
argument in a sub class vianew
hiding methods.Here are some screenshots:
Note that this is the additional problem I mentioned in #4358 in the footnote of this comment.
The text was updated successfully, but these errors were encountered: