Third Shelf » msbuild

Unit testing with Jenkins

Sydney du Plooy — Mon, 21 Mar 2011 15:51:23 +0000

Continuing to setup a build for the first time with Jenkins there is, uh, another challenge. For some reason, I thought it clever to make use of MsTest. This works wonderfully on the development machine. But, of course, when it comes to the build server, you can expect all sorts of weirdness. For example, error CS0246: The type or namespace name ‘TestMethodAttribute’ could not be found…

We’re sorry, but our testing tools don’t come standard with the .NET Framework, or in any other way, except TFS and Visual Studio, unless you are willing to follow this brave soul. I share Derik Whittaker’s sentiment on the MsTest and build server issue.

This is another issue to me because MSTest is the ONLY test framework (for .Net) that I know of that does not run with a single DLL placed into the bin (or any other output directory). I just have to ask the genius’ over in Redmond what the hell were they smoking when they decided to build MSTest. It is pretty clear they had no prior knowledge of how to use the other tools such as NUnit, MBUnit or xUnit (I know, xUnit was not out yet). I know this because of all the various testing frameworks MSTest is the one that does everything different. You could argue they were on the cutting edge and were innovating, but I call BS on that.

This can be solved. So long MsTest… Hello NUnit!

Converting from MsTest to NUnit

Converting from MsTest is a simple case of find and replace of attributes. NUnit has the nifty Assert.Catch which beats MbUnit, MsTest and xUnit. xUnit comes with Assert.Throws but cannot assert the exception message whereas NUnit can. No more [ExpectedException] attributes.

Integrating NUnit with the build file (which is MsBuild) is pretty easy:

A single Exec statement and out comes an Xml file. To keep the build server clean, I decided to add all the necessary files for unit testing into source control along with the project. The bare minimum files for running NUnit from the command line comes down to the following files:

nunit.core.dll
nunit.core.interfaces.dll
nunit.framework.dll
nunit.util.dll
nunit.console-runner.dll
nunit-console-x86.exe
nunit-agent-x86.exe
nunit-agent-x86.exe.config

To make it work on .Net Framework 4.0, you have to include the /framework=net-4.0 switch on the command line.

Setting up Jenkins with NUnit

Install the NUnit plugin for Jenkins, point it to your test results file and after a build you’ll get the summarised test results. It’s a neat table with all the classes and their respective timings and so on.

Finally, I have a working build with unit testing. If only it had an installer…

Git and Hudson Brothers

Sydney du Plooy — Thu, 10 Mar 2011 19:04:55 +0000

For a while now, I’ve been thinking about creating a source control and build server for a couple of projects that I’m working on. I’ll admit, I moonlight. Anyway, a great analysis ensued. Starting with the OS; what will it be, what does it need to be? Considering that I’m building .NET projects and they’re Windows based; well that kind of settles that. Next up, which source control system? Oh boy, this took a while…

Source Control

Since everyone, OK, almost everyone, raves about Git, I suppose I’ll have to succumb. But, this is where the fun starts. I want Git, I want Windows. Pushing, cloning and so on is what really I want. What a painful story… This requires the installation of MSysGit or Cygwin and some SSH server, blah blah, whatever. It was simply too much.

I decided to run VisualSVN on the server and then use git-svn to bridge that little dilemma. Well, that kinda sucked. After formatting and configuring and formatting and configuring, I finally found this post by Jeremy Skinner. It explains how to setup Git on Windows using IIS 7.0, without any other fancy installations and configurations. He calls it git-dot-aspx (GitAspx). To my surprise, this worked elegantly, the first time. Push, pull and clone without any issues. Great.

Continuous Integration

What a mental battle this turned out to be! What should I use, what do I need to use? There is from CruiseControl.NET to Hudson. A colleague mentioned Hudson and, being quite popular, I decided to investigate. This turned out to be a fantastic piece of software. It is a Java application, but I decided that it is well worth it. One click and it installs as a Windows service. One command line and it uninstalls cleanly. Unbelievable! Such a polished product. Also, it has many plugins from MsBuild to Git to Twitter. Talk about pressure, having your build status published to Twitter!

