asp.net

Specifying package dependency versions in ASP.NET vNext

David Zych

• 2 min read

This post was inspired by this question on StackOverflow. Noel asks:

At the company I work at we do the following when we need references to third party dlls in our projects:

  • Use nuget to get package
  • Pull dll’s out and create a “lib” folder and add the references here
  • this lib folder is added to git so other team members have all references when they do a pull from git
  • Reference dll’s stored in lib folder in our project
  • We do this to have full control and know exactly what references we are using.

My question is how is this achieved when using vnext and can we continue to do it this way?

Have watched “INTRODUCING: The Future of .NET on the Server” and it seems you list all dependencies in project.json file and when you do k restore it will go and download all based on feeds in nuget config file

New to ASP.NET vNext is the project.json file. That is the new configuration file which (as far as I know) is replacing the current web.config and .csproj files. Among other things you specify your dependencies in that file, and they are resolved by Nuget and the K Package Manager. The K Package Manager is run either automatically by Visual Studio or manually at the command line by running kpm restore.

Name/Value Pairs

The project.json file is just a json file, meaning you specify everything in Name/Value pairs. Dependencies are specified by the Package: version syntax, where the version can be a:

  • Specific Version
  • Latest Version of a specific set
  • Latest Version

Examples

In my fork of the Dependency Injection repository I have a specific version of Castle.Windsor specified:

"dependencies": {
    "Castle.Windsor": "3.2.1"
  },

If I wanted, I could specify the latest version by specifying no version at all:

"dependencies": {
    "Castle.Windsor": ""
  },

Or, if I wanted the latest patch of version 3.2 I could use a wildcard (*):

"dependencies": {
    "Castle.Windsor": "3.2.*"
  },

No more lib folder!

There is no more reason to have a special lib folder in your repository! During active development of your project you can specify a wildcard to always stay up to date. Once it’s time to release, you can lock down the version to a subset or a specific patch to ensure your application is using a known commodity.

This is also very helpful with your own libraries as well. If you have some class libraries that your applications reference, you can set up a custom Nuget feed and automatically have your applications get the latest versions of your own code. Neat!