TFS Automatically Adds Built DLLs to Source Control

The story continues:

If you execute the tf command from a cmd prompt, everything goes as described in the previous answer. If you do it from a PowerShell command prompt you get the following:

PS C:\> & tf.exe workfold c:\projects\Macaw.SolutionsFactory\FactoryIdeTools\trunk /login:macaw\serge,Trasimeno5
TF10125: The path 'c:\projects\Macaw.SolutionsFactory\FactoryIdeTools\trunk' must start with $/

It gives an error!

I have tried everything, but to no avail. I even tried it through the TFS object model, but that got really complex. To get the workspace for a local folder you need a name of the tfs server first. It is probably possible to iterate all currently mapped workspaces and iterate through the servers defined there (that is probably what tf.exe does) to test if the local folder belongs to that workspace.

I finally came up with the following solution:

I create a simple batch file ExecTfWorkprodCommand.bat wit the following code:

@echo off
rem This is a kind of strange batch file, needed because execution of this command in PowerShell gives an error.
rem This script retrieves TFS sourcecontrol information about a local folder using the following command:
rem tf workfold  /login:domain\user,password
rem %1 is path to the tf.exe executable
rem %2 is the local path
rem %3 is the domain\user [optional, integrated security used if ommited]
rem %4 is the password    [optional, if %3 is not specified]
rem Output is in format:
rem ===============================================================================
rem Workspace: Macaw.SolutionsFactory@VS-D-SVDOMOSS-1 (Serge)
rem Server   : tfs.macaw.nl
rem $/Macaw.SolutionsFactory/FactoryIdeTools/trunk: C:\Projects\Macaw.SolutionsFactory\FactoryIdeTools\trunk

if [%3]==[] goto integratedsecurity
%1 workfold "%2" /login:%3,%4
goto end

:integratedsecurity
%1 workfold "%2"

:end

And I call this batch script from PowerShell. From the result I want to parse:

• Tfs server name
• Folder on server

Example code on how to solve this:

$tfsProductInfo = & "ExecTfWorkprodCommand.bat "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\TF.exe" "c:\projects\Macaw.SolutionsFactory\FactoryIdeTools\trunk" domain\user password
if ($tfsProductInfo -eq $null)
{
    Write-Output "Can't determine Tfs source control information on local folder"
}
else
{
    $tfsserver = [Regex]::Split($tfsProductInfo[2], ": ")[1].Trim()
    $serverpath = [Regex]::Split($tfsProductInfo[3], ": ")[0].Trim()
    $localpath = [Regex]::Split($tfsProductInfo[3], ": ")[1].Trim()
    Write-Output "Server     : $tfsserver"
    Write-Output "Server path: $serverpath"
    Write-Output "Local path : $localpath"
}

I've found the best practice for 3rd party DLLs is to create a "Library" folder in your sln/proj file structure and copy all the necessary DLLs into this local folder for reference. You'll also want to make sure these DLLs are checked into source control. This way, everyone who works on the project gets the exact same versions of all DLLs, and the reference paths are exactly the same.

Referencing 3rd party libs in a arbitrary download or install location will be problematic, because it will require all developers to maintain the same download structure for all DLLs. Also, if everyone references DLLs outside of the project structure, it's harder to guarantee that everyone's on the same version.

The other option would be to have everyone install the DLLs into the GAC, but that can be a real pain too, especially with version management and deployment.