You are probably aware of NuGet by now. It is the “new” way to get 3rd party libraries into your software development projects. Since NuGet 2.0, it is possible to use the Package Restore functionality. While NuGet does have its downsides, it is much better than manually checking for updates for all your libraries.

Why you shouldn’t be using the NuGet Package Restore option

Long before the NuGet team implemented the package restore option, I was using Pepita to retrieve packages that were missing during a build. However, as soon as the NuGet team implemented the feature I thought I no longer needed Pepita. Oh boy, was I wrong…

It is disabled by default
The Package Restore feature is disabled by default. I have no idea why they did it, and frankly, I don’t care. It’s stupid because you need to enable it for every user on the machine. If you have a build server, you are screwed. They only offer the “solution” to define a system environment variable (are you joking, a system environment variable?).

It is slow
When restoring packages via NuGet, you can get a cop of coffee. In the meantime, don’t forget to go to the toitlet too. And in the meantime, also take a walk. No, this is a bit exaggerated, but it isn’t fast.

It must be enabled per project
The user interface is rubbish. You can enable package restore for a solution several times, and you never know whether it actually worked. The menu item is always available and it always seems to do “stuff”. In other words, you simply cannot trust it.

What is Pepita?

Pepita is a pet project of Simon Cropp. Simon was one of the first that found the missing feature about the package restore and decided to do something about it. While he primarily wrote it for himself, he was able to convince me to no longer check in the packages into source control but to let Pepita restore the packages during a build.

While I was sceptical in the beginning, I really started to like this idea because I could ship my solutions everywhere where it only contained code and no references assemblies. Pepita would take care of the package restore and I didn’t need to publish the NuGet packages with my source code.

As I wrote earlier in this blog post, I thought Pepita was gone and I no longer needed it. However, the package restore feature in NuGet was frustrating me because it didn’t work as it should.

At this time, adding Pepita to a project was still manual labour and required a developer to manually edit the project file. I politely asked Simon to introduce a Visual Studio addin which he did. Now Pepita is back, stronger than ever and ready to kick some NuGet ass!

Why you should use Pepita instead of NuGet package restore

It is super fast
No over engineered stuff with MEF where it all needs to be bound together. It is super fast. If no packages are missing, Pepita finishes in just 1 ms:

1>  All packages listed in packages.config are already installed.
1>  Pepita (version 1.6.0.0) Executing
1>      Cache path is C:\Users\Geert\AppData\Local\NuGet\Cache
1>      Using PackagesPath: C:\Source\Catel examples\lib
1>      Already exists so skipped C:\Source\Catel examples\lib\Catel.Core.3.3.1210251935-beta
1>      Already exists so skipped C:\Source\Catel examples\lib\Catel.Extensions.Controls.3.3.1210251935-beta
1>      Already exists so skipped C:\Source\Catel examples\lib\Catel.MVVM.3.3.1210251935-beta
1>      Already exists so skipped C:\Source\Catel examples\lib\Catel.Fody.1.4.0.0
1>      Finished (1ms)

It runs as msbuild task (in-process)
You might be thinking: so what? Well, if you are a professional developer (and I assume you are), you have a build server. This means that Pepita works on build servers out of the box without having to create system environment variables.

It caches downloads
Pepita caches downloads of downloaded packages. This means that if you have to restore Catel.Core.3.3 for 2 different solutions, it will only have to download the package once. This is also very cool when you are not connected to the internet and you need packages restored.

Where can you get it?

Pepita is available in the Visual Studio Gallery.

How does it work?

After you installed the Visual Studio extension, Pepita works extremely simple. Just select a project, go to Project => Pepita => Enable get as you can see in the screenshot below.

The cool thing is that you can now see whether you have package restore enabled for projects. It is also possible to select multiple projects and enable Pepita for all selected projects at once.

While developing Catel, we often release pre-release packages using NuGet. This gives the users that want the latest & greatest to keep up-to-date without having to compile the solution themselves.

NuGet provides a great way of managing “regular” packages, but this way is not supported for pre-release packages. All pre-release packages must be installed manually using the Package Manager Shell in Visual Studio using the following command:

  1: install-package Catel.MVVM –includreprerelease

