Why I use paket now

I never really had any major problem using the NuGet client. By reading the Twitter timeline, it seems I am the only one without problems. But depending on what dev process you like to use, there could be a problem. This is not really a NuGet fault, but this process makes the usage of NuGet a little bit more complex than it should be.

As mentioned in previous posts, I really like to use Git Flow and the clear branching structure. I always have a production branch, which is the master. It contains the sources of the version which is currently in production.

In my projects I don't need to care about multiple version installed on multiple customer machines. Usually as a web developer, you only have one production version installed somewhere on a webserver.

I also have a next version branch, which is the develop branch. This contains the version we are currently working on. Besides of this, we can have feature branches, hotfix branches, release branches and so on. Read more about Git Flow in this pretty nice cheat sheet.

The master branch get's compiled in release mode and uses a semantic version like this. (breaking).(feature).(patch). The develop branch, get's compiled in debug mode and has an version number that tells NuGet that it is a preview version: (breaking).(feature).(patch)-preview(build). Where build is the build number generated by the build server.

The actual problem

We use this versioning, build and release process for web projects and shared libraries. And with those shared libraries it starts to get complicated using NuGet.

Some of the shared libraries are used in multiple solutions and shared via a private NuGet feed, which is a common way, I think.

Within the next version of a web project we also use the next versions of the shared libraries to test them. In the current versions of the web projects we use the current versions of the shared libraries. Makes kinda sense, right? If we do a new production release of a web project, we need to switch back to the production version of the shared libraries.

Because in the solutions packages folder, NuGet creates package sub-folders containing the version number. And the project references the binaries from those folder. Changing the library versions, needs to use the UI or to change the packages.config AND the project files, because the reference path contains the version information.

Maybe switching the versions back and forth doesn't really makes sense in the most cases, but this is the way how I also try new versions of the libraries. In this special case, we have to maintain multiple ASP.NET applications, which uses multiple shared libraries, which are also dependent to different versions of external data sources. So a preview release of an application also goes to a preview environment with a preview version of a database, so it needs to use the preview versions of the needed libraries. While releasing new features, or hotfixes, it might happen that we need to do an release without updating the production environments and the production databases. So we need to switch the dependencies back to the latest production version of the libraries .

Paket solves it

Paket instead only supports one package version per solution, which makes a lot more sense. This means Paket doesn't store the packages in a sub-folder with a version number in its name. Changing the package versions is easily done in the paket.dependencies file. The reference paths don't change in the project files and the projects immediately use the other versions, after I changed the version and restored the packages.

Paket is an alternative NuGet client, developed by the amazing F# community.

Paket works well

Fortunately Paket works well with MSBuild and CAKE. Paket provides MSBuild targets to automatically restore packages before the build starts. Also in CAKE there is an add-in to restore Paket dependencies. Because I don't commit Paket to the repository I use the command line interface of Paket directly in CAKE:

Task("CleanDirectory")
	.Does(() =>
	{
		CleanDirectory("./Published/");
		CleanDirectory("./packages/");
	});

Task("LoadPaket")
	.IsDependentOn("CleanDirectory")
	.Does(() => {
		var exitCode = StartProcess(".paket/paket.bootstrapper.exe");
		Information("LoadPaket: Exit code: {0}", exitCode);
	});

Task("AssemblyInfo")
	.IsDependentOn("LoadPaket")
	.Does(() =>
	{
		var file = "./SolutionInfo.cs";		
		var settings = new AssemblyInfoSettings {
			Company = " YooApplications AG",
			Copyright = string.Format("Copyright (c) YooApplications AG {0}", DateTime.Now.Year),
			ComVisible = false,
			Version = version,
			FileVersion = version,
			InformationalVersion = version + build
		};
		CreateAssemblyInfo(file, settings);
	});

Task("PaketRestore")
	.IsDependentOn("AssemblyInfo")
	.Does(() => 
	{	
		var exitCode = StartProcess(".paket/paket.exe", "install");
		Information("PaketRestore: Exit code: {0}", exitCode);
	});

// ... and so on

Conclusion

No process is 100% perfect, even this process is not. But it works pretty well in this case. We are able to do releases and hotfix very fast. The setup of a new project using this process is fast and easy as well.

The whole process of releasing a new version, starting with the command git flow release start ... to the deployed application on the web server doesn't take more than 15 minutes. Depending on the size of the application and the amount of tests to run on the build server.

I just recognized, this post is not about .NET Core or ASP.NET Core. The problem I described only happens to classic projects and solutions that store the NuGet packages in the solutions packages folder.

Any Questions about that? Do you wanna learn more about Git Flow, CAKE and Continuous Deployment? Just drop me a comment.