Visual Studio Team Explorer Everywhere For Team Foundation Server 2010

0 views

Skip to first unread message

Message has been deleted

Fay Vitiello

unread,

Jul 17, 2024, 11:17:39 PM7/17/24

to teohetracu

As a response to Joe Ferner's post on why he dislikes TFS. I'll first touch upon the items brought forward by Joe. Some of them are just true, and I won't put too much effort in those, but some I just don't agree with.

visual studio team explorer everywhere for team foundation server 2010

Descargar archivo https://vbooc.com/2yPnr1

CodePlex -- First there was the SVN bridge (yes, someone hated TFS enough to make a product to make it look like something else) then Microsoft just caved and supported SVN directly. Not really a problem with TFS, it's just an indication that others feel the same way as I do.

And now they're adding GIT support as well. Not because they hate TFS as much, but because they want as many people to use their open source sharing tool for sharing Microsoft/.NET related projects. For many enterprise users the ability to use TFS is great, they use it in their daily job and it's their tool of choice. For me that is the case as well.

Others, who aren't using TFS in their daily routine, but are more accustomed to GIT or SubVersion prefer their tools. This is especially true for many of the people contributing open source projects to CodePlex. The best thing is that you can use any of the tools side-by-side, allowing people from all sides to contribute to your projects.

And you can install these bridges on your local TFS instance to allow cross team collaboration while still retaining one central repository for easy backup and restore, centralized reporting and centralized security.

Size -- I guess Microsoft doesn't really like it either since they don't even ship it with Visual Studios, if you do need it, its a separate download and a big one at that -- 200MB+. Subversion, Tortoise SVN, and Ankh on the other hand combined are less than 15MB. How they filled up 200MB I have no idea, maybe they installed a client that doesn't suck somewhere I don't know about.

Team Explorer ships with the Visual Studio Shell included. Which explains the large size of the download. They might have been able to ship a installer that just includes the Team Explorer bits which you could use if you already had Visual Studio installed. They decided not to. Again, for me not much of an issue, I use the Visual Studio Ultimate

They don't ship it with the Visual Studio versions that don't include a license to access TFS in their product price. For these people they provide the downloadable version. If you look at it from that perspective it's quite logical.

Read-only Files -- Every file on your system is read-only. Why does everything need to be read-only. If I'm in another editor and I want to make a change to a file, I need to switch over to VS and check out a file for edit. This is rediculous.

Agreed. And they're going away. To make your life in other editors easier, you could always install the Team Foundation Server Power Tools, which add Windows Explorer integration. Allowing you to check out a file from every File Open... dialog in Windows.

Identical Files -- I just want to see what changed. Why does TFS insist upon showing me all the files even if they are identical. Call me crazy but I like to see what files I actually changed when I check in. Someone told me there is some command line tool to see this but that's just silly.

Never felt this as an issue. TFS won't actually create a new version for identical files and your checkout will be undone. I usually make it a habit not to check out files if I don't change them. As others mentioned in the comments of the original post, there's a "undo unchanged" option in the Pending Changes window which will actually release any file you didn't change.

Code reviews/update -- On my current project I'm the project lead and I like to review the junior developers code when I update my code. Yeah, I can't do that, or I haven't found the button yet. Nor can I find the button to view a particular revision without finding a file that was part of that change and viewing it's history.

There's multiple ways to enforce a review process through TFS. The simplest way is to take away someones check-in rights and let them shelve their work. You can then review the shelve and check the changes in if you're satisfied. Ivo Manolov has written a nice post about how to do this.

Should you prefer a post-mortem review process, then you can use the View History... menu item in the Source Explorer window to quickly look up the most recent changesets. Then choose Changeset details to view the files changed during the check-in.

Visual Studio 11, together with TFS 11 will add a much more extensive review process to the Team explorer experience. I gave a presentation on these features at the Dutch TechDays conference a month ago.

