Since we launched Team Foundation Server 2012, I’ve been seeing a lot of questions regarding Eclipse and the Team Foundation Server plug-in that range from general configuration to licensing and I thought I’d take some time to get a post up to for clarification. Let me go over the licensing model and then you can continue through the article for the set-up guide.

We formally contacted Microsoft to get clarification on licensing and here’s what we’ve discovered and understood. In a typical in-house environment, in order to use Team Explorer Everywhere, you would need a client access license but in a hosted environment, you need a subscriber access license which is included for every user license that we offer as a services provider. Simply put: Feel free to use Team Explorer Everywhere against our servers without worrying about the licensing.

Now, just to make sure that everything’s covered, I’ll be going over a step-by-step guide on installing and configuring Eclipse on a Windows 7 workstation and for this example, you’ll need to download or install the following:

* Java SE Runtime Environment
* Eclipse Classic

I’d also recommend reviewing the requirements list at MSDN for the Team Foundation Server Plug-in for Eclipse before proceeding.

Let’s go over all of the steps.

1. If it’s not already available on your system, install the Java runtime.

2. Next, extract Eclipse Classic.

3. Launch Eclipse and then go to: Help > Install New Software…

4. From the Install window, click the Add… button.

5. Now, from the Add Repository window, supply the following values and then click the OK button:

* Name: TFS Plug-In
* Location: http://dl.microsoft.com/eclipse/tfs

6. Make sure that the resource that was just added is select in the Work with drop-down menu, check the Team Foundation Server Plug-in for Eclipse and then click the Next button.

7. Review the items that will be installed and then click the Next button.

8. When you reach the licensing terms, click the Finish button.

9. You should be prompted to restart Eclipse, click Yes.

10. Once Eclipse opens, go to: Windows > Open Perspective > Other…

11. At the Open Perspective window, select Team Foundation Server Exploring and click the OK button to proceed.

12. You’ll see the Team Explorer window available and then click on Connect to Team Foundation Server.

13. You’ll see another license agreement, make sure that you check I have read and accept the terms in the License Agreement and then click the Next button to continue.

14. Click the Add… button from the Add/Remove Team Foundation Server menu.

15. You’ll be taken to the Add Existing Team Project window where you’ll want to click the Servers… button.

16. In the Name or URL of Team Foundation Server field, use: https://tfs05.discountasp.net:443/tfs/ and click the OK button.

17. You’ll be prompted to authenticate and you can use your server credentials.

18. When you return to the Add/Remove Team Foundation Server window, the server should be available and you can click the Close button.

19. Next, at the Add Existing Team Project window, select your Team Project Collection, the Team Projects that you want to connect to and then click Next.

20. At the TFS Workspace step, you can choose to use an existing workspace or create a new one. To avoid any conflicts, I’ll go ahead and click the Add… button to create a new workspace.

21. I’ve created a new workspace called JoeEclipse — you can use any name that you’d like — and then click the Finish button.

22. That’s it! You should be connected and ready to go.

One of the key highlights of Team Foundation Server 2012 is an improved experience when you’re working offline and you would have to wonder: If it’s mentioned as a key feature, how bad was working offline previously?

If you’ve avoid opening a solution under source control in offline mode, you’re extremely fortunate. But for those that have to experience it with Team Foundation Server 2010, you might hear that it’s easier to call it a day than continue working.

Before going further, it’s important to discuss and understand what’s allowed the improvement: the local workspace. A workspace is a critical feature of Team Foundation Server since it’s what allows the differentiation between the changes that have been made against the data stored on the server and your working copy of files.

Prior to Team Foundation Server 2012, the only type of workspace that was available was a server-side workspace which has drawn plenty of criticism since an active connection to a TFS server was essentially required so that synchronization could occur. While the ability to make changes to files was available, it was an extremely tedious and cumbersome process.

The local workspace was introduced with Team Foundation Server 2012 as the default workspace type and it follows the Edit-Merge-Commit system – any changes that are made are noted and then synchronized with the TFS server at check-in.

There are some advantages and disadvantages between the workspace types so you may want to determine how a workspace will be used against a particular project.

Server workspaces have the following advantages and disadvantages:

Advantages:

• Ideal for a large number of files. According to a post made by Buck Hodges, you may want to consider using a server workspace if there are more than 50,000 files involved.
• Compatible with previous versions of Visual Studio. While users go forward with the transition to Team Foundation Server 2012, it’s highly probable that some users will need to continue using Visual Studio 2010 and if this is a case that might occur in your environment, you may want to continue using server workspaces if a workspace needs to be shared.
• Exclusive locks are observed (provided that the asynchronous check-out feature is not enabled).

