Join GitHub today
NuGet packaging #29408
Removes custom packaging scripts and most hand-written nuspecs with packages generated from csproj files that produce the assemblies contained in the packages.
This allows integration to Arcade build flow, proper dependency tracking and
Roslyn produces these kinds of packages:
Package and project interchangeability
In general, package and project references are designed to be interchangeable. That is, a project reference can be changed to a reference to a package produced by the project. This means that dependencies of a project correspond to dependencies of the package.
To avoid spilling dependencies on private VS packages to the dependency lists of our packages it was necessary to mark these dependencies with
Building multiple versions of packages (repacking)
Roslyn build produces 3 versions of packages: per-build pre-release, pre-release and release.
Exact dependency versions
When generating packages from projects NuGet Pack task currently doesn't support generating exact versions to nuspec file (e.g.
Pre-release package versions now include commit SHA.
@tmat does this mean that the packages we get directly out of our build won't have the exact versions? That's stil somewhat worrisome, as we do have teams like VS for Mac consuming those packages. If nothing else, @KirillOsenkov, @brettfo and others should be aware that they're losing some protection if they aren't careful.
Yes, it does. If this becomes an issue we can update the NuGetRepack tool to repack the per-build packages as well. Or we can just sent PR to NuGet to add the support like I described in NuGet/Home#7213
This pull request makes me realize how little I understand NuGet packaging. Specific questions in some comments.
@jasonmalinowski Looking into non-flowing package references issue - some of our test projects actually already have unnecessary package references. They repeat references that flow from test utilities.
It looks like the ideal state would be having one utility test project per layer (workspaces, features, editorfeatures, VS) that all test projects on that layer reference and that lists the dependencies needed on that layer. The rest of the test projects would then have no additional package references.
I think that's an issue now, since it means the packages we use on a regular basis won't have the same behavior of the ones we ship. In other words, this becomes an issue once we're about to ship packages we broke, didn't realize it, and have a major problem.
How hard is this to just fix, or work around?