There are two open source projects (TFS Code Review Process and TeamReview) that add similar Code Review features to TFS.
Deleted files -- Team Explorer doesn't show them by default. This took me a while to figure this one out. You need to go into VS options then find TFS and then click show deleted files. Why is this not on by default and why isn't there a button to toggle this setting in Team Explorer.

There's a free add-in available that adds the item to the Source Control context menu's. Plus a few other useful items, such as Destroy (delete with history), changing the data on your file system to the date the file was last changed in source control.

And most important: The ability to drag and drop files in the Source Control window.
Project file modification -- We have some people working inside a VPN and some out, the TFS server name is different depending on where you sit. Since the solution file stores the connection string to TFS it's constantly getting checked in.

The way bindings are stored inside Visual Studio projects and solutions is troublesome. I hope they will remove this eventually. This isn't really a TFS issue, but more a Visual Studio issue. The same thing applies to many source control systems that integrate with Visual Studio through the Source Control API.

Proper installation of TFS with a proper globally unique domain name would solve this. But I agree it's irritating if not setup correctly. Ed Blankenship has a great post on using friendly names in your TFS environment. You could also add the internal name to your host file and make sure that it resolves to the proper (VPN) ip address as a workaround.
Everything needs to be in the solution -- If you have a bunch of support files or non-.NET files, all of them need to be added to the solution or they don't get checked in or out. VS doesn't help you with this either because you can't have a solution folder map to a directory.

I actually tend to do a get-latest before opening my solution, as it's much faster to get the latest version without having the solution open in Visual Studio. That way you always grab all the other files as well

Integrating with non-.NET developers -- If you have a mixed development environment (Java, Ruby, etc) like we do. You need to run TFS and something else because all the non-.NET developers can't use TFS especially if they are on a Mac. Usually the something else is much better anyway so you might as well use that instead.

In comes Team Explorer Everywhere which provides both a GUI and command line utils and the Team Foundation Server Build Extensions. There's even an SDK to build your own TFS extensions using Java. Team Explorer Everywhere 11 and TFS 11 will also extend support for case sensitive file names. They're also providing a SourceSafe wrapper which allows any development environment that runs on Windows and that supported SourceSafe to connect to TFS. This includes Visual Studio 6, the old Rational toolset, PowerBuilder, Enterprise Architect and more.
Working offline/Speed -- If you ever travel relax and take a nap because you won't be developing. Everything you do talks to the server and that in turn makes it slow. Open up a file and start making changes, to the server you go. Move a file, to the server you go. Diff a change you made, to the server you go.

Workspaces -- Who ever came up with the concept of workspaces at Microsoft should be ashamed of him/herself. They are just a stupid idea. If you want two copies of the same project checked out (I do it with SVN if I'm working on a quick bug fix and a big feature at the same time) good luck because I can't figure it out.

There has long been a workgroup edition of TFS which is free for up to 5 members. And TFS 11 will ship with a TFS Express edition which will be free for small teams. You can get free TFS for open source projects on Codeplex and for now the Team foundation Service Preview is free and will probably be relatively cheap to use when it goes into full production mode.

The cloud hosted version comes with a number of nice advantages that are even hard to get by in the current full product version. Such as world wide distribution though Azure. Federation support with the ability to add your won identity providers. Cloud based on demand build servers (add new agents if the load requires it, put them to sleep when you don't need them). Central patch management from Microsoft (optional).

From a centralized IT perspective, the Team Foundation Services will be a very lucrative way to store your sources and work items securely for a very low cost of ownership. And it will be a great way to enable cross organisation collaboration with enterprise grade security built in.

Again the Team Foundation Server Power Tools really improve the experience. You can use Rollback Changeset to remove the changes added by a specific changeset from the History panel. Or you can rollback a file or folder from the Source Control window.

Agreed. Luckily you can configure any tool you like. And to boot, Microsoft is completely re-doing the merge experience in Visual Studio 11. The new merge tool also supports context aware merges for XML files, which no longer treats it as plain text.