Connecting to TFS from any version of Visual Studio

2016-11-16

I've written a couple of blog posts on this subject before and thought it would  be nice to consolidate them into one big post now that Visual Studio 2013 is about to be released. There are 3 major things to consider when connecting to TFS from an older version of Visual Studio.
  • The version of TFS you want to connect to
  • The version of Visual Studio you're connecting from
  • The version of Windows you're running
In this blog post:
  1. Connecting to Team Foundation Server 2015, 2017 or Visual Studio Team Services.
  2. Connecting to Team Foundation Server 2013.
  3. Connecting to Team Foundation Server 2012.
  4. Connecting to Team Foundation Server 2010.
  5. Configuring the MSSCCI provider for Visual Studio
  6. Connecting from Visual Studio 2005, 2008 or the MSSCCI provider
Since writing this post, Microsoft has produced an updated piece of documentation (which is already behind in some aspects) that describes most of the client/server combinations. One thing it adds which I haven't described, is the list of features that are available depending on your version of Visual Studio/TFS.

If you're having issues connecting after updating, it might be required to clear your local client cache to clear up certain issues like this one. Either the official way or the hard way.

If you also want to install the Team Foundation Server Power tools to match your Visual Studio/TFS version, check out this separate post.

Update: Updated download links to the final version of Team Explorer 2013.

Update (13-11-2013): Updated download links to the final version of Visual Studio 2012 Update 4.
Update (25-11-2013): Added information on client cache and feature docs.
Update (6-1-2014): Added update for VS2010 for Windows 8 and Visual Studio 2012
Update (21-1-2014): Added update 1 for Visual Studio 2013
Update (25-8-2014): Added update 3 for Visual Studio 2013
Update (21-7-2015): Added update 5 for Visual Studio 2013 and Visual Studio and TFS 2015. Since Visual Studio 2013 Update 5 contains updates to handle TFS 2015 Team Project Renames, it's recommended for anyone connecting Visual Studio or MSSCCI 2013 to TFS 2015.
Update (22-7-2015): Added update 5RC for Visual studio 2012.Since Visual Studio 2012 Update 5RC contains updates to handle TFS 2015 Team Project Renames, it's recommended for anyone connecting Visual Studio or MSSCCI 2012 to TFS 2015.
Update (26-8-2015): Replaced Visual Studio 2012 Update 5 RC with the final version.
Update (30-8-2015): MSSCCI 2013 now also supports Visual Studio Team Foundation Server 2015. But it still depends on Team Explorer 2013.
Update (27-10-2015): IntelliJ IDE's support added
Update (8-1-2016): logging on using Azure Active Directory is no longer supported on Windows XP/2013 and systems with IE8 or older.
Update (4-7-2016):Added Visual Studio 2015 update 3
Update (16-11-2016): Added TFS 2015 (same as TFS2015)

Solve basic auth proxy issues with Nuget, Visual Studio and Xamarin (hack)

2016-08-23

When you're using Visual Studio behind a Basic Authenticaton proxy, you may run into issues restoring Nuget packages. While I've never found a real solution for the issue, and trust me I've tried quite a few workarounds like the ones listed here.

You'll get the following error:

[5:06] Download failed. Please download https://dl-ssl.google.com/android/repository/android_m2repository_r29.zip and put it to the C:\Users\user\AppData\Local\Xamarin\Xamarin.Android.Support.Design\23.3.0.0 directory.
[5:06]  Reason: The remote server returned an error: (407) Proxy Authentication Required.

I've come to rely on my trusted hacking friend Fiddler and turn on "Automatically Authenticate".


Optionally configure your upstream proxy in Fiddler:



Restart Visual Studio so it picks up Fiddler as the proxy and you're good to go. Just leave Fiddler running in the background and all will be well.

A quick peek into Team Foundation Server 15 Preview

2016-07-09

