Yep. It flat out refuses to install on Windows Server. Firefox installs, Windows Media Player installs. But the plugin for Windows Media Player in Firefox doesn't. Bah humbug.

Right. Let's get that sorted. Download the .exe from the download page. Use your favourite version of 7-zip to extract all the files - the exe is just a wrapper around an msi file. Right click on the file and select Edit with Orca (Orca is an msi editor that comes with the Windows SDK, but it's not installed by default. The orca.msi file is in the bin dir). Now, find the LaunchCondition table and see the MsiNTProductType=1 condition. This is the one that's causing us the trouble. Right click, select drop row and save the file.

All done. Firefox can now play Windows Media files. On a server! Oh me oh my! The end of the world, etc, etc, etc…

I’ve dipped my toe into the open source waters a few times over the years, and it’s surprisingly hard to contribute. Now, I want to stress that this isn’t anything to do with the projects or the people involved – I’ve nothing but praise and admiration for all of them. Love you guys.

These are the problems that I see facing you:

1. Understanding the codebase. I downloaded the X Window System source once. And Firefox. Big mistake. Couldn’t understand a thing. There was just too much code. To set some kind of perspective, the current Chrome source requires 1.6 GB of hard drive space. The investment required to learn such a system well enough to fix a bug or implement a new feature is just huge.

Yeah, I know, I've picked the world’s largest OSS projects, but it should be recognised that there is a cost to not just learning the what and how of a codebase but also the why. It’s easier to change some change, it’s harder to change the right code.

2. Going dark. Jeff Atwood has already written about “going dark” – suddenly bounding up to an Open Source project with a massive code change that implements some huge feature or other. The trouble is, it’s very, very easy to go dark on an Open Source project.

I’ve done it. This blog has, for the last couple of years, run on a bit of software called Single User Blog. It was open source, I got a copy and used it to learn asp.net. And I made so many changes I ended up with a totally divergent codebase. Most of the changes I made didn’t get contributed back.

The trouble is, as a first time contributor, the desire is to contribute something worthwhile – which means a completed feature, not a string of small refactorings.

There’s an obvious solution here – communication. Talk to the project team, raise the issue, propose a solution, work on the implementation. Which leads us to…

3. It’s not your project. Perhaps the project team doesn’t want your feature or wants to implement it differently. You’re at the mercy of someone else.

And this one is also a downside to using Open Source software in a commercial environment. At my last place of work, we implemented a WS-* based security architecture in Java. We wanted to use one of the various Open Source libraries out there, but none of them fitted our needs – they didn’t implement enough, and didn’t provide enough extensibility hooks.

We had to make significant changes.

And we had no guarantees that those changes would ever make it back into the project. That was quite a gamble – we had a highly customised version of an open source project. We could no longer take updates from their code, meaning we were now completely responsible for the entire codebase.

Options here are forking (and the cost of owning the new project), and, yes, communication.

(But communication can be too slow. In this instance, we didn’t have the time to develop a relationship, discuss a roadmap and submit anything other than an aforementioned code bomb. Is that a cop out?)

4. IP agreements. This is one I hadn’t thought of, but is, in hindsight, completely obvious and eminently sensible. How do I, as a project leader, know that the code submitted by Joe Random Programmer is theirs to contribute? That it wasn’t created on work time, with work resources? Or that it doesn’t contain some patented implementation? And once you do contribute, who owns the copyright to that code?

So, you have to sign some sort of agreement and return it to the project.

Yes, if you intend to contribute source code or other materials which are intended to be compiled or otherwise integrated with the OpenOffice.org product, regardless of the size of the contribution (e.g., including contributions of 10 lines or less). However we encourage all contributors to the OpenOffice.org website domain, including the wiki, to fill out the SCA, as it streamlines the process for all.

I like WinMerge. It’s a nice, free file comparison program. Works very well indeed.

I have just 2 problems with it.

Firstly, it doesn’t support three-way merging, meaning I can’t use it for TortoiseSVN (that honour goes to SourceGear’s DiffMerge), but it’s great as a stand alone file diff-er.

Secondly, it comes with a poor set of defaults. Now, you can import and export your customised settings, so here’s a copy of mine. Main differences:

No splash screen

Consolas as the main font

Automatically scroll to the first difference

Multiple windows for file and folder comparison (why wouldn’t I want this set?)

Moved block detection is enabled – this can get much better results in the diff, and the location bar on the left shows a link between the source and destination of the moved block

Automatic rescan – detect new changes after each change to the file

Disabled backup files

And the biggie – changed colours for inline differences. By default, WinMerge checks for changes within a line, and displays those words that are different in a different colour. But, it displays the differences with a lighter colour than the rest of the line, de-emphasising the changes:

I’ve just swapped the colours, so the changed words are a darker shade, making it more obvious what’s changed:

Simple, but effective. And I’ve had to do this enough times, that I thought I’d output the settings so I’ve always got them to hand. If you’re interested, grab them from here.

I’ve come across this a couple of times, and it’s an awkward problem and an easy fix, so I’m letting this out into the wild, straight into the jaws of Google

The problem: Take a VS2005 solution, migrate it to Visual Studio 2008. Start running unit tests in the Resharper test runner. Change some code in the test or in the system under test and re-run the test. The code isn’t rebuilt. Blast.

Another symptom is the inability to debug your tests, even though the assembly has been built in debug mode.

The fix: Go to Build -> Configuration Manager. Whenever I’ve encountered this problem, the Active solution platform drop down has “Any CPU”, “.NET” and “Mixed Platforms”. A brand new solution (where Resharper runs as expected) only has “Any CPU”. Can you see where this is going? Yep. In the drop down, click “Edit...” and in the new dialog that appears, remove anything other than “Any CPU”. All should now work as expected.

This has been a public service announcement. And now, back to your normal working schedule.

Up until recently, SkyDrive and Live Sync (nee FolderShare) have been quite standalone offerings. You had a storage service, and a program that synchronised folders across machines. But they weren’t really integrated with each other – or indeed anything else.

Which made it all the more confusing that Microsoft was also offering Live Mesh – a synchronisation and storage platform. What was the deal? Why have both sets of services?

And now that we’ve seen Sync and SkyDrive in context, it’s obvious where Live Mesh fits in – it’s an evolution of these services, taking their functionality apart and putting it back together in a way that is more than the sum of its parts.

It’s nice to know that Mesh has a home to go to, and it’ll be very interesting to see what Windows Live does with it.

If you’re going to be ghost written, it makes sense to get someone good to do it for you.

ORM is clearly a religious issue, and some buy into it more than others. I’ve got reservations, and Jeff Attwood recently articulated them very nicely in a number of Twitter posts. Namely, ORMs are great for maybe 95% of the problems, but that final 5% you pay for.

codinghorror: for me, "leaky abstraction" means I am *forced* to understand the layer being abstracted to get it to work right. ORM,webforms.

And I think this pretty much nails it for me. The impedance mismatch is still alive and well and causing problems. Or to put it another way:

the only way to truly resolve the ORM problem is to get rid of the letters "O" or "R", depending on your tastes.