tf4mono for windows

Thanks to Nullsoft Scriptable Install System, I've created some win32 installation packages for tf4mono.

There are two install options.

The first, tf4mono-base-0.5.1-rc1.exe, has been compiled without any GUI code. It has no external dependencies and should run on any win32 box with the .Net 2.0 framework installed.

The second package, tf4mono-full-0.5.1-rc1.exe, includes the graphical TF explore command. To run this version on win32, you must first install the Gtk# Installer for Windows.

Neither package adds the tf4mono installation folder to the SYSTEM or USER path. You'll have to do this by hand for now.

If you're on a windows box and have a few minutes to test out the package, please do so. Any feedback on how they work would be awesome.

Explore Command

Rather than try to learn how to write a monodevelop plugin and the Gtk# API all at the same time, I thought I'd start out by just getting my head around Gtk#.

Consequently, I've been working on a tf explore command that popups a Gtk# Application that lets you explore the TFS repository you're connected to. Here's what it looks like thus far:

I've been pretty impressed with the available widgets and their ease of use.

I can't quite figure out yet how to show a WATCH cursor when the TF query is lengthy - I've tried several different incantations but all to no avail.

That's the only thing that seems like it should be easier.

Read-Write Local Trees in TFS

One rather annoying feature of TFS is that all files are marked read-only in your local tree until you checkout a file, at which point it becomes read-write. Its not hard to find other people who also find this very annoying.

I was hopeful MS would make read-write local trees an option in the Orcas release of TFS, but recently came across this post by Buck Hodges where he explains it won't be a feature in Orcas.

I was annoyed enough to add support for read-write files in version 0.5.0 of tf4mono.
To enable it just type

tf config File.ReadWrite true

Then from that point on tf get, tf undo, tf checkin, tf add and friends will do the right thing.

If you know what you're doing you can compile and run the tf4mono client on Windows, either against the MS TFS assemblies or with the tf4mono implementation of these assemblies.

I didn't want to lose this flexibility but to really do this right API level support would be required. Subsequently, I ended up teaching the tf4mono TFS assemblies to read the TF client XML config file. This is slightly distasteful but the standard assemblies already read the workspace cache XML file so I can live with it. I really didn't want to bolt this read-write stuff on top of the existing code, because that would have meant alot more stat's and chmod's under the hood.

Anyway to really make this work I also had to beef up the tf online command, but that will have to wait for another blog post.

Mono.GetOptions working overtime

When I started tf4mono, the command line Team Foundation client, I didn't really want to invent yet another option parsing library and it seemed like Mono.GetOptions would fit the bill.

Over time though I found myself adding more and more options to my Options.cs file, which really got out of hand. Finally, I found myself in a hotel room in Tulsa, Oklahoma with no internet access - a perfect time for code cleanups!

I ended up keeping global options in my Options.cs and moving all command specific options into each *Command.cs file, then I give both the global driver and the desired command a crack at parsing the arg array. With a little extra hackery to support command chaining, I ended up being able to do a huge code cleanup and really enhance the builtin tf help command.

While I was mucking around in there, I added a custom "Command" attribute to decorate my Command classes. Now each command in the tf client looks something like this:

[Command("history", "Display changelog history for specified file.")]
class HistoryCommand : Command
{
[Option("Recursive", "R", "recursive")]
private bool OptionRecursive = false;

[Option("Stop After", "", "stopafter")]
private int OptionStopAfter = -1;

With a little reflection, the tf client now has a reasonable tf help <cmd> feature, which gives you:

(/usr/local/src/tfs/tools/tf) tf help hist
history (alias hist)
Display changelog history for specified file.

Valid options:
/format:ARG        Format "brief" or "detailed" (also /F:ARG)
/recursive         Recursive (also /R)
/stopafter:ARG     Stop After
/workspace:ARG     Workspace name (also /W:ARG)

Now I just need to figure out a way to generate the asciidoc manpage source file from the builtin help and life will be golden.

Working on the fringes

Probably like most programmers, I enjoy coding a lot more than I do writing documentation. To combat this, I've decided I should force myself to write one new doc for every release of tf4mono that I make.

To that end, for the upcoming 0.4.7 release, I've whipped up a summary of the differences between the tf4mono TF client, and the standard MS client. In particular, where is tf4mono's TF better, and where is it worse. Lately, I've personally found myself leveraging the tf4mono client on my windows boxen to great benefit. YMMV.

As an aside, if you are looking for help with tf4mono, consider the new Google Group.

tf4mono on windows and ntlm authentication

Recently, I've had occasion to run not just the tf4mono "tf client", but also the tf4mono TeamFoundation assemblies on a windows virtual machine.

This uncovered several platform related issues, like code that was deleting or updating files that were read-only and deleting files that we still held open.

More importantly though, I got a new perspective on the longstanding issues I've seen with NTLM authentication on Mono from my linux box. Tf4mono basically is a client for a bunch of Team Foundation web services that frequently are setup to use NTLM for authentication. So here is what I found:

• on mono/linux I see periodic, somewhat predictable NTML authentication failures


• on mono/windows, it fails every time


• on msclr/windows, it works every time

I'm of course somewhat encouraged by the msclr/windows findings, which lead me to believe its not a problem in my code. Whew!

When I dug into the issue previously on mono/nix, I saw something somewhat similar to bugzilla bug 80687. Jim Matysczak suggests the problem is "that the the type 1 message and the type 3 message are not being sent in the same socket connection which is required by the protocol."

By the way, all the windows related changes are all in the project subversion and git repositories, but not in any release yet.

TechEd Musings

I spent the last week at TechEd Orlando and blogged about much of it on the internal company blog site. I thought I'd take a minute to post some thoughts for the Mono community as well.

It seems like "platform services" like Windows Sharepoint Services and Active Directory present a unique challenge when we're talking about Mono enabling cross platform solutions. They seem challenging to me because they're not just about writing more library code, you've got copyrighted UI images, underlying database engines, directory services, etc..

At TechEd, I definitely got the impression that developing ASP.NET solutions on top of Windows Sharepoint Services would become increasingly common and of course, be encouraged by MS. You get the seem impression about ADFS, which enables federated claims-based applications.

Does this mean more and more ASP.Net applications will become unportable, or will the community rise to the challenge of building out these type of server "platform services"? I'm wondering.

On another note, it was neat to see how MS is building on the .Net 3.5 System.ServiceModel.Web stuff and the ADO.Net Entity Framework, to build out Project Astoria, which is a REST based framework for data access for Ajax/Silverlight type clients. I'm sure hoping that the WCF mono bits around System.ServiceModel.Web that enable this don't prove hard to implement.

Demystifying a Black Art

I'm working my way through Steve McConnell's Software Estimation: Demystifying the Black Art.

He starts off by making it clear that estimates are NOT the same thing as targets or commitments. Often business partners might ask you for an "estimate" when really what they want is a commitment to a target date.

In fact, estimates should be seen as probability statements. Steve recommends you always give estimates as a range like "2 to 5 weeks", or as a number plus a probability like "I'm about 80% confident I can get this done in 4 weeks." I personally think giving a range is a much better practice - business partners are too quick to forget the stated probability in the latter approach.

So what is a good estimate, for most people not building bridges or nuclear reactors? Here's how he defines a "good estimate:"

A good estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets.

The idea? Get the target date and estimate date range close enough and a good project manager can get the project in on time be shifting resources, simplifying/dropping requirements, etc. The estimate serves as a way to see if you are close enough to make the target date a reality with tweaks along the way.

Anyway, if you are interested in learning more, consider buying the book.

System.ServiceModel.Syndication

Eventually, I'd like to add a "tfsweb" capability to Team Foundation for Mono, that would, as much as possible, mimic gitweb's capabilities.

With this in mind, I'll need to create Atom/RSS feeds to which users can subscribe so they can track changes to a TFS repository over time.

In hopes of not having to rewrite the Atom/RSS code sometime in the future to leverage the .Net 3.5 syndication classes, I'm taking a crack at adding the System.ServiceModel.Syndication clases to the mono olive tree.

As a starting point, I'm trying to make Matt W's syndication example code produce the same output on MS.Net and Mono. Is anyone else working on this namespace? Right now I have:

Assembly/AssemblyInfo.cs            |   57 ++++++++++++++++++++++++++++++++
Atom10Serializer.cs                 |   54 ++++++++++++++++++++++++++++++
Makefile                            |   22 ++++++++++++
README                              |    4 ++
SyndicationContent.cs               |   45 +++++++++++++++++++++++++
SyndicationFeed.cs                  |   63 +++++++++++++++++++++++++++++++++++
SyndicationItem.cs                  |   57 ++++++++++++++++++++++++++++++++
SyndicationSerializer.cs            |   50 ++++++++++++++++++++++++++++
System.ServiceModel.Web.dll.sources |   11 ++++++
TextSyndicationContent.cs           |   64 ++++++++++++++++++++++++++++++++++++
TextSyndicationContentKind.cs       |   40 ++++++++++++++++++++++
11 files changed, 467 insertions(+)

Not a whole lot yet, but on the other hand this looks like a pretty straightforward namespace to implement that won't take alot of time.

tf4mono version 0.4.4

I've pretty much implemented all the features I'm looking for in a Team Foundation client for Mono, added all the usability enhancements necessary for things like password caching in the gnome keyring, and added some configuration extras for those who don't like the default behavior of the TF SCM client. Its all packaged up into the 0.4.4 release of tf4mono.

I tried taking a crack at implementing a TF version control plugin for MonoDevelop, but the way TF works is so much different than SVN, that I'm having second thoughts about this approach. I'm thinking now that maybe I should base something off of the Mono.Addins infrastructure. TF has all this stuff about workspaces, mapped paths, read-only files till checked out, etc. that don't mesh well with the traditional SVN/CVS model. Its more akin to Visual Source Safe.

tf4mono version 0.4.2

I just released a new version of Team Foundation for Mono.

Highlights of this release include:

1. tf.exe supports two new commands: "ls-files" and "properties".

ls-files has options to show modified, out-of-date, unknown, and locally deleted file listings. This functionality doesn't exist in the Microsoft tf.exe client, and may be a reason to run tf4mono's tf.exe on Windows.

2. the tf.exe undo command now restores deleted files

3. tf.exe now compiles/runs on MS CLR.

4. Added API support for querying ExtendedItems.

5. Debian packages via "make dist"

6. Add GettingEventHandler, PendingChangeEventHandler, ProcessingChangeEventHandler, and OperationStatus delegates.

7. Many bug fixes were made to APIs, and client utility while testing on Windows. Greatly improved handling of ~/.tf/VersionControl.config cache.

8. Start of MonoDevelop plugin based on Subversion plugin. I'm not quite sure I can really map the way Team Foundation works onto the MonoDevelop VersionControl framework, but we'll see. Fundamentally, the way TFS works is much different than SVN.

tf4mono project site

I'm setting up a Google Code project site for my Team Foundation for Mono project.

I've been hacking out the Version Control assemblies for some time and recently started working on a MonoDevelop plugin.