Description
We have some libraries which are available as NuGet packages and are also included in a shared framework. Examples include System.Collections.Immutable and System.Reflection.Metadata, as well as all of the packages which are part of Microsoft.AspNetCore.App.
If an application depends on a NuGet package that includes a later version of the library than is included in the shared framework, then the updated library will be included in the app's published output. (We sometimes describe this by saying the library has been "lifted out" of the shared framework). The fact that the library is included in the publish output may be unexpected, especially if the updated library was a transitive dependency. This is amplified by the fact that framework-dependent apps compile against the .0 patch of the major.minor version of .NET Core that they target. So if a library is patched in a patch of .NET Core, then it is likely to be included in the published output of projects, even when, as time goes by, those projects are likely to run on patched versions of .NET Core which include the patched library.
Possibilities for how we could mitigate the issue include some combination of the following:
- Add a warning when a library is lifted to help people understand why the library is included in the output
- Allow projects to specify a minimum target framework version, which would allow later patches to be targeted at compile-time, avoiding lifting the library out
- By default, don't include patch updates to libraries in the framework in the publish output (major or minor updates would still be included). The normal way to get patched versions of the library on .NET Core would be to update the shared framework rather than by referencing a later version of a package. This would probably require that the assembly version didn't change in patches, in order to prevent binding problems when code compiled against the patch needs to run on an unpatched version of .NET Core.