Install the TFS databases to a different drive

Another in a long line of FYI posts (or should that be FMI - For MY Information)

I'm doing a clean TFS 2008 install at a client this week.  They want to install in a dual-tier configuration with the Data tier on their existing SQL Server 2005 box.  As is usual in most organizations, the SQL box has multiple drives with different uses.  The C: drive is for the OS and apps, D: is the "data" drive, E: for backups, etc. 

A question arose when they asked me to make sure that the TFS and Sharepoint databases install to their D: drive as so that it follows their conventions.  I did a little research in the TFS 2008 install guide but couldn't find any way to direct the installer to create the databases in a specific location.  After a bit of Googling (or should that be Live Searching?) I found a post from Brian Harry back in December that addresses this.

Basically, TFS will install the databases wherever the Master database is located.  To get it to onto a specific drive you have 2 options,

1. Install to the default location and then move the databases by hand (Brian has the steps in his post).
2. Move the Master database to the target drive and then install TFS (These steps are there too).

My recommendation?  If you have the space on the default (Master located) drive, install there and then move to the preferred one.  Mucking around with moving Master around is not worth the trouble.

It looks like Maor David has a good recipe for doing this on his blog.

He must know what he's talking about, he's a Consultant!

I have recently been working with a number of clients to assess their Application Lifecycle Management maturity.  When I kick-off one of these ALM Assessments I take an hour or so the morning of the first day to discuss the assessment process with the the client's management and the folks that we will be interviewing.  My opening remarks (after I introduce my team) are generally...

... The process over the next few days will go something like this.  We'll bring each of you in for an interview where we'll ask you "What's going well", "What's not going well" and then leave some time at the end for you to bring up things that we may have missed. 

At the end of the Assessment, we'll put together a summary of the interviews.  Then we'll all meet together and I'll tell you what you already know.

That's usually the part where the managers look at me strange and the rank-and-file staff members start nodding their heads knowingly.

A large part of any ALM assessment or review is listening to the interviewees and finding the common patterns in their stories.  A common thread usually emerges after the third or fourth interview.  When we're done, we document the issues and recommend remediation steps.  Usually we find that we are giving the same or similar recommendations that have come from the staff to management in the week and months prior to our arrival.  Management is usually very happy with the report and moves forward with implementation of the initial parts of the recommendations. 

I've always scratched my head at this.  Why is my opinion taken as being more valuable than those closest to the problem?  I had the same question from the other side when I was working as the "rank-and-file staff member" and we had consultants come in.  I could say that it's because of my years of experience in the development field which gives an "air of competence" to my every word, but again, I'm being self-delusional.

I think that J.D. Meier put the answer quite succinctly in his post Use the system to educate...

It's along the lines of "you can't be a prophet in your hometown" ... sometimes the change agent needs to be external.

Sometimes the change agent needs to be external, indeed...

MSBuild 3.5 (2008) Tidbit: You can now remove Items from ItemGroups

One of the new features of MSBuild 3.5 (2008) is the ability to remove entries from ItemGroups.  We've always been able to ""override" a Property value by defining that property again later in the MSBuild file.  In MSBuild 2.0 (2005), if we used that same pattern with ItemGroups, we would have duplicate entries as they are each considered distinct Items.  To remove an Item from an ItemGroup in MSBuild 2.0 you would have to create a new ItemGroup from the old one and skip the Item that you needed removed. 

In MSBuild 3.5 the removal of an Item from an ItemGroup can be achieved by using the new Remove parameter.

<ItemGroup>
    <Letters Include="a" />
    <Letters Include="b" />
    <Letters Include="1" />
    <Letters Include="d" />
</ItemGroup>

<ItemGroup>
    <Letters Remove="1" />
</ItemGroup>

This technique is great for modifying the entries in an ItemGroup that you did not initially define because it is in an Imported MSBuild file like so:

MyCompany.Common.targets
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <ItemGroup>
        <FilesToCopy Include="a.aspx" />
        <FilesToCopy Include="b.dll" />
        <FilesToCopy Include="c.aspx" />
        <FilesToCopy Include="d.gif" />
        <FilesToCopy Include="b.pdb" />
    </ItemGroup>
</Project>

MyBuild.proj
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Import Project="MyCompany.Custom.targets" />
    <ItemGroup>
        <FilesToCopy Remove="b.pdb" />
    </ItemGroup>
</Project>

In the example above we had an ItemGroup named FilesToCopy that contained some files that we wanted to copy out to a staging folder for our IT group to copy to Production.  The ItemGroup is used in other builds, specifically for builds that go to Dev and QA.  It's ok to send PDB files to the Dev and QA environments, but not to Production so we need to remove it from our ItemGroup.

Removing it is easily accomplished by adding the Remove entry in MyBuild.proj file after the Import tag so that we can manipulate the previously defined FilesToCopy ItemGroup.

The documentation for this property contains a significant number of other cool new ItemGroup manipulation features.

Documented here: http://msdn2.microsoft.com/en-us/library/bb651786.aspx

Links: TFS Version Control Concepts demystified

File this in the "Look what I just found" category.  A bit of a lag since the original posts, but well worth it for me.

Richard Berg has written some excellent articles demistifying  some of the concepts in Team Foundation Version Control (TFVC).  I especially like Concept #3 describing the "two meanings of 'Changeset' ".  That was one of those topics that I had yet to find a clear explanation of, until now.  Thanks Richard.

TFS Version Control Concepts 1: Items
TFS Version Control Concepts 2: Item Names
TFS Version Control Concepts 2b: Namespaces in practice
TFS Version Control Concepts 3: Item Versions and the two meanings of 'Changeset'

Visual Studio Team System Chat scheduled for 9-Apr-2008

Well, the Team System folks are at it again!  Another product group chat is coming April 9th.  As I've always said, this is a great way to get answers to your toughest questions from the Visual Studio and TFS product teams.  Thanks to the Teams for taking the time to talk with the user community.  These folks have been very responsive to the community since Day 1 and the VSTS 2008 and Code-name Rosario features are examples of this.

Here are the particulars:

Join members of the Visual Studio Team System product group to discuss features available in Team Foundation Server, Team Suite, Architecture Edition, Development Edition, Database Edition, and Test Edition. In addition, discuss what's new for these editions for Visual Studio 2008.

Add to Calendar

April 9, 2008
10:00 A.M. Pacific Time
Additional Time Zones