User Story: Package authors can validate that their multi-targeted packages are well-formed

[terrajobst]

The tooling we provide as part of the SDK has close to zero validation that multi-targeted packages are well-formed. For example, a package that multi-targets for .NET Core 3.1 and .NET Standard 2.0 needs to ensure that code compiled against the .NET Standard 2.0 binary can run against the binary that is produced for .NET Core 3.1. In the dotnet/runtime repo we have tooling that ensures that this is the case, but this can't easily be used by our customers. We have seen this issue in the wild, even with 1st parties, for example, the Azure AD libraries.

Spec TBD

Rough list from @Anipik:

1. Compatible frameworks in package have compatible surface area (including identity and version).
2. Ref is compatible with source (including version), source is consistent (in case of many src, they all have same version and public surface).
3. No duplicate types in the closure.
4. No binding redirects in the closure (permit baselining).
5. Compat with previous release. Both API compat and package applicability compat.
6. No applicability holes. EG ref/net5.0 without src/net5.0
7. Warn on unnecesary package references. A package reference that is never used directly by assembly. A package reference that gets removed by conflict resolution. PackageReference which is exposed to compile but only used at runtime.
8. Warn on missing package references. Package references exposed in one framework to consumers but absent in a compatible framework.
9. NETFramework targeting when .NETStandard is supported

[safern]

Assigning myself as well @ericstj agreed with me to drive this together with @terrajobst once specs are out.

[danmoseley]

Includes moving our code from CCI to S.R.M

[safern]

Includes moving our code from CCI to S.R.M

The plan is to use Roslyn (Based on PublicApiAnalyzer). If we use S.R.M we will end up on the same spot we're right now where every new Roslyn feature like Nullable ref types we need to wait for S.R.M to support that, or implement it ourselves.

[danmoseley]

Sounds good, my understanding was wrong.

[mairaw]

Bulk closing .NET 6 epics and user stories. If you think this issue was closed in error, please reopen the issue and update it accordingly.