Moving Dependencies to csproj is a bad idea

I’ve seen this blog entry (https://blogs.msdn.microsoft.com/dotnet/2016/10/19/net-core-tooling-in-visual-studio-15) that details moving the dependencies to the XML inside of csproj and I think this is a really bad idea. I am for moving most of what is inside project.json to csproj, but the great experience of editing the project.json for dependencies is going to slow people down, even if you do support intellisense. It’s just going to push people to use the PowerShell extensions or the VS Nuget UI both of which are a big step back.

This means we’re going from the simple and sublime:

"Microsoft.AspNetCore.Mvc": "1.0.0"

to:

 <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.0.0" />

This is even a step back from the XML file from prior versions since the csproj has to be reloaded to make these changes. Please reconsider this.

My suggestion is to keep the dependencies as a nuget.json or packages.json instead.

[bricelam]

Personally, I’m happy to see NuGet finally become a first-class citizen in the .NET project/build system. The real issue is that MSBuild needs to support additional file formats besides just XML…

[davkean]

Sorry folks, we have no intention of moving back to project.json. PackageReference is here is to stay.

For those using the new bits, having <PackageReference/> as items is quite powerful. Here’s a few of the things you can do with them:

Share package references across a solution Condition them Unify package versions across a solution