Roslyn: IntelliSense for OperationDescription does not find Behaviors member

[poke]

Version Used: Visual Studio 2017 v15.1 (26403.7)

Steps to Reproduce:

1. Create a new .NET framework project (e.g. console application), and add a reference to System.ServiceModel.
2. Declare a variable op of type OperationDescription
3. Try to access the Behaviors member of this object and observe what IntelliSense does.

Expected Behavior:
When typing op.Beh, IntelliSense should suggest to autocomplete to op.Behaviors.

Actual Behavior:
IntelliSense does not see the Behaviors member at all, so typing it completely will make IntelliSense autocomplete to op.OperationBehaviors. You can then remove the Operation part manually again, and the code is still valid and compiles fine. IntelliSense is even able to jump to the member by pressing F12 on it.

---

I have no idea what’s going on here, but this is driving me crazy. IntelliSense just doesn’t see the member although it is there and has been there for a long while. I’ve confirmed this behavior on three different machines.

[Pilchie]

This member is marked with the [EditorBrowsable(EditorBrowsableState.Never)] attribute, which is something that API designers can use to deliberately hide things from IntelliSense.

[NinjaSciurus]

Why would you deliberately hide a non-deprecated public property from IntelliSense? This only makes developing harder and more time-consuming...

[CyrusNajmabadi]

Why would you deliberately hide

Roslyn didn't hide anything. The API designer decided they did not think this was a member that should be shown in intellisense. You would have to talk to the authors of that API why they felt this should not be used.

[NinjaSciurus]

Roslyn didn't hide anything.

I was not trying to blame the Roslyn team, sorry if my comment suggested that. I am just looking for ideas why hiding public members might be useful in general because I get the feeling that I am missing something fundamental. As for the Behaviors property, you are right, only its development team can answer that.

[CyrusNajmabadi]

I am just looking for ideas why hiding public members might be useful in general

Sometimes an API author needs to expose some member for part of their system to work, but they don't want that member to be used by other callers. It's rare, but sometimes necessary due to factors specific to their domain.

Similarly, sometimes there are members exposed that will actually be confusing to users and will just end up doing the wrong thing. For example, Assert libraries often pick up .Equals from Object. Users may call this, thinking the assert library will actually check (and assert) that the values are equal. Of course, Object.Equals doesn't do this. It just checks the values and returns true/false. So, it's reasonable for the library to want to hide that .Equals so you instead call the .Equal method it exposes.

Another example is members that have been superseded by something else. They can't be removed (for breaking change reasons. But the author wants to help guide new code written to use the new APIs. Roslyn uses this itself in many of our own APIs that we have superseded.

etc. etc. etc.

Hope that helps explain things!