When writing code against the TFS SDK, you need to specify the version of the SDK to bind to: for TFS 2005, this you bind to version 8.0; for TFS 2008, you bind to version 9.0. In theory, you're expected to compile one version of your tool to talk to TFS 2005 and another to talk to TFS 2008. But if you happen to be calling simple methods^[2] that have identical signatures between the versions, you can use a little loader trickery to bind against both.

When compiling your application, link against the version 9.0 SDK. When those aren't found -- when the target platform only has the TFS 2005 client installed -- .NET will fire a library resolve event, giving you a second chance to load the DLLs. Then you can simply load the 2005 libraries and keep running your application.

When your application starts, hook up an AssemblyResolve event handler:

AppDomain.CurrentDomain.AssemblyResolve +=
    new ResolveEventHandler(ResolveAssembly);

Your ResolveAssembly method should look like this:

public static Assembly ResolveAssembly(object sender,
    ResolveEventArgs args)
{
    String[] arguments = args.Name.Split(new string[] { ", ", "," }, 
        StringSplitOptions.RemoveEmptyEntries);

    if (arguments == null || arguments.Length == 0)
    {
        return null;
    }

    String assemblyName = arguments[0];
    String versionRequested = null;
    String cultureRequested = "neutral";
    String pkTokenRequested = "b03f5f7f11d50a3a";

    for (int i = 1; i < arguments.Length; i++)
    {
        if (arguments[i].StartsWith("Version=", 
            StringComparison.CurrentCultureIgnoreCase))
        {
            versionRequested = arguments[i].Substring(8);
        }
        else if (arguments[i].StartsWith("Culture=", 
            StringComparison.CurrentCultureIgnoreCase))
        {
            cultureRequested = arguments[i].Substring(8);
        }
        else if (arguments[i].StartsWith("PublicKeyToken=", 
            StringComparison.CurrentCultureIgnoreCase))
        {
            pkTokenRequested = arguments[i].Substring(15);
        }
    }

    if(
        assemblyName.StartsWith("Microsoft.TeamFoundation.", 
            StringComparison.CurrentCultureIgnoreCase) &&
        versionRequested.Equals("9.0.0.0")
    )
    {
        return Assembly.Load(assemblyName +
            ", Version=8.0.0.0, Culture=" + cultureRequested + 
            ", PublicKeyToken=" + pkTokenRequested);
    }

    return null;
}

And with a few lines of code, you've got an application that works with either TFS 2005 or TFS 2008.

1. What's Remote Accelerator you ask? It's a single-user version control proxy for Team Foundation Server. It's perfect for branch offices and telecommuters who want faster access to TFS.
2. It's important to remind you that this trickery will only work with methods that have identical signatures between the 2005 and 2008 assemblies. Otherwise, you'll get some nasty class loading exceptions.

If you're using Teamprise on a Mac, the combination of the Textmate text editor and our SCM bundle is hard to beat for quick editing jobs. You can pick up the updated bundle at Teamprise Labs.

