Runtime: Doc enhancement: How can I quickly build the NuGet package for a single library that ships out of dotnet/runtime?

[ahsonkhan]

If I need to build and test a particular package (say System.Text.Json), here is what I do:

1) On a clean clone of the repo, run:

build.cmd -subsetCategory coreclr -c Release && build.cmd -subsetCategory libraries /p:CoreCLRConfiguration=Release -allconfigurations
2) Wait ~10 minutes.

Once built, I can find it in E:\GitHub\Fork\runtime\artifacts\packages\Debug\Shipping (along with all the other packages), add the local directory to my NuGet.Config, reference it from a console app project, and then dogfood it. We should update and capture the dogfooding steps in docs.

Is there a better/faster way to do so and can we improve the inner dev loop for that, where I don't have to build all the packages?

cc @ViktorHofer, @maryamariyan, @safern

[safern]

Is there a better/faster way to do so and can we improve the inner dev loop for that, where I don't have to build all the packages?

What we could do is introduce a property like PackageToBuild so that you do build.cmd -subsetCategory libraries -allConfigurations /p:PackageToBuild=System.Drawing.Common and then the allConfigurations leg, knows what to build only to build a single package and then build that package.

The current way you can achieve that is by disabling BuildPackages

https://github.com/dotnet/runtime/blob/c0e876f165792085c0eb10051409266bc9451f98/src/libraries/build.proj#L8

and commenting the following:

https://github.com/dotnet/runtime/blob/d5adc6be3d554df5b833c32686dd651038cf642e/src/libraries/dirs.proj#L13-L16

Then you can afterwards just build the pkgproj of interest, but that is a lot of steps, introducing a property that does it for you would be ideal.

cc: @ericstj @joperezr

[joperezr]

As @safern say, all we need in order to build a package is to restore the targetting packs, and build the ref assemblies, so that is why what @safern is suggesting above is to comment out all of the build of the implementation since you only really care about one single library. The only other optimization you can do, is to also set

https://github.com/dotnet/runtime/blob/48080fa967e85a4aa162281a950358eea430e5f4/src/libraries/build.proj#L6

to false since you don't really need to build native in order to build packages and that will save you quite some additional time.

[safern]

to false since you don't really need to build native in order to build packages and that will save you quite some additional time.

Well, some packages need to build the native stuff, no?

[joperezr]

nope :). IIRC the only native shim we package is for System.IO.Ports and I believe that this is a separate package entirely. BuildNative will only build clrcompression, and that guy only gets packaged on Microsoft.NETCore.App, so library OOB packages shouldn't need it.

[safern]

IIRC the only native shim we package is for System.IO.Ports and I believe that this is a separate package entirely

Right.

BuildNative will only build clrcompression, and that guy only gets packaged on Microsoft.NETCore.App, so library OOB packages shouldn't need it.

Ah, for windows, that's true, I was thinking of Crypto packages, but those shims ship inbox as part of the framework.

[ericstj]

You can build individual pkgprojs, assuming all ref and redist are available (as mentioned above). This will get easier once we stop relying on the ref and redist pass for non-netcoreappcurrent.

[krwq]

would be nice if we made dotnet pack work in our repo (even if targets are hacked and it's actually not using dotnet utils)

[ericstj]

WRT dotnet pack we could tackle that with https://github.com/dotnet/arcade/issues/1033, along with eliminating pkgroj and making our packages build from outer build of our src projects.

An ugly hack would be to have a Pack target defined in our src csprojs that just calls build on the pkgproj if it exists.

[joperezr]

Also just to update the instructions @safern and I provided above some time ago, there have been changes in the infrastructure so those are no longer up-to-date, but the good news is that it is much easier now to build one single package without the need to modify temporarily any source files. So if you are in master branch latest, and in a clean clone, all you have to do is to first build all targetting packs with:

build.cmd -s clr.corelib+libs.depprojs+libs.ref -rc release -allConfigurations

That shouldn't take long (takes about 3-5 mins on my machine depending on NuGet restore). After that you should be able to build all configurations for a specific library, like for example:

cd src\libraries\System.DirectoryServices.Protocols\
dotnet build src\System.DirectoryServices.Protocols.csproj /t:rebuild /p:BuildAllConfigurations=true

and finally you should also now be able to build the package itself, by running:

dotnet msbuild pkg\System.DirectoryServices.Protocols.pkgproj /t:rebuild

As long as you are only working with one library and don't really care about running tests (as running tests will require building the whole clr and libs runtime) then I recommend this workflow as a fast-paced way to be able to open library solutions in VS and have all building as expected as well as being able to build all configurations and the package (if building an OOB assembly)

[safern]

Thanks, @joperezr for updating the instructions.

That shouldn't take long (takes about 3-5 mins on my machine depending on NuGet restore). After that you should be able to build all configurations for a specific library, like for example:

I think this step shouldn't be necessary right? as building the pkgproj will build the ref and src for all configurations?

[ericstj]

@joperezr I think you can omit the step to build csproj as building the pkgproj will build all projects it contains.

[joperezr]

The thing I've seen is that if you use the workflow I proposed above, building the pkgproj won't call restore on the ref and src projects, which we now need to do, so it is just a way to make sure restore is called (notice how I used dotnet build and not dotnet msbuild since I wanted restore to happen)

[joperezr]

I haven't tried skipping my second step and just doing dotnet build pkg\System.DirectoryServices.Protocols.pkgproj but that probably works as well.

[safern]

Right, that is what I was about to ask 😄.

[ViktorHofer]

FWIW

1. You can omit the -s if the subsets are the first argument.
2. You shouldn't need to specify /t:Rebuild. In case you need it, dotnet build --no-incremental is the public facing switch for that.

[ViktorHofer]

Fixed (documented) by https://github.com/dotnet/runtime/commit/b7f809d7e37f8dade15fc6aa588565d3f0ee20a6: https://github.com/dotnet/runtime/blob/b7f809d7e37f8dade15fc6aa588565d3f0ee20a6/docs/workflow/building/libraries/README.md#build-packages

TL;DR:

build.cmd libs
dotnet pack src\libraries\System.Text.Json\src\

is sufficient now. No allconfigurations build needed anymore.