But it works on my PC!

We had an interesting issue of late building a Surface2 application solution within a TFS 2010 build system. The solution built fine in VS2010 on both my development PC and also using VS2010 on my TFS build box (both Windows 7 64bit PC), so I know I had all the right SDKs in place. However if I built it via TFS 2010 Team Build I got the error

App.xaml (136): Unknown build error, 'Index (zero based) must be greater than or equal to zero and less than the size of the argument list…”

This error appeared after we added this new block of XAML code

<VisualTransition GeneratedDuration="0:0:0.2">
  <VisualTransition.GeneratedEasingFunction>
        <CircleEase EasingMode="EaseInOut"/>      - this was the line the error was reported on
  </VisualTransition.GeneratedEasingFunction>
</VisualTransition>

I assumed the issue was that Visual Studio was somehow able to resolve an assembly reference that MSBuild could not.

so to try to resolve this I copied the MSBuild command line that was being run by the TFS build from the build log and ran it in a command prompt on my build box. Happily I got the same error, so at least it was repeatable. I then removed options on the command line until I had the minimum to give the errors. I ended up with

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe "C:\Builds\7\Surface\External Concierge CI\Sources\BlackMarble Concierge.sln"

If I changed to

MSBuild.exe "C:\Builds\7\Surface\External Concierge CI\Sources\BlackMarble Concierge.sln"

the error when away, so it had to be the version of MSBuild. When I used the 32bit version (picked up by default via the PATH) all was OK, the 64Bit gave the error.

So my fix was just to force the build to run x86 and all was OK

As part of the on-going effort in documentation I have recently published more documentation for the TFS build extension project activities

• AssemblyInfo
• CodeMetric (updated) and CodeMetricHistory
• File
• Twitter

One of my favourite new features in VS11 is that the unit testing is pluggable. You don’t have to use MSTest, you can use any test framework that an adaptor is available for (at the release of the beta this meant the list of framworks on Peter Provost’s blog, but I am sure this will grow).

So what does this mean and how do you use it?

Add some tests

First it is worth noting that you no longer need to use a test project to contain your MSTest, you can if you want, but you don’t need to. So you can

1. Add a new class library to your solution
2. Add a reference to Microsoft.VisualStudio.TestTools.UnitTesting and create an MStest test
3. Add a reference to xUnit (I used NuGet to add the reference) and create an XUnit test
4. Add a reference to XUnit extensions (NuGet again) and add a row based xUnit test
5. Add a reference to nUnit (you guessed it - via NuGet) and create a nUnit test

All these test frameworks can live in the same assembly.

Add extra frameworks to the test runner

By default the VS11 test runner will only run the MStest test, but by installing the xUnit.net runner for Visual Studio 11 Beta and NUnit Test Adapter (Beta) either from the Visual Studio gallery or via the Tools –> Extension Manager (and restarting VS) you can see all the test are run

You can if you want set it so that every time you compile the test runner triggers (Unit Testing –> Unit Test Settings –> Run Test After Build). All very nice.

Running the tests in an automated build

However, what happens when you want to run these tests as part of your automated build?

The build box needs to have have a reference to the extensions. This can be done in three ways. However if you are using the new TFSPreview hosted build services, as announced at VS Live, only one method, the third, is open to you as you have not access to the VM running the build to upload files other than by source control.

By default, if you create a build and run it on the hosted build you will see it all compiles, but only the MStest test is run

The fix is actually simple.

1. First you need to download the xUnit.net runner for Visual Studio 11 Beta and NUnit Test Adapter (Beta) .VSIX packages from Visual Studio Gallery.
2. Rename the downloaded files as a .ZIP file and unpack them
3. In TFSPreview source control create a folder under the BuildProcessTemplates for your team project. I called mine CustomActivities (the same folder can be used for custom build extensions hence the name, see Custom Build Extensions for more details)
4. Copy the .DLLs from the renamed .VSIX files into this folder and check them in. You should have a list as below
   
   
5. In the Team Explorer –> Build hub, select the Actions menu option –> Manage Build Controllers. Set the Version control path for  custom assemblies to the new folder.
   
   

You do not need to add any extra files to enable xUnit or nUnit tests as long as you checked in the runtime xUnit and nUnit assemblies from the Nuget package at the solution level. This should have been default behaviour with NuGet in VS11 (i.e. there should be a package folder structure in source control as shown in source explorer graphic above)

