Feb 192013
 

Recently, I had to authenticate to Team Foundation Server using an account with greater permissions to perform some administrative tasks.  As you may know, this requires entering alternate credentials when you add the server to the list of TFS servers, or when you need to connect to the server.  Once you’ve connected once, you aren’t prompted again as the credentials are cached locally.

In the past, to remedy this, you could simply delete the local TFS cache, which is located in the following directory (Windows Vista and onwards):

<system drive>\Users\<your profile>\AppData\Microsoft\Team Foundation

image

However, in more recent versions this has changed somewhat, and the user’s credentials are no longer linked to the local TFS cache or configuration.

Where are the Credentials?

Good question.  After some digging about, it seems that the credentials are now stored in the user’s Credential Manager store within Windows.  If you aren’t familiar with this, it was introduced on the more recent versions of Windows, and it lives via the Control Panel, under the following path: Control Panel->User Accounts

image

Inside this location, you can view all the locally cached credentials, including Windows Credentials:

image

Note: that it appears that for TFS credentials used by Team Explorer and other applications, the credentials are the ones under “Generic Credentials” not under “Windows Credentials” (in case you have TFS entries in both).

Making Changes

To modify or remove the credentials you use to connect to TFS, simply expand the appropriate entry and click on “Edit”, or to delete the local credentials, click on “Remove”.  If you opt to remove the credentials, you’ll be prompted to enter new credentials next time you connect to the specified TFS server.

image

 

So that was a little out of the way. When I tested this, I made sure that I’d disconnected from TFS before changing/removing the credential configuration.

It would be nice if Team Explorer linked to the Credentials Manager so we didn’t have to go digging to work this out, wouldn’t it?

Jul 182012
 

The series so far:

Part 1 – Setting up TFS Azure
Part 2 – Configuring Visual Studio to use TFS Azure
Part 3 – Registering Team Build controllers for TFS Azure
Part 4 – Builds in the Cloud (this article)

Introduction

Following on from an earlier series of articles on TFS Azure comes this update.  Recently, Microsoft integrated cloud-based build controllers to streamline the process of getting your automated builds online.

This is an excellent alternative to having to procure and configure your own on-premise build machine, and means that you can create basic build definitions with little overhead.

Where we left off..

In the previous article, we had configured an on-premise build server which hosted and performed local build services for our TFSPreview TFS instance.  This was the only option in the initial release of TFS Azure as there were no cloud based build services available.

New Capability

I recently created a new TFS Team Project to allow some collaboration.  I’d been in discussions last month with local Microsoft TFS expert Grant Halliday, he’d mentioned that there was now a cloud-based build controller option available.

Today I uploaded a very basic solution comprising of a console application and a Unit Test project.  Adding the cloud-based CI capability was easy as pie.

Configuring Your Cloud Build Controller

Simplicity itself. 

1. Once you have a valid solution in source control, simply right click on the Builds item in your Team Explorer and select “New Build Definition”:

image

2. Give your new build a name:

image

3. Configure the build trigger (notice all the regular options exist):

image

4. Next, set the build workspace(s) as per normal:

image

5. This is where it gets interesting.  You configure the build defaults, but there are some interesting options when using the cloud-hosted build controller:

image

Note that “Hosted Build Controller” is in the list of controllers available.  There is also an option which checks build output into source control (no need for a build share!)

6. There are also much the same options for the build process as you’d expect with an on-premise controller – and you can add your own build definitions as per normal.  Note that there is a new definition here also – “AzureContinuousDeployment” which we might touch on in another article.

image 
:

7. Once you’ve set your retention policy, you are good to go.

image

Executing a build

Treat it like any other build controller/build host!  You can manually execute or (if you’ve configured gated check-ins or CI build definitions) just make some changes and commit.

image

You can even watch the building process in real-time, just like a non-Cloud-hosted build controller:

image 

Summary

Couldn’t be easier!  Obviously, if your build process or solution require any special steps you may hit a wall with the hosted build controller.  This capability though, might be useful for selected branches of a large solution in which you wished to place gated check-ins/continuous integration, where the output is unit testing + classes.

All I can say is – this is a step in the right direction.

Jun 022012
 

Introduction

Following on from the previous article, where I installed the Visual Studio 11 Release Candidate on a Windows 8 Release Candidate, I’m now going to step through the process to set up a complimentary ALM capability – Team Foundation Server 2012 (Release Candidate).

As per the previous article, links to the downloads for all products mentioned are listed in the following article.

Preparation

I’ve installed a copy of the Windows Server 2012 (Datacenter) Release Candidate as the host for my TFS installation.  This configuration will not support SharePoint Foundation 2010 – so this is not a recommended configuration if you want to use Team Projects/Team Sites.

As I was preparing to install TFS, I copied the .ISO files across from my SAN, and noticed something interesting on Windows Server 2012 RC – the file copy dialog reveals a lot more information on the progress of the file copy operation:

file-copy

Once you have mounted and run the initial TFS 2012 RC installer, there is an initial configuration of the base setup files, followed by the TFS configuration screen.

initial-screen install-screen

The initial option is to display the “Standard Single Server” configuration option:

config-choice

Pre-installation

I’ve pre-installed SQL Server (so I can add reporting services later), but I’m going to use the “Basic” TFS configuration, since I won’t have SharePoint configured.  If you also want to pre-install SQL Server, the configuration you are likely will require is per the below screenshot:

sql

Once again, it is always a good idea to familiarise yourself with the TFS prerequisites which can be found in the TFS install guide which is found in the root of the TFS disc.

The Basic Configuration

Anyhow, continuing onwards – as I mentioned earlier, I’m picking the “Basic” configuration (I’ll do a series of articles on setting up a complete solution once Team Foundation Server 2012 goes RTM).

config-choice-basic

This leaves us with very few things to configure.  Literally, all I need to do is decide whether I’ll let the installer use SQL Server Express, or to point at an existing SQL Server instance.

basic-config

The configuration is verified, and once you hit the “configure” button, the configuration is executed:

installing verifysuccess

Finished!

When the configuration is complete, you should be able to connect to TFS from Visual Studio 11 directly (no need to install Team Explorer separately!).  In my case, I connected as an Administrator, but you would obviously want to create some users and groups.

connectconnected

In the next article

Now that we have Visual Studio 2012 connected to TFS 2012, we can create a Team Project and begin a project!  I’ll go back and establish Reporting capabilities in a later article.