For a good Windows alternative, these two products turned out to be highly effective and user friendly.

Automating a ClickOnce Deployment – Part3

Sydney du Plooy — Sat, 20 Mar 2010 18:34:33 +0000

Continuing the series on Automating a ClickOnce Deployment it’s time to implement the deployment scheme in a build file.

After the build file compiled the solution we are ready to start the copying of the installation files to the deployment server. Before we start the copy process we have to create a new directory for the new application version. In the following snippet I simply generate a new version number and then create a directory where we will copy the installation files to:

We are ready to copy the application files to the server:

The ApplicationFiles is an item group with the installation files that we are copying. Note: we do not transform the filename to include the .deploy extension because we first need to generate the deployment manifest with the files in the right location before changing the name of the files. (See Gotcha #3). Next, we create the application manifest with the Mage utility which will be stored in the application directory (not in the version directory). Mage is a manifest generator and is used to generate both application and deployment manifests. In the snippet below we are using Mage explicitly to generate the application manifest:

So far so good, we have now managed to generate the deployment manifest from the files located in the …\Published\App directory and placed the file in the …\Published\App\$(VersionNumber) directory. We will now point the application manifest to this deployment manifest so that the correct files are installed on the client machine.

We now have everything that we need in order to generate the application manifest.

If you read part 2 of this series you should be able to map these properties straight to their positions in the application manifest file and their functions. The only thing that remains is to rename the files to include their .deploy extensions. This can easily be done in the following way:



'$(DeploymentServer)\Published\App\$(VersionNumber)\%(Filename)%(Extension).deploy')" />

Visiting the URL http://deployment-server/Published/App/App.exe.manifest and clicking on the Install button you should see the following dialog:

Gotchas

There are a few gotchas that you might find on your way to success and I’ve listed the most common ones here and their solutions for your convenience:

Gotcha #1: Reference in the manifest does not match the identity of the downloaded assembly …

This is easily resolved by adding the NoWin32Manifest property to solution in the SolutionsToBuild group:


  NoWin32Manifest=true

Gotcha #2: XML files are marked as data files, by default.

This means that XML files are published to the data directory whose location can found by querying the System.Deployment.Application.ApplicationDeployment.CurrentDeployment.DataDirectory property.

Gotcha #3: The customHostSpecified attribute is not supported for Windows Forms applications.

Not a very helpful error, but chances are that you generated the deployment manifest with the installation files having the .deploy extension and not on the original filenames.

Automating a ClickOnce Deployment – Part2

Sydney du Plooy — Sat, 20 Mar 2010 14:47:42 +0000

Continuing the series on Automating a ClickOnce Deployment it’s time to have a look at the manifest files. There are two required manifest files that give clickonce the necessary information to deploy the application:

an application manifest (.application);
a deployment manifest (.manifest).

Application Manifest

The application manifest describes the application that we are going to install. So, let’s have a look at the contents of this file:

xml version="1.0" encoding="utf-8"?>

  
  asmv2:publisher="App Publishers Company" asmv2:product="App" xmlns="urn:schemas-microsoft-com:asm.v1">App
  mapFileExtensions="true">
    
      
        
      
    
    
  
  
    
      
      
        
          
        
        
        DrLiyVjtlKhOmtuzuXhFSTqi/9Q=

One of the important things to note in this manifest is the mapFileExtensions attribute in the deployment tag. This attribute indicates that our installation files have a .deploy extension – MyApplication.exe is copied to the deployment server as MyApplication.exe.deploy and is renamed when installed on the client machine. In the deploymentProvider tag we specify where the application can find future updates and from where this application was installed.

The next interesting tag is dependentAssembly, which points to the deployment manifest to use when installing the application on the client machine. We specify the deployment manifest in the codeBase attribute which describes how the application installs. Note that the codebase attribute points to a version folder in which the deployment manifest resides – for every new release of the application this application manifest is either overwritten or updated to point to the new version of the installation files and deployment manifest.

Deployment Manifest

The deployment manifest describes the how the application installs and what files to install on the client. Once again, let’s have a look at the contents:



  
  
  
    
    
  
  
    
      
        
        
      
      
        
      
    
  
  
    
      
        
      
    
  
  
    
      
    
  
  
    
      
      
        
          
        
        
        CXehkPHON56TeTj7ZWsy++QsymE=
      
    
  
  
    
      
        
      
      
      6hHtbL9F9sfgWmKLYrWRpYmILCE=

The first tag of interest here is the entryPoint tag that identifies the application to run once the installation completes. In order to start the application clickonce will execute the command with the parameters specified in the commandLine tag.

Every application has dependencies that must either be installed with the program or should have been installed. In the first dependency tag we see that the minimum operating system version required is Windows XP. In the second dependency tag we see that the dependencyType attribute instructs clickonce to verify that the .NET Framework 2.0 is already installed on the client.

In the third dependency tag we see that the dependencyType is install, which instructs clickonce to install this dependency on the client. Remember that the .deploy extension will automatically be removed during the installation process.

The next tag is a file tag that specifies a non-assembly file that is copied into the application installation directory. Note: by default when clickonce encounters a xml file it assumes it as a configuration file and will copy it to a data directory; along the application directory; instead of the application directory. You can find the data directory location by querying the System.Deployment.ApplicationApplicationDeployment.DataDirectory property.

In the next installment of this series we will show a build file example and generate a deployment manifest with the Mage tool.

Executing a task remotely with MsBuild

Sydney du Plooy — Mon, 19 Oct 2009 16:47:36 +0000

Recently, we were in need of executing a command on a remote server as part of our automated build process. For this we decided to make use of Windows Management Instrumentation (WMI). Before jumping to the code, copying and pasting it, there are always some security issues that need to be addressed. For this task there are also some service configurations that are required on the remote machine.

Note: All of the following settings are configured on the remote machine on which the command will be run remotely.

Security

Follow the steps below to set the WMI permissions for the build service account:

Click on Start > Control Panel > Administrative Tools > Computer Management.
Expand Service and Applications.
Right-click on WMI Control and click on Properties.
On the property dialog select the Security tab.
Expand Root > CIMV2.
Click on the Security button.
Click on Add and add account.
In the list of permissions, allow the following permissions:
- Execute methods
- Remote enable
Click on OK.

Follow the step below to set the Local Security Policy for the build service account:

Click on Start > Control Panel > Administrative Tools > Local Security Policy.
Expand Local Policies > User Rights Assignment.
Find and double-click on Log on as a service.
Click on Add User or Group and add account.
Click on OK.
Find and double-click Log on as a batch job.
Click on Add User or Group and add account.
Click on OK and close the Local Security Policy window.

Services

Follow the steps below set the dependent services to automatically start:

Click on Start > Control Panel > Administrative Tools.
Double click on Services.
Ensure that the following services are Started, and are set to start Automatic.
- COM+ Event System
- Remote Access Auto Connection Manager
- Remote Access Connection Manager
- Remote Procedure Call (RPC)
- Remote Procedure Call (RPC) Locator
- Remote Registry
- Server
- Windows Management Instrumentation
- Windows Management Instrumentation Driver Extensions
- WMI Performance Adapter
- Workstation
Close the services dialog.

Here is the code for the build task that will execute a command on a remote machine:

/// 
/// Executes a command line on a remote machine.
/// 
public class RemoteExec : Task
{
 /// 
 /// Initialises a new instance of the  class.
 /// 
 public RemoteExec()
 {
   RemoteMachine = Environment.MachineName;
 }

 /// 
 /// Gets or sets the name of the machine on which to execute the command.
 /// 
 public string RemoteMachine
 {
   get;
   set;
 }

 /// 
 /// Gets or sets the command to execute on the remote machine.
 /// 
 [Required]
 public string Command
 {
   get;
   set;
 }

 /// 
 /// Executes the task on the remote machine.
 /// 
 /// true if the task succeeded, otherwise, false
 public override bool Execute()
 {
   if (string.IsNullOrEmpty(Command))
   {
     Log.LogError("Command property was not set.");
     throw new ArgumentNullException("Command");
   }

   var connOptions = new ConnectionOptions();
   connOptions.Impersonation = ImpersonationLevel.Impersonate;
   connOptions.EnablePrivileges = true;

   var managementScope = new ManagementScope(
     string.Format(@"\\{0}\ROOT\CIMV2", RemoteMachine), connOptions);
   managementScope.Connect();

   Log.LogMessage(string.Format(CultureInfo.CurrentCulture, "Connected to {0}: {1}",
   RemoteMachine, managementScope.IsConnected));

   if (!managementScope.IsConnected)
   return false;

   var objectGetOptions = new ObjectGetOptions();
   var managementPath = new ManagementPath("Win32_Process");
   var processClass = new ManagementClass(managementScope, managementPath, objectGetOptions);

   var processParameters = processClass.GetMethodParameters("Create");

   processParameters["CommandLine"] = Command;
   try
   {
     var outParams = processClass.InvokeMethod("Create", processParameters, null);
     var processID = Convert.ToUInt32(outParams["processId"]);

     Log.LogMessage(string.Format(CultureInfo.CurrentCulture,
       "Creation of the process {0} returned: {1}", processID, outParams["returnValue"]));

     var stopQuery = new WqlEventQuery(string.Format(CultureInfo.CurrentCulture,
       "select * from Win32_ProcessStopTrace where ProcessID={0}", processID));

     var processStopEvent = new ManagementEventWatcher(managementScope, stopQuery);
     processStopEvent.Options.Timeout = new TimeSpan(0, 1, 0);

     Log.LogMessage("Waiting for process to complete...");
     processStopEvent.WaitForNextEvent();
     processStopEvent.Stop();

     Log.LogMessage("Completed.");
   }
   catch (Exception ex)
   {
     Log.LogError(ex.Message);
   }

   return true;
   }
}

The task can then be used as follows:

There we have it, executing a command remotely from MsBuild!

Creating JunctionPoints with MsBuild

Sydney du Plooy — Sat, 10 Oct 2009 14:32:37 +0000

With our build process we decided on a deployment folder structure that required us to create NTFS Junction Points. Junction Points are links to other folders, also known as soft links. Below is an example of how these links appear in Windows 7. It also shows our deployment folders for various build types:

All the folders with shortcut arrows are junction points or links to folders in the Published folder. For each build, the binaries are copied to a build numbered folder in the Published folder. Only when a build is successful; meaning that all code compiled and unit tests passed; do we update the junction point to the relevant build numbered folder in Published.

By using the code written by Jeff Brown in this article, I was able to create a custom build task that enabled us to the create and delete junction points with relative ease. Here is a link to the source code for an MsBuild task that will enable you to manage junction points with MsBuild.

Automating a ClickOnce Deployment – Part1

Sydney du Plooy — Sun, 06 Sep 2009 17:50:55 +0000

In our build process, using Team Foundation Build, we decided to use ClickOnce for application deployment. In this post I’ll try to set the lay of the land. In the following couple of posts I will take you through the process of setting up a clickonce deployment.

Choosing the deployment strategy

There are essentially two different ways to deploy clickonce applications. They are:

Physical media such as CD or DVD
Network share or web

Deciding on the strategy that will work for you is largely determined by the available bandwidth at the client site. If there is none to very little bandwidth, or no internet connectivity, choose CD / DVD. Otherwise choose Network share or web.

We opted for the web strategy and so I will base the series around this strategy.

Lay of the land

Assume that we have one build server and one deployment server. The build server will push the build artifacts to the deployment server from where clients will use clickonce to install the application. The application is pushed to the deployment server after every build with a new version number.

To make the explanations easier we will setup a hypothetical configuration and base the deployment configuration on it. Our hypothetical solution consists of a single application, which we will call App. Below is a diagram that demonstrates this configuration:

