MS Project and Work Items

If you are a project manager or know a project manager who is using Microsoft Project with Team Foundation Server to manage Work items you may have noticed that Start and Finish Dates only update in one direction. It seems that by default PublishOnly is set to True in the Field Mapping for MS Project for these fields, therefore if you have a schedule in Project and you publish it to the Team Foundation Server the work items will have the start and finish dates from project. However if you load up a project from the work items in your Team project the dates will not be reflected.

You can change this by downloading a mapping file, changing it and uploading it again. Use the command line utility TFSFieldMapping.exe to accompish this. Read this article to understand how to download and upload mapping information. 

The command is as simple as:
TFSFieldMapping download TeamFoundationServer TeamProject MappingFile.xml
TFSFieldMapping upload TeamFoundationServer TeamProject MappingFile.xml

After you have downloaded the Project Field Mapping information you can change the PublishOnly attribute to False and upload the file again.

 

Go Ahead Run your Tests in the Build

Do you want to be able to run tests in Team Build without having to use a .vsmdi file.

Well now you can. Buck Hodges  has a post with a download which includes a task for running tests in your build by simply specifying the .dll's.

Buck also says this new task will be included in the next release of  Team Foundation Power Toys.

Perhaps someone is listening!

Visual Studio and Team Systems Service Pack Betas

So we have a few service packs to talk about....

Firstly, Visual Studio 2005, SP1 is now in beta testing. This is a fairly big service pack, lots of bug fixes, and the odd new feature. The list is not complete of things fixed yet but Microsoft promises to update that list when they ship. You can read the announcement here and if you like, register for the beta on the Microsoft Connect Site. In that announcement, Soma also goes on to talk about Vista support and what that means for Visual Studio 2002, 2003, and 2005. Keep in mind, this has little to do with your applications running on Vista - but is about running the development environment on Vista.

Secondly, Brian Harry anounced the beta availability for Team Foundation Server SP1. You can register for the download on the Microsoft Connect Site. I'm most thankful for full-fledged extranet support. As you may know, there are some security hiccups when not using a VPN and trying t pass through a variety of firewalls/proxy servers. This one should have been in the 1.0 release in my opinion, but better late than never.

I do a fair amount of Work Item Type customization for customers so I'm pretty excited about the ability to create custom controls on your work item forms.

Other notable improvements: Better performance and scale, Excel/Project 2007 Support, Support for the new Web Application Projects.

I have it on good authority that you don't have to worry about what version of the client you have for compatibility with the server. So feel free to mix and match, you know, like Garanimals.

 

You'll find increased scalability and better performance with Work Item Tracking, Version Control, and the Data Warehouse.

Team Foundation Server Users and Microsoft Project Resources

After some investigation this seems to be a pretty well known issue. However I had not come across this issue so I thought I would Blog it so I can easily find the solution again.

Although there are work arounds for this issue, you will be happy to know this will be fixed and is addressed in KB #919232

When the TFS Client is installed, Microsoft Project like Excell becomes connected to the Team Foundation Server via a new tool bar in Project. Using this a Manager can read or publish work items from the TFS Project. The problem, is when the users on TFS are defined in Active Directory the AD friendly name is Lloyd, David. In MS Project multiple resources can be assigned to a task using a separator. Which by default is a comma.

Here in lies the problem. When you take a project and try to publish tasks with multiple users to TFS you will get an error, telling you the user is not defined. When you read tasks from a TFS Project it will work but you will end up with multiple users. (Lloyd and David)

There may be more than one solution to this, however I found a simple solution on the MS Forums which is to simply change the separator Character in your Regional Settings so Project does not use a Comma as the separator.

If you're not sure where this is follow these directions:

From Control Panel open Regional and Language Options
On the Regional Options tab click the Customize Button
On the Numbers tab change the List Separator

There are other work arounds but they are not even worth mentioning.

Visual Studio Team System Public MSDN Chat

Come and join members from the Visual Studio Team System product group to discuss features available in Visual Studio Architect, Developer and Tester editions and Team Foundation Server. There will be experts on hand to answer your questions.

Join the chat on Wednesday September 6th, 2006 1:00pm - 2:00pm Eastern time. (Convert this to your timezone.)

To add this to your calendar, click here.

Unit Testing Custom MSBuild Tasks

If you're developing custom MSBuild Tasks, and you're interested in testing them (and you should) using NUnit or VSTS there are a few considerations.

The first is the strategy you want to adopt for testing the custom task. In the spirit of “Unit” testing, you may choose to test only your code in the tightest scope possible. In this scenario, you may choose to new up your custom task, set some properties on it, and fire the Execute method.

Be forewarned however, that when you do this, you don't have the full Build engine around running around your task. If you use the built in task logging mechanism, i.e.

Log.LogMessage("QueueName {0}, Message {1}", this.queueName, this.message);

You'll get an exception thrown....

Error message:

Test method ExecuteTest threw exception: 
System.InvalidOperationException: Task attempted to log before it was initialized.

Stack trace:

at Microsoft.Build.Shared.ErrorUtilities.ThrowInvalidOperation(String resourceName, Object[] args)
at Microsoft.Build.Shared.ErrorUtilities.VerifyThrowInvalidOperation(Boolean condition, String resourceName, Object arg0)
at Microsoft.Build.Utilities.TaskLoggingHelper.LogMessage(MessageImportance importance, String message, Object[] messageArgs)
at Microsoft.Build.Utilities.TaskLoggingHelper.LogMessage(String message, Object[] messageArgs)
...

If you still want to test your custom task like this, you can test for the presencen of the build engine and not use it's built in logging features....i.e.

if (this.BuildEngine!=null)
     Log.LogMessage("QueueName {0}, Message {1}", this.queueName, this.message);

Of course, if you choose to fire off your custom build task within the scope of the build engine by executing a test build script harness (and that's a good idea too) you won't run into this problem, i.e.

Process buildProcess = new Process();
buildProcess.StartInfo.FileName = "C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\MSBuild";
buildProcess.StartInfo.Arguments = "testscript.msbuild /target:testTarget”;
buildProcess.StartInfo.WindowStyle = ProcessWindowStyle.Hidden;
buildProcess.StartInfo.CreateNoWindow = true;
buildProcess.Start();
buildProcess.WaitForExit();
buildProcess.Close();
//TODO: Assert that the script did what it was supposed to do.

My preference is to do both types of tests. The first style is helpful in the case of my actual custom task being faulty. If the first style fails, I'm very certain that the error is within the guts of that task. The second style is helpful in more of an integration test way. If the second style fails (and not the first) it means there is a problem in the way I'm calling my custom task within a build script.

VSTS Unit Tests with "extra" files

Sometimes you need to have an external file when you're creating unit tests. Perhaps you are reading a known state into an object, or reading in some XML to insert test data into a database.

If you are reading this blog, you probably already tried adding these “extra” files into your VSTS Test Project, and perhaps even thought to change the file's “Copy to Output Directory” to “Copy Always”. This has the effect of copying your extra file to the bin/debug (or release) folder underneath your project as part of a build. What you may not know is that your tests don't actually run from this directory. When VSTS runs a local test, a directory is created below the <SolutionFolder>/TestResults folder. There are a couple of techniques you can use to ensure your extra files show up in this directory.

  1. If your external file is specific to a certain test, is only required when you run that test, and doesn't change based on other environmental variables, then you can add a DeploymentItem attribute to your test method. There are a few overloads, check the documentation.
  2. If your external file is more of a global configuration file that many tests rely on, or if the external file has multiple variations you can edit your Test Run Configuration. The menu option is Test > Edit Test Run Configurations > Local Test Run. Select the Deployment item on the left, and then add a reference to the external file.

    By default you only have 1 local test run configuration, but you can add more. The localtestrun.testrunconfig file is usually located under the Solution Items folder. You can right click this folder in Solution Explorer and select Add New Item. There is a category for Test Run Configuration, and a corresponding item as well.

More on Visual Studio Team Edition for Database Professionals

Was looking at sessions for the afternoon. And came across one that I had missed before on this topic. The book didn't actually say it was about this but I recognized the name Mairread O'Donovan from the VSTS influencer's the night before. She was the one telling me about this new product.

I have been skipping VSTS sessions so far since I have been working with it for so long I thought they might be too light, but this is new and I wanted to see the product in action.

Some of the features I didn't find out about last night.

  • Reverse engineer your SQL Server Database
  • Version Control
  • Schema Build and Deploy
  • Unit Testing
  • Schema Compare
  • Data Compare
  • Data Generator (This is a nice tool for creating sample test Data, FOR DEVELOPERS NOT TESTERS we'll talk later)
  • Schema refactoring
  • TSQL editor
  • Query Execution
  • Plus the normal Team Foundation Server stuff (Work items and Process Integration)

It would be nice if they would also include in this tool the following. If the Team is reading this feel free to use this as high level requirements.

  • Integrate Profiler
  • Debugging from code straight into SQL easily with no extra work
  • Modeling (for Barry)

VS for DBA's

I attended a little party on Monday night for VSTS influencer's.

I met some very nice people, who are very excited about their work. I had a short discussion about the new Visual Studio for DBA's. This sounds like a nice tool. One of the features I liked from a testing/deployment/promotion model point of view is being able to compare Data between versions of the Database.

When you are testing an application you must have control variables. So often this is not the case. Other industries are laughing at us over this. I remember reading an article in American Scientific written by an engineer who was slamming the software industry because we do not have standard process and controls in place like the engineering community. Anyway One of the most important parts of testing is to have a Database that you know the state of when executing tests. If you don't know what data is in your Database how can you be sure the test results are accurate.

It sounds to me like there will be tools to help in the coming version or Visual Studio for DBA's

The Never Ending Load Test

Ways to mess up your Team System Tests...

In Visual Studio Team System you can create a Manual Test, which is a great tool I know many people will ignore but that is for another Blog entry.  You can also create a Load Test and the developers were smart enough to filter out Manual Tests. This was clever because a manual test, while processing stops to ask you to perform the test and record the result. This would stop the load test and completly mess up any data you are trying to gather.

However you can still add a Manual Test to your Load Test by putting it in an Ordered Test first. So if your Load test seems to have stopped check to see if someone added a manual test to one of your ordered tests.