(You do know about the new labs.teamprise.com, don't you? We've published some cool Team Foundation Server tools there already, and we've got a lot more coming soon, so be sure to check it out.)

As of our launch, we have a variety of build tools, our check-in policy SDK and a source code management plugin to the popular TextMate text editor.

But check back - we've got some more exciting projects in the works that we can't wait to share with you.

Flexible Project Mappings in Eclipse
Many customers - especially those moving from other version control systems - want more control over the import process in Eclipse. In earlier versions of Teamprise Plug-in for Eclipse, we required that your Eclipse projects live beneath the Eclipse workspace root. While this restriction was mostly sensible, many customers wanted to be able to keep a hierarchical project layout. In Teamprise Plug-in for Eclipse 3.2, we allow you to set up your local project layout however you wish, then perform your Import from Team Foundation Server.

To take advantage of this new functionality, open up Team Explorer before
performing your import and map your working folders manually before performing
your input. Let's say your projects look like this in Team Foundation Server:

$/BigProject
$/BigProject/Client
$/BigProject/Client/com.example.bigproject.client
$/BigProject/Client/com.example.bigproject.client.ui
$/BigProject/Client/com.example.bigproject.client.ui.win32
$/BigProject/Client/com.example.bigproject.client.ui.gtk
$/BigProject/Server
$/BigProject/Server/com.example.bigproject.server
$/BigProject/Server/com.example.bigproject.server.soap
$/BigProject/Server/com.example.bigproject.server.core

Now you can set a working folder mapping for $/BigProject - say to
C:\BigProject - then open up the Teamprise Import Wizard and select all your
projects. They'll be imported relative to C:\BigProject:

C:\BigProject\Client\com.example.bigproject.client
C:\BigProject\Client\com.example.bigproject.client.ui
C:\BigProject\Client\com.example.bigproject.client.ui.win32
C:\BigProject\Client\com.example.bigproject.client.ui.gtk
C:\BigProject\Server\com.example.bigproject.server
C:\BigProject\Server\com.example.bigproject.server.soap
C:\BigProject\Server\com.example.bigproject.server.core

You can even do a Get Specific Version inside the Source Control Explorer:
the Import Wizard won't overwrite the version you download, so you'll be
able to import a historic version easily.

The only restriction is that you must map these projects outside of your
Eclipse workspace root - projects inside your Eclipse workspace root must
live in a flat listing. (This is an Eclipse restriction, not a
Teamprise-imposed one. Sorry!)

Kerberos Authentication
Teamprise clients now support passwordless authentication to the Team
Foundation Server on Linux and Mac OS X platforms using a Kerberos ticket.
This provides a convenient, and secure way to authenticate to your Team
Foundation Server.

Switch to Branch
This is a handy little feature that allows you to work with multiple branches more easy in Eclipse. Want to work in a different branch? Simply right click on a project, select "Switch to Branch" and select the TFS branch that you want to work in. Then you can make whatever changes you want in that branch and switch back to your main branch.

Command-Line Client Functionality
The Teamprise Command-Line Client adds a lot of new functionality in 3.2, most notably full support for merging branches from the command line. CLC also adds conflict resolution, diff support and improved navigational functionality.

Other New Stuff
3.2 offers much better controls in work item tracking -- native controls for Areas and Iteration dropdowns, autocomplete for other work item dropdowns, and a better history control on most platforms. Plus we've added support for a new IDE: IBM RAD 7.5, as well as a new operating system: HP-UX on Itanium processors.

Teamprise Client Suite 3.2 (and any of the component products) is a free
upgrade for existing Teamprise Client Suite 3.x customers, as well as
customers with a current maintenance agreement. We recommend upgrading to
get these great new features.

If you're interested in hearing a little bit about some of the difficulties in writing cross-platform code in general (or a cross-platform Team Foundation Server client in particular), then I recommend you give it a listen. It's an overview of the topic, and not a deep dive into some of the hairy monster you might encounter, but I have (and will continue to) blog about those topics more in depth.

Ouch. That's a question I didn't want to have to answer, since I haven't put up a post since last July, over six months ago. So this is that blog post where I apologize and make some vague assertions that I've been really busy since then.

To be fair, I have been really busy: let's not forget that Teamprise is a startup. And while we're not the sort of startup where the developers have sleeping bags^[1] under their desks and the owners crack the whips, let's make no bones about the fact that there are times when you're working frantically to hit your deadlines and you let the less important things slip. Like writing in this blog.

And although I'm apologizing, we're both probably happier that I'm not blogging when I'm in the midst of the writing lots of code or this would actually end up as a cross between twitter and a trainwreck. I can see it now:

Day 42: It turns out that xstream 1.1.3 is totally incompatible with the IBM JRE that ships with RAD 7.5. Fascinating, huh?

So keeping a little quietude on the blog front lets me get some perspective on what I'm working on, and I can write about the bigger picture instead of whatever tiny hunk of code has pissed me off that day. And the bigger picture is that 2008 has been a whirlwind of development at Teamprise:

Teamprise Client Suite 3.0 - 3.1.3
Client Suite 3.0 was released in March to complement Team Foundation Server 2008, and it included a lot of new features, big performance enhancements, and lots of little improvements^[2]. You can read more about 3.0 on Martin Woodward's blog, and more about 3.1 on mine.

Teamprise Remote Accelerator
I snuck away from working on Client Suite for a few months in the fall and focused on this handy application that provides developers a big speed boost when they're remote from their Team Foundation Server. This was an internal tool that we "productized" and released at the Microsoft Professional Developers Conference in October. I'll write more about it soon -- I really should have blogged about it back then, but instead I jumped right into...

Teamprise Client Suite 3.2
We haven't released it yet, but I'm including 3.2 on our year-end retrospective since we've put a lot of effort into its development this year^[3]. As with all the point releases, it's a free upgrade for existing 3.0 customers (or customers who have purchased maintenance), and we think you'll be very happy with it. We're really excited about 3.2, and I'll be writing more about it soon.

So that's my excuse, and while I feel like a guy who's turning in his homework late, there should be some potentially interesting stuff coming up.

1. jwz, of course, has the canonical tale.
2. I keep being told not to say "bug fixes" since they're not "bugs", they're "features", right? And "feature fixes" sounds really stupid, so I'll settle on "improvements". And the fact that I footnoted this illustrates why I am horrible at marketing.
3. Okay, well, me less so than most of the rest of the team, seeing as I snuck off to work on Remote Accelerator for a while. Sorry, guys.

The biggest new feature in 3.1 is support for working offline in both our Teamprise Plug-in for Eclipse and our Teamprise Explorer clients. Offline support is a big advantage for TFS users who have unreliable network connections - particularly telecommuters and road warriors, who might want to get some work done wherever they are, be it a coffeeshop or an airplane.

If you're an Eclipse user and wish to go offline from your Team Foundation Server (or if your network unfortunately takes you offline), just go to the Team menu and select "Work Offline". You'll be disconnected from TFS, yet you'll still be able to perform all the file operations like you expect -- you can add, edit, move and delete files just like if you were online. When your network connection returns, you can choose the "Return Online" menu option and pend all those changes to the server.

Working offline in Teamprise Explorer is even simpler, you don't need to specifically enter offline mode. Simply make whatever changes you wish in your workspace, and click "Return Online" from the Source Control context menu. Explorer will synchronize your local workspace with the server and pend any changes you made while you were offline.

The Command Line Client has had offline support since version 3.0, so that's nothing new, but it does get some cool features aside from that. We've added an XML output option for many commands so that you can parse the results easily from a script. The "brief" and even "detailed" formats tend to truncate output for easy interactive viewing, but this can be troublesome for scripts. The new XML output should be perfect for getting all the information out of Team Foundation Server.

Those are a few of the bigger features, but there are many more. And seeing as this is still a point release, there are a lot of bug fixes, too. If you want to see all the details, check out the 3.1 release notes.

We've spent a lot of time on 3.1, and we think you'll enjoy it, even if you're not the type of person to upgrade for "just a point release".

We'll be giving demos of the new Teamprise 3 and all it's great new features. Hope to see you there!

If you're in the greater Chicagoland area next week, I've been invited to the Chicago VSTS User Group to give a tour of the new version of Teamprise. If you're interested in how Team System can play nice with Java developers, I suggest you stop by and check it out:

The meeting begins at 5:30 PM at the Microsoft Chicago (Loop) Offices:
77 W Wacker Dr, Suite 2300

Please RSVP if you're going to attend.

Even if you can't make it next week, be sure to check out the Chicago VSTS User Group, or another user group near you. It's a great resource if you're a VSTS or Team Foundation Server user!

Teamprise will be exhibiting at the Chicago launch event tomorrow, March 11. We're in booth 47 - stop by and say hi if you're attending.

Even better -- our very own Martin Woodward will be presenting at the Dublin launch event tomorrow. Be sure to check him out if you're attending out there.

Otherwise, there are still plenty of events in a city near you - be sure to go check out what's new in TFS 2008!

But I'm not going to lie, I'm really put off by the advertising. This year's theme for the conference is Alan Turing. How this conference has been going on for 14 years and ignored him up to now is a mystery to me. (They made a carrier pigeon the theme in 1997. That's right, a carrier pigeon apparently did more for security than Turing.)

