blog community

Welcome to blog community Sign in | Join | Help
in Search

Martijn Beenes

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

    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:

    TF30331

     

    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”.


     TFS Setup

     

    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

    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

    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

    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:

    http://blogs.infosupport.com/photos/martijnb/images/13944/425x319.aspx 

    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

    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

    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

    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

    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

    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%

    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

    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 Include="c:\Build\_PublishedWebsites\*\*">

    <Output ItemName="PublishedWebSites" TaskParameter="Include" />

    </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);" >

          <Output ItemName="FilesToCopy" TaskParameter="Include"/>

    </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.

  • Web Deployment projects in a Team Build.

    Recently one of our customers decided to incorporate Team System into there development process. They wanted to migrate al there existing sources from there source repository system to Team Foundation Version Control.

    The sources mainly exist of ‘old’ asp code and some vb 6.0 code. There is some .NET 1.1 code as well but it will be migrated to .NET 2.0.

    I have been asked to help implement a Team Foundation Build to compile the .NET code and deploy the deliverables as well as the asp files.

     

    As described in this post, Team Build calls various targets. Some of those targets are already implemented by Microsoft. One of the default implemented targets is the CoreDropBuild target. This target is responsible for copying the output files to a deployment directory.

    The files being copied are the assemblies that are created in the build, the program database files and files that are marked in the projects as files to be copied to the output directory (property: Copy To Output Directory is set to true.)

    Al these files, for all the solutions in the build, are copied to a single directory. Unfortunately, this results in some unwanted behavior. Because all the files are copied to a single directory, files with the same filename are overwritten and only one copy of a file with a specific filename is available in this directory.

    Furthermore, because all the files are dropped into a single directory, directory structures needed for the application (especially websites) are no longer available.

    Fortunately Microsoft recently released a new project type, the Web Deployment project type that helped us a lot.

    This project is linked to a Web site project or a Web application project and ensures that the websites are correctly deployed using MsBuild.

     

    A small problem occurs however when those web deployment projects are used in a Team Build environment. Because the default Team Build implementation builds the output of all the projects in a build to a single build directory, the bin directory for each project is empty. The Web Deployment project however expects that the binaries for the web site/application projects are located in those bin directories.

    As the Visual Studio 2005 project files are actually MsBuild files, this problem is easily fixed. Just add some custom MsBuild code to the web site/application project files to copy the output files back.

     

    Here is an example of the MsBuild code I used, to copy the binaries back to the project bin folder.

     

    <Target Name="AfterBuild">

    <CreateItem Include="$(OutDir)\$(AssemblyName).*">

           <Output ItemName="FilesToCopy" TaskParameter="Include" />

    CreateItem>

     

    <Copy SourceFiles="@(FilesToCopy)"

          DestinationFiles="@(FilesToCopy –> '$(MSBuildProjectDirectory)\Bin\%(Filename)%(Extension)')"

          ContinueOnError="true"

    />

     

    <ResolveAssemblyReference

          Assemblies="$(AssemblyName)"            

          SearchPaths="$(OutDir);{TargetFrameworkDirectory};{GAC}"

          TargetFrameworkDirectories="$(TargetFrameworkDirectory)"

          FindDependencies="true"