Martijn Beenes

TF30331: Team Explorer could not connect to the Team Foundation server.

martijnb — Tue, 21 Oct 2008 10:55:00 GMT

In the last couple of months I have been helping a lot of our customers migrate from Team System 2005 to Team System 2008.

Some customers did not have their licenses updated on the day that I came by to help them upgrade Team System. In order to perform the upgrade on that day, and let them continue working with Team System, I advised them to install the trial version of Team System and update the license key on a later date when they acquired the correct license key.

Unfortunately, some customers forgot to perform this upgrade and after 90 days of Team System running without any problems the developers got the following error when trying to connect to Team System:

As the message states the trial edition of Team System had expired and the license must be updated to continue running Team System.

The question that I then got was, how can I update my license?

Well, the license can be updated in the following way:

1) Open the “Add or Remove programs” dialog (StartàControl Panel à Add or Remove programs)

2) Select the “Microsoft Visual Studio 2008 Team Foundation Server” entry.

3) Click the change/remove button. The Maintenance mode dialog of the Team System setup should appear.

4) Select the “Upgrade to Microsoft Visual Studio 2008 Team Foundation server”.

5) Enter the new licence key and click in the “Next” button.

The setup will now update the Team Foundation server license and you should be able to use Team System again.

Update: MSDN Evening session on Windows Installer Xml

martijnb — Mon, 23 Jun 2008 19:34:00 GMT

I recently blogged about a session I did for Microsoft Belgium on Windows Installer Xml. This session was recorded and is now online. The recording only shows the slides and demo’s I did. If you would like to view this session, you can view it here.

MSDN Evening session on Windows Installer Xml

martijnb — Fri, 06 Jun 2008 14:40:00 GMT

On June 4, I did a session for Microsoft Belgium on Windows Installer Xml during a MSDN evening session. You can read more about MSDN evening sessions in Belgium here.

In this session, I explained the basic concept of Windows Installer packages and by using a number of demos, showed how to create a fully customized Windows installer packages using Windows Installer Xml.

You can download the slide deck here and a zip file containing the demos can be downloaded here.

Developer Days 2008 presentation on Sync Framework

martijnb — Thu, 05 Jun 2008 19:11:00 GMT

On may 22, I did a session on the Microsoft Sync Framework during the dutch Developer Days 2008.

Here is a picture of me during the thursday session:

In this session I gave an overview of the Sync Framework. I used a simple demo application to demo some of the features of the Sync Framework. You can download the slide deck here and a zip file containing the demos can be download here.

During my session, I showed a video of Mike that is using different kinds of devices and has his data available on everyone of them. This video is not part of the slide deck (it is just to big). If you want to watch the video again, you can download it from here.

I had a good time presenting this session. I hope it was a useful for you as well.

Using WiX UI library

martijnb — Thu, 29 Nov 2007 08:33:00 GMT

When using WiX, I found that most of the development time is spend on building a user interface. Fortunately WiX provides a library with some default dialog sets. Those dialog sets provide a familiar wizard-style user interface and can help you build MSI files much faster. At the WiX website you can read which dialog sets are available in the WiX library.

In most cases these dialog sets will provide the user experience you need, although you might want to change the background image, banner image or change the license text to give the MSI a custom look and feel.
With WiX 2 this can be accomplished by placing the appropriate image files in a sub-folder of the current directory in which the wixobj file is located. The sub-folder should be named: Bitmaps. In this directory files can be placed that must be used by light.exe instead of the defaults. These files must have specific names and dimension. In the table below the different filenames, and dimensions are mentioned:

File name	Description	Dimensions
bannrbmp.bmp	Top banner bitmap	500 × 63
dlgbmp.bmp	Background bitmap used on welcome and install-complete dialogs	503 × 314
exclamic.ico	Exclamation icon on the wait-for-costing dialog	32 × 32
info.ico	Information icon on the cancel and error dialogs	32 × 32
New.ico	Button icon on directory-browse dialog	16 × 16
Up.ico	Button icon on directory-browse dialog	16 × 16

The license text can be updated by placing a License.rtf file in the in the directory were the wixobj file is located.

Unfortunately this trick doesn’t work anymore with WiX 3. This doesn’t mean that it is not possible to change the images or license text. With WiX 3 you can specify the images, icons and license text by providing the path to those files as arguments on the command line. The following arguments are available for this:

Property name	Description
WixUIBannerBmp	Path to the top banner bitmap
WixUIDialogBmp	Path to the background bitmap used on welcome and install-complete dialogs
WixUIExclamationIco	Path to the exclamation icon on the wait-for-costing dialog
WixUIInfoIco	Path to the information icon on the cancel and error dialogs
WixUINewIco	Path to the button icon on directory-browse dialog
WixUIUpIco	Path to the button icon on directory-browse dialog
WixUILicenseRtf	Path to the license file

Specify the argument on the command line in the following way:

Light.exe <some_wixobj_file> -dWixUILicenseRtf=[Path-to-License-file]

Uploading MsTest results to TFS

martijnb — Wed, 21 Nov 2007 08:08:00 GMT

At Info Support we have been building and maintaining an automated build process over the last six years. This process is largely based on NAnt and has a lot of custom code.

When Team System was released, we started upgrading our build to use the Team System Version Control environment instead of Visual SourceSafe. Furthermore we integrated our build into TFS by writing custom tasks to register builds with Team System and log information with team System during the build. This way we’re able to keep our existing custom build environment (that provides much more features then the default TeamBuild with Team System does) and still provide the full TFS experience with Visual Studio.

In our automated build process we’ve been using NUnit to execute unit tests. This tool has been the defacto standard for quite some years and is fairly easy to use. However, with the launch of Team System Microsoft released their own test engine called MsTest. Now that MS released the test tools also in the Professional SKU we wanted to support MS test as well in our build. To remain backwards compatible, we’ve decided to extend our build to support both NUnit and MsTest.

I have been working on this feature for some days and kept running into the same problem. Running the MsTest tests locally turned out to be very simple. The problems started when I tried to upload the test results back to Team System. I kept on getting the error:

Publish Failed. Test Type not installed on the server for test type: "Microsoft.Samples.VisualStudio.TestTools.HostAdapters.VsIde.RunConfigData".

As it turns out this issue only appears with solutions that were opened on a machine were the Microsoft Visual Studio 2005 SDK is installed.
Searching the internet I found this comment on the Microsoft connect site, provided by the VS SDK team:

In case you build VS packages, you have to have VS SDK installed. This is the main purpose of VS SDK. If you do not need to extend VS with the new packages, please uninstall the VS SDK and the problem will go away. It is by design of the Test project to persist all the registered host types in the test run config file and VS SDK installs the VS IDE Host Adapter.

Unfortunately uninstalling the SDK is not an option for us as we do extend Visual Studio. I realized though, that when this information is put into the test run config file, the information is not mandatory. It should be possible to delete this information, without breaking the test run config file.

We ended up building a very simple MsBuild task that will scan the test run config file before the tests are executed and delete the hostData element in the test run config file.

Hope this helps,

Cloning a Team Foundation Server

martijnb — Sat, 28 Jul 2007 23:21:00 GMT

This weekend we upgraded our production servers running Team Foundation Server (the “Whidbey” release) to the Beta 2 of the Team Foundation Server “Orcas” release.
First, I have to say, the upgrade experience compared to the beta 1 is much, much better. Just run the installer, fill out some account information and wait a while until the upgrade is done.

We encountered no problems during the upgrade, but unfortunately after the upgrade things took a bad turn. The first server we upgraded crashed. The operating system was completely deleted from the hard drive. In turned out that we ran into a nasty bug on TFS “Orcas” that is very hard to run into. My colleague Marcel de Vries wrote a blog post about it. You can read it here.

So with the server gone, we had to install our server from scratch.

To prevent these kind of production problems and because of the need to store our customer code separately from our own codebase, we had already decided to split our big Team Foundation Server in two. To accomplish this, we created a clone of our main Team Foundation server and upgraded the cloned server to the “Orcas” Beta 2 bits. As the server had crashed, we needed to run this process again.

There is a nice guide available from Microsoft to clone a (Whidbey) Team Foundation Server. You can read it here.

There is one imported thing to note when using this guide. This guide is meanly meant to re-install your server after it crashed or for whatever other reason. But it assumes that after (or even during) the cloning process the “source” server is no longer available.

In our case we wanted the “source” server to be up and running next to the newly cloned server. To accomplish this you need to give one of the Team Foundation servers a new instance id. This can be accomplished with the following commands:

“%TFSInstallDir%\Tools\InstanceInfo.exe" stamp /setup /install /rollback /d TFSWorkItemTracking,TFSBuild,TFSVersionControl,TFSIntegration /s <<your new data tier>>

