-
Notifications
You must be signed in to change notification settings - Fork 264
Description
When using "legacy"-style .csproj
project files we have a separate packages.config
file where all dependencies are listed, including transitive ones. This allows a use case when one installs a package with dependencies and then decides which transitive dependencies can be manually updated. So, the benefits are:
- Dependencies are easily identifiable due to presence of a flat list
- Fine-grain control over all dependency versions
There are drawdowns of course: the flat list can blow up to a huge one.
E.g., after installing Autofac.WebApi2.Owin from NuGet, we have a picture like this:
Transitive dependencies which are clearly viewable can be manually updated very easily.
When using the new Sdk-style .csproj projects NuGet references are added as <PackageReference/>
to the project file itself and transitive dependencies are resolved by MSBuild automatically:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net462</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Autofac.WebApi2.Owin" Version="4.0.0" />
</ItemGroup>
</Project>
So, to update transitive dependencies, one would have to
- Identify them (e.g. via obj/project.assets.json)
- Add all of them explicitly to the project
- Perform updates
And this has to be done after each update and for every (!) transitive dependency in the project which is nearly impossible.
This seems like a "regression" to me.
The best possible resolution would be to show transitive dependency updates in NuGet GUI or via CLI. If the user decides to update one of the dependencies, it would get explicitly added to the project. (similar to #3159)
Maybe there is some workaround to achieve the specified behaviour?