ASP.NET Core 1.0 NuGet packaging

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
  • etc..

Good News

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.

embedding resources

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.

portable content

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:


The 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 dnu commands:

These are especially useful on the build-server to handle various common tasks at desired times.


Extras, extras — read all about it! I suggest further reading and investigation. I have found the schema store useful and the github repo even more so.