DVCS and the Pinocchio Test

I know in this day and age there are still folks out there not using source control systems.  I can't help that. This post isn't for you.  Sorry.

I also know that there are some folks out there still using VSS.  Stop.  Do you not listen to your architects? Do you like having to deal with exclusive check-in/check-out locks?  What's the matter with you?

Even TFS, with its central hub, seems a bit quaint to anyone not stuck in a Corporate IT gig where you're forced to go with an on prem solution.  Sheez, at least move that stuff to TFS online.  But whatever.  At least you can merge and have simultaneous editing.

Yeah, I feel all the cool kids tell me they're using DVCS systems.  Cori Drew got me excited about git (though I don't use the powershell command line personally), and I've since used it for both part time work and my personal projects.  In my new organization, we're using Mercurial, so I'm getting to see this side of things now. My only personal regret is that I missed the Subversion era.

And for the most part, these DVCS systems are awesome.  There are some hassles, and you can get yourself in a real twist if you're not careful with branches, but overall, I quite like the experience.
One of the biggest issues I have with using DVCS systems (doesn't matter, Git and Hg have the exact same issues) with .NET is that the .csproj files are so fragile.  Two people want to add files and/or references to the project at the same time, and Visual Studio seems less than consistent about where it puts stuff, often leading to merge conflicts.  And get that merge wrong, and whoo, you are in for some rollbacks.

So here's my recipe on how to handle this.

1. if you're going to add a file or reference, do that first.  Add the empty file and the reference and check that in immediately.  You're adding an empty file or reference, so generally you're not going to break the build.  The point is to keep that .csproj file change open and out there for the minimum amount of time.
2. I like to make sure that my tests are picked up and running, so I'll often write a Pinocchio test.  What's that?  Goes like this:

namespace MyNamespace
{
    [TestFixture]
    class MyTests
    {
        [Test]
        public void PinocchioTest()
        {
            //I wish I were a real test
        }
    }
}

This cracks me up every time I see it, too.  I read it in the voice of Pinocchio from Shrek.

Fixing My Custom TFS 2010 Activities to Run on TFS 2012

Wow, what a technologist.  A post or two a month about everything except technology.  Well today, I'm going to document one of my most recent struggles in the hope that someone will benefit.

Started off getting this error.

TF215097: An error occurred while initializing a build for build definition \<My Project Build Name> The values provided for the root activity's arguments did not satisfy the root activity's requirements:'DynamicActivity': Expected an input parameter value of type 'Microsoft.TeamFoundation.Build.Workflow.Activities.BuildSettings' for parameter named 'BuildSettings'.'DynamicActivity': Expected an input parameter value of type 'Microsoft.TeamFoundation.Build.Workflow.Activities.TestSpecList' for parameter named 'TestSpecs'.Parameter name: rootArgumentValues

Bizarre.  So what it comes down to is that 2012 does not work with artifacts either built against or referencing a component from 2010.  A 2012 build controller won't run custom build activities (which I had) that were compiled against the TFS 2010 binaries.  Further, the custom XAML files were polluted by the workflow designer, said to be a bug in the designer, but that smells fishy to me.

Here's the steps I took.

1. I rebuilt my custom activities with all the references pointing at the new 2012 TFS .dlls.  
2. I overwrote the old custom activity .dlls in the $\BuildProcessTemplates\CustomActivities directory and checked them in.
3. After that, my builds still didn't work, failing with essentially the same error, so I used the XAMLCleaner code I found here to scrub my custom build workflow templates (.XAML files).
4. Running anything and causing one of these version issues requires the build controller to be reset.  Use the TFS admin console to do so.
5. My *.CI builds all use the DefaultTemplate.xaml.  The upgrade gave me a DefaultTemplate.11.1.xaml.  I deleted the DefaultTemplate.xaml locally, renamed the DefaultTemplate.11.1.xaml to DefaultTemplate.xaml, and checked it in.  .CI builds ran fine.
6. Once I had made all these changes, I checked everything in and ran my custom web and default release builds, and they worked.

Hope this can help someone.  I love TFS ALM, but sometimes the stuff is daunting.  The two links above really helped me out.