How do I get the latest version of my solution recursively like its done in the solution explorer context menu of Visual Studio? Need to do this from the command line or via a macro.

/* 'tf get' only gets contents of a folder recursively (not solution). It does not look at project dependencies and so on. That won't work. */

I'm trying to automate a part of my daily routine by using a set of batch files. I am sure a lot of developers would love to have something like this.

+1  A: 

Well... It looks like you have three options.

  1. In your batch file, issue a tf get at each directory branch you want.

  2. reorganize your solution so that all of the dependencies are under the same root path.

  3. Use the visual way of right clicking on the loaded project and issuing the get command.

The only time it's actually solution aware is when the project is loaded in the IDE; or when it's loaded by the build servers.

Chris Lively
Chris,At times, I've seen the IDE automatically check-out files for reasons I could not understand. I am sure tf.exe will not handle those things automatically. There should be some means via a macro or using an msbuild script...I am trying to create a batch file which gets the latest version of a solution and builds it. There are about 10 solutions which I need to update this way every morning...
Vulcan Eager
As a side note: studio will check out solution files if it thinks a project file has been added / changed. Also, it will check out test related files (.vsmdi for example) for pretty much no reason at all. I'm not sure what this has to do with pulling the latest version and building it though.
Chris Lively

Have you found out which specific files are being checked out by the IDE?

Jon Limjap
Jon, In one case VS checked out the project file with the following message: There appears to be a discrepancy between the solution's source control information about some project(s) and the information in the project file(s).
Vulcan Eager

I know you mentioned batch files, but let me throw something else out for you.

I'm going to guess that you are using the 2005 version of TFS. 2008 has all of the scheduling stuff built in.

However, you could also use to do scheduled builds for you. I've used both TFS 2008 and CruiseControl and they both seem to work just fine.

Chris Lively
+1  A: 

TFS has a .Net SDK that allows you to create your own custom programs that interact with a TFS Server. You could write a small program that performs the task you need:

TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer("MyServer");
VersionControlServer vcs = (VersionControlServer)tfs.GetService(typeof(VersionControlServer));

WorkSpace[] myWorkSpaces = vcs.QueryWorkSpaces("MyWorkSpaceName", "MyLoginName", "MyComputer");

myWorkSpaces[0].Get(VersionSpec.Latest, GetOptions.GetAll);

One more possible solution is to use powershell. The following link is to a code project sample which shows how to get a solution from TFS and build it locally. Powershell is a much better solution than regular batch files.

Chris Lively

Don't do this. VS is not nearly as smart as you think. (As evidenced by the mysterious & futile checkouts that everyone has experienced for 3+ product cycles, you & I included. This is not the mark of a reliable system!)

What you describe only works for project-to-project references. Running source control operations from Solution Explorer will "by design" omit:

  • project-to-assembly references
  • video, sound, PDFs, any other type of media that VS doesn't support but may play an integral role in the product
  • MSBuild *.targets files that are referenced in your projects
  • any files of any kind that are referenced from custom targets
  • any 3rd party executables required by the build process
  • etc

Just say no to incomplete synchronization. Down that path, only headaches lie.

Run 'tf get' with no path scope from the command line, or rightclick -> Get from the root $/ node in Source Control Explorer.

Richard Berg
+1  A: 

I agree that Solution Explorer will "by design" omit all those objects, but only if you do not include them as Solution items, which I believe you should include in your solutions, so that a newbie can open the solution, do a Get Latest, and know they have all the dependencies needed for that solution, and not have to learn how to do it via a command line tool, or use Source Control Explorer if they don't want to.

Including all the non-code dependencies as solution items (we organize the solution folders using the same folder structure as their source control folders) reduces "voodoo" knowledge required to open and compile the solution for new developers on a project.

It would be good if you could link entire folder trees to a solution folder in the VS solution.

Mike Diehl