Disadvantages:

• All local copies of files are set to read-only. If a solution is opened offline, you’ll be prompted to overwrite changes every time.
• In offline mode, core abilities such as adding, deleting, renaming or undoing changes to a file are not available.

Local workspaces have the following advantages and disadvantages:

Advantages:

• Local files are not set to read-only and changes can be made.
• All normal functionality is available. For example, you can create a new file and it would be recorded as a pending change.
• If a change is made to a file outside of Visual Studio, it will be detected.

Disadvantages:

• Exclusive check-out locks are not enforced.
• A high number of files may result in performance degradation.

The default setting for a workspace is set to local but if you need to alter an existing workspace or create a new workspace, you’ll find the option under the “Add Workspaces” window.

To get an idea of what using a server workspace is like in offline mode, let’s take a quick walkthrough.

Server Workspace

1.    To make sure that there was no connectivity to a server, I used the most effective method of guaranteeing no connection – I unplugged the network cable. After verifying that no network connectivity was available, I opened an available solution in offline mode.

2.    In a sample application that I had available, I updated two files, About.vbhtml and Index.vbhtml and then saved my changes. Here’s what you’ll see every time a file is saved.

3.    I decided to add a new file.

4.    To simulate a restored connection to the server, I just plugged the network cable back in and attempted to go online.

Note: The file that was added is not detected as a change.

5.    The new file will need to be manually added to source control and then checked-in.

Local Workspace

1.    For working offline with a local workspace, I used the same high tech method that I used for the server workspace and opened the solution in offline mode. Here’s what the Solution Explorer window looks like:

2.    I opened and updated the Web.config file and then saved. I was not prompted to overwrite an existing file that was set to read-only and the change was noted immediately:

I continued working and just made a simple change to the Index.vbhtml file.

3.    I reconnected the cable and went online. All of the changes that I had made were recorded as pending changes.

4.    I recreated the disconnected environment, added a new file and then went back online. Unlike the server workspace, the change was detected:

While not everyone may find themselves in a situation where working offline is required, the introduction of the local workspace is a much appreciated and welcomed enhancement.

When we launched our hosted Team Foundation Server 2010 Build service, an active outbound Internet connection was not available. But after receiving many requests, we made plans to perform an infrastructure-related update that would accommodate the needs of our customers. We have been working tirelessly behind the scenes and I’m happy to announce that the project has been completed – you can now connect to an outside system!

As a showcase, I thought I’d do a small write up on deploying directly from one of our TFS Build servers to a server in our web hosting environment so let’s go over the steps that you’ll need to perform.

1. Use the Team Foundation Server Hosting Support Portal and open a request with the technical support team to get Web Deploy 2.0 installed on your TFS Build server.

2. After we’ve completed the installation, access the IIS Tools utility in your DiscountASP.NET Control Panel (web hosting) and make sure that the version of the .NET Framework is selected.

3. You can use an existing Team Project but for this article, we’ll use a C# Web Application.

4. After you’ve created the Web Application Project, connect to your Team Foundation Server 2010 server. If you’re a new user, follow the steps available in the DiscountASP.NET TFS Knowledge Base for configuration instructions.

5. Create a new Team Project. In the event that you need a reference, use the steps in our Create a new Team Project using Visual Studio 2010 article.

6. Add the Visual Studio project that you’ve created to source control. For help with this particular step, you can start from step number five in our Getting Started with Team Foundation Server guide.

7. You can modify an existing Build Definition or you can use the steps in the How to create a Build Definition article to create a new Build Definition and when you reach the Process step, click on Advanced and locate MSBuild Arguments.

8. In order to proceed, you’ll need your web server information which can be found on the Account Information page. You’ll need to prepare the following line and then add it to the MSBuild Arguments:

/p:DeployOnBuild=True /p:DeployTarget=MsDeployPublish /p:CreatePackageOnPublish=True /p:DeployIisAppPath=”HostedDomainName/myapp” /p:MsDeployServiceUrl=WebServerName.discountasp.net:8172/MsDeploy.axd /p:username=AccountUserName /p:password=AccountPassword /p:AllowUntrustedCertificate=True

9. Add the information to the TFS Build Definition, save the changes and then execute a build.

10. Once the build has completed, access the deployed application.

While the example that was provided targeted a hosted site specifically, you are not limited to just the DiscountASP.NET servers, you can deploy to any system that’s been configured to receive connections.

If there are any technical questions you might have, feel free to contact the support team.