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

Warn if types from Microsoft.VisualStudio.Shell.XX are exposed #64

Open
sharwell opened this issue May 14, 2018 · 4 comments
Open

Warn if types from Microsoft.VisualStudio.Shell.XX are exposed #64

sharwell opened this issue May 14, 2018 · 4 comments

Comments

@sharwell
Copy link
Member

Problem statement

Types from Microsoft.VisualStudio.Shell.XX.0.dll are not subject to the normal versioning strategies in Visual Studio. Exposing them in signatures can result in compile or runtime failures in side-by-side load scenarios.

Proposed solution

An analyzer can report a diagnostic for all cases where an exposed signature depends on a type defined in one of these assemblies.

@AArnott AArnott self-assigned this Jul 3, 2018
@AArnott AArnott changed the title Warn if types from Microsoft.VisualStudio.Shell.XX are exposed VSSDK007 Warn if types from Microsoft.VisualStudio.Shell.XX are exposed Jul 3, 2018
@AArnott AArnott changed the title VSSDK007 Warn if types from Microsoft.VisualStudio.Shell.XX are exposed Warn if types from Microsoft.VisualStudio.Shell.XX are exposed Jul 3, 2018
@AArnott AArnott removed their assignment Jul 3, 2018
AArnott added a commit to AArnott/VSSDK-Analyzers that referenced this issue Jul 3, 2018
At this point though, I'm not sure what the analyzer can really do. Public types will derive from MPF types in normal scenarios (like deriving from Package or AsyncPackage), which would seem to be exposing MPF types publicly. How can we get away with flagging such as a problem?

microsoft#64
@AArnott
Copy link
Member

AArnott commented Jul 3, 2018

I'm actually thinking we should Won't Fix this. @sharwell, how can we flag when assemblies expose MPF types in their public API when it's by design that they should do so? For example, a public type will derive from Package. In fact many MPF types may be exposed in "public" API for testability purposes (yes InternalsVisibleTo could be used, but that can be an MPF interop problem too, as we've seen with Roslyn).

@AArnott AArnott added the wontfix This will not be worked on label Jul 3, 2018
@sharwell
Copy link
Member Author

sharwell commented Jul 5, 2018

For example, a public type will derive from Package.

There are two resolutions for this:

  1. The safest resolution is to mark the type which derives from Package as internal instead of public.
  2. An alternative solution, typically for cases where the developer knows there are no other assemblies depending on a project, is to simply disable the rule.

@AArnott
Copy link
Member

AArnott commented Jul 6, 2018

@sharwell Would your team mark all the relevant types internal or would you turn the rule off?

@sharwell
Copy link
Member Author

sharwell commented Jul 7, 2018

@AArnott they are supposed to already be internal, but we'd fix any that were found.

@AArnott AArnott removed the wontfix This will not be worked on label Oct 7, 2018
AArnott added a commit that referenced this issue Apr 14, 2022
…st.Sdk-16.7.0

Bump Microsoft.NET.Test.Sdk from 16.6.1 to 16.7.0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants