Chris May

Because I didn't like the options for integrating SQL Server code into TFS, I wrote an application that scripts all our database objects to text files and then checks those files into TFS every night.  If there is a change in any of the files, those changes are versioned in TFS so we can go back and see when things were changed or recover old code without restoring the entire database.

But recently there was a problem with the server that my app runs on, and during the restore process, the backup process was run twice on a set of folders (at least that is my best guess) leaving thousands of duplciate files in a myriad of folders.

So for example, if there was a file called:

$\DatabaseFiles\sqlserver1\SomeDBName\SPs\dbo.SomeSP.sql

then the restore process created another file called

$\DatabaseFiles\sqlserver1\SomeDBName\SPs\Copy of dbo.SomeSP.sql

The problem is that my application does bulk checkins each night of all files under the \DatabaseFiles folder.  I didn't realize that the backup process had been messed up until it was too late, and those thousands of files were already checked into TFS.

So using this page to help with some of the syntax of using the TF.EXE command line too, I was able to perform a recursive wildcard delete.

In the end something like this worked just great:

tf.exe delete /recursive /noprompt "C:\TFSroot\DatabaseFiles\Copy of*"

Notice that the wildcard is applied to all recursive folders under C:\TFSroot\DatabaseFiles\.

Nice.

 

Problem:

We have a server that gets all files from TFS and uses Nant w/ Visual studio to compile our projects.  Basically nant issues a command line statement to get VS to build a given solution.

Everything was working great, until I upgraded our clients to 2008.

I went through and upgraded all our solutions.

I installed vs 2008 on the server.  But when I try to build from the command line, it tells me that the solution file "is from a previous version of this application and must be converted in order to build in this version of the application."

I tried directly copying my solution file (skipping the source control step) directly to the server but I get the same message.

If I try to build it from the command line with VS 2005 it tells me that the solution is too new!! 

So 2005 says the solution is too new, 2008 says it is too old!

The solution on the server has the "version 9" icon, just like on my laptop.

The solution file starts with:
Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio 2008

Resolution:

Even thought I compared the solution files and found them to be exactly the same using a diff compare tool, I allowed the server to run the "upgrade" process on the solutions.  I didn't save any of the changes it made, but from then on it recognized those files as having been already upgraded.

I even replaced the "server upgraded" solution files with the old solution files that it didn't like and it continued to work just fine.

There must be some other files stored somewhere that made it think that it hadn't been upgraded yet.

This isn't a great solution, but it works at least.

 

Sometimes you might try to rename a folder in TFS Team Explorer and it tells you that you can't rename the folder b/c an existing item exists (but it doesn't).

The reason is that if there is a delete folder with the same name, it won't allow you to name a current folder with the same name.

To see your deleted folders (so you can undelete, rename, and delete again) you can use the following option under Tools->Options.

If you create a branch in TFS, you can easily merge it back later, but if you have 2 branches or folders that you want to merge, but are not related (they weren't branched from one another) you need to do a baseless merge.

This article describes the process:

http://msdn.microsoft.com/en-us/library/bb668976.aspx

But the short end of it is that you run the following command at the VS command prompt:

tf merge /baseless c:\source c:\dest /recursive

It will launch the dialog box for you to manage the merge from there.

For some reason the TFS Team Explorer UI doesn't give you the ability to delete team projects.

To do this you need to make use of the TfsDeleteProject command line utility.

Basically just navigate to:

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE

and run the command:

TfsDeleteProject /server:http://SERVERNAME:8080 PROJECTNAME

After you do this, you may need to run the "TfsVersionControl Administration Job" job on the machine running SQL for TFS.  It's under SQL Agent/Jobs.

Finally, the team projects will continue to show up in Source Control Explorer.  This is because you need to do a "GET" on the projects in order for them to clean up local files.  Once you do a get on the projects they will be gone from your workspace list.

Once in a while someone checks in some file they didn't want checked in.

You can roll back these changes/checkins by using the Team Foundation Server Power Toy.

Team Foundation Server Power Tool Commands

Team Foundation Server Power Tool (tfpt.exe) is a command-line tool. To use these commands, start tfpt.exe at the Command Prompt. Some of the commands will display a graphical user interface when used. In addition, you can access the Annotate and Treediff commands from Source Control Explorer in Visual Studio or Team Explorer. Team Foundation Server Power Tool includes the following commands:

Unshelve Command
Use the unshelve command to unshelve and merge the changes in the workspace.

Rollback Command
Use the rollback command to roll back changes that have already been committed to Team Foundation Server.

Online Command
Use the online command to create pending edits on writable files that do not have pending edits.

GetCS Command
Use the GetCS (Get Changeset) command to get the changes in a particular changeset.

UU Command
Use the UU (Undo Unchanged) command to undo unchanged files, including adds, edits, and deletes.

Annotate Command
Use the annotate command to download all versions of the specified files and show information about when and who changed each line in the file.

Review Command
Use the review command to optimize the code review process to avoid checking in or shelving.

History Command
Use the history command to display the revision history for one or more files and folders. The /followbranches option returns the history of the file branch’s ancestors.

Workitem Command
Use the workitem command to create, update, or view work items.

Query Command
Use the query command to run a work item query and display the results. If you do not provide a specific query, all the active work items assigned to you are displayed.

TreeDiff Command
Use the treediff command to display a visual representation of the differences between files in two server folders, in a server folder and a local folder, or in two local folders.

Treeclean Command
Use the treeclean command to view and optionally delete files that are not under source control in the current directory and all subdirectories. This command is useful when you want to remove temporary files from your local workspace, such as files created by the compiler.

 

To use it for rollbacks, just add the install path to the tfpt.exe to your PATH environment variable.  Then, browse to the root of the project directory that you want to perform a rollback in and run "tfpt rollback" from the command line.

It will give you a user interface where you can find search for a chance-set to rollback.

Once you do it, you may have to "check in" the changes you just made, but I have used this several times and it has worked great.

 

From CodePlex:

patterns & practices Team Development with TFS Guide (Final Release)

Welcome to the patterns & practices Team Development with Visual Studio Team Foundation Server project site! This guide shows you how to make the most of Team Foundation Server. It starts with the end in mind, but shows you how to incrementally adopt TFS for your organization. It's a collaborative effort between patterns & practices, Team System team members, and industry experts. This guide is related to our Visual Studio Team System Guidance Project.

Download the Guide

Final release is available! Start using the guide today, while we continue to make improvements.

• Download the Team Development with Visual Studio Team Foundation Server Guide

Download the Diagrams

Download the Visio diagrams we used in the guide so that you can modify them and use them to document your own particular environment.

• Download the Team Foundation Server Guide Visio Diagrams

 

I just opened VS to do something in TFS Source Control Explorer only to find that all my controls were disabled and right clicking on anything only showed "No Commands Available."

Turns out that this was because I had to change my default source control plugin to VSS for a project I was working on.  If you go to Tools->Options->Source Control and select TFS as the default SCC plugin, it will fix the problem.

I recently sought out any companies that were providing hosted TFS projects.  Microsoft is doing this with CodePlex.com, but only for open source projects.

Amazingly there is nothing out there for people who want to pay to have their project hosted in a TFS environment.

Some sites suggest that this may be offered soon: http://www.staheli.org/vsteamsystem/

But as of now, nothing...

Which is too bad, because I think the source code control of TFS is pretty nice, and I would like to use it in the future on some of my projects.

I am still trying to find more value in the Team System/TFS combo.  There are some really great benefits that we are seeing in terms of using TFS for our source control, but a lot of the things I had hoped to do with TFS are simply not good enough to actually use.  Unit testing, continuous integration, bug tracking, code policy etc.

Here are a list of addin widgets for team system:
http://teamsystemexperts.com/widgets.aspx

I'm hoping that some of these can provide some added value to the entire system.

Somehow the term ALT.NET has been created to describe people who use .Net to program, but try to avoid the "standard" practices and tools that microsoft pushes.

Roy Osherove has an article where he pits the HOT and NOT as seen by the alt.net guys.

My major issue with trying to adopt more of these practices is that I work mostly on existing large applications.

I can't just show up at a client who already has millions of LOC using a more standard approach with thousands of stored procedures, and jump into a Monorail/NHibernate project.

For now I am focusing on getting one of my clients using a server based build and deployment.  We have already moved off of VSS, which is making a big difference in our productivity.

I was searching for some guidance on this and came across a nice paper:

Explained :Structuring Your Solutions And Projects In Source control Using Team Foundation Server

What Files Should Be Source Controlled?

The following list identifies the key file types that you should add to source control. These are the file types that are added when you click Add Solution to Source Control.

Solution files (*.sln). Solution files maintain a list of constituent projects, dependencies information, build configuration details, and source control provider details.

Project files (*.csproj or *.vbproj). Project files include assembly build settings, referenced assemblies (by name and path), and a file inventory.

Visual Studio Source Control Project Metadata (*.vspscc). These files maintain project bindings, exclusion lists, source control provider names and other source control metadata.

Application configuration files (*.config). XML configuration files contain project and application specific details used to control your applications ’s run time behavior.

 

Web applications use files called Web.config. Non-Web applications use files called App.config.

Note: At run time, the Visual Studio build system copies App.config to your project’s Bin folder and renames it as Yourappname.exe.config. For non-Web applications, a configuration file is not automatically added to a new project. If you require one, add it manually. Make sure you call it App.config and locate it within the project folder.

Source files (*.aspx, *.asmx, *.cs, *.vb, …). Source code files, depending on application type and language.

Binary dependencies (*.dll). If your project relies on binary dependencies such as third party DLLs, you should also add these to your project within source control. For more information about managing dependencies, see "Explained: Managing Source Control Dependencies in Visual Studio Team System."

What Files Should Not Be Source Controlled?

The following files are not added to source control because they are developer specific:

Solution user option files (*.suo). These contain personalized customizations made to the Visual Studio IDE by an individual developer.

Project user option files (*.csproj.user or *.vbproj.user). These files contain developer specific project options and an optional reference path that is used by the Visual Studio to locate referenced assemblies.

WebInfo files (*.csproj.webinfo or *.vbproj.webinfo). This file keeps track of a project's virtual root location. This is not added to source control to allow individual developers to specify different virtual roots for their own working copy of the project. While this capability exists, you and all team members are recommended to use a consistent (local) virtual root location when you develop Web applications.

Build outputs that include assembly dynamic-link libraries (DLLs), Interop assembly DLLs and executable files (EXEs). Note that you are advised to add assemblies that are not built as part of your system build process (such as third-party controls and libraries) to Source Control within the projects that reference them.

As someone who is trying to jump into the unit testing world, one of the major problems I had was deciding on using NUnit (which everyone uses) or use MSTest(built in).

I didn't want to jump into this and realize 500 hours later that I picked the wrong framework.  Well, now it seems I don't have to worry about that as much. 

First I was reading this article by Roy Osherove, and somehow I ended up on this page talking about converting between NUnit and VSTS projects, and from there I found a link to this page, which contained this great piece of code:

#If NUNIT Then
Imports NUnit.Framework
Imports TestClass = NUnit.Framework.TestFixtureAttribute
Imports TestMethod = NUnit.Framework.TestAttribute
Imports TestInitialize = NUnit.Framework.SetUpAttribute
Imports TestCleanup = NUnit.Framework.TearDownAttribute
#Else
Imports Microsoft.VisualStudio.TestTools.UnitTesting
#End If

This allows you do have the came code for NUnit and MSTest.  Just change the NUNIT variable and recompile.

The other thing you need to do is use <TestAttribute()> instead of <Test()> on your NUnit tests, but I don't see the difference there.

 

So I have this problem.

If someone declares:

Public iProductId as Integer

then I want to be notified.  But if someone declares:

Protected WithEvents txtUserName as Textbox

I don't want to be bothered.

Every control declaration we have throws an error in the static code analysis tools.

So after asking around, I guess it is not possible to cusomize the existing rules to exclude common prefixes such as lbl, txt, cmd etc.

So apparently the only option left is to disable those rules and create my own. 

So here are a few links that deal with creating custom links.

MSDN

Kevin Castle

FxCop Team

 

MS has released a power tool for TFS, and here are the MS hosted forums:

Team Foundation Server - General
Discuss Team Foundation Server general concepts.

Team Foundation Server - Setup
Discuss Team Foundation Server setup and configuration.

Team Foundation Server - Administration
Discuss Team Foundation Server administration and operations.

Team Foundation Server - Version Control
Discuss Team Foundation Version Control, including branching, merging, and shelving.

Team Foundation Server - Work Item Tracking
Discuss Team Foundation Work Item Tracking, including work item customization and Office integration.

Team Foundation Server - Reporting
Discuss Team Foundation Reporting, which uses SQL Server 2005 Reporting services to report team project metrics.

Team Foundation Server - Build Automation
Discuss Team Foundation Server's build automation features.

Team Foundation Server - Process Templates
Discuss Team Foundation Server process template development and customization.

The VSSConverter tool which allows you to convert from VSS to TFS will attempt to utilize a local version of SQL Express.

This sucks, as I hate SQL Express.

After some searching/trials/errors, I found a way to get it to work against a SQL Server 2005 database.

Just add the SQL tag to your migration settings xml file like so:

<Source name="VSS">

      <VSSDatabase name="D:\Program Files\Microsoft Visual SourceSafe\VSSHttp"></VSSDatabase>

      <UserMap name="D:\VSS2TeamFoundation\Usermap.xml"></UserMap>

      <SQL Server="name_of_your_SQL_Server" />

</Source>

Roy Osherove blogs that he was mistaken when he suggesting using mocks for data access code.  With the improved Rollback attributes that he helped create, along with people like Justin Burtch who created a similar attribute for VSTS, they are now thinking that this is the way to go: rolling back database changes.

Roy is no fan of VSTS testing, finding a few bugs and some questionable design decisions.  Those don't seem like deal breakers for me, but we will see.

Here is an article from MS on how to od the upgrade.

Thankfully, it is a very easy process.

This is good news for those of us who were kinda pissed that Team Foundation Server didn't come with this type of interface to begin with:

http://blogs.msdn.com/bharry/archive/2007/03/26/microsoft-acquires-teamplain.aspx

 

I went to a DevCares event today and heard some people talk about TFS.

The topic of Checkin Policies was of spcial interest.  I quickly found this policy that will require that methods be documented.

http://www.codeplex.com/Wiki/View.aspx?ProjectName=TFSCCPolicy

I think this would be a GREAT thing to have in our environment, where comments are very scarce.