Changing URL of Team Foundation Server 2010 Projects

If you want to change the URL of your projects in Team Foundation Server, sometimes it’s as straightforward as changing one URL in a dialog box.  However, good luck with that.  Probably there will be network, software configuration and work-flow after effects you need to deal with, and I thought I’d put them all in one place to make it easier for others trying to change their project URL’s.

Here is a summary of what you may have to do, and these steps are covered in this post:

1. Change default URL in TFS administrative control panel
2. Add new registry entry to allow default machine name to be different from URL
3. Change TFS web config file to include your new URL
4. Add new project location URL in Visual Studio
5. Unbind solution from source control that points to old URL
6. Bind solution to source control that points to new URL

This first blog post is helpful in that the author will also deal with what has to happen if  TFS is linked to SharePoint.  If simply changing the name does’t work completely further on down in interactive posts, there is a reference to changing your registry.  You’ll need to add a DWORD to HKLM\System\CurrentControlSet\Control\Lsa and call it DisableLoopbackCheck as you can see in the screen shot below.

For me, this was only part of the solution.  The other was that I had to edit the web.config file of TFS to allow me to use the new url.  Here is the link to that post.

So, after changing the URL in the TFS control panel, changing the registry and reconfiguring the TFS web site web.config file I was able to access TFS from my new URL both inside and outside of my network.

One additional issue remains.  That is in Visual Studio, your project is bound to the old location and now you’ll not only have to bind your project to your new location, but you’ll have to remove all source code bindings from the old location and change them to the new location.

To add a new TFS location, go to Connect to Team Project and then click on the Servers… button.  Then Click on add, and enter in the name of your new URL as shown below.  The old name was MMANT4, and the new name is tfs.maltercorp.com:

Connect to new TFS

To remove source control bindings from the old URL, you access that through File/Source Control.  The menu items will be different given what Visual Studio detects.  I opened my project and because it had source control bindings pointing to a different location, I got a dialog box that told me it was going to open in disconnected mode.

When you do that and then open Source Control through the File menu, you’ll see choices to unbind which I did.  Then I went back in to File/Source Control and clicked on bind to source control.  I clicked through the error messages using the ignore button.  All history is retained.

I did not test this in a multi-participant team environment, so I don’t know what will happen if you have other developers.  I suspect that they will have to unbind and bind back to source control as well as bind to a new TFS server location.  I’m sure if there are a number of developers, this will require some coordination on your part.

If I had TFS to set up all over again, I would look into what it would take to create it with a URL that is useful to outside users.

None of this was hard to do, but there was a lot of stuff in many different places, and I thought putting it all together on one place would be useful.

Breaking out of HTTP.SYS hell

I am working on using SSL with WCF and when it came time for me to add a service reference for my project I kept getting the following error: “This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case.”

I was able to access my SVC file in a browser using the new domain certificate I had created for the service website.  The certificate was issued by our domain certificate authority.   I was also able to access the WSDL file as well with no problems.

SecureService Service SVC File

So, why was I getting an error when trying to create a service reference?  Because the web site’s http binding did not have a host header.  To add a host header to your website, open IIS Manager and click on the web site you want to configure.

IIS Manager

Next, click on the bindings link to open the Site Bindings dialog box.  Find the http type, click on it and then click on the edit button on the right to open the Edit Site Binding dialog box.

Site Bindings Dialog Box

In the Host name edit control, enter the friendly name you used when creating the certificate.  Don’t enter http or https.  Click ok.  Click Close to close the Site Bindings dialog box.

Edit Site Binding

Now go back to your client and click on Service References and right click to get the popup menu and then click on Add Service Reference.  In the Address: edit control enter the URL of your service, and in the Namespace enter in the name you want for your service reference and then click go.

Add Service Reference

You should get a windows login dialog box.  Provide your login credentials and click on and you now have your service reference.

I don’t have a lot of experience with host headers other than having to use them when you only have a single IP address and want multiple web sites (not virtual websites, but top level websites) to share it.  When given a choice,  I opt for adding multiple IP’s on a NIC and then every website gets a separate IP Address and separate DNS address.

However, I guess now there are other reasons for using host headers, and breaking out of HTTP.SYS hell is one of them.

Security Exception when using AJAX Control Toolkit on Server 2008

I am using the AJAX Control Toolkit for its tab UI and my compile and link cycles came and went without incident on my Vista development machine.  However when I deployed to our integrated unit test environment on Server 2008, I got the following error when accessing the page with tabs:

System.Security.SecurityException: Request for the permission of type ‘System.Web.AspNetHostingPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089’ failed.  Here is a screen shot for reference.

I did a lot of checking and I found articles that involved accessing the AJAX Control Toolkit on a different machine, but that was not my issue.  After publishing via Visual Studio to our server, all dll’s were in their normal folders.

The solution was to change one of the defaults on the application pool for this website.  The value is under the Process Model section in Advanced Settings and is Load User Profile.  By default it is set to false which will emulate IIS6 behavior of not loading the user profile for the application pool identity.  Setting it to true solved the problem.

That was it. Make sure you recycle your application pool and restart your web site.