"% TFSInstallDir %\Tools\InstanceInfo.exe" stamp /d TFSWorkItemTracking,TFSBuild,TFSVersionControl,TFSIntegration /s <<your new data tier>>

The first command is the clear the instance id, the second to stamp a new instance id. After executing these commands you have a newly cloned server side-by-side with the original server.

The cloning process can take up quite some time. It took us about 4 hours to clone the server. This might take less or more time depending on the size of the Team System databases. We have a TfsVersionControl database of over 6 gigabytes and it took about 25 minutes to create a backup of this database and another 25 minutes to restore it.

Because of the server crashes (It crashed twice before we understood what was causing the problem) we cloned our production server three times in the last few days. Since the backup and restore actions for the Team System databases took us so much time, we created a T-SQL script to restore the databases and move them to a new location. You can download the script here. (Note that the location and names of the backup files will be different on your machine.)

Our servers our now al up and running with the Team System “Orcas” Beta 2 bits, thanks to the guys of Microsoft that helped is fix the data that was causing the server crash.

Hope this helps.

Renaming TFS Orcas Beta 1 VPC

martijnb — Tue, 08 May 2007 06:12:00 GMT

At Info Support we are involved in the Microsoft Technical Adaption Program for Visual Studio Team System codename Orcas.

As part of this program we recently downloaded the Virtual PC Image containing Visual Studio Team System codename Orcas beta 1. (You can download it from the Microsoft site here.)

Last week I ran into some trouble when I was renaming this image. Another colleague of mine was using an image with the same name. I decided to rename the Virtual PC and add it to the domain to prevent further trouble.

First I renamed the machine and restarted the image. Next I added the image to our corporate domain. Then I followed the steps as described here to reconfigure the Team Foundation Server.

Al seamed well, until I tried to connect to the Team Foundation Server using my domain account. I got the following error:

TF31003: Your user account doesn’t have permission to connect to the Team Foundation Server http://server:8080/. Contact your Team Foundation Server administrator and request that the appropriate permissions be added to your account.

I verified that I was administrator on the image. I tried connecting with the local administrator and that worked just fine. When I looked at the Group membership under the Team Foundation Server settings, I noticed the domain users where not listed in the Team Foundation Administrator group.

I tried adding the domain user explicitly. This resulted in the error:

Team Foundation Server could not resolve the user or group ‘Martijn Beenes’. The user or group might be member of a different domain, or the server might not have access to the domain. Verify the domain membership of the server and any domain trusts.

This error message triggered me to check the application pools used by Team Foundation Server. The identities of these application pools were all configured to use a local user account.

I changed the identities to a domain account we have available for services. When connecting to Team Foundation Server I still got an error message. And even worse the TFSWSS application pool had crashed.

It turned out that I needed to add the domain user (which the application pools were running on) to the local IIS_WPG group as well. This solved my problems.

Hopes this helps.

An introduction to Windows Installer Xml

martijnb — Thu, 07 Dec 2006 19:04:00 GMT

Recently I wrote an article on Windows Installer Xml (WiX for short). Windows Installer Xml is an open source initiative from Microsoft for a toolset that builds Windows installation packages from XML source code.

I have written an introduction article on this technology that just got published in the Software Developer Network Magazine of november. You can read the article here. (You must be a member to read the complete article.)

If you got excited after reading about WiX, you can download the latest version from sourceforge.net.

Why my coverage didn't reach 100%

martijnb — Fri, 20 Oct 2006 09:47:00 GMT

Some time ago I encountered an interesting feature (!) of the test engine within Visual Studio 2005. I had written a couple of unit tests for some code I had developed. After running the tests I reviewed the coverage results. I'd expected to reach 100% coverage. Instead, the coverage results showed me that I had missed a code block.

By clicking on the method name containing the non-covered code block, I went straight to the code. It looked like this:

private object GetTypedValue(string type, string value)