Gian Maria Ricci already covered a nice overview of what's new in the install experience of TFS 15 in the latest Preview Release. Let's walk through the new features in the product... though I suspect that many of you won't see a lot of surprising things, given that many of the features have been released to Visual Studio Team Services in the past months.

A quick scan through all the tabs and pages of Web Access reveals a cool number of new features, though maybe not yet as many as you had expected. Just remember that the time between releases has steadily gone down from 3 to 2 and now only 1 years. The differences are no longer earth shattering, but still very welcome!

Publish your VSTS extension using Team Build and Release Management

2016-06-10

While I've released my VSTS Extension Tasks to GitHub and the Visual Studio Marketplace some time ago, I was reminded that I've never really blogged about it yet. You may wonder what it does.

The VSTS Extension Tasks are a set of tasks for Team Build and Release Management to package, publish, share and install extensions to your Visual Studio Team Services account or TFS 2015 update 2 server.

There are quite a few people using the extension to package and publish their Visual Studio Team Services and TFS extensions.

There's a few places with more information on how to use them:
I'm using these tasks to package and publish my other build tasks:
A few other MVPs/Rangers that are using these tasks include Richard Fennel, Rene van Osnabrugge, Peter Groenewegen and Utkarsh Shigihalli and others.

Publish your extension to a local TFS Update 2 server

2016-06-01

With the availability of extensions for TFS I've been looking for an easy way to publish extensions and their updates to the local marketplace. While I'm sure that Microsoft will at some point integrate the two, for now you need to manually sync the extensions between the VSTS Marketplace and your local TFS Marketplace.

Turns out that the tools used to publish to the VSTS Marketplace work for the TFS one as well. to publish an extension you do need to pass in the service url manually and this took a little bit of fiddling to figure out what to put in there. Turns out that it takes the server root,

C:\t>tfx extension publish --root . --manifest-globs vss-extension.json 
    --service-url http://jessehouwing:8080/tfs --proxy http://localhost:8888
Checking if this extension is already published
It isn't, create a new extension.
Waiting for server to validate extension package...

=== Completed operation: publish extension ===
 - Packaging: C:\t\jessehouwing.jessehouwing-vsts-variable-tasks-0.0.0.vsix
 - Publishing: success
 - Sharing: not shared (use --share-with to share)

If your server isn't configured with Basic Authentication enabled, you can use the Fiddler hack to authenticate over NTLM. As you can see by the --proxy option int he command above, that's what I'm doing at the moment.

It should be relatively easy to build a PowerShell script that uses the --json option to list all extensions on the local TFS Marketplace and then check the online marketplace for a newer version to automatically sync extensions which have already been installed. Stick that in a Build Definition on a Schedule and your local marketplace will always be up to date with the latest versions. That's something for a future blogpost.

Automatically populate your Source branch when publishing to Sonar

2016-05-10

When you enable your build definition to trigger on multiple branches, you may not want them all to publish into the same Sonar project. 

Sonar has the concept of Branches, they're simply appended to the Project Key with a `-`. This prevents an old Hotfix build from messing up the trend information of your current development. It also helps you configure different baselines for older versions (branches).

When building from the Visual Studio Team Services Build tasks you can configure the branch automatically by including the Build.SourceBranchName variable in your Project Key:


Some background on the values assigned to this variable can be found on the Visual Studio Team Build Variables documention:

Build.SourceBranchName
BUILD_SOURCEBRANCHNAME

The name of the branch the build was queued for.
  • For Git this is the last path segment in the ref. For example inrefs/heads/masterthe name ismaster.
  • For TFVC this will last path segment in the root server path for the workspace. For example in $/teamproject/branch the name is branch

Define a custom Authentication Scheme for your VSTS extension

The standard Authentication Schemed in VSTS include Basic (username/password), Token, Service Credential (for Azure) and AzureCertificate Authentication. If you simply need a username password or a Personal Access token you can derive your own Credential Type from one of the exiting Authentication Schemes.

You can see an example of this technique in my VSTS Extension tasks

