And, without modifying your project “*.*proj” files.

And, without storing nuget.exe in your project’s source control.

NuGet 1.6 is out and with it is a new update to Visual Studio that will update your solution and projects with some extra code and even the NuGet.exe application so that your build process will dynamically download the required NuGet packages.  Rightly so, this is in response to the request that NuGet packages not be stored in source control as they just take up space since they are always available via download.

I understand the approach that was taken (including a .targets file as well as the nuget.exe as well as updating the **proj files) however, I think all of that is unnecessary clutter if your build process can handle it alone.

So, I looked at the NuGet commands and updated the standard TFS 2010 build template to manage this additional step automatically.  With this new template, there is no need to update your solution or projects or include NuGet.exe in your project source.

The only thing you really need to change in your project source control is remove the “packages” folder from source control.  That folder will automatically be created during the build.

Even if you already have custom build templates, you should be able to copy the NuGet restore section over since it is all contained in a single sequence.

The one thing this solution does not do is download the packages locally on your dev machine.  So, if you are getting a solution from source control for the first time, you won’t get all of the references you need since the packages folder isn’t in TFS.  That is easily fixed with a simple PowerShell script that you can run locally to set you up.  All of this is provided below.

The solution:

The Template:

Download the “NuGetRestoreTemplate.xaml” template and add it to source control.  This can be anywhere -  it doesn’t need to be part of your Team Project, it just needs to be in a location where your build can access it.

NuGet.exe:

You have 3 options here.

1. The easiest and least intrusive your build machine is to add NuGet.exe to source control.  Like the template, this does not need to be in your Team Project.  Just put it in a location where your build can access it.  You then tell the build definition where it exists in source control.  This approach makes updating NuGet.exe easy since it’s all done through source control.  You never have to get on the build machine which in some environments is next to impossible.
2. Put it on your build server and remember the exact file path.  You can tell the build definition exactly where to look for it.
3. Put it on your build server and add that folder to your PATH environment variable.  If you do this, then you will leave the location blank in the build definition.  It will be found automatically.  One note here: if you do this, you may have to reboot your machine so the build process realizes the right path.

One suggestion for the template and the NuGet.exe location in source control:  Create a general Team Project that will house all of your build goodies such as custom templates, custom activities and support applications.  I generally create a “BuildActivities” project and put everything in there.  You just need to give everyone read access to it.

To follow along with this recommendation, I created a “BuildActivities” Team Project.  In it I have a “BuildProcessTemplates” folder where I keep all of the generally available build templates.  I have a “NuGet” folder where I keep the “NuGet.exe” application.  I also have subfolders in here for previous releases (just in case).  I also have a folder called “Custom Activities” for all of the custom activities that my templates require.  Note: the template I created for the solution I am describing does not require any custom activities.  I just included that suggestion for completeness.

Creating the Build Definition

Creating the build definition is pretty straight forward.

1. When you get to the Process, click “New…” next to your “Build process file:”.
2. Click “Select an existing XAML file”
3. Click “Browse” and navigate to where you placed the template in source control
4. Click “OK”

The “NuGet Restore/Install” section will appear in the build process parameters

Enter the location of the NuGet.exe file.  In this example I placed it in source control but you can just as easily enter the full path on the build machine if that’s where you placed it.  Leave this blank if you put NuGet.exe on the build machine and in the “Path”.

Next, you can add the locations of where to look for the NuGet packages during download.  You can enter multiples here – just delimit with a semi-colon “;”.  If you leave this blank, NuGet will attempt to look at “%AppData%\NuGet\NuGet.config” for NuGet repositories.   Keep in mind that if you leave the parameter blank and expect the build machine to look in the config file, that location is account specific.  The ID of the build process will need to have that file available.

In my example, I included a local network share I set up as a gallery as well as the official NuGet Gallery.

The “Additional Install Arguments” is there if you want to include other parameters like “-Prerelease” or “-ExcludeVersion”.  Note: include the “-“ before each parameter.

That’s it.  You can now remove the “packages” folder from source control and do a build.

Of course, and as always, I would recommend testing this first on a sample app within your environment just to see how it works.

When you run the build, you will see in your log file something similar to this:

This shows that the build process has dynamically downloaded all of the required NuGet packages.

Resources:

NuGet Restore/Install/Update:

Here’s the templates and PowerShell Script:

• NuGetRestoreTemplate.XAML
• NuGetRestore.ps1
• NuGetRestoreUpdateTemplate.xaml

The 2nd template I’ve provided will do the same “restore” process but will also update to the latest version of the NuGet packages rather that just the versions listed in the projects.  It is called NuGetRestoreUpdateTemplate.xaml.  Note: it may or may not break your code to use the update template depending on the version of the package that is downloaded.  See the NuGet documentation for more details.  You can include the “-safe” option in the build definition to avoid the breakage.

