.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'.

Working with TFS work items in Excel

Visual Studio ships with a pretty good query engine that you can use to retrieve a list of work items, but if you need to change the filter criteria frequently or calculate totals for estimates or remaining work, Visual Studio can’t cut it on its own. Fortunately, the integration between TFS and the Microsoft Office suite is fantastic and we can export our data into Excel with a few simple clicks.

Hey, if you’re reading this because you’re a project manager at my office and I sent you this link, you’ll need a few things on your machine for this to work:

1. Download a copy of Visual Studio Team Explorer.  It’s basically a slimmed down shell of Visual Studio without all the code editing features and it includes all the goodies for you to query work items and export to Excel.  If you have Visual Studio installed, you can skip this step.
   • Visual Studio Team Explorer for Visual Studio 2012
   • Visual Studio Team Explorer for Visual Studio 2010
2. You’ll need read permissions to the TFS Team Project. Reach out to your friendly IT support for this.
3. If you’ve never connected to the TFS server before, you’ll also need the TFS Server name, Team Project Collection name, and Team Project name.

There are two ways to get TFS work items into Excel:

• Import TFS Work Items into Excel
• Export TFS Work Items from Visual Studio or Team Explorer into Excel

Importing TFS Work Items into Excel

Let’s assume that you’ve never connected to TFS before. Managing this from Excel is actually pretty easy.

1. Open Excel and create a blank workbook
2. Select the “Team” option from the Ribbon. If “Team” isn’t available in the Ribbon, you haven’t installed Team Explorer. (see above)
3. Select the “New List”.
   
4. The Connect to Team Foundation Server dialog will appear.
   
5. Click the Servers button. The Add/Remove Team Foundation Server dialog will appear.
   
6. Click the Add button to open the Add Team Foundation Server dialog.
   
7. Fill in the server name and details provided to you by IT. You’ll know you’ve entered the right information when the Preview matches the information provided.
   
8. After all the connection information is provided, select the appropriate Team Project Collection, and the Team Project that you want to use.
   
9. Finally a dialog appears that lets you select an existing TFS query.
   
10. Once you’ve selected, the query, click OK. Voila!
    

Exporting TFS work items to Excel from Visual Studio

Exporting your favorite query from Visual Studio to Excel couldn’t be easier. Simply run the query and then select “Open in Microsoft Office –> Open Query in Microsoft Excel”

Famous Last Words

Here’s a few tips with working with work items Excel:

• At any time you can get the latest by clicking the “Refresh” button
• If you make changes, you can push them back to the server by clicking the “Publish” button. (You’ll need write permissions for this)
• This worksheet is tied directly to the server, so don’t forward the spreadsheet to individuals that don’t have access to the data. For this, copy the entire worksheet to another worksheet.