Visual Studio 2008 introduced a feature that detects where the current Team Foundation Server is online or offline when you start the IDE.

In the situation where your server is actually ONLINE, but you want to treat it LIKE it’s offline, you have a couple of options.

Option 1 - Use the ‘tfpt tweakui’ utility

You can edit the server setting and go offline.

• Close Visual Studio
• Download and install the latest Team Foundation Power Tools
• Start a Visual Studio Command Prompt
• Type: tfpt tweakui
• Open the server
• Check the [X] Server is offline checkbox
• Open Visual Studio

Option 2 - Yank the network cable before starting Visual Studio

Obviously the IDE won’t be able to contact the server, and will inform you that it is now offline.

Option 3 - Set a registry key

Create a *.reg file with the following text in it, and run it before starting Visual Studio.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\TeamFoundation\Servers\SERVERNAME]

"Offline"=dword:00000001

"AutoReconnect"=dword:00000000

When you want to go back online, you can either go to "File | Source Control | Go Online", or delete this registry key.

If you’re doing a deployment out to a test server as part of your Continuous Integration build process, you may have some unit tests (or web/load tests) to run after the deployment. Since these tests are testing more than just an assembly, they can be considered integration tests.

This can easily be accomplished by modifying your TFSBuild.proj script. Start by overriding the AfterDropBuild or similar MSBuild target and calling the <TestToolsTask> with the correct parameters.

First of all, you’ll need to define the tests that you want to run. The simplest way is to create a Test List called “Integration Tests” that gets saved in your test metadata file (*.vsmdi).

<ItemGroup>

  <IntegrationTestList Include=”$(SolutionRoot)\src\MySolution.vsmdi”>

    <TestList>Integration Tests</TestList>

    <FlavorToBuild>Release</FlavorToBuild>

    <PlatformToBuild>Any CPU</PlatformToBuild>

  </IntegrationTestList>

</ItemGroup>

There are two additional properties that we need to set, they are the Platform and Flavor. The reason for this is that when MSTest.exe tries to publish the integration test results to TFS, it needs to know what platform/flavor build to build against. And since we are doing this in AfterDropBuild, the configuration information isn’t available.

If your application requires additional files, or extra test run settings, you will need to specify them with a Test Run Config file:

<PropertyGroup>

  <RunConfigFile>$(SolutionRoot)\src\MySolution.testrunconfig</RunConfigFile>

</PropertyGroup>

And finally we can override the AfterDropBuild target to run the test list:

<Target Name=”AfterDropBuild”>

  <!– Execute Integration tests against remote server. –>

  <TestToolsTask

    Condition=” ‘$(IsDesktopBuild)’!=’true’ and ‘%(IntegrationTestList.Identity)’!=””

    BuildFlavor=”%(IntegrationTestList.FlavorToBuild)”

    Platform=”%(IntegrationTestList.PlatformToBuild)”

    PublishServer=”$(TeamFoundationServerUrl)”

    PublishBuild=”$(BuildNumber)”

    SearchPathRoot=”$(OutDir)”

    PathToResultsFilesRoot=”$(TestResultsRoot)”

    MetaDataFile=”%(IntegrationTestList.Identity)”

    RunConfigFile=”$(RunConfigFile)”

    TestLists=”%(IntegrationTestList.TestList)”

    TeamProject=”$(TeamProject)”

    TestNames=”$(TestNames)”

    ContinueOnError=”true” />

</Target>

Now when you view the Team Build results, you will have two sets of Test Results published against the single build.