Team Project rename: is it that easy?

Renaming a Team Project was the most asked feature for Team Foundation Server since 2005, with over six thousands votes on it. Microsoft finally delivered that feature in April, in Visual Studio Online first and then in Team Foundation Server 2015.

Why did it take so long?

Team Foundation Server relies on a set of SQL Server databases, with a quite…complex schema. It wasn’t just about detecting a certain name and replacing it, it is all about GUIDs and the likes. A lot of work was done on the architecture, and more of it client-side.

Client-side? Yes.

When you rename a Team Project in either Visual Studio Online or Team Foundation Server, what happens among the operations is that also you are also creating a redirect from the old Team Project to the same, renamed one.

Take a look:

this Foo Team Project has some work in it:

a query with an explicit value in it (Foo instead of the @Project macro):

and of course some code.

You can then rename it:

and what you’ll need to do is to care about code mappings (workspaces or remotes, this would be best handled by a client update – 2015, 2013.5 or 2012.5). Code is migrated, Builds are migrated, and all the Work Item Tracking migration is completely effortless.

So you say yes, and the Team Project is renamed. Teams with ‘Foo’ in their name are migrated too:

Areas and iterations are migrated too, as expected:

Even the explicit query is migrated!

So what happens if you go straight to Foo?

This:

 

This doesn’t mean you are going to lose the possibility of using the former name – if you will reuse it, you would just lose the URL redirect but all the renamed artefacts would be kept as-is..

There are a couple of things you need to manually address after this. As mentioned above, you need to sort out the Workspaces or the Git Remotes, depending on the Version Control System you are using.

If you are using a BDT Build Definition with Lab Management, you need to refresh the Build Definition by running the wizard again so it can be properly linked again with the right Team Project. This is actually a workaround which will be solved by the new TFS 2015 Legacy Build Controller, but if you need to use older Controllers that’s how to sort it out.

On-premises, run a ProcessWarehouse job and a ProcessAnalysisDatabase job as soon as possible, so you will avoid any stale data in SSRS and the Excel Services in SharePoint would be already updated with the current names. The jobs would run anyway in the time interval you set, but this will avoid any temporary inconsistency in the reporting data.

Eventually, clear the SharePoint cache and run a SharePoint timer job so the Excel Services are up and running on the right values.

TFS and HTTP status 417

Panic today – a guy couldn’t connect to Team Foundation Server with a weird “The request failed with HTTP status 417: Expectation failed.”

What did it happen? I never saw such a HTTP status code!

A bit of investigation explained the reason for it – the proxy he is using doesn’t support the expect100Continue behaviour, dropping the connection.

The guy used a proxy server indeed and he did not check the “Bypass proxy server for local addresses” checkbox. After checking that, he was able to connect to Team Foundation Server like everybody else.

It is also worth mentioning that this can impact also components like the Extension Manager, and you can bypass that setting by adding a node in the devenv.exe.config file - <servicePointManager expect100Continue="false"/>

How to configure SCVMM-based Lab Management for selected Team Projects

Not all the Team Projects we have in the company might need to get Lab Management, and we pretty much know about the need of locking down certain resources.

So if you want to enable SCVMM-based Lab Management you need to configure the Library Share and the Host Group on a case-by-case basis instead of dropping them all in, by un-checking the Auto-Provisioning checkbox here:

Then you need to run TFSLabConfig TPLibraryShare /add and TPHostGroup /add to enable the single Team Project.

How easy is to use a Symbol Server with Team Build vNext?

Answer: it is extremely easy!

A Symbol Server is a very important piece of infrastructure every development team should have. It enables someone debugging (with the aid of an IntelliTrace file for example) problems happened in production, relating them with the right version of the code deployed.

To use a Symbol Server with the new Team Build, you need to have a local build machine, and a file share. That’s it.

Download the agent, and expand it in a folder – say C:\agent:

 

Once done, launch ConfigureAgent.ps1

 

A command line wizard will start. Most of the times you only need to enter the relevant Visual Studio Online account or Team Foundation Server URL. If you want to run it as a service the default would be with LOCAL SERVICE, but you can obviously use whatever account you need.

Now you have a Build Agent on the Default Pool:

 

Create a build, and you will have the Index Sources & Publish Symbols activity already part of it. Then you only need to enter the file share you want to use for the Symbols Server, and launch a new Build.

  

What is this all about? If you browse the file share you will have all your PDBs indexed.

 

Then you can hook it to Visual Studio, so whenever you open an IntelliTrace file, or whatever other dump you can get from a production crash, it will point to the right version referred in the source of the crash itself.