.props files and NuGet 2.5

My last post showed a very simple PowerShell script to automate project properties as part of a NuGet package. Shortly after posting, I exchanged a few tweets with some very smart people. The suggestion was that there’s a new feature in NuGet 2.5 that can pull .props and .targets files directly into your project without having to resort to powershell scripting. I had to try this.

So, I created a .props file:

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <PropertyGroup>
        <AssemblyOriginatorKeyFile>mykey.snk</AssemblyOriginatorKeyFile>
        <SignAssembly>true</SignAssembly>
    </PropertyGroup>
</Project>

And put it in a new package:

Then added my shiny new package to a new project.

…And nothing happened.

…At first. I had to unload and reload the project to see the changes.

<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="..\packages\StrongKey2.1.0.0\build\StrongKey2.props" Condition="Exists('..\packages\StrongKey2.1.0.0\build\StrongKey2.props')" />
  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <Platform Condition=" '$(Platform)' == '' ">x86</Platform>

I’m thinking, for my example anyway, that powershell is better suited for this?

Manipulating Projects with NuGet Powershell scripts

I’ve been playing with hosting NuGet packages on our internal NuGet server a fair bit recently and encountered some interesting feedback from a colleague: none of our packages are signed with a strong-name. Gasp! Strong naming is definitely something that falls under the you really should bucket but gets quickly put in the not today simply because it’s a pain. If you’re familiar with the concept, the challenge with strong-naming is that if you give one assembly a strong-name then all dependent assemblies must also have one. This quickly cascades into a lot of repetitive tasks.

The pain of repetitive tasks is something that NuGet handles really well, so why not put my signing-key in a nuget package to automate this process? The concept of this package is extremely straight forward:

1. Add my snk file to the project as content
2. Manipulate the project properties in the install.ps1 script

I’ve really been wanting to write some PowerShell scripts for NuGet packages for a while now, but haven’t had the opportunity. My initial thought was to manipulate the project as an Xml document, but abandoned that approach as some research showed that Visual Studio would prompt the user to reload the project.

After some Googling, I came across a HaaHa (Haack/Hanselman) presentation at MIX11, where Scott’s AddMVC3ToWebForms package had some dirty hacks to manipulate the project. There’s a really good discussion in the NuGet forums that suggests using MSBuild API is a good approach to manipulate the Project properties only if what you want isn’t directly available from the Visual Studio API. 

Fortunately for me, manipulating the properties I wanted was dead easy so my script couldn’t be simpler:

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

$project.Properties.Item("AssemblyOriginatorKeyFile").Value = "mykey.snk";
$project.Properties.Item("SignAssembly").Value = "true";

$project.Save();

Few handy tips I discovered while writing this…

You can get access to the $project variable using the Package Manager Console:

$project = Get-Project

You can list the details of your objects using the get-member cmdlet:

$project | get-member

And you can get a dump of the current values, and list of properties easily:

$project.Properties
$project.Properties | select Name

Well, that’s all for now. Let’s hope this is the start of some awesome PowerShell NuGet badassness for you.

Happy Coding'.

NuGet PackageRestore is awesome

It’s safe to say I’m a NuGet fan.  I’ve been using and following NuGet since the original Nubular days, but somehow I missed the significance of the Package Restore feature announced in version 1.7. I’ve had a chance to try it out. Simply put, it’s awesome.

Package Restore is a feature that allows your project to download and install packages as they’re needed, which means you don’t have to commit these packages into your source control repository. Java developers will recognize this feature as something similar to Maven, which has been around for while, but for .NET this is a very welcome change.

Enabling the feature in Visual Studio is pretty simple, just bring up a context-menu on the Solution Explorer and choose “Enable Package Restore”. Once enabled developers (and your build server) don’t even need to have NuGet installed to take advantage of this, they simply need an environment variable “EnableNuGetPackageRestore” defined.

The impact this feature has on your development team is subtle, but very powerful, and after using it on my current project I’m realizing how crippling our previous approach has been.

Up to this point my usage of NuGet has focused around the initial stages of the project, when the solution and dependencies are initially being put together. In this scenario, I’m checking the packages NuGet installs into my source control which means other developers (and my build server) have everything they need to compile the solution after they’ve got the latest source from the server.

Checking libraries into source control exposes a few interesting, and a bit too common, pain points:

• Upgrading packages isn’t easy because developers may manage the dependencies for projects manually, even if they have NuGet installed. In a way, I can’t blame the developers for doing this because this is, after all, how we’ve been managing our dependencies for years. But ultimately this practice defeats the purpose of using NuGet in the first place: I can’t upgrade all my projects in my solution to a newer version of the package if there are projects that NuGet isn’t aware of.
• Source control can get bloated with different versions of packages over time. If developers are using NuGet to manage their packages, they might forget to remove old versions in the repository. It takes a bit of extra discipline to stay on top of this.
  • Side note: depending on the connection between your build agent and server this bloat is potentially slowing down your build.
• Developers can still experience problems where their Local workspace isn’t current. This problem happens fairly frequently, if a developer isn’t getting the latest copy of the packages folder on a regular basis.

Over the past few weeks, I’ve found the package restore feature addresses these concerns, plus a few extra perks:

• We’re more open to trying out new packages because there’s less operational overhead. Developers don’t have to worry about breaking the build because they forgot to check in required assemblies, and the impact to remove the dependency is limited to the project file and config file. Less operational overhead makes the team more flexible to change when necessary.
• There’s new found desire to move existing dependencies to NuGet packages. NuGet has helped our team visualize the relationship between our dependencies which plays into how we’ll update and manage our packages, but it also automates the dependency management. For example, the process of duplicating a project’s dependencies when setting up a test project is greatly simplified. Once these benefits are realized, you’ll being to scrutinize the dependencies in the solution that aren’t managed by NuGet. In some cases, this has led us to create packages for our reusable libraries – which is so awesome because this will benefit our project and the organization as a whole. And that’s cool.

So there you have it. If you’re not using NuGet, you should download it and give it a try. If you’re already using it but not leveraging Package Restore I challenge you to give it a spin – does it make your team productive? Leave a comment below!

Happy coding.