Use Central Package Management

Problem

Back in the day when we had packages.config all the nuget dependencies were specified so our scheme of having a single props file that included all versions was always correct. Now that we get implicit dependencies in package references it is possible for us to have different implicit nuget package versions for different projects. It is also possible for these implicit package references to unify to different versions on a per-project basis.

Solution

Using central package management will (based on my initial investigations) allow nuget to fail the build if implicit dependencies resolve to different versions across projects. This also has the added benefit of us adopting a nuget feature that is expected to have VS UI support vs our current approach which we do not expect to ever be supported in VS.

Implementation

I would like us to adopt and use this feature in the most idiomatic way possible. According to the nuget docs that would mean adding a Directory.Packages.props file to our repo. Briefly prototyped this approach here

Implementation Blockers

• We need an SDK and MSBuild that contains this bugfix

[jmarolf]

I think we are aggressively agreeing here. So here is the work I think I am signing up for:

1. Update roslyn to .NET 5 RC2 (which will have the nuget fix)
2. Add Directory.Packages.props file to the repo root
3. Remove {PackageName}Version variables from Version.props
4. Submit a PR to maetro to be aware of Directory.Packages.props and update them as necessary

[jmarolf]

Well MSBuild is a turing complete language. Supporting all patterns that are possible with it would be rather difficult in general. We need to draw the line somewhere. We could try and convince the nuget team to support Versions.props natively but I would also argue that arcade lies far outside the design of anything considered normal by .NET tooling. Supporting arcade in VS tooling implies that we think these patterns are normal and, frankly, they aren’t. I do not want to hear that some external company has adopted the pattern of a using a powershell script to download a nuget package that contains a Tools.proj file that they use to download vswhere to find where msbuild is. I would like the dotnet restore and dotnet build patterns to be the norm and I would prefer that we acquiesce to the Directory.Packages.props pattern.