Note: To hide the published share simply name it with a trailing dollar sign i.e. “Published$”.

Initial configuration

First of all we need a folder on the deployment server to push the build artifacts to. For this, create a published folder on the deployment server and share it with modify permissions granted to the TFSSERVICE account. Remember the TFSSERVICE account that TFS uses for the build service?

Furthermore, we need to configure Internet Information Services (IIS) to interpret the clickonce files correctly according to their extension. For this, add the following MIME types in IIS:

.application    application/x-ms-application
.manifest       application/x-ms-manifest
.deploy         application/octet-stream

If you are using IIS 6.0, have a look at this article “IIS 6.0 Does Not Serve Unknown MIME Types”.

In the next installment I’ll discuss the different files that describe the application and deployment.

CopyDirectoryDifferences Build Task

Sydney du Plooy — Mon, 01 Sep 2008 16:20:41 +0000

In my attempt to optimize our build script work, I found myself needing to copy a list of files from one directory to another without overwriting existing files in the destination directory.

Scenario:

We need to gather code coverage information using multiple test containers (assemblies with unit tests inside them). This results in instrumenting all the assemblies that the test container depends on. This happens before the execution of unit tests in each test container.

Solution:

Use the MSBuild copy task to copy all the files from the source directory to the destination directory without overwriting the files that already exists in the destination directory. Simple enough, eh? Except, there is no support for this scenario to be found in the Copy Task that ships with MSBuild by default.

We are left no choice but to roll our own. Here is a code listing of the task that I wrote to do precisely that:

/// 
/// Copies files from a source directory to a destination directory that
/// do not exist in the destination directory.
/// 
public class CopyDirectoryDifference : Task
{
  private string _SourcePath = string.Empty;
  private string _DestinationPath = string.Empty;
  private ITaskItem[] _FilesCopied = {};

  /// 
  /// Gets or sets the source path from where files will be copied.
  /// 
  [Required]
  public string SourcePath
  {
    get { return _SourcePath; }
    set { _SourcePath = value; }
  }

  /// 
  /// Gets or sets the destination path to where files will be copied.
  /// 
  [Required]
  public string DestinationPath
  {
    get { return _DestinationPath; }
    set { _DestinationPath = value; }
  }

  /// 
  /// Gets the files that were copied to the destination path.
  /// 
  [Output]
  public ITaskItem[] FilesCopied
  {
    get { return _FilesCopied; }
  }

  /// 
  /// Finds the files that are different between two directories and copies them from
  /// the source directory to the target directory.
  /// 
  /// true if the task completed successfully, otherwise false.
  public override bool Execute()
  {
    if (!Directory.Exists(_SourcePath))
    {
      Log.LogError("Source path does not exist.");
      return false;
    }

    if (!Directory.Exists(_DestinationPath))
    {
      Log.LogError("Destination path does not exist.");
      return false;
    }

    string[] sourceFiles = Directory.GetFiles(_SourcePath);
    string[] destinationFiles = Directory.GetFiles(_DestinationPath);
    List copiedFiles = new List();

    foreach (string file in sourceFiles)
    {
      string fileName = Path.GetFileName(file);

      if (!File.Exists(Path.Combine(_DestinationPath, fileName)))
      {
        Log.LogMessage("Copying file {0} from {1} to {2}.", fileName, _SourcePath, _DestinationPath);

	try
	{
	  File.Copy(Path.Combine(_SourcePath, fileName), Path.Combine(_DestinationPath, fileName), false);
	  copiedFiles.Add(new TaskItem(Path.Combine(_SourcePath, fileName)));
	}
	catch (IOException ex)
	{
	  Log.LogError("Failed to copy the file {0}. Exception: {1}", Path.Combine(_SourcePath, fileName), ex.ToString());
	  return false;
	}
      }
    }

    if(copiedFiles.Count > 0)
      _FilesCopied = copiedFiles.ToArray();

    Log.LogMessage("Done.");

    return true;
  }
}