We want to keep the examples repository up-to-date with the latest & greatest as well. However, the examples repository contains over 25 example projects. Imaging having to execute this for every project on every beta release (which we are planning to do every night as a nightly build).

Using PepitaGet

First of all, I always use PepitaGet in my projects. It is a great small too that you can use as PreBuild step in your project file. It will automatically download NuGet packages that are references by a project, but not yet downloaded. It is a must have if you want to follow this procedure, or you must have your own way (script, NuGet, or …) of downloading the packages listed in the packages files of your projects.

Removing the “old” packages

First of all, you will have to close Visual Studio. Simply delete the right packages from the packages folder in the solution root (in our case, the beta packages for Catel):

Replacing the version number in the packages

Next thing to do is to search for all packages.config files. Open them all together in notepad++ and find the old package version number. Then press CTRL + H (Find and Replace) and replace the old version by the new version and click “Replace All in All Opened Documents”:

Once the replacement is completed, save all files.

Replacing the hint path in the project files

It is also important to replace the hint path for the libraries in the project files. Otherwise, the project files will search for the assemblies themselves (and you definitely don’t want that to happen). To replace the hint path, search for all csproj files and open them in notepad++. Again, replace all the occurrences of the old version with the new version:

Start Visual Studio, build the solution and let PepitaGet do its work

Last but not least, start Visual Studio again and let PepitaGet do its work. As soon as you build, the prebuild step (which runs PepitaGet) will kick off PepitaGet and download the required NuGet packages as you can see in the screenshot below:

Starting with December 21st, beta packages of Catel will be published to NuGet. Starting with NuGet 1.6, it is possible to create “pre-release” packages. This way, it is possible to give users that like to live on the edge a change to update their packages via NuGet.

Strange versioning

The versioning of the beta versions is a bit strange. This is due to a bug in NuGet which does not support the full SemVer standard to include build numbers. Therefore, the beta versions are always 1 less than the next official version.

For example, say that version 2.4 is currently the official version, and the team is working towards version 2.5. Then all beta versions for 2.5 will have this version number:

2.4.[yyyyMMdd]-beta (thus on December 21st, the version would be 2.4.20111221-beta).

Installing the beta via NuGet

Unfortunately, the NuGet package manager does support pre-releases. So, the beta versions must be installed via the shell. This example installs Catel.Windows as a package. However, to install other packages simple change the ID (name) of the package.

Installing the latest beta

   1: Install-Package Catel.Windows –IncludePrerelease

Installing a specific beta

   1: Install-Package Catel.Windows –IncludePrerelease -version 2.4.20111221-beta

Updating to the latest beta

   1: Update-Package Catel.Windows –IncludePrerelease

Updating to a specific beta

   1: Update-Package Catel.Windows –IncludePrerelease -version 2.4.20111221-beta

Updating to the latest stable version

   1: Update-Package Catel.Windows

I always try to create NuGet packages for Catel to create an “as easy as possible” installation experience. Catel uses lots of code snippets to increase the speed at which a developer can create view models and more. So, how do we deploy these code snippets using NuGet?

Good question, I couldn’t find the answer so I decided to create the solution myself. The cool thing about NuGet is that it supports Powershell scripts. Keep in mind that this is not an introduction to NuGet, I expect you to already know how to create basic NuGet packages.

Files preparation

First,  create a “tools” folder if you haven’t already created that for your NuGet package. Then, copy all your code snippets into that directory so you have something like the image below:

As you can see, both the code snippets as the scripts are located in the “tools” folder of the package. For more information about what kind of scripts can be included, please read the NuGet documentation.

Install script

