Skip to content
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

Open
TyreeJackson opened this issue Aug 7, 2015 · 10 comments

Comments

@TyreeJackson
Copy link

commented Aug 7, 2015

Problem

Consider the following projects and classes:

ProjectA

is not included in the solution

namespace ProjectA
{

    using System;
    using System.ComponentModel;

    public class BaseClass
    {
        [EditorBrowsable(EditorBrowsableState.Never)]
        public new Type GetType() { return base.GetType(); }

        [EditorBrowsable(EditorBrowsableState.Never)]
        public new static bool Equals(object objA, object objB) { return Object.Equals(objA, objB); }

        [EditorBrowsable(EditorBrowsableState.Never)]
        public override bool Equals(object obj)  { return base.Equals(obj); }

        [EditorBrowsable(EditorBrowsableState.Never)]
        public override int GetHashCode() { return base.GetHashCode(); }

        [EditorBrowsable(EditorBrowsableState.Never)]
        protected new object MemberwiseClone() { return base.MemberwiseClone(); }

        [EditorBrowsable(EditorBrowsableState.Never)]
        public new static bool ReferenceEquals(object objA, object objB) { return Object.ReferenceEquals(objA, objB); }

        [EditorBrowsable(EditorBrowsableState.Never)]
        public override string ToString() { return base.ToString(); }

        public static void DoSomeBasicThing() {}

    }

}

namespace ProjectA
{

    public class ClassA : BaseClass
    {

        public static void InitializeClassA() { }

        public void DoSomethingA() {}

    }

}

ProjectB

is included in the solution; has a binary reference to ProjectA

namespace ProjectB
{

    using System.ComponentModel;
    using ProjectA;

    [EditorBrowsable(EditorBrowsableState.Never)]
    public class ClassB : BaseClass, IInterfaceA<ClassB>
    {

        public void DoSomethingB()
        {
            var objectA = new ClassA();
        }

    }

}

ProjectC

is included in the solution; has a binary reference to ProjectA; has a project reference to ProjectB

namespace ProjectC
{

    using ProjectB;

    public class ClassC 
    {

        public void TestEm()
        {
            var objectB  = new ClassB();
        }

    }

}

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 the System.Object [static Equals, static ReferenceEquals, and GetType] appear in the Intellisense menu despite being marked with the EditorBrowsable attribute with the EditorBrowsableState.Never argument in a sub class via new hiding methods.

Here are some screenshots:

Visual Studio 2013 - viewing ProjectA.ClassA's Intellisense menu from ProjectB.ClassB: Visual Studio 2015 - viewing ProjectA.ClassA's Intellisense menu from ProjectB.ClassB:
Visual Studio 2013 - viewing ProjectA.ClassA's Intellisense menu from ProjectB.ClassB Visual Studio 2015 - viewing ProjectA.ClassA's Intellisense menu from ProjectB.ClassB
Visual Studio 2013 - viewing objectA's Intellisense menu from ProjectB.ClassB: Visual Studio 2015 - viewing objectA's Intellisense menu from ProjectB.ClassB:
Visual Studio 2013 - viewing objectA's Intellisense menu from ProjectB.ClassB Visual Studio 2015 - viewing objectA's Intellisense menu from ProjectB.ClassB
Visual Studio 2013 - viewing ProjectB.ClassB's Intellisense menu from ProjectC.ClassC: Visual Studio 2015 - viewing ProjectB.ClassB's Intellisense menu from ProjectC.ClassC:
Visual Studio 2013 - viewing ProjectB.ClassB's Intellisense menu from ProjectC.ClassC Visual Studio 2015 - viewing ProjectB.ClassB's Intellisense menu from ProjectC.ClassC
Visual Studio 2013 - viewing objectB's Intellisense menu from ProjectC.ClassC: Visual Studio 2015 - viewing objectB's Intellisense menu from ProjectC.ClassC:
Visual Studio 2013 - viewing objectB's Intellisense menu from ProjectC.ClassC Visual Studio 2015 - viewing objectB's Intellisense menu from ProjectC.ClassC

Note that this is the additional problem I mentioned in #4358 in the footnote of this comment.

@Pilchie Pilchie added this to the 1.1 milestone Aug 10, 2015

@Pilchie Pilchie modified the milestones: 1.2, 1.1 Sep 3, 2015

@hmahajanHM

This comment has been minimized.

Copy link

commented Jan 27, 2016

Is this fixed? I can still see this bug on VS 2015 Professional Update 1 build 14.0.24720.00

@jcansdale

This comment has been minimized.

Copy link

commented Oct 20, 2016

The NUnit team is suffering from this issue when developing our Assert API. We'd like to hide Equals, to prevent users from accidentally entering the following:

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:

equals

You can find the issue here:
nunit/nunit#1726 (comment)

See also:
https://twitter.com/jcansdale/status/788704315695398912 😉

@kornelijepetak

This comment has been minimized.

Copy link

commented Apr 5, 2017

I don't understand why this is so hard to fix?
It should be a piece of cake now that Intellisense already got filtering by types, methods, properties, etc.

Is this a VS thing, or Roslyn? Which system is responsible for Intellisense population?

@sebastianbk

This comment has been minimized.

Copy link

commented Jun 26, 2017

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?

@ryo0ka

This comment has been minimized.

Copy link

commented Sep 3, 2017

Any update?

@sharwell sharwell modified the milestones: 15.5, Unknown Sep 3, 2017

@CyrusNajmabadi

This comment has been minimized.

Copy link
Contributor

commented Sep 3, 2017

@ryo0ka PRs welcome :)

@sharwell sharwell added this to Community Priority in IDE: sharwell Sep 6, 2017

@sharwell sharwell moved this from Community Priority to Internal Priority in IDE: sharwell Sep 6, 2017

@sharwell sharwell self-assigned this Sep 7, 2017

@sharwell

This comment has been minimized.

Copy link
Member

commented Sep 7, 2017

@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

  • Define the intended behavior
    • Target item is in the current project
    • Target item is found via a project reference
    • Target item is found via an assembly (metadata) reference
  • Locally experiment with Visual Studio 2013 to identify any differences between the intended behavior and the behavior you observe in Visual Studio 2013
  • Post results of intended behavior and Visual Studio 2013 experiments here for review/sign-off (feel free to copy from the original bug report comment where it helps, but review text for accuracy)
  • Implement the completion filtering according to the intended behavior
  • Implement tests covering each of the intended behavior scenarios

Time requirement

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

@jinujoseph jinujoseph removed this from the 15.5 milestone Oct 14, 2017

@kzu

This comment has been minimized.

Copy link
Contributor

commented Dec 27, 2017

As far as intended behavior, I'd say the members with EditorBrowsableState.Never should never be show, regardless of how the member was discovered (current project, project reference or assembly reference). An improvement would be to show it anyway for the first two, but I'd say it's very much a nice too have with very low pri.

@apmorton

This comment has been minimized.

Copy link

commented Nov 12, 2018

@JieCarolHu @sharwell what is the status of this? I am interested in helping to get this issue fixed.

@JieCarolHu it looks like you have done some work on this in the past (#25290), but the PR is closed and appears dead for several months. Is there still work on this? Was it killed because of the required public API changes?

The work in #25290, although incomplete, does appear to fix some cursory unit tests I wrote up for this issue. What is the blocker on finishing this work? Presumably approval or buy-in from whomever owns the relevant public APIs?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.