Buck Hodges

Visual Studio Online, Team Foundation Server, MSDN

August, 2007

Posts
  • Buck Hodges

    TFSBuildLab beta 2 for TFS 2005

    • 2 Comments

    I mentioned TFSBuildLab a month ago when it hit beta 1.  Peter Blomqvist and Mathias Olausson have been hard at work and have now released beta 2.  They expect to hit 1.0 in the near future.  If you are looking for features like continuous integration and scheduled builds in TFS 2005, you'll want to give this a try.

    What is new in Beta 2?

    Service

        Support for tracing using trace listeners
        Made automatic notification registration optional
        Removed the need for LDAP to resolve email for notifications

    Admin Client

        Context menus with refresh commands
        Full screen mode (press F11 to toggle)
        Added hosting of reports in the dashboard
        Minimize to tray
        Sorting possibilities on the contents of the grids
        Added Edit trigger/policy
        Added Copy trigger/policy

    Notification Client

        Added support for executing alert commands
        Notifications occurs when a build starts as well

    Policies

        A policy for restricting checkins based on a source control path
        A policy for restricting checkins when the build is broken
        A policy for requiring a comment when performing a checkin

    Peter has posted about their own dogfood statistics.

    We have now been dog fooding TfsBuildLab in production since 2007-04-24 on a several projects the largest of them consisting of 5 parallel development branches each containing approximately 10 000 source files.
    Some statistics since the start (didn't have the time to do the graphs this time):
        1854 Automatic cleanups
        935 Scheduled builds
        754 Continuous integration builds

  • Buck Hodges

    TFS 2008 Beta 2 upgrade fixes are now available

    • 3 Comments

    We discovered and fixed several issues that blocked some users from upgrading from TFS 2005 to TFS 2008 Beta 2.  You can get the instructions and download the two updated executables at http://www.microsoft.com/downloads/details.aspx?FamilyId=C4015D2F-2383-4270-9AAD-97129590F31D&displaylang=en.

    Overview

    SYMPTOMS
    When you upgrade a Microsoft Visual Studio 2005 Team Foundation Server installation to Visual Studio Team Foundation Server 2008 Beta 2 you may receive one of the following errors:

    • "There is no team project named' in source control"
    • "TF220059: The installation process cannot continue"
      Installation will fail to complete when these errors are encountered.

    CAUSE

    • The first error, "There is no team project named' in source control", occurs when a Team Project is deleted and then re-created with the same name in Microsoft Visual Studio 2005 Team Foundation Server and then the database is upgraded as part of Visual Studio Team Foundation Server 2008 Beta 2 installation.
    • The second error, "TF220059: The installation process cannot continue", occurs when upgrading a Microsoft Visual Studio 2005 Team Foundation Server installation configured to run using a local account to Visual Studio Team Foundation Server 2008 Beta 2. The Visual Studio Team Foundation Server 2008 Beta 2 installer incorrectly tries to contact an Active Directory instance to authenticate the local account.

    http://mscompub/dmt/dialogs/preview/PreviewResources/img/1ptrans.gif

    more...

    For those who are interested, here are a few more details on the Team Build upgrade issues fixed by the aforementioned release.

    Upgrading the Team Build feature runs as the final step of the upgrade process from TFS 2005 to TFS 2008.  It fails in the following cases, causing the overall TFS upgrade to fail.

    1. The customer has deleted a team project and created a new one by the same name.  This manifests as a PK violation and is recorded in the setup log.
    2. The customer has deleted a team project that had builds associated with it, but v1 Team Build either wasn’t called by tfsdeleteproject.exe due to other failures or failed to delete one or more builds associated with that team project for some reason.  The upgrade fails when it tries to upgrade those builds.  This one manifests as an error looking up a team project that no longer exists ("There is no team project named' in source control").
    3. The customer has inserted cycles into the project details when manually inserting builds in v1 (i.e., “fake” builds).  This manifests as a SQL recursion exception.  This problem should be quite rare.  I just included here for completeness on the known issues that are fixed.
  • Buck Hodges

    How to construct the Team System Web Access 2005 URL to a file in version control

    • 4 Comments

    Grant Holliday asked for an explanation of how a Web Access URL should be constructed to for a file in TFS version control, similar to the work item links explained in the TSWA 2005 FAQ.  Hakan responded with the details, which are shown below.

    http://[TeamSystemWebAccessSite]/UI/Pages/Scc/ViewSource.aspx?scc-item=[ItemData]

    ItemData is the HtmlEncoded form of the query string, such as “id=10&cs=-1”

    • id: the item ID of the item in source control (you need to know this instead of the file path)
    • cs: changeset number (-1: latest)

    For example, if the file id is 151611,

        HtmlEncode(“id=151611&cs=-1”) -> “id%3D151611%26cs%3D-1”

    So the URL would then be

        http://tswa.domain.com/UI/Pages/Scc/ViewSource.aspx?scc-item=id%3D151611%26cs%3D-1

    We’re planning to provide more friendly URLs in a future version, similar to the wi.aspx approach.

  • Buck Hodges

    Team System Web Access for TFS 2005 FAQ

    • 14 Comments

    I wanted to highlight the TSWA for TFS 2005 FAQ since it contains good information, including how to switch between Windows authentication and forms authentication, turning off forms authentication, and how to construct the URL to a work item using the work item's ID.

    Visual Studio Team System Web Access FAQ

    • Q: Can I install Team System Web Access on an existing Web site?
    • Q: Which Web site port should I use for Team System Web Access Web site?
    • Q: How can I activate the log file?
    • Q: What’s the difference between Forms-based authentication and Integrated Windows authentication modes?
    • Q: How can I switch between Forms-based authentication and Integrated Windows authentication modes?
      • To enable Forms based authentication:
      • To enable Integrated Windows authentication:
    • Q: How can I enable sending work items as e-mail messages?
    • Q: What’s the URL to use if I want to send the link of a specific work item?
    • Q: How can I disable signing out and logging in as a different user (i.e., disable forms authentication)?
    • Q: How can I customize the bug form?
    • Q: Can I use Team System Web Access with Team Foundation Server in workgroup (non-domain) mode?
    • Q: Can I use Team System Web Access with single server / dual server Team Foundation Server configurations?
  • Buck Hodges

    TFS API: Determining if an edited file has changed

    • 1 Comments

    A few times over the last several months, the question has come up regarding how to determine whether a file on disk that is being edited is different that what is checked into TFS version control.  Folks looking at the PendingChange object have asked about the difference between the two hash value properties.

    If you query for the pending changes in the workspace using GetPendingChanges() (or QueryPendingSets() if you don't want all of the pending changes for the workspace), you'll get an array of PendingChange objects.  The PendingChange object has quite a few properties.  Two of those properties are HashValue and UploadHashValue.  Unfortunately, the documentation on MSDN doesn't really do them justice.

    The HashValue property is the right one to use if you want to determine whether a file with a pending edit has been modified.  HashValue is the MD5 hash of the content of the version against which the change was pended.  This value will be different from the MD5 hash of the file on disk, which you will need to compute yourself using MD5CryptoServiceProvider, if the file has been edited and actually changed.

    I would recommend not using the UploadHashValue.  The UploadHashValue is the hash for the content last uploaded during a shelve or failed checkin operation.  This is used internally for the optimization to avoid uploading the same content repeatedly.  For example, a checkin may fail due to a conflict after all of the file contents have been uploaded.   To make subsequent attempts faster, the server keeps the content that was uploaded and the client checks to see if it needs to send the content when the checkin is attempted again.  The UploadHashValue is only really useful for this process.

    Note that the GetHashCode() method is the standard .NET Object’s GetHashCode(), so it’s not relevant to the discussion of content hash values.

    One caveat to computing hash values is that on systems where FIPS enforcement has been enabled, the MD5CryptoServiceProvider class cannot be used (it throws an exception), and TFS itself does not compute hashes when that is the case (the hash values are just used for upload optimization, so upload optimization is disabled).  You can learn more about FIPS enforcement at http://blogs.msdn.com/shawnfa/archive/2005/05/16/417975.aspx.  The summary of the issue is that FIPS standard only allows the SHA family of hash algorithms.

    This post applies to TFS 2005 and newer.

  • Buck Hodges

    TFS 2008: Calling custom targets and documentation for the beta 2 object model

    • 2 Comments

    Aaron Hallberg has a written a great post on one of the new extensibility mechanisms we've added to the Microsoft.TeamFoundation.Build.targets file that forms the backbone of the msbuild process (it's imported by every tfsbuild.proj file and contains all of the targets and properties).  Aaron shows you how to have a different target called for each of the projects and solutions that you build, which allows for greater flexibility in hour your projects and solutions are built.

    Calling Custom Targets Within Team Build

    In Team Build v1 (VSTF 2005), the CoreCompile target always invoked the Build target of the solutions specified in the SolutionToBuild item group within your TfsBuild.proj file.  To support ClickOnce deployment, an additional item group called SolutionToPublish was supported - all solutions specified in this item group had their Publish targets invoked instead of their Build targets.  Team Build Orcas (VSTF 2008) generalizes this and allows custom targets to be specified for each solution in the SolutionToBuild item group (along with custom properties). 

          <SolutionToBuild Include="$(BuildProjectFolderPath)/path/MyClickOnceSolution.sln">
            <Targets>Publish</Targets>
          </SolutionToBuild>
          <SolutionToBuild Include="$(BuildProjectFolderPath)/path/MyStandardSolution.sln">
            <!-- <Targets>Build</Targets> -->
          </SolutionToBuild>
          <SolutionToBuild Include="$(BuildProjectFolderPath)/path/MyCustomProject.proj">
            <Targets>SomeTarget;SomeOtherTarget</Targets>
          </SolutionToBuild>
    more...

    By the way, even though the word "solution" appears in the name "SolutionToBuild," you can specify project files as well (e.g., foo.csproj).  It doesn't have to be a solution (we've kept the name "SolutionToBuild" from v1 for compatibility and because "SolutionOrProjectToBuild" just seemed like overkill).

    Aaron has also posted a new CHM file that contains the documentation for the Orcas beta 2 Team Build object model: Orcas Beta 2 Object Model Documentation.  If you want to use the new API, you'll want this documentation file.

  • Buck Hodges

    TFS 2008: A basic guide to Team Build 2008

    • 33 Comments

    Patrick Carnahan, a developer on Team Build, put together the following guide to the basic, as well as a few advanced, features of Team Build in TFS 2008.  It's a great way to get started with continuous integration and other features in TFS 2008.

    Team Build – Continuous Integration

    One of the new and most compelling features of Team Foundation Build is the out-of-the-box support for continuous integration and scheduling. A few in-house approaches have been built around the TFS Soap Event mechanism, most likely set to listen for check-in events and evaluating whether or not a build should be performed. The disadvantages to this approach are the speed and accuracy at which build decisions may be made.

    For all of the following steps, it is assumed that the ‘Edit Build Definition’ dialog is currently active. To activate this dialog, expand the ‘Builds’ node of the team project to which your V1 build type belongs (or to which you want to add a new V2 build definition) and click on ‘Edit Build Definition’ as shown below.

    Setting up the workspace

    Setting up a workspace is pretty important to the continuous integration build, since this is how the server determines when to automatically start builds on your behalf. Although the default workspace mapping is $/<Team Project Name> -> $(SourceDir), something more specific should be used in practice. For instance, in the Orcas PU branch you should use (at a minimum) the mapping $/Orcas/PU/TSADT -> $(SourceDir).

    What is this $(SourceDir) variable? Well, in V1 the build directory was specified per build type, meaning that the build type was built on the same directory no matter what machine the build was performed on. In V2 we have separated out the idea of a build machine into a first-class citizen called a Build Agent; this is where the build directory is stored. The variable $(SourceDir) is actually a well-understood environment variable by Team Build, and is expanded to: <BuildAgent.BuildDirectory>\Sources (more on the Build Directory and environment variables later). Typically you will want to make use of $(SourceDir) and keep everything relative to it, but there is no restriction that forces this upon you.

    Just so we’re on the same page with the workspace dialog, a picture has been included below. Those of you familiar with version control workspaces should feel right at home!

    Already have a workspace ready to go? Simply select the ‘Copy Existing Workspace’ button to search for existing workspaces to use as a template. The local paths will be made relative to $(SourceDir) automatically!

    Defining a Trigger

    The trigger defines how the server should automatically start builds for a given build definition.

    http://blogs.msdn.com/photos/buckh/images/1623211/original.aspx

    The first option should be self-explanatory, and keeps the build system behaving just like V1 (no automatic builds). The other options are as follows.

    • The 'Build each check-in' option queues a new build for each changeset that includes one or more items which are mapped in a build definition's workspace.
    • 'Accumulate check-ins', otherwise known as 'Rolling Build', will keep track of any checkins which need to be built but will not start another build inside of the defined quiet period. This option is a good way to control the number of builds if continuous integration is desired but you want a maximum number of builds per day (e.g. 12 builds per day, which would require a quiet period of 120 minutes) or your builds take much longer than the typical time between checkins.
    • Standard scheduled builds will only occur if checkins were made since the previous build. Don't worry about this rule affecting the first build, however, because the system will ensure that the first build is started right on time.
    • Scheduled builds can optionally be scheduled even if nothing changes. This is useful when builds are dependent on more than what is in version control.

    Drop Management

    One of the side effects of a continuous integration system is that a greater number of builds will be created. In order to manage the builds and drops created through CI we have introduced a feature in Team Build called drop management.

    Drop management is enabled through a concept we call Retention Policy in Team Build, which allows you to define how many builds to retain for a particular build outcome. For instance, you may only want to keep the last 5 successful builds and only one of any other kind. Through retention policy you can define this by setting the appropriate values in the dialog shown above and the server will manage the automatic deletion of builds for you.

    What if you don’t want a build to be susceptible to automatic deletion? We have an option available on individual builds if you would like to retain a build indefinitely (it just so turns out that this is what the menu option is called). To do this go to the ‘Build Explorer’ in Visual Studio 2008 (available by double clicking a node under the Builds node in the Team Explorer window), right click on the build, then select ‘Retain Indefinitely’. Once this option has been toggled on you will see a padlock icon next to the build.

    If you decide that the build is no longer useful, simply toggle the option off for the build and let drop management take care of the build automatically.

    Advanced Topics

    1. Automated UI Tests

    Automated UI tests cannot be run in the build agent running as a windows service since it is not interactive, meaning that it cannot interact with the desktop. So, we have provided the ability to run an interactive instance of the service out-of-the-box!

    The first thing you will need to do is create a new build agent on the server. To do this you should right click on the ‘Builds’ node for your team project, then click ‘Manage Build Agents’. Once this dialog comes up, click the ‘Add’ button which will bring you to the dialog below.

    The display name can be anything descriptive you want. For instance, if the machine name is ‘BuildMachine02’ you may choose to name the build agent ‘BuildMachine02 (Interactive)’ so you can easily differentiate between the interactive and non-interactive agents. The computer name should be the computer name of the machine on which the build service resides, and the port should be changed to 9192 since it is the default interactive port. When changing the port you may see a dialog with the message below, which may be safely disregarded in this case since you’ll be using the default interactive port.

    TF226000: After you change the port that is used by Team Foundation Build, you must also update the build service on the build computer to use the new port. For more information, see http://go.microsoft.com/fwlink/?LinkId=83362 .

    In order to run the build service in interactive mode just start a command-prompt on the build computer in the directory %PROGRAMFILES%\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies (if you do not want to run the build agent service as yourself then you need to be sure to spawn the command-prompt as the correct user using the ‘runas’ command). Now that you’re in the directory as the appropriate user all you need to do is type ‘TFSBuildService.exe’, which will output something similar to the following:

    C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies>TFSBuildService.exe

    Press the Escape key (Esc) to exit...

    Once you see that prompt your interactive agent is ready to go. You’ll need to leave that command running. Be sure that any time you need to run automated UI tests that you target the correct agent!

    2. Build Directory Customization

    In TFS 2005, you were able to specify the root build directory which should be used in the build type definition file TfsBuild.proj. During the build, the root build directory would automatically get expanded to:

    <Root Build Directory>\<Team Project Name>\<Build Type Name>

    This was not configurable and was done this way to ensure uniqueness across build types being built on the same machine. The sources, binaries, and build type were then brought into sub folders named ‘Sources’, ‘Binaries’, and ‘BuildType’, respectively. Since the names could get quite long, there were quite a few issues with path name length errors which were unavoidable.

    In TFS 2008 we have made it easier to customize the build directory on the agent through the use of 2 well-known environment variables.

    $(BuildDefinitionPath), which expands to <TeamProjectName>\<DefinitionName>

    $(BuildDefinitionId), which is the unique identifier by which the definition may be referenced (an Int32)

    The build directory is no longer guaranteed to be unique by the system automatically unless one of these two variables is used. This approach has some great advantages, especially since $(BuildDefinitionId) is merely an Int32 and will definitely reduce the length of paths at the build location!

    There is another method by which this path may be reduced even more if the source control enlistment requires it. If you take a look at the file %PROGRAMFILES%\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\TfsBuildService.exe.config on the build computer, you will see some settings which may be of interest to you.

    <add key="SourcesSubdirectory" value="Sources" />

    <add key="BinariesSubdirectory" value="Binaries" />

    <add key="TestResultsSubdirectory" value="TestResults" />

    These control the name of the sub-directories which will house the Sources, Binaries, and TestResults. If you need an even shorter path, you could name the sources sub directory ‘s’!

    NOTE: Be sure to restart the team build service ( the Windows service or the interactive service, as needed) after making changes to this file in order for the changes to take effect!

    3. Port Configuration

    For Orcas we have changed the communication method for the build agent (the build agent is the service installed and running on the build computer). In TFS 2005 the Team Build Server communicated with the build machines via .NET Remoting. In TFS 2008 we changed this to use SOAP+XML over HTTP, just like the other Team Foundation services. In order to do this, we have switched to using Windows Communication Foundation self-hosting functionality to expose the service end-point without requiring Internet Information Services (IIS) on the build computer. There is a new series of steps which must be followed in order to change the port for an existing TFS 2008 build agent.

    1. Disable the build agent on the server using the 'Manage Build Agents' option in Visual Studio 2008 described above. This will keep the server from starting new builds on the machine, but will let existing builds finish. This way you do not accidentally stop an in-progress build from finishing.
    2. Once there are no builds running, issue a 'Stop' command to the build Windows service, either using the Windows Services control panel or from the command line using the "net stop vstfbuild" command.
    3. Navigate a command prompt to the directory %PROGRAMFILES%\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies.
    4. Open the file TFSBuildService.exe.config, and look for a child element in the <appSettings> section with the key="port" (case sensitive!). Change the value of that key to the desired port and remember the value for the next step.
    5. In the same directory there will be an executable named wcfhttpconfig.exe. This will ensure that the appropriate URL ACLs are in place to allow the service account to listen for incoming HTTP requests. The command you should issue is: 'wcfhttpconfig reserve <domain>\<user name> <port number>'. You must run this command as a local administrator.
    6. Now issue a 'Start' command to the window service. 
    7. Change the status of the build agent back to 'Enabled' using the 'Build Agent Properties' dialog and click ok.

    You can find the official docs on MSDN at How to: Configure an Interactive Port for Team Foundation Build.

    NOTE: Changing the port of the Interactive Service is exactly the same as the instructions above with one exception: the appSettings key you will need to modify is ‘InteractivePort’.

    [UPDATED 9/07/07]  I've added links to the official docs on changing the port.

  • Buck Hodges

    Download: Creating and Customizing TFS Reports

    • 4 Comments

    I don't often post about reporting.  My last post was about sample reports for TFS from a year ago.

    If you are trying to understand it or just get more out of it, there are now more resources to help you.  On Friday (Aug. 10, 2007), a new article on TFS reporting became available for downloading.

    Creating and Customizing TFS Reports

    Brief Description

    This article provides an introduction to the important concepts and step by step instructions to Create and Customize Reports for Microsoft® Visual Studio® Team Foundation Server (TFS).

    Overview

    If you’ve used Microsoft® Visual Studio® Team Foundation Server (TFS), you may have seen reports that you would like to customize. Working with reports can be very intimidating because it uses different technologies that you may not be familiar with. This article provides an introduction to the important concepts you’ll need to learn a “minimal path” through the technologies. Reporting in TFS is built on top of Microsoft SQL Server Reporting Services and Microsoft SQL Server Analysis Services. You’ll also need some additional tools on top of Visual Studio, such as Business Intelligence Development Studio.

    Instructions

    1. Download the zip file and extract the contents to a folder on your
      computer. The zip file contains the following items:
      1. PDF Document: Creating and Customizing TFS Reports.pdf
      2. TFS Reports
        1. Bug Trends.rdl
        2. Remaining Work by Count.rdl
        3. Remaining Work by Size.rdl
        4. Status by Area.rdl
      3. PDF Documents explaining the TFS reports
        1. Bugs Trends.pdf (for Bug Trends.rdl report)
        2. Remaining Work.pdf (for Remaining Work by Count.rdl and
          Remaining Work by Size.rdl reports)
        3. Status by Area.pdf (for Status by Area.rdl report)
      4. PDF Document: How To Install a Report to TFS Project.pdf
      5. readme.txt
    2. Follow the directions in the readme.txt

    Other great resources for learning about reporting include the following post with some screencasts by Jimmy Li, one of the developers working on TFS reporting.

    Understanding the TFS Cube

      The initial learning curve for the TFS Cube is pretty steep. It is quite overwhelming to figure out the relationships between the large number of dimensions and measure groups in the TFS cube at first. In this blog entry I will explain some of the most commonly used perspectives and show how you can easily create Excel reports from them. 

      *Note* that this blog entry is still relevant to you even if you don't have perspectives on your cube.  What I cover here will help you better understand the cube schema.  In the demos below I connect Excel to cube perspectives.  However you can create the exact same reports by connecting to the Team System Cube.

      more...

    Mauli Shah, a tester for TFS reporting, posted a collection of links of reporting resources.

    Ameya Bhatawdekar, program manager for TFS reporting, wrote a post on how to do reporting with Visio: Team Foundation Server Reporting and Visio.

    If you have feedback on what you would like to see in TFS reporting, be sure to contact Ameya or leave a comment on his blog.

    Enjoy!

  • Buck Hodges

    Using CruiseControl.NET to trigger TFS 2005 builds for continuous integration

    • 3 Comments

    I ran across the following post by James Dawson and thought it may be of interest to folks trying to do CI with TFS 2005.  Of course, you'll find CI as part of the product in TFS 2008.

    TeamBuild Plug-in for CruiseControl.NET

    I've been meaning to write this post for a couple of months now as a follow-up to a session that Colin and I gave at the Microsoft Architect Insight Conference back in March, but just haven't found the time... at least, that's my excuse - anyway cutting to the chase!

    Since the release of Team Foundation Server (TFS) there have been several Continuous Integration add-ons produced by various folks:

    We've used most of the above, but despite however well they worked have found myself wanting some feature or other that was available in CCNet (actually it more about being badgered by developers about the missing features!).  Whilst some of the above could have been extended to support these features, I couldn't help but feel that this would have been reinventing the wheel - hence the idea to extend CCNet.

    more...

  • Buck Hodges

    TFS 2008: Command line help for tf.exe now prints to the console

    • 6 Comments

    In TFS 2005 running help from tf.exe popped up the MSDN help browser.  That was a bit lame, but we didn't allocate the time to do it right.  That's been fixed in TFS 2008.

    Running tf.exe /? produces a list of commands, and tf someCommand /? produces detailed help on that command.

    Here are a couple of examples.  These two commands are also new in TFS 2008.

    D:\>tf destroy /?
    TF - Team Foundation Version Control Tool
    Copyright (c) Microsoft Corporation.  All rights reserved.

    Destroys, or permanently deletes, version-controlled items from Team
    Foundation version control.

    tf destroy [/keephistory] itemspec1 [;versionspec]
               [itemspec2...itemspecN] [/stopat:versionspec] [/preview]
               [/startcleanup] [/noprompt]

    Versionspec:
        Date/Time         Dmm/dd/yyyy
                          or any .Net Framework-supported format
                          or any of the date formats of the local machine
        Changeset number  Cnnnnnn
        Label             Llabelname
        Latest version    T
        Workspace         Wworkspacename;workspaceowner

    D:\>tf folderdiff /?
    TF - Team Foundation Version Control Tool
    Copyright (c) Microsoft Corporation.  All rights reserved.

    Displays a visual representation of the differences between files in two server
    folders, in a server folder and a local folder, or in two local folders.

    tf folderdiff [sourcePath] targetPath [/recursive] [/noprompt]
                  [/server:serverName:port] [/filter:filter]
                  [/filterLocalPathsOnly]
                  [/view:same,different,sourceOnly,targetOnly]

  • Buck Hodges

    Team System Web Access: Workaround for installation problem on a non-English Windows OS

    • 1 Comments

    [UPDATE 8/8/07]  There is now a KB article on this issue.

    Hakan posted the following on Brian Harry's blog in response to a customer report about encountering the following issue when installing the new Team System Web Access release on German, French, Italian or Spanish Windows.  We plan to add this to the FAQ page.

    Symptom:

    You receive the following error while trying to install Team System Web Access.

    System.Security.Principal.IdentityNotMappedException: Some or all identity references could not be translated.

    (Spanish) System.Security.Principal.IdentityNotMappedException: No se pudieron convertir algunas o todas las referencias de identidad.

    (French) System.Security.Principal.IdentityNotMappedException: Impossible de traduire certaines ou toutes les références d'identité.

    Cause:

    During the installation, we grant permissions to Network Service account for the Cache folder. On some non-English operating systems, the installer cannot locate the Network Service account because the account name is localized.

    Affected Operating Systems:

    This problem only happens when TSWA is installed on a German, French, Italian or Spanish Windows. Other Windows languages are not affected by this issue.

    Workaround:

    If you're installing Web Access on a Windows with any of the following languages: German, French, Italian, or Spanish; before running the installer, please follow the steps below:

    1. Create a new local user group with the name "Network Service"

    2. Add the localized network service account to the recently created "Network Service" group. Here's a mapping:

        German - NT-AUTORITÄT\NETZWERKDIENST

        French - AUTORITE NT\SERVICE RÉSEAU

        Italian - NT AUTHORITY\SERVIZIO DI RETE

        Spanish - NT AUTHORITY\SERVICIO DE RED

    3. Run the TSWA setup.

    We’re tracking this issue on our support forum:

    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1954637&SiteID=1

  • Buck Hodges

    Deleting test results from a build

    • 3 Comments

    In either TFS 2005 or TFS 2008, you can delete the test results published against a build (How to: Publish Test Results).  However, discovering this feature may be difficult, and I didn't find it on MSDN in a quick search of the docs.

    What you'll need to do is to bring up the build details (aka the build report) in Visual Studio.  Then expand the test results, right click on the link to the Test Run and choose Delete.

    deleting test results from a build

  • Buck Hodges

    TFS 2008 beta 2: How to add a Network Service account to the Build Services group

    • 4 Comments

    We changed the build agent setup such that the default presented in the setup GUI is to use Network Service as the build service account.  One big advantage of doing this is that the Network Service account doesn't have a password that expires, removing one annoying administrative issue.

    Once you install the build agent, you need to add the service account to the Build Services security group for the team project where the build definition resides.  That's all explained in the installation guide and other documentation.

    In beta 2, however, the Network Service account for a computer cannot be added to the Build Services group using the Visual Studio 2008 GUI (normally, you would right-click on the team project, choose Security, then Group Membership, and add your account to the group).

    We have fixed this issue for the final release of TFS 2008.  You can find the workaround of running tfssecurity.exe in section 2.7.4 of the TFS 2008 Readme.

    Jim pointed out to me this morning that the readme link on the installation media for beta 2 takes you to a page that does not have this workaround listed (that'll be investigated, too).

  • Buck Hodges

    Vote for your favorite version control system to migrate to TFS

    • 0 Comments

    Matt Mitrik, program managers for the TFS migration and synchronization toolkit, wants to know which version control systems are most important for them to focus on.  Go here and vote now.

    What migration tools are you looking for?

    I've heard plenty of requests for tools to migrate data from competitor products to TFS, and I'm trying to find out which tools have the highest demand. If you need a tool to integrate Subversion and TFS, for example, please reply to this post and let us know. Or better yet, create a new item in the issue tracker so that others can vote on the tools they want to see developed.

    I'm also thinking about how to encourage the community to work together to develop migration and synchronization tools. Surely there is more than one person with a need for a SVN tool that is willing to develop it using the toolkit, so why not bring those heads together?

    I'll start it off and open an issue for a SVN to TFS migration tool, and see where that goes. Hopefully others will follow.

    http://www.codeplex.com/MigrationSyncToolkit/WorkItem/List.aspx

    This was sort of a chain.  I was catching up on blogs, and I saw Eugene's post about Martin's post about Matt's post.

Page 1 of 1 (14 items)