With the switch to the SDK based *.csproj format for Visual Studio projects, the file format was greatly improved. One of the biggest new features is the usage of PackageReference to simply reference NuGet packages with a single entry. In contrast to the old way, all NuGet packages are typically downloaded to some default folder, usually %USERPROFILE%\.nuget\packages.

Recently, with the latest Visual Studio 2017 V15.9, the GeneratePathProperty was introduced. It allows you to define a build variable that holds the path to the NuGet package folder. It's useful if you want to access files in the NuGet package in your build steps. This could be, for example, running a CLI tool or, in my case, copying some files from the package to your output path.

For example, the xBim toolkit is an Open Source collection of libraries that let you work with digital building models. Some of the more compute intensive operations are performed via a C++ dll that is loaded at runtime. For this, xBim requires the compiled dlls to be present in the output folder so it can find and load them.

In my xbim-meets-angular demo, I have a small component that lets you upload IFC building model files, which are then tesselated and displayed right in the browser. For this, I want the C++ dlls to be copied to the build and publish output directories. I used to have a PowerShell build script do that, but now it's really simple to do with the project system itself:

Both libraries, for x86 and x64, are copied to the build and publish output in this snippet. No other code is required! You just need to set GeneratePathProperty="true" on the package reference, then the variable $(PkgXbim_Geometry) will point to the path of the package - including its version. Dots in the package name are simply replaced with underscores, so the variable for the package Xbim.Geometry becomes PkgXbim_Geometry.

There's one small thing, though: Currently, it seems to work only for project types using the Microsoft.NET.Sdk.Web SDK, regular ones don't work yet. But support is just around the corner. In the meantime, you can simply use dotnet build instead of MSBuild if you're compiling for the classic .NET framework.

Happy building!