But now that RSA has finally decided to recognize the man, they're doing some stupid advertising around it: What Would Turing Do? Which, frankly, would make a cool bumper sticker, and I would have been impressed... if they had just asked the question and not tried to answer it.

Instead, they give some odd answers that show that their marketing department never bothered to talk to a developer - or even a read a Turing biography. Their answers are frequently bizarre and have nothing to do with Turing: he would "have a raging sushi addiction", "be a huge Dr. Who fan" and would "collect rare Phillip Glass vinyl". (Yes, they also didn't bother to google "Phillip Glass" to realize that they misspelled his name.)

This is the company that was founded by three math PhDs who invented the RSA public key algorithm the RC block ciphers, and the MDx hash functions. And they're suggesting that he would "recite the far reaches of imaginary numbers to pass the time"? I'd like to think that would be beneath Turing... hell, it would be beneath me. (A googleplex times i. A googleplex plus one times i. See, not very satisfying is it?)

Very disappointing.

Especially since it's obvious that really, Turing wouldn't care about sushi or Bill Gates. He'd be far too busy enjoying the liberal sexual mores of this fine time we live in.

When working on native code, I tend to make all my code work in C first - debug it, write some native test cases, and ensure that everything works. Then I write a little JNI glue to make it accessible from Java. This has worked surprisingly well, and given few surprises. But what happens when something goes wrong?

For example: I was writing some ugly Win32 code to do some various things that can only be done in C. Despite my aversion to programming in Windows, I whipped up some native code to access what I needed. I wrote some test cases to confirm that everything worked, and I was pretty happy with myself, until I realized that all the work I had done was on ANSI C strings (ie, null-terminated char arrays.)

Regardless, I tied it up to my Java with some JNI code just to watch it fail when I passed in Unicode strings.

I'm not particularly well-versed in the intricacies of Unicode, and even less so Win32 programming with its WCHARs and PSEC_WCHARs and nasty habit of #define'ing function names to those that end in W. So I wasn't real sure of exactly what I needed to change to make my native code Unicode friendly. It sure would be nice if I could debug this in VisualStudio.

Attaching to a running process in gdb is easy - and it's easy to provide debugging symbols for that process. VisualStudio is a little less straightforward, but just as easy.

First, make sure that your DLL is emitting debugging symbols. Ensure that you're passing these flags to the compiler and linker:

CFLAGS: -Od -DDEBUG -D_DEBUG -Zi
LFLAGS: -DEBUG

Build your native DLL and ensure that a .PDB file was created - this is the debugging information for your library. Run your java application.

Open VisualStudio and setup your symbols. Go to Tools -> Options, and open the Debugging -> Symbols pane. Add a new PDB location which points to the PDB file that was created from your build.

Now you can attach to your java process by going Tools -> Attach to Process.

Finally, you can load the source (ensure that this is the source you built from, in the same directory as your PDB file) and set breakpoints, etc.

I call shenanigans. Pompous? Maybe. Galling? Give me a break.

It's true, Microsoft would never do something like this. Mostly because Microsoft cares precious little about interoperability with other network filesystems. CIFS is good enough for everybody - how's that for smug?

I suggest ignoring the whiners and embracing the BSOD icon. And then take it a step further: install xscreensaver and use the BSOD screensaver. Then smile when people tell you "there's something wrong with your computer!"

Teamprise was invited to present at this month's Chicago VSTS Users Group to discuss using TFS from within the Eclipse IDE and from non-Microsoft platforms. I'm excited to make a fool of myself speaking in public (and excited to learn that a VSTS Users Group exists in Chicago.)

I'll be speaking with David Dugan who's a Senior Consultant for Sogeti. David will be discussing accessing TFS from older versions of Visual Studio.

Maybe I'll see you there!

Perhaps this dialog doesn't look particularly strange, until you realize that the install disc only included four CD images:

(This was the MSDN install for Vista.)