So, I admit. All my TFS projects has been fresh projects with no old code to take care of... until now.

I suddenly stood before the task to move some code from VSS to TFS, or actualy a customer wanted to...and the usual mind set was there: "How hard can it be...?"

And it turned out to be quite easy, even easier than I expected. This is what I did:

• Archiving the project (just in case..)
• Analyze VSS (and correct errors of course, but there wasn't any)
• Run VssConverter in analyze-mode after creating an AnalysisSettings.xml-file:

<?xml version="1.0" encoding="utf-8"?>
<SourceControlConverter>
   <ConverterSpecificSetting>
         <Source name="VSS">
               <VSSDatabase name="c:\VSSDatabase"></VSSDatabase>
         </Source>
         <ProjectMap>
         <Project Source="$/FolderA"></Project>
         <Project Source="$/FolderB"></Project>
         </ProjectMap>
   </ConverterSpecificSetting>
</SourceControlConverter> 

• Change the UserMap.xml-file that was generated during the analyze session.
• Create a new team project in TFS
• Run VssConverter i migrate-mode after creating a MigrateSettings.xml-file

<?xml version="1.0" encoding="utf-8"?>
<SourceControlConverter>
    <ConverterSpecificSetting>
        <Source name="VSS">
            <VSSDatabase name="c:\VSSDatabase"></VSSDatabase>
            <SQL Server="."></SQL>
            <UserMap name="c:\Migrate\Usermap.xml"></UserMap>
        </Source>
        <ProjectMap>
            <Project Source="$/FolderA" Destination="$/TeamProjectA">
            </Project>
            <Project Source="$/FolderB" Destination ="$/TeamProjectB/ProjectB">
            </Project>
        </ProjectMap>
    </ConverterSpecificSetting>
    <Settings>
        <TeamFoundationServer name="My_TFS_Server" port="8080" protocol="http">
        </TeamFoundationServer>
        <Output file="Migration.xml"></Output>
    </Settings>
</SourceControlConverter>

And it just worked!!!

In the after discussion with the pleased customer about what features in TFS he should use, he came upp with the question "Well, we have our own, in house developed, item tracking system. Is it possible to move the data from that into TFS?". And I remember that I saw the video on channel9 with Matthew Mithrik about TFS Migration Toolkit and answered: -Of course...

It'll probably be another blog post about that if the customer decide to do that and if I will be a part of it.

I tried for a while to get a Web Deployment Project to work together with a Web Application Project to get an automated deployment by my TFS/Team Build, but I ran out of patience. It worked on my local machine, but on the build machine it didn't work at all. Instead I decided to manually edit the WAP project file and it turned out that it was quit easy to accomplish an automated deployment in that manner.

All I have to do is to hook up to the "AfterBuild" target and do some copying:

<Target Name="AfterBuild" Condition=" '$(Configuration)|$(Platform)' == 'Deploy.Dev|AnyCPU'">
    <Message Text="Latest build deployment to @(LatestBuildDir)" />
    <Exec Command="xcopy &quot;$(ProjectDir).&quot; &quot;@(LatestBuildDir)&quot; /y /s /f" />
    <Exec Command="xcopy &quot;$(OutDir).&quot; &quot;@(LatestBuildDir)bin\&quot; /y /f" />
 </Target>

I started with creating a special configuration (Deploy.Dev) to be built on the build sever, I dont want to do this on the team developer machines, and I dont want to do this on each checkin either. I configured my Team Build to do this every night.  Then just defining the directories and do some xcopy. It will probable lead to some problems in more complex scenarios, but for my project it works just fine, and with not that much of an effort.

The first day was on the subject of “Agile Development with Team System”, which consisted of four sessions. The over all impression of Roy Osherove is good. He is a good speaker, who manages to fill the audience with enthusiasm in four consecutive 75-minute sessions.

Session1 : Introduction to Agile Methodologies and Concepts

Roy started by talking about the basic thoughts about and the fundamentals of agile methods. It was, at least for me, old stuff, but it was useful to get a review and another person’s angle on the subject.

He continued by comparing traditional (engineering) methods with agile, adaptive ones. He also did a quick walk through of a number of agile methods and the differences between them.

To the end he talked about the agile manifesto and how to, step by step, move toward a more agile way to work.

Session 2: Test Driven Development with Team System

In his second session, he talked about unit tests.

• What they are;
• What they are not;
• How to write bad or good unit tests;

And at last I got to see some code on the screen…

He compared different frameworks and products for unit testing .NET-code:

• NUnit
• MbUnit
• Team System Unit Testing

The differences, strengths and weaknesses.

Session 3: Continuous Integration

In his third session he went through how to set up Continuous Integration with TFS. And how to do it if TFS isn't available: with MSBuild and/or CruiseControl.Net

There were lots of demos in this session as well.

Session 4: Running Projects using Scrum and VSTS

The last session of the day was about the Conchango Scrum plug-in to VSTS and how to use it to get the Scum process working with VSTS.

Lots of demos of the different steps to move the work forward, for example to create product backlog items and sprint backlog items etc.

It seems that it works smooth and easy and it’ll be fun to start with this on Monday when I’m coming home."