ORTHOcoders » Deployment

Nuget gotcha: Avoid storing packages in the repository

Amir Barylko — Sun, 13 Mar 2011 18:26:10 +0000

It’s been a while since Nuget project was released. Since the project birth I’ve been watching closely to see when would be a good opportunity to start using it for my projects and recommend using it for my clients.

Basically, the Nuget project solves dependency management for all your .NET projects. That means that you don’t need to search any more for libraries that you need to use like NHibernate or nUnit and just install them from a centralized server.

The path to Nuget

So far I’ve been using Rake for all my builds and I’m super happy with it. Using a DSL specifically designed for building projects is a great advantage, Ruby gives you lots of flexibility and the Albacore gem is the cherry on top.

One of the many things that I like about the Ruby world is gem + bundler combination. For .NET projects I’ve been using also noodle to copy the dependencies to my local folder (usually called lib).

However not everything is ponies and rainbows:

Ruby based solutions are not always well received in .NET project (no matter how good they are)
Not many developers publish their libraries / frameworks
Creating gems with .NET assemblies is discouraged since Nuget was born

All this reasons plus the fact that the .NET community was embracing the idea of package management using Nuget make me consider it as a great option.

However one thing was keeping me from doing the change, and that is the ability of reading a configuration file and use it to download all dependencies (very similar to what Bundler does).

And that was it…. Until a couple of days ago….

Nuget Adoption

Last week I say a tweet by @davidebbo saying that Nuget supports now reading from a config file!

Why is that so important? Because I don’t want to store my dependencies in the repository any more!

The assemblies that we use in a project usually don’t change until we update a newer version. What’s the point of storing them with our code if we can use just a reference to them and download them at our leisure?

It takes way less space to store our repositories and updating the packages quite easier because you just change the references and the configuration file, and that’s it, everyone gets them.

Also imagine sharing in your company all the internal assemblies by publishing them to a local Nuget server instead of having a share drive or similar. Update the version whenever you want! No more versioning dependencies nightmares! And everything is treated the same way, they are all packages!

So I installed latest version of Nuget (following the link above) and started the conversion:

Step 1: Changing the References

Open your .sln file, remove all your references and add them again by doing right click + Add Package Reference. That would accomplish the following:

Find the reference in the package server
Install it to a local package folder (usually called Packages)
Write a config file with the dependency installed (in the same folder as the project)

Step 2: Modify the Rakefile

I need dependencies in order to build, so I need to make sure that before building all my dependencies are satisfied, to do so I modified the task setup:dep to do the following:

namespace :setup do
	desc "Setup dependencies for nuget packages"
	task :dep do
		FileList["**/packages.config"].each do |file|
			sh "nuget install #{file} /OutputDirectory Packages"
		end
	end
end

And I need to make sure this happens every time before building, so I need a dependency in the build task (remember that I’m using Albacore for the msbuild tasks).

	desc "Build the project"
	msbuild :all, [:config] => [:setup] do |msb, args|
		msb.properties :configuration => args[:config] || : Debug
		msb.targets :Build
		msb.solution = solution_file
	end

Step 3: Enjoy!

That’s it! Super easy! If you want to check the code please go to github and download it.

.NET Dependency Management

Amir Barylko — Sat, 08 May 2010 23:29:13 +0000

The problem

One of the features that I miss when I work in .net is a tool to retrieve my dependencies (i.e. assemblies, tools) from a centralized server to avoid copying them again and again from project to project.

In the java world Maven does that (and much more) for you, and in the Rails world a utility called Gems (a gem is a ruby library) exists that will download and install the dependencies of your project for you.

To illustrate the point, let’s look at the .NET Media Library project. The project file structure looks something like this:

+—Media Library

+—Main: main source, all the projects are in here.

+—Test: Testing source, all the testing projects are in here.

+—Lib: Dependencies for the projects.

+—Tools: Tools to be used to build, test, deploy, etc.

I have to potential candidates to store external resources (actually I’m using SVN externals, but is giving me lots of grief), lib and tools.

Under lib I have the libraries like:

And under tools I have

Every library and every tool has a particular version, even some of them have dependencies on their own that I have to compile, store and copy every single time I start a project or I want to upgrade.

What to do? What to do indeed….

A new project is born

What to do? Create my own, of course.

Disclaimer: I don’t want to reinvent the wheel, so, if you know of a similar project, please let me know ASAP!

My goal is to build a tool that will use a configuration file in which I can declare my dependencies and will download them from a known host.

Similar to Gems I’d like to use a DSL (Domain Specific Language) to be declarative and have a clear syntax to describe, versions, sources, targets, aliases, etc.

However, I’d like to take advantage of another language that I can build on top, to have lots of features out of the box that otherwise I need to implement on my own.

Don’t be scared, BOO is here!

What better candidate than Boo? Quoting the site:

Boo Boo is a new object oriented statically typed programming language for the Common Language Infrastructure with a python inspired syntax and a special focus on language and compiler extensibility.

After using Binsor in a few projects I was convinced that Boo is an excellent choice to build the tool. So my first step was to buy the book DSLs in Boo: Domain-Specific Languages in .NET, and start reading.

First Draft DSL Syntax

Let’s imagine that we want to declare dependencies for the .NET Media Library, here is my idea so far:

lib_folder lib
source http://MavenThought.com/nass

# Testing libraries
lib MavenThought.Commons, 0.2
lib MavenThought.Testing, 0.2
lib nunit, 2.5
lib SharpTestEx, 1.0
lib SpecFlow, 1.2

# Castle Stack
lib Castle.Core, 1.1
lib Castle.Windsor, 2.0

# ORM
lib NHibernate, 2.1
lib SQLite, 2.1

# Web framework
lib OpenRasta, 2.0.3
lib JSon.NET, 3.5

The lib keyword declares the dependency and the version and we can see at the top the configuration for the destination folder and the source to get the dependencies. Because we are using Boo we can use the comments, etc…

Any feedback?

MSBuild scripting part II, Versioning and Deployment

Amir Barylko — Wed, 31 Dec 2008 23:46:36 +0000

MsBuild Introduction

MsBuild is a language to create build scripts using predefined tasks. Please check my previous blog for a full description

Versioning

Before talking about deployment we have to consider how to version our assemblies before copying them to any environment. Having the correct version number is very important once you start a development iteration. The QA team needs to know which version to test and report, the user needs to know which version they are seeing, you need to know which version is causing problems, etc…

.NET uses the Properties/AssemblyInfo.cs file to store the version info. Inside each file you will find the following code:

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version
//      Build Number
//      Revision
//
// You can specify all the values or you can default the Build and Revision Numbers
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("1.0.0.0")]

Here is a brief description of the recommended usage of each number:

Major: This number indicates a big difference between versions. When it changes the user will expect “Major” changes in functionality.
Minor: This number indicates fixes, bugs, etc. Still same functionality but with some modifications.
Build: This number indicates the amount of times you built the app so far. (not always used)
Revision: This number indicates the revision number from your source control. This number is very important because it would give you the information needed in order to check the revision you need and be able to reproduce bugs, errors, etc.

So far, so good. We just need to change all the files in each project and put the same version… and when it changes… again… easy, right?

MsBuild to the rescue

Not to fret my friend, luckily we have msbuild on our side. First of all we will define the version we want in or msbuild file, using a property group.

	

	
		MediaLibrary
		\temp\Export\$(ProjectName)
		\temp\Builds\$(ProjectName)\Latest
		0
		1
		0

As you can see the revision number is not included because we would like to use the source control tool to get the revision number every time we run the script to make sure we always have the right version.

Tigris has a set of tasks that will help us to achieve our goal. You can download it for free and install it.

Now that we have the version we want (Major.Minor.Build) we need to get the revision number from the repository and store it into a property. Because I use SVN I’ll use the SvnVersion task from Tigris to get the version number and store it into the property Revision.

If you also use SVN you will need a command line tool in order to run svnversion. Collabnet has a free SVN client you can download and use.

After finding the version number we need to find all the files that we would like to change. For that purpose we will define another ItemGroup including all the AssemblyInfo.cs files in our hierarchy and store them into the variable AssemblyFiles.

The final step is to replace each declaration with the version in the AssemblyInfo.cs file with the version we defined in our build file using the FileUpdate task for each cs file.

The FileUpdate task uses a regular expression to find the version number. In this case we are looking for four digits separated by dots and as replacement we use the variables we defined previously.

Deployment

Alright. We have all our assemblies (executable, etc) with the right version and we are ready to roll.
Now, we need to build again to include the right version in release mode and then copy the files to the destination of our preference.

A common practice is to copy the files to a folder where all the team knows the latest version will reside. Using a continuous integration tool like Cruise Control .NET or TeamCity makes easier to have always the latest version available as soon a new change is committed to the repository.

I’ll call this task DeployBin and will do the following:

Delete the destination folder
Call the UpdateAssemblyVersion task to update to the latest version of all the Assembly.cs files.
Build again (Release mode) to have the latest binaries with the version updated.
Create the destination folder.
Define a variable called SourceFiles using an ItemGroup to include all the assemblies I would like to copy and excluding the ones I don’t need (testing assemblies).
Copy all the files listed in the SourceFiles variable to the chosen destination.

Ready? Here is the magic:

Voila! That’s it! You can make the deployment as complicated as you want. You can separate the folders, rename the previous version, etc, etc.

Here is the complete file in case you would like to look at it. I hope you will find it useful.

In my next blog about MSBuild we will talk about creating custom tasks.

Any feedback is most welcome.

Enjoy.