Dotmad.net

We all know about the “cool new kids in town”, meaning new technologies all developers want to use. Offer a developer two positions:

1. Programming with C# 1.1
2. Programming with WPF and C# 3.5

What do you think most developers will choose?

However, there is the question of an existing project, written in an “uncool” technology.
In my experience developers tend to push towards using newer technologies, but how do you convince the people in charge?

Here are my thoughts on the subject:

Framework 2.0 vs. 1.1
Advantages: Performance boost if you are using ArrayLists with value types in them (when you switch to generic Lists)
Disadvantages: Incompatibility issues requiring code changes (should be very minor)

Framework 3.5 vs. 2.0
Advantages: Using Linq for new complex data access and query modules, otherwise I’m unsure
Disadvantages: Same as switching between 1.1 and 2.0

WCF vs. Various communication technologies
Advantages: Much easier to configure and deploy, can drastically change the communication method without any code changes
Disadvantages: Not applicable when you do most of the communication in a non-.Net world if you remote points are not using web services protocols (example: communication with hardware sensors)

Workflow foundation
Advantages: Easier to manage complex workflows. Enables user modification of workflows.
Disadvantages: If an existing workflow code is already written - major code rewrite.

WPF vs. Winforms (with CGI+)
Advantages: Creating easily resizable forms due to vector graphics use. Customize look & feel in ways which are almost impossible to duplicate using winforms. Easier interaction between UI/graphics designers and developers.
Disadvantages: Will require serious code rewrite. Performance issues still exist (I have yet to witness a professional map engine based on WPF)

Team system vs. various source control / task management systems
Advantages: I have used SourceSafe, PVCS and Rational ClearCase/ClearQuest, and to this date I think VSTS is better is terms of performance, ease of use and customizability, especially when you need to integrate source control and task management.
Disadvantages: Requires Windows - how do you use VSTS to manage C++ code in a Unix/Linux environment?

I have been asked several times for my experience regarding installation of Team System inside an organization using (up to this point) an older version control system, so here are few tips:

1. Team system is a complex software to install, maintain and upgrade. Study the various pitfalls you may encounter and plan your installation strategy very carefully.
   You can find an updated installation guide and administator’s guide in Microsoft’s web site, and it’s probably newer than the guides on your installation discs.
   Team system is mainly composed of the server’s installation (I recommend a dedicated server), and an installation of the Team explorer on each developer machine. It uses SQL server as it’s database server.
   Update: You should also read the “Operations Guidance for Team Foundation Server“.
2. Decide and implement domain permissions for users (developers) and automated services.
3. If you also need to install SP1, be aware there are known issues with the upgrade.
4. Be aware to the fact there are several databases, so be sure to include all of them in your backup scheme. If you don’t have a backup scheme - make one!
5. You also need to select a branching strategy that suits you for your source control.
   Update: Jeff Atwood wrote a great post explaining branching strategies.
6. You can also use VS2005 only for source control, and develop your application using VS2003 or Delphi (for example).
7. Choose how to use your infrastructure’s assemblies repository. You can get them from the source control or store them locally on each computer, but then you don’t guarantee all developers will use the latest version.
   Another option is using a shared folder to store them, but you make yourself more susceptible to network problems.
   One trick is using the window’s subst command, mapping the shared folder to a drive, leaving you the ability to backup the repository locally and mapping it to the same drive if the network is down.
8. Create an automated build server. This takes some work, but will help you detect invalid code changes by developers. Choose the frequency to run the build at, from once a day to after every check in.
9. Don’t fall for the NIH syndrome - there are many tools out there to make your life easier - use them.
   If you want to build non-native .Net code, consider getting a commercial tool (such as FinalBuilder for Delphi) and running it from your build code - it will be cheap compared to the developer-days you’ll be saving.
   If you are using the bug tracking capabilities of Team System, be sure to remove the default event registration of the build service, otherwise your “fixed in ver” combo will contain hundreds of values. If you forgot, here is how you remove values from it.

You can download useful TFS posters here.
And here you can find the book: “patterns & practices Team Development with Visual Studio Team Foundation Server”.

Martin Woodward wrote a post containing a list of the 30 most useful (to him) properties for the build file.
The nice part is that in the table he also includes examples for each property.

The idea with the AssemblyInfo task is to:

1. import Microsoft.VersionNumber.targets
2. populate the AssemblyInfoFiles item group with the list of AssemblyInfo.* files to be updated
3. set whatever properties you want to modify - AssemblyMajorVersion, AssemblyMinorVersion, etc.

You can find further info here.

One of the major advantages of the “Shelf” feature in Team System is the ability to backup all your current code the the central server for backup, even before checking in complete changes.
To do this programmatically you first need to get the name of the TFS server, and get the version control service:

TeamFoundationServer tfs = new TeamFoundationServer(tfsName);
VersionControlServer versionControl = (VersionControlServer)tfs.GetService(typeof(VersionControlServer));

Now you can call the VersionControlServer.QueryWorkspaces method, which receives 3 parameters (WorkspaceName, WorkspaceOwner, WorkspaceComputer) when each of them (or all) may be null.
Using the workspace you need to call the Shelve method, supplying the pending changes with the GetPendingChanges method.

Here is the complete code:

public static void ShelveAll(string tfsName, string workspaceName, string workspaceOwner, string workspaceComputer){    TeamFoundationServer tfs = new TeamFoundationServer(tfsName);    VersionControlServer versionControl = (VersionControlServer)tfs.GetService(typeof(VersionControlServer));    foreach (Workspace ws in versionControl.QueryWorkspaces(workspaceName, workspaceOwner, workspaceComputer))    {        PendingChange[] changes = ws.GetPendingChanges();        if (changes.Length > 0)        {            Shelveset set = new Shelveset(versionControl, DateTime.Now.ToString("yyyyMMdd HHmm"), ws.OwnerName);            ws.Shelve(set, ws.GetPendingChanges(), ShelvingOptions.None);        }    }}

For Hebrew speakers only, Guy Burstein recorded several short (7-15 minutes) screencasts showing some of the application blocks inside EntLib 3:

1. Logging application block
2. Exception handling AB
3. Validation AB
4. Policy injection AB

For English speakers, I found several screencasts here.

And there is also a new Team System screencast site: “How do I?“.