By now I would hope that everyone is familiar with NuGet, but in case you’ve been living under a rock.
” NuGet is the package manager for the Microsoft development platform including .NET. The NuGet client tools provide the ability to produce and consume packages. The NuGet Gallery is the central package repository used by all package authors and consumers.
There are numerous reasons to utilize package managers for development, some of the most obvious reasons are as follows:
- Intelligible and automatic dependency management
- Minimize risk of dll hell
- Minimize source control contents
From within Visual Studio, with ASP.NET Core 1.0 projects you still have access to NuGet. In fact the “Manage NuGet Packages” dialog still exists and will allow you to define packages that your application can consume, which takes them on as a dependency. The
project.json file serves as a means for defining these
dependencies. Utilizing the
dnu CLI at the root of the project, if we execute
dnu restore — all of the dependent packages called out are downloaded and placed within the
packages directory. This is where our references are pointing.
This is very much similar to the
nuget CLI, but there are less switches available. One might compare
dnu restore to
nuget restore, furthermore one might assume that these are synonymous or that
dnu is simply a wrapper around
nuget and it calls into it. Both of those assumptions are in fact wrong. The .NET Utility, namely
dnu CLI implemented its own version of package management. While there are consistencies with
nuget — it should be known that they are different.
There are several improvements in my opinion with regard to the
project.json file relevant to NuGet packaging. Imagine that you’re creating a class library or even a shared MVC component library, in either case it might be valuable to embed resources into the package. This can easily be achieved by simply adding a “resource” property to your JSON. The value is a file system globbing pattern — essentially a directory and some wild card indicators. For example if we wanted all of the views in our MVC componet lib to be embedded resources, the following would suffice:
The glob pattern matches on every sub-directory starting from “Views” and finds files of any name but with the
.cshtml file extension. When they’re embedded into the executable (i.e.; the
.dll), they maintain their path hierarchy, so the controllers that call them can still do so if they specify the path and the MVC file provider is an EmbeddedFileProvider.
In addition to the embedding of resources, we can identify content that we want to be part of our package. This is beneficial when you want a file to always be somewhere relative to the location of the executing assembly — like a
config file. To achieve this simply add a “content” property to your JSON like the following:
project.json has several hooks into the
dnu commands by way of the “scripts” property. This defines a “pre” and “post” for each of the following
These are especially useful on the build-server to handle various common tasks at desired times.