{
    "id": "marketplace-service-endpoint",
    "description": "Visual Studio Marketplace",
    "type": "ms.vss-endpoint.service-endpoint-type",
    "targets": [
        "ms.vss-endpoint.endpoint-types"
    ],
    "properties": {
        "name": "marketplace-auth-key",
        "displayName": "Visual Studio Marketplace",
        "url": "https://app.market.visualstudio.com/_apis/gallery",
        "authenticationSchemes": [
            {
                "type": "ms.vss-endpoint.endpoint-auth-scheme-token"
            },
            {
                "type": "ms.vss-endpoint.endpoint-auth-scheme-basic"
            }
        ]
    }
}

But what if you need to extend beyond the basics? There are ways to extend the UI with additional textboxes, as done in some of the other extensions you'll find out on GitHub.

{
    "id": "saucelabs-endpoint-type",
    "description": "Sauce Labs Credentials",
    "type": "ms.vss-endpoint.service-endpoint-type",
    "targets": [ "ms.vss-endpoint.endpoint-types" ],
    "properties": {
      "name": "saucelabs",
      "displayName": "Sauce Labs Credentials",
      "url": "https://saucelabs.com/rest/v1/",
      "inputDescriptors": [],
      "authenticationSchemes": [
        {
         "type": "ms.vss-endpoint.endpoint-auth-scheme-basic",
          "inputDescriptors": [
            {
              "id": "username",
              "name": "Username",
              "description": "Username",
              "inputMode": "textbox",
              "isConfidential": false,
              "validation": { "isRequired": false, "dataType": "string" }
            },
            {
              "id": "password",
              "name": "API Token",
              "description": "API Token Found on your saucelabs account page",
              "inputMode": "textbox",
              "isConfidential": true,
              "validation": { "isRequired": true, "dataType": "string" }
            }
          ]
        }
      ]
    }
  }
} 

NOTE: I've been asked by Microsoft to explain that even though the below code will currently create your custom auth scheme, the product still assumes that the standard list of authentication schemes is fixed. You will run into unforeseen issues until this fully opens up at some point in time.

I'm leaving the below piece for reference, as it's a nice way to understand how the extensibility works and how items are defined, but please do not use it at the moment to create custom auth schemes. While your extension will likely pass all validations, it may cause all kinds of issues for your consumers.

Instead, expand the Basic or Token auth scheme with additional parameters and change the Name/Description to make the UI reflect your needs.

If you want to go beyond that and want to define your own UI with its own fields, the next step is to define your own endpoint-auth-scheme. The documentation on this contributionpoint is still scant, but if you dig into a TFS 2015 update 2 installation you'll find some very useful examples.

Navigate to C:\Program Files\Microsoft Team Foundation Server 14.0\Tools\Deploy\TfsServicingFiles\Extensions to find the standard extensions that define the basic behavior of a standard installation. In there you'll find 4 vsix files



If you dig a little deeper you'll find extension.vsomanifest which contains the Json snippet you're after. The example from the Service Credential is one of the most extensive:

{
    "contributions": [
        {
            "id": "endpoint-auth-scheme-service-principal",
            "description": "Service Principal based endpoint authentication scheme",
            "type": "ms.vss-endpoint.service-endpoint-auth-scheme",
            "targets": [
                "ms.vss-endpoint.endpoint-auth-schemes"
            ],
            "properties": {
                "name": "ServicePrincipal",
                "displayName": "Service Principal Authentication",
                "inputDescriptors": [
                    {
                        "id": "servicePrincipalId",
                        "name": "Service Principal Id",
                        "description": "Client Id for connecting to the endpoint.\nRefer to link on how to create Azure Service Principal.",
                        "inputMode": "textbox",
                        "isConfidential": false,
                        "validation": {
                            "isRequired": true,
                            "dataType": "string"
                        }
                    },
                    {
                        "id": "servicePrincipalKey",
                        "name": "Service Principal Key",
                        "description": "Service Principle Key for connecting to the endpoint.\nRefer to link on how to create Azure Service Principal.",
                        "inputMode": "passwordbox",
                        "isConfidential": true,
                        "validation": {
                            "isRequired": true,
                            "dataType": "string"
                        }
                    },
                    {
                        "id": "tenantId",
                        "name": "Tenant Id",
                        "description": "Tenant Id for connecting to the endpoint.\nRefer to link on how to create Azure Service Principal.",
                        "inputMode": "textbox",
                        "isConfidential": false,
                        "validation": {
                            "isRequired": true,
                            "dataType": "guid"
                        }
                    }
                ]
            }
        }
    ]
}
You'll be able to stick these in your own extension manifests in order to create a full custom endpoint credential type with a complete custom authentication scheme. The sample below can be adapted to do exactly that:

