Wednesday, January 27, 2016

Configuring .NET Core projects for optimal local development

When developing an ASP.NET Core applications, among other decisions, you need to choose which version of the ASP.NET Core and .NET Core packages to consume. When using .NET Core tooling in its default state, you will likely bump against the following issues when developing many projects locally:

  1. The default Nuget settings are a global configuration (%AppData%\NuGet\NuGet.config).   How do different developers keep their Nuget package source configurations in sync if they are not in source control?
  2. The default package source folder is a global setting (%userprofile%\.dnx\packages).  How can you run separate projects against a different .NET Core package versions without getting version conflicts for packages?

Choosing a .NET Core version for your solution

ASP.NET Core source code is developed on GitHub and then pushed to several different Nuget feeds, based on the stability of the code.  The cadence and feed choices are as follows:

  • aspnetvolatiledev – Any package that compiles is pushed here. Only used by contributors dealing with breaking changes between repos.
  • aspnetcidev – A coherent set of packages that compiled referencing eachother. Used by contributors when building under normal circumstances.
  • aspnetvnext – A coherent set of signed packages that have passed automated testing. Used by consumers evaluating the latest developments in the stack.
  • Nuget.org – Official releases used by general consumers.

The choice will depend on your appetite for risk/change/stability.  Choosing the Nuget.org release means that your packages will be very stable for a long period (e.g. Beta 5, Beta 6, RC1, RC2, etc.) but you will have a lot of catching up to do when new packages are released due to the high amount of code and API churn that is happening at the moment.

In choosing the ASPNETCIDev feed you will avoid monolithic refactors but, instead, you will get hit with regular breaking changes that will impact your development productivity on a daily basis.  

The vNext feed sits between the official feed and the CIDev feed and provides a trade-off between daily breaking changes or a monolithic set of changes.

Restoring Packages

.NET Core projects define their dependencies in global.json and project.json files.  Global.json identifies the platform version dependency while project.json specifies individual package dependencies.  After you have configured these files in your project, it is simply a matter of running the dotnet CLI tool to restore packages from the feed source to your local machine.  




The dotnet restore command uses Nuget configuration to identify which feeds to use when restoring.  The user profile defaults for Nuget are located at %AppData%\NuGet\NuGet.config.  These defaults are updated when you manage package sources via the Nuget configuration tool in Visual Studio.

To add the vNext feed source to your defaults, open the configuration tool and add an entry to the MyGet feed



Configuring per-project settings

Developers should have the best F5 experience possible - which means they should be able to checkout source code and run it without any friction.  Thankfully we can enable this by configuring settings on a per-project basis.

The dotnet restore command will look for and load a local project Nuget configuration before it loads the global configuration from the user profile.

Similarly, command will look for a packages setting in the global.json solution configuration to identify where to locate restored packages before defaulting to %userprofile%\.dnx\packages.


My configuration

The following files explain my personal configuration for local projects to achieve projects that are self-describing of their dependencies and which assist with reducing developer friction.

The first task is to create a local Nuget.config in the root folder of your solution.

The first line of the Nuget.config clears any package sources that might be configured at another level - e.g. the global user setting. This ensures that the local Nuget.config, defines all sources that are relevant for the project and that these are checked in to version control with the rest of the source code.

Next step is to configure a separate location for packages that are restored for the project. This ensures that the project is not impacted by other packages that might exist in the global package store which might have come from a feed which is running at a different cadence to the local project.

At this point, running the dotnet restore command will restore all dependency packages from the vNext feed into a local packages folder in the root folder of the solution.


The final step is to configure Git so that the packages folder is excluded from version control.  This is simply a matter of adding a line to the local .gitignore file for the solution.




No comments:

Post a Comment