Open sharwell opened 6 years ago
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).
For example, a public type will derive from Package.
There are two resolutions for this:
Package
as internal
instead of public
.@sharwell Would your team mark all the relevant types internal or would you turn the rule off?
@AArnott they are supposed to already be internal, but we'd fix any that were found.
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.