{
    "manifestVersion": 1,
    "id": "jessehouwing-vsts-custom-authscheme",
    "name": "Custom Authscheme",
    "version": "0.0.0",
    "publisher": "jessehouwing",
    "targets": [
        {
            "id": "Microsoft.VisualStudio.Services"
        }
    ],
    "scope": [
    ],
    "description": "Creates a custom auth scheme and matching endpoint definition.",
    "categories": [
        "Integrate"
    ],
    "tags": [
        "Sample"
    ],
    "screenshots": [
    ],
    "content": {
    },
    "links": {
    },
    "branding": {
        "color": "rgb(36, 43, 50)",
        "theme": "dark"
    },
    "icons": {
    },
  "files": [
  ],
  "contributions": [
    {
        "id": "endpoint-auth-scheme-custom",
        "description": "Jesse's custom scheme.",
        "type": "ms.vss-endpoint.service-endpoint-auth-scheme",
        "targets": [
            "ms.vss-endpoint.endpoint-auth-schemes"
        ],
        "properties": {
            "name": "CustomAuthScheme",
            "displayName": "Jesse's Custom Authentication Scheme",
            "inputDescriptors": [
                {
                    "id": "email",
                    "name": "Email",
                    "description": "Email.",
                    "inputMode": "textbox",
                    "isConfidential": false,
                    "validation": {
                        "isRequired": true,
                        "dataType": "string"
                    }
                },
                {
                    "id": "passphrase",
                    "name": "Passphrase",
                    "description": "Passphrase.",
                    "inputMode": "passwordbox",
                    "isConfidential": true,
                    "validation": {
                        "isRequired": true,
                        "dataType": "string"
                    }
                }
            ]
        }
    },
    
    {
      "id": "marketplace-service-endpoint",
      "description": "Visual Studio Marketplace",
      "type": "ms.vss-endpoint.service-endpoint-type",
      "targets": [
          "ms.vss-endpoint.endpoint-types"
      ],
      "properties": {
          "name": "my-custom-scheme",
          "displayName": "Custom Scheme",
          "url": "https://app.market.visualstudio.com/_apis/gallery",
          "authenticationSchemes": [
              {
                  "type": "endpoint-auth-scheme-custom"
              }
          ]
      }
    }
  ]
}

Reference specific line of a file in the Code hub

2016-04-04

One of the features of GitHub I use quite often is the ability to right-click any line number to create a link to that specific file on the exact line. It can eb useful when submitting issues or when providing a link to a piece of sample code.

While not so easy to find in VsTeam, the feature is there. To link to a specific line in the code hub first navigate to the file you want to link to, then copy the current location from the browser and append &line={number}.

That's all!


Access all available build variables from your VSTS Build task

2016-03-09

NOTE: This cmdlet works with the Powershell host that shipped with TFS 2015 RTM and which will be replaced with a new task runner. Whether this functionality will remain, is uncertain.

If you want to know which variables are available during your build, or if you want people to create variables with a specific prefix and want to do anything with that, then you need access to the list of all available variables.

