August 03, 2004
Versioning Common Components

At work we have a set of inter-dependant components (a lot of which I have written) that are used in multiple products. It's important to keep all shipped versions of components so that when debugging we can use the correct component parts. There are several problems to overcome when working with components like this:

  1. the components do not change all at once, but because they have dependencies on each other they need to be built as a set, or we have complicated version mapping issues.
  2. the version numbers: we could either version all the components as a set, but this hides what components have been updated in the builds. We chose to not tie the version numbers, but this means that we need to be able to identify the correct set of versioned components.
  3. keeping the sets identifiable for debugging at a later stage.
  4. changing references to assemblies in visual studio .net is a pain, especially if the project is in source control.

I needed to develop a strategy for use and versioning because managing this lot manually was becoming a time-waster. This post details what I came up with, and in response I hope to hear other people's solutions to the same problem.

We keep a shared components directory on a server, called \\Server\SharedComponents (names changed to protect the innocent). This directory holds all shipped versions of the components, and also the current development ones. Inside that directory, there is a directory called Head. Inside head are placed the most recent builds of components that work as a set. These components are all built at the same time using a NAnt script. In fact, that's a bit of a lie because some Managed C++ bits won't build with NAnt at the moment so are done manually but in an ideal world...

The projects that we work on that use these components use the head build while in development. When the product is preparing for a release, we use the following steps:

  1. Copy the known-good set of components into a dated directory, e.g. 20040803
  2. Branch the product in source control and use a python script to check the projects out, change all the project references to point at the now stable components distribution, and check the projects back in again (with a suitable change log message, of course!).

We now have a fixed set of components for one release, and with very little effort all of the references are changed to use this build. In the future that branch can be checked out and all will be as it was on the day of release!

This solution is not perfect, identifying a set of components can be slightly hard and there are still issues with keeping change logs for component sets up-to-date but it's a step in the right direction (for us, at least!).

So tell me, how do you solve this problem?

p.s. I'll post the python script here at some point for those interested.

Posted by Simon at 12:11 PM
March 31, 2004
VS.NET 2003 Templates

How many thousand times have you created a new C# class, then deleted the ?Add constructor logic here? and/or the default, useless XML Documentation comment? Far too many, I'm sure.

Solving this problem is simple: Remove them from the template that's used to generate new classes. The file is found at the following location (VS.NET 2003):

%programfiles%\Microsoft Visual Studio .NET 2003\VC#\VC#Wizards\CSharpAddClassWiz\Templates\1033

Other templates are scattered around below the %programfiles%\Microsoft Visual Studio .NET 2003\VC# directory. Simply do an in-file search for ?///? and you'll find several more.

(I think EricGu or someone else posted something about this a while ago, but I can't find the post.)

[via Jeff Key, "Remove default comments in C# files"]

Posted by Simon at 10:09 AM
March 08, 2004
The Road to Indigo

More on my quest for knowledge about Indigo/WSE/DIME:

Rich Turner has an interesting article talking about how you can develop web services infrastructure now so that it migrates well to Indigo:
On the road to Indigo: Prescriptive Guidance for Today's Technologies

How about some coverage related to Indigo, DIME and the new MTOM/XOP stuff. Specifically, with Indigo will I still be able to send binary attachments without incurring the base64 overhead. If so, then how?

Posted by Simon at 11:17 AM
March 02, 2004
The Road to TCP SOAP...

I'm trying to learn about SOAP and related technologies. I have recently been working on a connected wire protocol which involves sending XML messages to and from client and server. Most of it is a request-response system with the occasional unsolicited server->client message. Each message is wrapped in a pre-defined XML envelope. Sounding a bit like SOAP to anyone? So, I'm interested in how I can replace part of this system with SOAP.

So, here's how it went in tonight's web info-quest:

I'm using microsoft technology to start with: .NET to .NET.

MSDN → Search for SOAP and Web Services and Messaging in various combinations. Find →
XML and Web Services → Web Services Enhancements → Programming with Web Services Enhancements 2.0TCP Messaging

In the future, I will need to send binary files from the client to the server (data for transmission). Therefore I'm also looking for neat ways to send both XML messages and the occasional bit of binary data.

I started out by noticing something about DIME somewhere. Back to MSDN →
Sending Files, Attach,ments, and SOAP Messages Via Direct Internet Message Encapsulation,
Understanding DIME and WS-Attachments - sounds good, but the article is really old (ok, really old in Web Services terms).
Google for DIME and Indigo (Indigo is Microsoft's up and coming web services stack stuff, so it's a good term to see if DIME is no longer loved) → DIME is dead PASWA/MTOM is the way to go (ah-ha!) → Back to MSDN →
Messaging Specifications Index PageXML, SOAP, and Binary Data:

Hmm, no concrete evidence of an implementation. Back to Google →

Google for WSE and MTOMDon Box's Spoutletmnot → XOP and MTOM.

Hmm. This leaves me confused. Dime is dead, MTOM is the way forward. Only it doesn't seem that anybody has bothered to create MTOM yet. What's a developer to do?

Update: It seems that in WSE 2, Microsoft are abstracting attachments from the DIME-specific to more general attachments so that migration to MTOM will be less painful: Philip Rieck.

Posted by Simon at 09:46 PM
January 29, 2004
NPerf

NPerf is an excellent new performance testing framework for .NET code by Jonathan de Halleux. [via CodeProject]

Posted by Simon at 02:19 PM
December 09, 2003
Python for .NET redux

Miguel of Mono fame notes that Jim Hugunin has created an early .NET compiler for Python that performs much better than the previous effort by ActiveState.

A copy of Jim's message can be found here.

Posted by Simon at 02:45 PM
September 24, 2003
EnableVisualStyles and ImageList

It would appear that due to a bug in EnableVisualStyles you have to call Application.DoEvents after the call to Application.EnableVisualStyles or your image lists won't work properly any more. Hope this helps someone.

Posted by Simon at 04:53 PM