You can now queue a build and you should see all the tests are run (in my case MStest, XUnit and nUnit). The only difference from a local run is that the xUnit row based tests appear as separate lines in the report

So now you can run tests for any type on a standard TFSPreview hosted build box, a great solution for many projects where just a build and test is all that is required.

Whilst writing documentation for TFS community build extensions (just published the Zip activity documentation) I hit upon a problem working with TFS11. The TFS community build extensions support both TFS2010 and TFS11beta, unfortunately the two versions need to be built separately (once against TFS2010 DLLs and once against TFS11 ones). As of version 1.3 of the extensions both versions are shipped in the download.

In the past in the past I have tended to work in TFS2010 on this community project, but since the VS/TFS11 beta release I am trying to move over to the new build. So to write the documentation for the ZIP activity I started in TFS11. I followed the usual method to use a custom activity (there is no improvement over this frankly horrible process in VS11) so within VS11 I added the ZIP activity to a copy of the defaultprocesstemplate.xaml. All appeared OK but when I ran a build with this new template. I got the error

The build process failed validation. Details:

Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error:   Compiler error(s) encountered processing expression "BuildDetail.BuildNumber".

Type 'IBuildDetail' is not defined.

On checking the .XAML file you can see there is duplication in the namespaces

[Note the greatly improved compare tooling in VS11]

This it  turns out is a known issue logged on Microsoft Connect. The answer, at this time, is to do you build process .XAML editing in a text editor like Notepad, not a good story, but a workaround.

Just published documentation of the VB6 activity on the Community TFS Build extensions site

A new 1.3.0.0 release of the Community TFS Build Extensions has been published today. This contains some fixes  and two new activities

• SPDisposeChecker – checks for SharePoint best practice
• CatNetScan – checks for common security issues

Whilst upgrading a TFS 2010 build today to the new 1.2 release of the Community TFS Build Extensions we hit an issue. All seemed to go OK until the build tried to use the StyleCop activity, which failed with the error

Showing a modal dialog box or form when the application is not running in UserInteractive mode is not a valid operation. Specify the ServiceNotification or DefaultDesktopOnly style to display a notification from a service application.

After a bit of pointless fiddling we decided the only option was to set the build service in question to run interactively (set on the build service properties in TFS administration console on the build box). Once this was done the following dialog popped up

 

On checking the assemblies copied into the CustomAssemblies folder referenced by the build controller we found we had an older version of this file (from the previous release of the build extensions).

Once we replaced this file we got a bit further, we did not get a dialog, but the build failed with the error in the log

Error: Could not load file or assembly 'StyleCop, Version=4.6.3.0, Culture=neutral, PublicKeyToken=f904653c63bc2738' or one of its dependencies. The system cannot find the file specified.. Stack Trace:    at TfsBuildExtensions.Activities.CodeQuality.StyleCop.Scan()    at TfsBuildExtensions.Activities.CodeQuality.StyleCop.InternalExecute() in D:\Projects\teambuild2010contrib\CustomActivities\VS2010\MAIN\Source\Activities.StyleCop\Stylecop.cs:line 134    at TfsBuildExtensions.Activities.BaseCodeActivity.Execute(CodeActivityContext context) in D:\Projects\teambuild2010contrib\CustomActivities\VS2010\MAIN\Source\Common\BaseCodeActivity.cs:line 67.

The issue was we had not upgraded the StyleCop assemblies in the CustomAssemblies folder to match the ones the 1.2.0.0 release of the build extensions was built against (it needed 4.6.30, note not the latest 4.7.x.x.). So we changed these files to the 4.6.3.0 release and the build worked

Interestingly note that the file names have changed from the 4.4.x.x. to 4.6.x.x release of StyleCop from Microsoft.StyleCop.*.dll to just StyleCop.*.dll, so make sure you delete the old files in the CustomActivities folder to avoid confusion.

To the top tip here is to make sure you update all of the assemblies involved in your build to avoid dependency issues.

A new release of Community TFS Build Extensions have shipped. You can find more details on Mike Fourie’s blog or at the project home on Codeplex

I have just published some documentation on theTFS2010 community build extensions RoboCopy activity

I have just published updated documentation on the SharePoint build activity for the Community TFS build extensions.