Though it's easy to access a specific variable by name using the Get-Variable cmdlet, it's not so easy to access all variables. Plus, the Get-Variable command only works when you know the full name beforehand.

Using the below function you receive a dictionary with the name and current value of each variable. You can use it to build tasks that use convention over configuration and retrie a list of all variables that start with a prefix you expect:

$MyVariables = (Get-Variables $distributedTaskcontext).Keys | ?{ $_.StartsWith("MyPrefix.") }

Use te cmdlet below to fetch all variables and do with them what you like:

function Get-Variables{
    param
    (
        $distributedTaskContext
        [switch] $safe = $false
    )
    begin
    {
        Write-Debug "Entering: Get-Variables"
        
        $type = [Microsoft.TeamFoundation.DistributedTask.Agent.Interfaces.IServiceManager] 
        $variableService = $type.GetMethod("GetService").MakeGenericMethod([Microsoft.TeamFoundation.DistributedTask.Agent.Interfaces.IVariableService]).Invoke($distributedTaskContext, @())
        $dictionary = New-Object "System.Collections.Generic.Dictionary[string,string]" ([System.StringComparer]::OrdinalIgnoreCase)
    }
    process
    {
        if ($safe.IsPresent)
        {
            $variableService.MergeSafeVariables($dictionary)
        }
        else
        {
            $variableService.MergeVariables($dictionary)
        }
    }
    end
    {
        Write-Debug "Leaving: Get-Variables"
        return $dictionary
    }
}

I used this little snippet to create a new build task which can expand the value of nested variables. You can find it here:

Configure SSL for SonarQube on Windows

2016-02-24

The documentation for SonarQube explains how to configure SSL when you're running on Linux and how to use the native Tomcat functionality for a simple test environment, yet they recommend not to use this functionality in any production like setting.

Instead SonarQube recommends the use of a Reverse Proxy to secure you sonar installation. With the help of IIS and the Url Rewrite module, that's a piece of cake to setup.

What you'll need:

After installing and enabling these features, I had to do an IIS Reset and re-open the IIS Manager for all features to start working.

Next we'll go through the steps to configure the reverse proxy.

Binary promotion of Visual Studio Team Service Extension

2016-02-01

When creating a Visual Studio Team Services extension (such as a collection of build tasks), it makes sense to publish it as a private extension first. You can do this by overwriting the extensionid from the commandline, but there is no direct commandline switch to override the visibility of an extension. I used to patch the extension manifest, but today finally uncovered the correct way of doing it.

It turns out that the TFS cross platform commandline (tfx) has a --override option which you can pass a piece of json to which will override any json in the extension.

So if your standard publish command looks like this:

tfx extension publish --extension-id vsts-tfvc-tasks --publisher jessehouwing --vsix package.vsix

Then the command to publish the private test version would look like this:

tfx extension publish --extension-id vsts-tfvc-tasks-TEST --publisher jessehouwing --override "{""gallerySpecs"": [ ""Private"", ""Preview""], ""public"": false }" --share-with jessehouwing

Instead of passing the json on the commandline, you can also specify an --overridesFile.

Or, on the safer side, make the extension-manifest you commit to your source control repository always do a private preview release, and then use the --override option to merge the real publish settings.

Note: ensure you escape every double quote in the JSON by doubling it up.

Now I can setup a Visual Studio Release Management template to publish the tasks, test against my personal account and then promote that vsix unmodified to the marketplace. But that's for the another blog.

Publish Build Tasks to TFS 2015 without configuring Basic Auth on the server

2016-01-30

When you want to publish build tasks to a TFS 2015 server, you need a Basic Authentication enabled endpoint. Unless your server is configured with SSL, this is a major security concern. Until now the guidance I received was to setup a second Application Tier, configure it with Basic Auth and configure it to only accept traffic from localhost. The sole purpose of that machine is then to upload build tasks and later probably extensions to a TFS 2015 server.

Today I found a neat little trick that removes this need. Fiddler to the rescue!

Start Fiddler and enable it's option to auto-authenticate:

Mimic the XAML build's Output Location option in Build 2015

2016-01-26

If you've been using XAML builds in the past, you've probably discovered that, by default, it drops all the outputs of all your projects into one folder called the Binaries Folder. Unless you do anything using a post-build script, the contents of that folder will be copied verbatim to the drop location.

In TFS 2012 a new option appeared giving you a little more control over the output location; giving you 3 options:
  1. Single Folder (like it worked in 2010)
  2. Per Project (Creates a folder per solution)
  3. As Configured (don't redirect output, so the default would put the binaries under your project folders, as it would on your local machine by default).
If there's one feature of XAML builds which confuses the hell out of people, it's the Output Redirection. At first people don't expect this to happen (they expect As Configured to be the default) and then the naming of "Per Project" confuses people even more, as it turns out that it ends up creating a subfolder for each Solution or msbuild .proj file (based on the solution name).

Build 2015 takes away this issue, by having As Configured to be the default and by offering a simple Copy and Publish Artifacts task which collects the project output and copies it to the staging location. One of the nice advantages of this setup, is that it also makes it easier to do incremental builds, speeding up your CI builds.

But, if you're coming from a XAML build and you already have a lot of existing post-build steps that assume all your files to be in a specific folder or set of folders, it may be easier to replicate that behavior than to rewrite all these scripts.

Let us go through the three options in XAML build and let's see how you'd handle these in Build 2015.

As Configured

This is the default behavior in Build 2015. It does whatever your project files have configured. If you are sing the default project templates of Visual Studio, that means that files are dropped in the "Project\Bin\Configuration" folder.

You'd use a standard Visual Studio Build or MsBuild task followed by a Copy and Publish Artifacts task to recursively gather the output and copy them to the Staging Location and from there to the Drop Location.


The default configuration of the Copy and Publish Build Artifacts task are to scan the $(Build.SourcesDirectory) recursively and grab the contents of every "\bin\" folder.

When you use As Configured in XAML builds, nothing gets copied to your drop folder, unless you actually do that. The Copy and Publish Artifacts task will do this for you. Or you can run your own powershell, batch or other script to copy your files to the $(Build.ArtifactStagingDirectory). Either pass the target location using a argument or grab it from inside your powershell script using the environment variable $env:Build_ArtifactStagingDirectory:

Then call the Publish Build Artifacts task to publish them (note don't want to use the Copy and Publish task here, since your script has already copied the files).


Single Folder

When specifying Single Folder in XAML builds, all the binaries for all your projects will end up in the root of the drop location. This was the default in Team Foundation Server 2010 and caused a lot of confusion when people started adopting Team Build back in the days.

There are two ways to mimic this behavior. One is to build your solution with no additional options and then use the default Copy and Publish task. I assume that you may be building multiple configurations here:


If you want to grab all the folders under bin, you could simplify this further to: **\bin\.

This solution yields the same result, but may still cause issues with your current scripts, which may assume that msbuild redirects all outputs to a single folder. It's not hard to create a situation that's even closer to the old XAML build's functionality.

The first thing you need to do is instruct the Visual Studio Build task to redirect the build output to the $(Build.BinariesDirectory).


Then simply copy everything from under $(Build.BinariesDirectory) to the staging location and publish it:


The advantage of using the intermediate Binaries Directory, is that you can do incremental builds, if you were to build directly to the $(Build.ArtifactStagingDirectory) the output will be thrown away after each build, increasing your build time when you're not using Clean Repository and Clean Build.

Per Project

The third option in the XAML build allows you to create a subfolder for each... and here it gets confusing... Selected solution. It's called "Project", but I think this dates back from the 2008 era when you'd build an MsBuild Proj file. 

There is no easy way to do this in Build 2015. You could use Build Multiplexing or add multiple Visual Studio Build tasks followed by multiple Copy and Publish Build Artifacts tasks. Basically taking the technique from the SingleFolder option and adding in the name of the solution hardcoded in each task or through a custom variable.

Manipulating your TFVC repository from Build 2015

Though generally considered a bad practice I crafted two build tasks to manipulate your TFVC repository from the build. You can now edit, delete and add files and check those changes in when you're ready.

Before I explain how they work and how you can use them, I need to get the following out of the way:

I do not think it's a good idea to change your sources as part of a build.
Unless that's the only thing your build definition does.
In these cases it should not build your sources and produce your shipping artifacts.

The reason why I'm reluctant, is that changing your sources during the build has impact on other features of the Visual Studio Team Services platform. 
  1. As your code is being built, certain artifacts are generated, such as your debug symbols, test results, code coverage etc. And these artifacts are associated with the Changeset number of the build. This may break or cause problems with Remote debugging, Source Server support, Intellitrace and Test Impact Analysis among other features. Other tools that may be impacted are obfuscators.
  2. Since your scripts change files, features such as Incremental builds won't work. They'll always have to rebuild the projects, since there are always modified files. This is especially so when you use tasks to patch the AssemblyVersion attribute. This will slow down your builds slow down the feedback cycle as a result.

Building multiple configurations and/or platforms in Build 2015

2016-01-11

In XAML builds you could specify one or more configurations to build, if you left these values empty, the solution default would be built. Unless you were using a customized build template, each build|configuration pair would be built and tested in sequence.


The Build Agent will create a sub-folder for each Platform|Configuration if you specify multiple values.

In Build 2015, you can also build multiple configurations and/or platforms. And what's pretty cool, if you have multiple build agents available, you can build and test these in parallel. If you have a single agent, or are using the Hosted build with the standard build minutes, it will build all combinations in sequence.

Upgrading from XAML to Build 2015 with minimal changes

2016-01-10

This series is currently a work in progress

XAML builds on Visual Studio Team Services will be deprecated in September 2016. While support for XAML builds seems to stay around on-premise for a little while longer, it's time to upgrade to Build 2015.

You may have invested quite a bit in the XAML build system in the past, but as long as your changes have been mostly limited to custom MsBuild tasks and targets, Powershell or batch scripts, then upgrading to Build 2015 is (almost) a piece of cake.

In this series I'll go through the basic settings in the XAML Default Template and I'll explain how to transfer each setting over to the new system. There are still a few things which are not possible in the new system, such as configuring Gated Checkins for TFVC, but almost every other setting can be converted over.

Before going over each setting, I'll assume that you've installed at least one build agent, or are using Visual Studio Team Services with the Hosted Build option.
Other tips and tricks

Access multiple TFVC repositories in a Build 2015 definition

2016-01-08

When you have a TFS project collection with many Team Projects, it's a common practice to have a "shared" project containing a collection of commonly used libraries. This library may consist of Checkin policies, Build Activities, MsBuild tasks and Custom MsBuild targets. The alternative used to be to check in these files with each team project, running the risk of them getting fragmented quickly, leaving you in a situation that is very hard to maintain.



Nowadays I'd opt to put most of these dependencies in a vsix or in nuget package and distribute them using a custom gallery or the upcoming Package Management features in Visual Studio Team Services. 3rd party solutions like ProGet and MyGet can also fill in this demand.

Unfortunately, when migrating from one system to another, you don't get the option to change the whole solution structure or the way 3rd party dependencies are retrieved all at once, so you may need to mimic the old "shared repository" pattern when migrating build from XAML over to Build 2015.


Add additional fields to "Edit Test Case using Grid" option in VS Team Services

2016-01-01

If you're bulk-creating, importing or editing test cases in Visual Studio Team Services, you're probably aware of the "Edit as Grid" option, which opens your test case in a spreadsheet like layout for bulk editing:

Not many people know that you can extend this grid easily to bulk-edit additional fields, like Area Path, Assigned To or any other field which exists on the Test Case work item.
 

Search This Blog

Loading...

Most Reading

Archives