Job Openings

If there's anyone looking for a ASP.Net developer position in the Pittsburgh (PA) area and you've contributed to the mono project in the past, please put a link to your resume in the comments for this post. We're a great company to work and are early adopters of .Net related technologies. I'd love to be able to hire folks who have helped out the mono project. Thanks!

MonoDevelop and Team Foundation

Now that MonoDevelop is nearing a 1.0 release, I thought I'd take another look at fleshing out a TeamFoundation plugin for MD.

For starters, I'm taking the "tf explore" command in OpenTF, factoring out the Gtk classes into a separate assembly, then building out an MD addin that makes use of it.

Obligatory screenshot:

It will take a while to clean up this code and the build machinery, and to figure out how to make better use of builtin MonoDevelop addin services, but perhaps in a release of two, we'll have something useful. If you're interested in helping, please do!

At some point, I'm also hopeful that those developing the VersionControl API for MD can consider the needs of a Team Foundation plugin. I'd be very interested in seeing if we can make something work for SVN, GIT, etc. and TFS. That'd be a much better situation.

OpenTF Build Changes

I started the OpenTF project out by copying the Mono Olive tree, and replacing its assemblies and tools with my Team Foundation files. This worked well on *nix, but recently I've been trying to improve support for building on Windows as well.

Should I use cscript, nmake, powershell, BAT, project files, or some combination of these? How could I implement a build solution that didn't just duplicate the same build instructions (source files, references, etc) in 2 different formats: one for windows and one for *nix?

I decided to keep things simple on Windows - just use a VS2005 solution with a bunch of project files. Then for *nix, I decided to make libxslt's xsltproc a build requirement, and generate the list of sources and references for the mono olive make machinery using a few simple XSL stylesheets.

For example, all the .sources files are now generated via build/sources.xsl. Which looks something like this:

  <xsl:template match="/">
    <xsl:apply-templates select="Project/ItemGroup/Compile"/>
  </xsl:template>

  <xsl:template match="Compile">
    <xsl:value-of select="@Include" /><xsl:text> </xsl:text>
  </xsl:template>

I also have .references files for each assembly, also generated via an XSL file from the .csproj.

Now, I just maintain the VS2005 project files, and leave the *nix build stuff to the stylesheets. I added support for conditional sources using the Conditional attribute. Its working quite well thus far.

Using git-svn with Mono

Why use git to hack on mono?

I've found myself far more productive and make heavy use of feature branches and squashed commits for my day job, so when I hack on mono, I really enjoy being able to leverage the same capabilities.

By "squashed commits", I guess I should really say, leveraging the power of a distributed version control system that lets me break down a task into many smaller steps, commit each step individually, then squashing the whole thing down to one patch that I can post to mono-devel for review.

So do you set things up to use git with Mono?

cd /usr/local/src/
mkdir mono && cd mono
mkdir mcs && cd mcs
git-svn init svn+ssh://username@mono-cvs.ximian.com/source/trunk/mcs
git-svn fetch -r 86200 && git-svn fetch
cd ..
mkdir mono && cd mono
git-svn init svn+ssh://username@mono-cvs.ximian.com/source/trunk/mono
git-svn fetch -r 86200 && git-svn fetch

Note: the above recipe copies the svn history only back to revision 86200. You can pick any valid svn revision number you like, or if you want the full revision history see this page on the Mono wiki.

Ok. Everything's setup. Now what?

First, let's say I want to hack on some ASP.NET ashx page bug. I'll setup a local branch "ashx" to store whatever code I write/change:

git-checkout -b ashx

Now I have two branches: "master" which was setup by git-svn above, and "ashx" which I just created and switched over to. Now, I can:

emacs -nw class/System.Web/...
git-commit -a -m "1st step"
emacs -nw class/System.Web/...
git-commit -a -m "2nd step"
emacs -nw class/System.Web/...
git-commit -a -m "3rd step"

Ok, now to post a message to mono-devel:

git-diff master ashx > ~/Bug6884.fix
mutt

When everything looks good and no one has any complaints, I can finally commit back to mono's svn repository with:

git-branch master
git-pull --squash --summary . ashx
git-commit -a -m "message for mono's svn"
git-svn dcommit

This "squashes" my commits down into one batch of changes on the master branch, which I then commit and push to svn repo.

Finally, How do I update my local tree?

git-svn fetch && git-svn rebase remotes/git-svn

Note: This will update the current branch you are on locally.

Hope someone finds this helpful!

test RPM for tf4mono

I just caught up on my reading of the mono mailing list and saw Miguel's post about Mono Packaged .NET apps for Mono.

Since I have debian packages and a win32 installer for tf4mono, I thought it might be time to make an RPM package as well and maybe help this QA effort.

Anyway, I downloaded the very helpful Mono 1.2.5 VMWare image and went to work on creating a spec file for rpmbuild. Side note: cleaning out the bash history and ~/.ssh might be a sensible improvement to this image.

I had to try and remember all the old rpm command line options I used to use in my sleep - as I fell in love with debian's apt-get several years ago and forgot most rpm incantations.

Anyway, here's the resultant RPM package. By the way, I enabled the optional gtksourceview-sharp based syntax highlighting in the package.

If anyone can review the tfs.spec.in file or the RPM file and offer suggestions for improvement, please do so. I'll gladly make a necessary cleanups.

I installed the package and ran "tf show build" and "tf show stats /server:my.tfs.server.ip" and "tf explore /server:my.tfs.server.ip" and everything seemed in order. The "tf show" commands are new in the soon to be released 0.5.2 version of tf4mono.

Monthly Sleep Deprivation

Oddly enough, I've seem to have fallen into a schedule of releasing updates
to tf4mono about once a month. This month's release is
tf4mono 0.5.1 which includes win32 installation packages, a GTK-based gui mode
for exploring TFS repositories, many command enhancements, improved builtin help with
usage guidelines, and numerous bugfixes.

I always need a bit of downtime after a release first of course -
working on open source software as a hobby is fun,
but always ends up meaning lost sleep every so often.

Anyway, I'm interested in hearing what features would make tf4mono
more useful to you. Better support for locking files? Handling merge conflicts?
Easier building on win32 platforms? More GUI support? Let me know!

The master/trunk branch of tf4mono just got a "stats" command which makes use of
/VersionControl/v1.0/administration.asmx to generate some server statistics.

Here's some sample output:

(~/Source/tfs-lsg-1.0) tf stats
Files:           812421
Folders:         20033
Groups:          481
Pending Changes: 7907
Shelvesets:      180
Users:           184                                                                         
Workspaces:      154

I plan on augmenting this output a bit, but its a good start.

The most nagging issue for me is actually a NTLM bug in mono that I keep hoping someone will eventually fix. It could be bug
#80687, though I'm not sure of it. On windows boxen, tf4mono never gives occasional auth failures, but on mono it does - especially on a fast network.

By accident, I noticed that I never saw any auth failures when working from home
over a VPN, but at work I'd see the auth failures quite regularly. If I route my
TFS traffic at work thru my home machine, thru the VPN, and back to work I never see auth failures. So it seems the faster the network the more likely you are to see this NTLM bug in mono.

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.