Closed
Description
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:
- Compatible frameworks in package have compatible surface area (including identity and version).
- Ref is compatible with source (including version), source is consistent (in case of many src, they all have same version and public surface).
- No duplicate types in the closure.
- No binding redirects in the closure (permit baselining).
- Compat with previous release. Both API compat and package applicability compat.
- No applicability holes. EG ref/net5.0 without src/net5.0
- 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.
- Warn on missing package references. Package references exposed in one framework to consumers but absent in a compatible framework.
- NETFramework targeting when .NETStandard is supported