The PowerShell script will restore all of the NuGet packages locally if you are not storing the “packages” folder in source control:  NuGetRestore.ps1

My Other TFS Build Template Projects:

TfsVersioning Automated Assembly Versioning on CodePlex

NuGetter Automated NuGet Package Generation on CodePlex

I just found out that Brian Keller mentioned my TFS NuGetter (CodePlex) project that automates the creation, push and publish of NuGet packages through TFS 2010  as his “Pick of the Week” on the August 19th episode of TWC9 (“This Week on Channel 9″).

You can see that episode here:  http://channel9.msdn.com/Shows/This+Week+On+Channel+9/TWC9-August-19-2011

That part was very cool.  The only thing that would’ve made it even more exciting (to me anyway) would have been if he knew who actually created it.  Oh well, it was still cool that it was his pick.  I appreciate the mention Brian!

I’ve been gathering up a bunch of resources around doing development on Azure and decided to post them where anyone, including me, can find them.

Windows Azure Site

• Home
• Pricing Calculator
• Case Studies

Project Templates

• Windows Azure Accelerator for Web Roles
• Windows Azure Worker Role Accelerator
• Windows Azure Toolkit for Windows Phone 7
• Windows Azure Toolkit for Social Games

Lightswitch

• Team  Blog
• LightSwitch Developer Center
• E-Book Available: Beginners Guide to Visual Studio LightSwitch
• Silverlight Show – Learning Lightswitch
• How Do I: Deploy a LightSwitch Application to Azure?

Development / SDK’s

• Windows Azure SDK and Windows Azure Tools for Microsoft Visual Studio
• Windows Azure AppFabric SDK V1.0
• Windows Identity Foundation SDK
• Windows Azure AppFabric SDK CTP
• Tips and Tools for a Better Azure Deployment Lifecycle
• File Based Diagnostics Config with IntelliSense in Azure SDK
• Client Side Tracing for Windows Azure AppFabric Caching
• .NET StockTrader 5 Sample Application

Information, blogs, videos, etc.

• Windows Azure Team Blog
• Team Blog Videos

Training

Last count there was 70+ examples here showing you how to get started with Azure. From the beginning with “Hello World” through SQL Azure, WCF, Silverlight, ASP.Net, LINQ, Storage, Workflow, etc. In VS08/VS10 – C# & VB.NET.

There is a lot of code out here…

• Windows Azure Platform Training Course
• Windows Azure Samples: Learn Through Code
• Access Control in the Windows Azure Toolkit for Windows Phone 7

Planning

Microsoft Assessment and Planning Toolkit 6.0

• Catalog all of the applications in your environment
• Estimate the needed capacity to run your applications on the Windows Azure platform
• Evaluate applications based on migration difficulty
• Stack rank applications in terms of migration suitability
• Obtain a TCO-ROI analysis for the application

Management

SQL Azure Management REST API Reference

WIF gives you the ability to develop claims-based applications and separate or externalize the authentication of users from your application.  It is a better separation of concerns for the application and gives you more capability for creating a secure application that accesses local or web (cloud) services.

Features you can add to your app using WIF

• Authentication
• Personalization
• Federation
• Identity Delegation
• Single Sign On (SSO)

Supported OS Bases

• Windows 2008 Server SP2
• Windows 2008 Server R2
• Windows 7
• Windows Server 2003 SP2
• Windows Vista

Development Framework Versions

• .NET 3.5 SP1
• .NET 4.0

Installation (Step 1)

To develop using the WIF SDK you will first need the Windows Identity Foundation run-time installed on your machine.  Obviously, this suggests that you will need to install this runtime on any machine that is providing WIF-based services.  You will also need IIS as well.

When I went to do the installs I realized that they were in separate places and have different requirements based on the OS that you are using.  Hopefully, the information I have below will organize that a little better so you can just go get what you need and not have to weed through a bunch of “use this here” and “use that there” statements across multiple pages.

One side note.  The reason I started down this path is that I wanted to work with some sample code that a colleague gave me using WIF.  In the application there in a reference to “Microsoft.IdentityModel.dll”.  My search for that assembly led me here.  So, if you’re looking for that assembly, you’ve now found it.

WIF Runtime Installation Downloads

WIF SDK Downloads

Runtime Installation

It will call this installation the “Update for Windows (KB974405)”

Accept the license terms to continue…

It will then do the installation…

And complete…It only took about a minute on my x64 laptop.

SDK Installation

Slightly different license acceptance screen…

Where do you want the files…

Are you sure…

Install…

Done.  This install took significantly longer than the runtime – around 5 minutes.

Download from CodePlex: http://tfsversioning.codeplex.com/

