Chris Burrows' Live Space

Visual Studio Team System 2010 - Love that DashBoard

Thu, 09 Oct 2008 12:25:57 GMT

One of the benefit that you get when working for a company like Readify is you are given time to spend brushing up on the latest technology. With all of the new Visual Studio 2010 video's that Brian Keller has producing over the last week has been great to be able to spend a couple of days getting into them. I must say that I have been impressed with some of the new features. One that has caught my eye so far is the Dashboard that they are planning for the portal. Whilst watching the Requirements Management and Traceability screen cast I grab the following pictures to give you an insight into what the new portal is going to look like.

I'm on the move

Thu, 09 Oct 2008 12:02:06 GMT

After playing around with Windows Live for a while I have decided to make Windows Live the centre of my digital world. To that end I have finally moved my blog across. Redirects are in place and the new address is http://madtechnology.spaces.live.com.

The New Build Summary screen in Team Build 2010

Thu, 09 Oct 2008 11:34:32 GMT

The team has been doing some great work around Team Build and have made some significant changes to the way that it works. While watching the Channel 9 Video from Jim Lamb I grabbed some screen shots of the improvements. There are many more so I would recommend that you watch the video.

Here they are:

New Build Summary Screen

Activity Log View of Build Summary

Broken Builds View on Build Summary Screen

This one is really interesting, What you can do is double click on the error and if it is a compile error it will bring up the version of the file that was build and allow you to fix the error and check it back in again.

Another Trick with .TestRunConfig,DeploymentItems and Team Build

Tue, 03 Oct 2006 11:43:01 GMT

Just when you think it is safe to go out and use the power of Visual Studio 2005, some little thing comes out to bite you. We had just added in another directory into suite of deployment items into our list of items to be deployed and guess what? You got it they were not appearing in the Out directory. After doing some digging I found that actually some of the files where getting copied, but not all of them. When I examined these file in Visual Studio I noticed that one of the files had the Copy to Output Directory set to "Copy If Newer". I changed this to "Do Not Copy" and suddenly the files started appearing. Strange, Strange, strange but it works!

Code Coverage, Web Application Project

Thu, 21 Sep 2006 20:36:26 GMT

One of the challanges that I have been having lately was getting code coverage working on our build machine. I was able to get code coverage working for normal dll's but I couldn't get it working for Web Application projects. The old saying "it worked on my machine" held true in this case. I could get the code coverage working for the Web application project, but I couldn't get it working on my machine. After scratching my head for a while, I thought to myself where is the code for the web site getting executed when you just tests against the web site. After having a look on the build machine, I had a hunch that it might be in the _PublishedWebSites directory. So I added a quick bit of code to the web application project to write out it's location to the event log and it confirmed my hunch. (For those of you who are unsure where the _PublishedWebSite directory is found it is in <BuildDirectory>\<TeamProjectName>\<BuildTypeName>\Binaries\<Configuration>\_PublishedWebSites. On my build machine that is d:\build\TestTeamProject\TestContinuous\Release\_PublishWebSites.

So how did I solve the problem. What I did was open up the solution file on the build machine underneath the <BuildDirectory>\<TeamProjectName>\<BuildTypeName>\Source directory. I then openned up the .testrunconfig file (See Enabling Code Coverage) and added the assemblies that I wanted to enable code coverage for and I suddenly had code coverage results.

For those who don't have access to the build machine, you can achieve the same thing by editing the .testrunconfig file manually. Instead of double clicking on the .testrunconfig file, right mouse click and selected open with. This will bring up the following dialogue.

Select the XML Editor. This will bring up an XML editor from which you can manual edit the file. The section that you are looking for is below:


	
		<isCodeCoverageEnabled type="System.Boolean">True</isCodeCoverageEnabled>
	
	

		    <codeCoverageItems type="System.Collections.Generic.List`1[[Microsoft.VisualStudio.TestTools.Common.CodeCoverageItem, Microsoft.VisualStudio.QualityTools.Common, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a]]">
	
	

		      <_items type="Microsoft.VisualStudio.TestTools.Common.CodeCoverageItem[]">
	
	

		        <element type="Microsoft.VisualStudio.TestTools.Common.CodeCoverageItem">
	
	

		          <binaryFile type="System.String">bin\Debug\UpdateWarehouse.exe</binaryFile>
	
	

		          <keyFile type="System.String" />
	
	

		          <pdbFile type="System.String">obj\Debug\UpdateWarehouse.pdb</pdbFile>
	
	

		          <instrumentInPlace type="System.Boolean">True</instrumentInPlace>
	
	

		          <outputDirectory type="System.String" />
	
	

		        </element>
	
	

		      </_items>
	
	

		      <_size type="System.Int32">1</_size>
	
	

		      <_version type="System.Int32">1</_version>
	
	

		    </codeCoverageItems>

All that you need to do is add in one of the elements and update the _size and _version with the number of elements in the collection array. A tip that I discovered. Normally when you open the .testrunconfig file as an XML document all you see if one long string. If you do CTRL+A then CTRL+F (That is select all then Edit.FormatDocument).

Ah the Joys of Deployment items in testrunconfig files

Thu, 21 Sep 2006 20:36:03 GMT

I got into work this morning and I found that our build had misterously broken over night and the tests had started to fail. (One if the challanges we have at the moment is our build machine is on a laptop that gets locked away at night so sometimes people can checkin with out having a build fired off). Anyway, after a quick look at the exception that was being raised in the tests the files wheren't being found on the build machine. Easy I thought, I have seen this issue before somebody has played around with the .testrunconfig and the we have got a trailing slash. I quickly opened up the .testrunconfig and to my suprise it look fine. There where 2 directories and a couple of files in the deployment item section and the directories had the trailing slash removed. Dam! This is going to be fun. To cut a long long story short. I spent the next 3 hrs, trying to get different combinations to see if I could get the files to be copied across. In frustration I decided to take a break. Always a good thing if you have been looking at a problem for a while. I went back to see what had changed in the last changeset. On closer examination I noticed that somebody had added directory called "TestData". Nothing out of the ordinary, however, in the deployment section of the .testrunconfig file we where trying to deploy a directory called TestData. I said to myself, this couldn't be the problem could it? So I renamed the directory and started the build off again. Amazingly, it started working.

So the moral to this story is two fold. Firstly, always, take a break when thinking about a problem. Secondly, remember if you are using directories as DeploymentItems in your tests make sure there isn't the same directory anywhere in your solution. As an aside, I'm not happy that I don't know why this is happening so I might go and see if I can find out how to undertand why it works like this.

Removing rows from Excel when working with Data Driven Tests

Thu, 14 Sep 2006 10:13:22 GMT

You guessed it, we are getting down and dirty with data driven tests and Excel. Just another tip for young players. When deleting rows from Excel that you are using don't use the delete key, rather select the rows that you want to delete and choose "Delete Rows". If you don't then the rows are still assumed to contain data and your tests will fail.

How to force the Column Data Type when using Excel in Data Driven Tests

Thu, 14 Sep 2006 10:13:10 GMT

Where I'm working at the moment we are using the new data driven tests to help us test different combinations of test data while using the same underlying test. At the moment we are using an Excel spreadsheet to store the test data and the expected results and expected exception. A while ago one of the team members grabbed me to look at a problem. For a particular row of test data a specific cell value was not being flowed through to his test. After looking at it for a while, I noticed that this contained text data, while the rest of them contained numeric data. This then reminded me that the Excel ODBC Driver infers the columns data type from the first X rows. (I think it is 10 but am not 100% sure). Therefore, as the majority of the data in this column was numeric, the column type in .NET was being set to decimal.

So how did we solve it. First we tried just changing the format of the column to text, but this did nothing. So the next thing we tried was a little known feature in excel which if I remember correctly stems all the way back to the days when Excel was competing with Lotus 123. One way of forcing the type of the cell from numeric to text is to place the ' character in front of the number. For example if you want the number 1234 to be treated as text you would type in '1234. This solved the problem, the columns type was now set to Text rather than numeric.

Error user doesn't exist in database after restoring a database with SQL User Accounts.

Wed, 13 Sep 2006 09:34:05 GMT

If you SQL Accounts on your database (not something that I would recommend in production) and you are restoring databases you are proberbly aware of the following above error. Now if you are like me the first thing that you do is check to see if the user exists in the database. If you are restoring the db, most of the time it does. It then takes a couple of seconds for me to remember that if you are restoring a database from a different server then the link between the SQL Server account and the User in the database doesn't exists. So even when you open up the database and see the user you cannot still login. The way you normall fix this is by deleting the user from the database, then going back to the user underneath SQLSecurity and granting access to the database for that user again. After doing this a couple of times I got sick of it and created the following script.


	
		DECLARE @USERNAME varchar(8000)
	
	

		SELECT @USERNAME = 'fred'
	
	

		
	
	

		
	
	

		
	
	

		if not exists (select * from dbo.sysusers where name = @UserName)
	
	

		BEGIN
	
	

		    exec sp_grantdbaccess @USERNAME , @USERNAME 
	
	

		
	
	

		    EXEC sp_addrolemember 'db_owner',@USERNAME 
	
	

		END
	
	

		ELSE
	
	

		BEGIN
	
	

		    EXEC sp_change_users_login 'Update_one',@USERNAME ,@USERNAME 
	
	

		END

What this does is grant access to the current database to the given username specified and then adds then to the role db_owner. I have another script which will restore the database as well after I've santised it I'll post it.

The simplest possible way to add performance counters to your application using Enterprise Library January 2006

Fri, 08 Sep 2006 09:55:42 GMT

After spending a couple of days looking at how the instrumentation works in the Enterprise Library and finding out how lacking the documentation is around instrumentation I thought I would share my experiences with you. The best I dive into solution mode I thought I would describe what the enterprise library provides on top of the out of the box performance counters. The biggest thing it does is abstract away the creation and management of the performance counter. Instead of writing code you can just use a few of attributes, use the EnterpriseLibraryPerformanceCounter class, create an installer and away you go. It is that simple.

Rather than leave it at that, let me walk you through the exact steps that you need to follow.

Step 1. Create a Class to House the Performance Counters

The first thing that you need to do create a class that will hold the performance counters, and do the work of updating them when required. For example:


	
		using System;
	
	

		using System.Collections.Generic;
	
	

		using System.Text;
	
	

		using Microsoft.Practices.EnterpriseLibrary.Common.Instrumentation;
	
	

		using System.Diagnostics;
	
	

		
	
	

		namespace SamplePerformanceCounter
	
	

		{
	
	

		    
	
	

		    [HasInstallableResources]
	
	

		    [PerformanceCountersDefinition(PerformanceCategory, "SampleInstrumentationCounterHelp")]
	
	

		    public class SimplestPerformanceClass
	
	

		    {
	
	

		        private const string PerformanceCategory = "Simplest Performance Category";
	
	

		        
	
	

		        [PerformanceCounter("Operations Started/sec", "OperationStartedHelpResource", PerformanceCounterType.RateOfCountsPerSecond32)]
	
	

		        private EnterpriseLibraryPerformanceCounter _operationStarted = new EnterpriseLibraryPerformanceCounter(PerformanceCategory, "Operations Started/sec");
	
	

		
	
	

		        public void OperationStarted()
	
	

		        {
	
	

		            _operationStarted.Increment();
	
	

		        }
	
	

		
	
	

		    }
	
	

		}

Step 2. Create an Project Installer

The next step is to create a project installer, this is really really simple. Just create a class that looks like the following.


	
		using System.ComponentModel;
	
	

		using System.Configuration.Install;
	
	

		using System.Management.Instrumentation;
	
	

		using Microsoft.Practices.EnterpriseLibrary.Common.Instrumentation;
	
	

		
	
	

		
	
	

		namespace SamplePerformanceCounter
	
	

		{
	
	

		    /// <summary>
	
	

		    /// Let the system know that the InstallUtil.exe tool will be run against this assembly
	
	

		    /// </summary>
	
	

		    [RunInstaller(true)]
	
	

		    public partial class ProjectInstaller : DefaultManagementProjectInstaller
	
	

		    {
	
	

		        /// <summary>
	
	

		        /// Represents the installer for the instrumentation events. Not intended for direct use.
	
	

		        /// </summary>
	
	

		        public ProjectInstaller()
	
	

		        {
	
	

		            Installers.Add(new ReflectionInstaller<PerformanceCounterInstallerBuilder>());
	
	

		        }
	
	

		    }
	
	

		}

Step 3. Use the Performance Counter Class

All the hard work is done, you can now start to use the performance counters. For example


	
		SimplestPerformanceClass performance = new SimplestPerformanceClass();
	
	

		 for (int i = 0; i < 1000000; i++)
	
	

		{
	
	

		      performance.OperationStarted();
	
	

		}

Step 4. Install the Performance Counters

The final setp is to install the performance counters. This is done simply by running install util over the assembly that contains the project installer. This is as simple as and looking for "The Commit Phase Completed Successfully"

> intallutil simplestpossibleperformancecounter.exe

You're done. To see the output of all your hard work fire up performance monitor, add in the your counter to the output and away you go!

In my next post I'll describe how instrumentation implement instrumentation, in the same way as the Application blocks in the Enterprise Library do.

Unit Tests failing because files cannot be found on build machine

Thu, 07 Sep 2006 11:05:25 GMT

After my post yesterday on Using External Files in unit tests, I found a bug when using the deployment section of a testrunconfig file to copy a directory of files. Whilst this worked fine on the local developers machine, however when it ran on the build server the files didn't appear. After about 30 minutes of googling I came across this post in the forums. I've taken the steps and modified them slightly so you don't have to leave Visual Studio.

1. In Visual Studio right click on your active .testrunconfig file in the solution items directory. This is usually called localtestrun.testrunconfig.

2. Selected open with and choose the XML editor

3. Find your folder in the file. Unfortunately, the XML is produced in on big line that means that using the find command is the quickest way of doing this.

  <deploymentItems type="Microsoft.VisualStudio.TestTools.Common.DeploymentItemCollection">
   <m_container type="System.Collections.Hashtable">
    <key type="Microsoft.VisualStudio.TestTools.Common.DeploymentItem">
     <path type="System.String">MyProject\DBScriptFolder\</path>
     <outputDirectory type="System.String" />
    </key>
    <value />
   </m_container>
  </deploymentItems>

4. Delete the '\' (backslash) from the end of that string

5. Save and check-in. Sit back and watch the continuous integration fly!!