{

// Return the correct type.

switch (type)

{

case "bigint":

return Int64.Parse(value);

case "bit":

return bool.Parse(value);

case "char":

case "nchar":

case "ntext":

case "nvarchar":

case "text":

case "varchar":

return value;

case "datetime":

case "smalldatetime":

return DateTime.Parse(value);

case "decimal":

return decimal.Parse(value);

case "float":

case "real":

return float.Parse(value);

case "int":

return int.Parse(value);

case "money":

case "smallmoney":

return SqlMoney.Parse(value);

case "smallint":

return Int16.Parse(value);

case "xsd:base64Binary":

return Convert.FromBase64String(value);

default:

throw new NotSupportedException("...");

}

At first glance I noticed nothing strange. All my code paths seemed to have been executed during the tests. Then I noticed that the begin (“{“) and end (“}”) tags of my method were marked as covered but the same tags specifying the beginning and end of the switch statement were not.

A college of mine (thanks Ka Wai) pointed me to the Microsoft forums where this problem is discussed. It seems this problem can occur when using a foreach or switch statement. (The problem with the switch statement will only occur when you have 6 or more case statements.)

When using the coverage capabilities of Visual Studio 2005, some code is compiled with your source code. The CLR is generating some extra code under the covers that is used for the foreach and switch statements. This has to do with some optimization the CLR makes.

So some extra code is run when the tests are executed. The code coverage tool is therefore actually telling the truth. Some of the IL code isn’t actually covered by the unit tests. Unfortunately the not covered IL code doesn’t correspond with a specific statement in your code so it won’t show up in Visual Studio.

If you really want to achieve 100% coverage you can use a for loop instead of a foreach statement and a nested if-else construction instead of the switch statement. But I don’t recommend it. In my opinion, you should never change your code in favor of a test or coverage. You should rather favor readability and maintainability of the code.

MsBuild metadata

martijnb — Mon, 10 Jul 2006 12:13:00 GMT

Last week I came across an interesting problem with MsBuild. I recently blogged about Web Deployment projects in a Team Foundation build. A big advantage of the Web Deployment projects is, that the website/web application output files are copied to a sub directory rather than being dropped in the build output directory which is the case for all other project types.

Unfortunately this behavior was not enough for the build I was working on.

In a TeamBuild, only containing Web Application projects and Web Deployment projects, I needed to copy the published websites to a new directory and add an extra subdirectory into the path.

Let me clarify this with an example: I needed to copy “c:\Build\_PublishedWebsites\WebSite1\**\*.*” to “c:\MyWebApplications\WebSite1\wwwroot\**\*.*”.

The key to solving this problem is getting a list of all the websites in the _PublishedWebSites directory and linking them to a collection of files that are contained in those website directories. Unfortunatly this can’t be accomplished in a single MsBuild statement. But I can be solved by using metadata on items and item collections.

MetaData

Metadata is extra information about items in a collection. This metadata can be used to manipulate the item collection.

Each item in an item collection has some metadata that can be used. For instance each item has a metadata property FullPath specifying the full path to the item on disk. Here you can find a list of the well-known item metadata that is associated with each item in an item collection.

It is also possible to add your own metadata to items in a collection.

I used this feature in the build I was working on to create an item collection in which each item had some custom metadata.

Lets take a look at the example again. The first step to take is getting a list of all the websites in the _PublishedWebSites directory.

Just create a new item collection, selecting all the (first level) directories under the _PublishedWebSites directory. (A pre condition is that the directories you want to select must contain at least 1 file. Empty directories or directories only containing directories themselves are ignored by the CreateItem task.)

</CreateItem>

The new item collection contains all the files that are available in the directories. Each item will have some metadata we need to use. One being: RelativeDir. This metadata property holds the directory (part of a path) that corresponds with the * or ** specified in the Include filter when creating the item collection. In the example, it will contain “WebSite1”.

Next we need an item collection of all the files that are part of the websites, grouped per website. This can be accomplished by selecting all the files and directories in the directories we collected in the PublishedWebSites item collection.

By only using the RootDir and Directory metadata properties, it is possible to create an item collection containing all the files. When creating a new item collection based on a previous created item collection, the metadata properties of the previous created item collection must be copied to the new collection (if you need to use them again). In case of the example, the RecursiveDir property must be copied.
It is not possible to overwrite the well-known metadata properties so a new metadata property must be created.

By adding this metadata it is possible to ensure that the directory name of the website directory is preserved.

<CreateItem

Include="@(PublishedWebSites->'%(RootDir)%(Directory)\**\*.*')"

AdditionalMetadata="WebSiteDir=%(RecursiveDir);" >

</CreateItem>

The FilesToCopy item collection will contain all the files that must be copied, and will have all the relevant metadata to create the destination path.

<Copy

SourceFiles="@(FilesToCopy)"

DestinationFiles="@(FilesToCopy->'c:\MyWebApplications\%(WebSiteDir)\wwwroot\%(RecursiveDir)%(FileName)%(Extension)’)"

This is just one example of how you can use metadata on items and it shows that the use of metadata can be a powerful way to solve specific problems.