The goal of this project is to create a way to modify the automated build process of TFS 2010 so that versioning is automatic while giving the user the flexibility that they need given the project’s process requirements. I’ve done this in the past using the angle-bracket programming paradigm of MSBuild – powerful but hard. This time I took advantage of the WF capabilities of TFS Build.

Version 1.5.0.0 Features:

• Control over assembly attributes has been extended to include:
  • AssemblyTitle
  • AssemblyDescription
  • AssemblyConfiguration
  • AssemblyCompany
  • AssemblyProduct
  • AssemblyCopyright
  • AssemblyTrademark
  • AssemblyCulture
  • AssemblyInformationalVersion
• Use “Replacement Patterns” to include dynamic (build-time) information in the attribute values
• Control over AssemblyVersion and AssemblyFileVersion exists as in the previous versions
• New (Version 1.5.0.0) custom activity assembly is backward compatible so you can replace the assembly and you do not have to change any existing build definitions
• New Build Process Template is included to provide build definition access to the additional assembly attributes: VersioningBuildTemplate15.xaml

Example: The Build Definition screen when using the updated build process template:

Example: Properties dialog from within Windows Explorer showing the attributes generated dynamically in the build process.

Previous and Related Posts to TfsVersioning:

• Production Ready Assembly Versioning with TFS 2010
• TfsVersioning Build Activity Now Fortified with F#!
• NuGetter Build Process Version 1.0 Released

Not sure why but in Windows 7 when you look at the properties of a .NET assembly and go to “Details” it shows you the “File version” and “Product version”.  Unfortunately, they are both the same and it’s confusing trying to figure out what version number it is really showing.

With Microsoft .NET assemblies, there is an assembly version and there is an assembly file version.  The assembly version is the version you think of when you want to know an application’s version number.  E.g., version “1.2.3.4” and I believe that it should be in the “Product version” in the details window but it’s not.  The assembly file version is used more to indicate which build created the assembly.  E.g., version “1.2.2234.332”.  Therefore, it is usually a more accurate version number and it’s the one that is displayed in the “Details” window (for both version numbers listed).

Now, back to Windows 7.  You can’t just look at the properties and get all of the version information that you need.  For this reason I created a utility to tell me the version info (assembly and assembly file versions) and the strong naming information as well.

Here’s what it looks like when you start it up:

If you drag an assembly from Windows Explorer into that window it will extract the name and version information and display it like below:

You can keep dragging files into the window as many times as you want.

Julian Date in the version:

I use “Julian” dates in my versioning so that the Assembly File Version can increment with each build.  If you look at the version above you will see that the third version value in the Assemby File Version is “11112”.  It’s nice that it’s a Julian date but what day is it?  Right click on the window and you will find out through a message box like this one:

Now you can see that it was April 22, 2011.

You can get the code for the Version Reporter here: http://bit.ly/e4Mu5L

Anyway, this is a useful utility for testing to see if your build versioning process is working and for verifying version numbers in assemblies as you are trying to deploy.

I’ve created data driven tests many times in Visual Studio and I’ve used Excel spreadsheets, comma separated value (CSV) files and XML.  I’ve even written a blog post or two on the subject.  No matter how many times I do it though, it seems that I always get stuck at the beginning because the data files don’t get deployed. WTF? You’d think I would remember how to do it.  Apparently, that’s not the case cuz tonight I ran into the same fricken, aggravating error message and just stared at it like I’d never seen it before.

Here’s the error message:

“The unit test adapter failed to connect to the data source or to read the data. For more information on troubleshooting this error, see "Troubleshooting Data-Driven Unit Tests" (http://go.microsoft.com/fwlink/?LinkId=62412) in the MSDN Library.”  BTW, this was in VS 2010.

Best part is that if you go to that link, it’s not “Troubleshooting Data-Driven Unit Tests”.  It’s titled "Working with Unit Tests” and it’s under VS 2005.  No troubleshooting tips to be found there.  Nothing that helped anyway.

So, I stared at my code and thought, why can’t MSTest find the stupid file and deploy it?!!! It’s not like it’s hidden.  It’s sitting right there in a folder next to the test.

   1:  [DataSource("Microsoft.VisualStudio.TestTools.DataSource.XML", "|DataDirectory|\\WidthTestData.xml", 

   2:              "Row", DataAccessMethod.Sequential)]

   3:          [DeploymentItem("MyProjTest\\TestData\\WidthTestData.xml")]

   4:          [TestMethod]

   5:          public void WhenObjectCreatedShouldValidateWidthValues()

   6:          {

   7:             ...

   8:          }

I did searches on the error and came across many frustrated forum messages trying to find out where the RelativePathRoot is because the DeploymentItem attribute file location is supposed to start from “RelativePathRoot” and go from there.  With that problem in mind, I pointed the DeploymentItem path to many, many variations. Project folder\subfolder\file, ..\subfolder\file, ..\..\subfolder\file, etc. None worked.  I even hardcoded the path and that didn’t work.  Hmmm, a clue.

RelativePathRoot wasn’t the problem.  (BTW, if you were wondering, RelativePathRoot is just the folder of the solution that contains your test project.  Maybe that will be useful to someone.)

I decided to use the Test Settings / Deployment option (double click on “Local.testsettings” in Solution Items and you will get the Test Settings dialog) to force deploy the file rather than rely on the DeploymentItem attribute.  When I clicked on the “Deployment” option I saw it immediately (again).  I forgot to check to see if the “Enable deployment” option was checked.  There’s 45 minutes of aggravation I’ll never get back.

Once I clicked that option, my data driven tests started working and all was good – for the moment anyway.  So, keep that in mind when you run into that cryptic error message when you’re creating data driven tests. 

One other thing, setting the file to “Copy always” or “Copy if newer” is NOT the answer.  Don’t do it.

And now, back to my regularly scheduled testing…

Today I thought it be cool to create a web site on Azure and use all of the great new capabilities of MVC3 and Razor.  So, I fired up Visual Studio 2010 and unfortunately there were no templates that allow you to do such a thing.  Well then, knowing that you can “bin deploy” MVC 3 apps on servers that don’t have MVC3 installed on them by including the right binaries I figured I would give it a go anyway.  Here’s what I did and this may look like a lot of steps but I was able to do this all in the span of about an hour sitting at Hooters, coding, talking to some friends and having a beer.

1. I created 2 solutions in 2 different folders. One to create the Azure setup (I just used the existing MVC2 template to get things started) and a separate one with MVC3 using Razor as the view engine.
2. In the Azure solution, I deleted all of the common MVC folders (Content, Controllers, Models, Scripts and Views) to get them out of the way
3. In Windows Explorer, I copied those same folders from the MVC3 project over to the Azure project (the MVC2 and MVC3 folder structure is consistent)
4. Back in Visual Studio (in the Azure project), I clicked on the “Show All Files” icon so I could see the folders and files
5. Right-click on each of the folder names that I had previously deleted then copied and selected “Include in Project”.  All of the subordinate files are included automatically.
6. Now, to help make sure that the MVC3 assemblies are available for the application, I created a “Binaries” folder in the Azure project.  Thanks to Scott Hanselman’s Post and Reflector I found out which assemblies to copy and from where.  Copy all of the assemblies on the list to the Binaries folder you just created.  Here’s the list:
   -  System.Web.Mvc.dll (v 3.0.0.0) and System.Web.Helpers.dll are the two assemblies that the application needs direct references to.  The rest of the assemblies are dependencies of those two. 
   -  Microsoft.Web.Infrastructure.dll
   -  System.Web.Razor.dll
   -  System.Web.WebPages.dll
   -  System.Web.WebPages.Razor.dll
   -  System.Web.WebPages.Deployment.dll
   Mvc can be found here:  Depending on your system (Program Files or Program Files (x86))\Microsoft ASP.NET\ASP.NET MVC 3\Assemblies
   The rest can be found here:  Depending on your system (Program Files or Program Files (x86))\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\Assemblies
7. Make sure the “Build Action” on the dll files in the “Binaries” folder is set to “None” on all files
8. Remove the existing reference to “System.Web.Mvc” since it is pointing to version 2 and we want version 3
9. Add references to all the assemblies and set the “Copy Local” property of each to “True”.  Worth noting: The application really only needs references to a couple of the assemblies (mainly Mvc and Helpers) so it is arguable that you should only reference those two in the app and the installation process should make the rest of the assemblies available rather than using the VS project do your dirty work.  I tend to agree with that and in a production setting I would subscribe, however, for the purposes of this post, and to ease the deployment to Azure, I added all 7 of the references directly in the project and set them all to copy local.
10. Modify Web.config (this is easier doing a side-by-side compare with the original MVC3 app and the Azure app config files)
    1. In “<system.web><compilation …><assemblies>” change the version number of “System.Web.Mvc” to “3.0.0.0
    2. Add “<add assembly="System.Web.Helpers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />” and “<add assembly="System.Web.WebPages, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" /> to the list of assemblies.  So, ultimately, it will look like this:
       
    3. Make sure <pages><namespaces> looks something like this: 
       
    4. Finally, for the sake of being thorough, change the assembly binding at the bottom of the config so that all references point to MVC version 3
       

Your MVC3/Razor app should now be runnable within the local Azure development environment.  I’m not going to cover it in this post but if you add a certificate and appropriate credentials, you should be able to publish the app directly to a live Azure site.