Everything you want to know about Visual Studio ALM and Farming
Brian Harry is a Microsoft Technical Fellow working as the Product Unit Manager for Team Foundation Server. Learn more about Brian.
More videos »
We strive to ensure that developers working with Team Foundation Server in the Eclipse and cross platform worlds enjoy as great an experience as their counterparts enjoy in Visual Studio. We also want to keep Team Explorer Everywhere up to date with the latest versions of Eclipse. Six months ago we shipped Team Explorer Everywhere 2010 on the same day as Team Foundation Server 2010. In the past six months the team has been hard at work on an update that will address many of the remaining gaps.
Today, we released a Beta that you can find here: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=4449babd-1dc8-40e3-9e27-2b743a4a173c&displaylang=en
This Beta release comes with a “go-live” license and we use it in our development everyday. I hope that you will feel comfortable doing the same. As this is a service pack, it will be available to all Team Explorer Everywhere owners at no additional charge. This release will continue to work against any released version of TFS – 2005, 2008 or 2010.
Installing it is easy and uses the standard approach to installing Eclipse plug-ins. You’ll find the installation instructions here: http://download.microsoft.com/download/8/B/1/8B11ABAC-0957-44BB-BA7C-80DCD882D481/InstallTEE.htm
Please provide us any feedback you have. You can use the forum at http://social.msdn.microsoft.com/Forums/en-US/tee/threads and we will try to respond promptly.
It’s fitting that we are releasing this on the first anniversary of the Teamprise development team joining Microsoft. Please join me in congratulating them on the work they’ve done to produce two great releases in one year!
Here’s a summary of the improvements in this release:
The initial Team Explorer Everywhere release was pretty good at globalization – the current plug-in will sort and displays dates etc in the users locale and handle a localized version of Team Foundation Server. But all the UI strings were hard coded in English. After shipping the initial release, a major engineering effort was undertaken to correctly externalize all these strings and prepare the product so that it can be translated into other languages. This is done using the add-in language pack model used for many Eclipse projects. After we’ve shipped the beta release we will work on a Japanese language pack and make that available before the end of the year. After we ship the final release of SP1 we will make available Japanese, French and German language packs. Depending on interest we may look at translating to other languages over time. The model used also supports community created language packs if there is demand for them.
We had Gated check-in for the RTM release but it was more like the experience that we give to developers using Visual Studio 2008 with a 2010 server. The new release will give the Eclipse developer the same rich experience as Visual Studio 2010 developers get today. When you check-in code affected by a gated build definition you get a prompt as to what you would like to do
Assuming you request a gated build, the changes will be shelved and a build submitted on your behalf. When the build completes you will be notified right inside of Eclipse.
However – we haven’t forgotten folks using the cross-platform command line client. There we have a new “reconcile” command (only available in the cross-platform version of tf) that will allow you to check on the status of your gated build from your terminal window and reconcile your workspace with any changes checked-in on your behalf from the build server.
Combined with the Build Extensions Power Tool that was also recently updated, we have a very powerful build solution for your Java developers. The team have been using gated check-ins with the build extensions to build Team Explorer Everywhere for a number of months now and are very happy with how it works for them.
Alongside Gated Check-in we did the work to enable private builds from Eclipse. Again, this works in the same way as in Visual Studio 2010. If you want to perform a build on the build server then you can manually queue a build passing in a shelveset. That way you can validate your changes work on the build server before checking them in.
We also took the opportunity to catch up on some of the improvements that we’d made to build explorer in Visual Studio 2010. You now have icons showing you the type of build that you have submitted and you are more easily able to find builds belonging to you.
In the new process templates that ship with TFS 2010 we make more use of HTML fields to provide a rich text field to enter information about that work item. These are used extensively by the Microsoft Test Manager tool to help a tester create a bug with a nicely formatted repro steps. The problem was that Team Explorer Everywhere didn’t have a nice way to edit these fields as we did in Visual Studio. Eclipse 3.5 and above gives us better support for embedding a web browser control inside of an Eclipse dialog cross-platform and so we made use of this in the beta release to provide a rich HTML editing control inside the work item. For developers using older versions of Eclipse we fall back to the HTML editing control that we shipped in original version.
In previous versions of Team Explorer Everywhere if you are on a non-windows machine that is not joined to your Windows domain using Kerberos then you had the option of storing your TFS credentials in a file managed by Team Explorer Everywhere in your local profile. The problem is that the password was stored in plain-text – and just relied on your file permissions to keep this data secure. In the beta release we will make use of the keychain on Apple or the Key Ring on Gnome systems to store these credentials in a more secure manner. That said if people are really concerned then we still support the ability to log-in via single-sign-on or not store your password at all and just be prompted when you need to log-in.
We’ve had custom control support for work items in Visual Studio since day one. Over time we also introduced the ability to create a custom control for web access users. In the RTM release of Team Explorer Everywhere we included some code to help with custom work item controls with the plan being that we’d create some examples out-of-band. However, once we started looking at these examples we realized that the experience was less than ideal so we introduced some fixes in SP1 to improve the experience. After the beta is released the team will publish more details on how to create custom controls for Eclipse. It will be a third control implementation – this time in Java – so we will be looking for feedback as to how useful this is for you.
The Eclipse plug-in has several features to help in ignoring files from the local file system from version control by the use of a special file called “.tpignore” that is checked in at the project root. This is especially useful for Maven developers, but others teams sometimes need to use it as well. For more information on the mechanisms available for ignoring files check out this post (http://blogs.msdn.com/b/tfsxp/archive/2010/05/04/excluding-eclipse-project-resources-from-version-control.aspx) over on the Team Explorer Everywhere team blog. We heard some feedback in the forums that this file wasn’t easy to use so we’ve added some UI for it in Eclipse to make it easier to ignore files and folders straight from the Team context menu in Eclipse.
In previous version of the Eclipse plug-in you were required to use an external tool to resolve merge conflicts. We’ve fixed this to properly support the internal merge tool if available in Eclipse including support for 3-way merging. You can still use external merge tools if you prefer, but at you have more choice now.
Eclipse developers commonly make use of the Synchronize perspective when comparing their local workspace with the server version. For tools like Subversion or CVS that work in an offline model this is an essential part of the developer workflow. We’ve been proud to support Synchronize in Eclipse not only because it is an Eclipse specific feature (the closest we have in Visual Studio is folder compare), but also because Synchronize support is one of the features that is often ignored by other tool vendors less committed to Eclipse as a fully supported platform for developers. In the beta release we improved the label decorating of files in Synchronize making it easier to determine what the changes are that you are looking at. We also make use of new server functionality in TFS 2010 to improve the performance of Synchronize.
We use shelving and unshelving extensively as part of our own internal use of Team Foundation Server. A shelveset is the primary mechanism that we use for code reviews for example, and we do these before every check-in. The team came up with a subtle improvement to the shelve and unshelve dialogs to help you re-use data in these controls. For example, if you unshelve a shelveset from a colleague then you will find their user-id in a drop down of recently used id’s next time you search for the shelveset. Similarly if you regularly shelve with the same name (i.e. “In Progress”) then you will find this getting autocompleted for you as you type. It’s just a small change but an example of one that we are trying in Eclipse first to see what people think.
To keep support for the latest versions of Eclipse and to ensure we are picking up all the security fixes in the latest versions of Java we’ve had to drop support for Eclipse 3.0 and Eclipse 3.1 in this release, along with support for running Eclipse under a 1.4 Java JRE. You can still obviously develop applications in Eclipse that target a 1.4 runtime just that you need Java 5 or higher to run your instance of Eclipse. All the discussions we had with customers suggest that this isn’t going to be an issue as over 90% of them use the latest version of Java on the desktop to ensure they are getting security updates – but if you will be adversely affected by this then please let us know.
Feature parity wise, probably the biggest thing missing that we’d like to see in the Eclipse integration is the branch visualization feature that we have in Visual Studio 2010. While we’d love to have this in Eclipse, we found when we spoke with customers that the branch/merge work was not the highest priority of the things we needed to go fix. We do want to bring this to Eclipse in a future release.
As you can hopefully tell from this, we are continuing our investments for our Eclipse and cross-platform developers and plan to keep doing so.
After this SP1 release we will focus the team on supporting all the new features we are planning for our next version of Team Foundation Server. It’s still too early to talk about those, but expect in the next few months I’ll start giving some glimpses of the direction we are headed :-) It’s a safe bet that your Eclipse and Cross-platform developers will have access to new versions of Team Foundation Server just as soon as your Visual Studio developers do. We remain committed to making Eclipse and cross platform developers first class members in teams using Team Foundation Server.