Let’s take a look at the content of the scripts. I created a Powershell script (install.ps1) with the following content:

   1: # Install script for code snippets with NuGet

   2: # =============================================

   3: # Written by Geert van Horrik (see http://blog.catenalogic.com)

   4: #

   5: # Version 1.0 / 2011-02-18

   6: #

   7: # Required call to get environment variables

   8:  

   9: param($installPath, $toolsPath, $package, $project)

  10:  

  11: # You only have to customize the $snippetFolder name below,

  12: # don't forget to rename the $snippetFolder of the other file

  13: # ("uninstall.ps1") as well

  14:  

  15: $snippetFolder = "Catel"

  16:  

  17: # Actual script start

  18: $source = "$toolsPath\*.snippet"

  19: $vsVersions = @("2005", "2008", "2010")

  20:  

  21: Foreach ($vsVersion in $vsVersions)

  22: {

  23:     $myCodeSnippetsFolder = "$HOME\My Documents\Visual Studio $vsVersion\Code Snippets\Visual C#\My Code Snippets\"

  24:     if (Test-Path $myCodeSnippetsFolder)

  25:     {

  26:         $destination = "$myCodeSnippetsFolder$snippetFolder"

  27:         if (!($myCodeSnippetsFolder -eq $destination))

  28:         {

  29:             if (!(Test-Path $destination))

  30:             {

  31:                 New-Item $destination -itemType "directory"

  32:             }

  33:         

  34:             "Installing code snippets for Visual Studio $vsVersion"

  35:             Copy-Item $source $destination

  36:         }

  37:         else

  38:         {

  39:             "Define a value for snippetFolder variable, cannot be empty"

  40:         }

  41:     }

  42: }

The code should fairly speak for itself. On my test-machine (Windows 7, 32-bit, only VS 2010 installed), this is the output:

“Installing code snippets for Visual Studio 2010”

Uninstall script

A good installer should also uninstall the contents if required. Therefore, there is also an uninstall script (uninstall.ps1):

   1: # Uninstall script for code snippets with NuGet

   2: # =============================================

   3: # Written by Geert van Horrik (see http://blog.catenalogic.com)

   4: #

   5: # Version 1.0 / 2011-02-18

   6: #

   7: # Required call to get environment variables

   8:  

   9: param($installPath, $toolsPath, $package, $project)

  10:  

  11: # You only have to customize the $snippetFolder name below,

  12: # don't forget to rename the $snippetFolder of the other file

  13: # ("install.ps1") as well

  14:  

  15: $snippetFolder = "Catel"

  16:  

  17: # Actual script start

  18: $source = "$toolsPath\*.snippet"

  19: $vsVersions = @("2005", "2008", "2010")

  20:  

  21: Foreach ($vsVersion in $vsVersions)

  22: {

  23:     $myCodeSnippetsFolder = "$HOME\My Documents\Visual Studio $vsVersion\Code Snippets\Visual C#\My Code Snippets\"

  24:     if (Test-Path $myCodeSnippetsFolder)

  25:     {

  26:         $destination = "$myCodeSnippetsFolder$snippetFolder"

  27:         if (!($myCodeSnippetsFolder -eq $destination))

  28:         {        

  29:             if (Test-Path $destination)

  30:             {

  31:                 "Uninstalling code snippets for Visual Studio $vsVersion"

  32:                 Remove-Item $destination -recurse -force

  33:             }

  34:         }

  35:         else

  36:         {

  37:             "Define a value for snippetFolder variable, cannot be empty"

  38:         }        

  39:     }

  40: }

How should I use the scripts for my own packages?

I developed the scripts in such a way that they are compatible with all known versions of Visual Studio (2005, 2008 and 2010).  The cool thing is that you only have to modify the following line in both scripts:

   1: $snippetFolder = "Catel"

Just give the folder your own name. Don’t think to be smart by renaming it to “”. You will then delete all the code snippets of the user, and I can tell you one thing: they won’t be happy… I added a protection for this in the script, but just make sure you don’t do that.

Downsides

The downside of this script is that if a package is used in multiple projects, and it is uninstalled in one project, the code snippets are uninstalled and thus not available for other projects. You might want to choose to keep the files on the system as garbage, it’s up to you.

Downloads

NuGet Code Snippets scripts.zip (1.32 kb) [Downloads: 372]

Disclaimer:
Only tested on Windows 7 32-bit with Visual Studio 2010 and NuGet 1.1.