Fabrice's weblog

Source-control for home and contractors

A summary comparison of some code versioning products by William Batholomew.
Read also some other opinions.

See you, see me

Versioning Hell

There have been voices talking about the lack of updates to the .NET Framework and Visual Studio, especially since we learnt that the next versions won't be released before 2005. Microsoft did not release fixes while some well known problems exist. If you don't know the "Help | Check for Updates" command in Visual Studio, it's not worth looking for it, you won't find updates there. All we got was the .NET Framework 1.1 and Visual Studio 7.1.

I may have an idea why there is no lighter and interim updates: maybe it's not easy or even possible to release updates!

How did I come to that conclusion?

Let's take the following situation with one assembly referencing another:

Not trying to compete with Rory here ;-)

If you want to update Ass1, and have Ass2 use that updated assembly, you have to update Ass2. This is because each assembly references the other ones using their name and their version. If you don't update Ass2, it will continue to use Ass1 version 1.0, the version it has been built with.
If you take that to the Framework level, it's all a bowl of spaghetti with dependencies everywhere. Don't forget also that applications, components and Visual Studio are also part of this Italian delicacy and tied to it as well.

Releasing a fix to one assembly requires releasing new versions of all the assemblies referencing it. If you touch a part of the framework, you need to review the whole of it. This is not bad, this is even a good thing in fact. This ensures that the framework is consistent. But it is understandable that Microsoft cannot release multiple version of the framework. We all know how difficult it is to get a new version of the framework (like any other software, especially from some companies) to be validated by administrators. Imagine what a mess it would be if there were versions 1.2 and 1.3 in addition to versions 1.0 and 1.1... You would also have to update your application so they benefit from the new versions.

Do I miss something? What solution do you see to that problem?
Trying to get rid of the DLL Hell, are we locked in an Assembly Versioning Hell?

What about some refactoring?

When you work with configuration files throughout the framework and the application blocks, you encounter assembly qualified names. Assembly qualified names (AQN) look like this: "MyNamespace.MyClass, MyAssembly". This is useful, because a string like this gives you everything you need to find a type. You can simply use Type.GetType() to access a type, based on its AQN.

I was searching for a method to parse AQNs for my own configuration files because I need to call Activator.CreateInstance(string, string), which expects assembly name and type name broken apart.
Well, I looked in the framework, and I found several methods.
There is Assembly.ParseTypeName(). There is TypeInfo.ParseTypeAndAssembly(). There is RemotingXmlConfigFileParser.ParseType().
The first one is internal to the CLR, the others have implementations of their own. Maybe more implementation are scattered around the framework, and maybe more in application blocks or other apps.

I'd say it's time for some refactoring to create one and only method in the framework. It's not because writing this method is difficult, but it's violating the DRY principle. What if AQNs change in .NET 3.2?
It would be nice if this method gets public too so we don't have to write our own...

Slowing down your horses

Now that the dates for Whidbey and Yukon have slipped again (Visual Studio 2004 is now Visual Studio 2005, and VS2005 is now VS2006 or VS2007!), maybe we'll see less madness about all the fabulous novelties in Whidbey, Yukon and Longhorn. Looks like we won't be deploying on Longhorn before 2009. That's 5 (FIVE) years from now. Unless you live in the future, maybe you'd better focus on the now more than on the cool new upcoming features...

Update: the title of this post should probably be "Slowing down your white horses" :-)

Software for Rent

Do you think a rental model for software could exist?

There are some software that I use only occasionally, such as disk partition managers, disk defragmenters, benchmarking tools... These tools can't be used online for obvious reasons, so they'd still have to be downloaded. No ASP model.

But still, maybe I could avoid buying these products, but instead rent them like I could rent a car or a DVD?

The Data Loader Object design pattern: Lightweight Containers, Inversion of Control, Abstract Factory

Sami Jaber published a new article on DotNetGuru (in French, but to be translated soon on the English DotNetGuru - Update: now available in English) about lightweight containers such as Pico, Spring, Avalon or HiveMind. As a complete gringo to J2EE, this notion of containers and Inversion of Control was completely new to me.

Well, maybe it's not so new to me because it reminds me of something I did recently.
I have this Document object that contains some data structures. Let's call those, Struct1 and Struct2. These structures need to be loaded from some database somewhere. For the sake of simplicity, let's forget how the datasources are identified. What is important is that the data structures be completely independent from these data sources, mainly because we could want the data in an SQL database, in XML files, or whatever. This is why I use Data Loader Objects.

Here is how it works when the Document object needs to be loaded:
The data structures are contained in an InstanceCollection object. This instance collection is put into a new instance collection, under the ID Targets. The loaders then get created in this new instance collection, based on a configuration file. The loaders are created using a Provider pattern (I just call it the AbstractFactory pattern).

The loaders are automagically connected to their respective data structure with property setters. As the following configuration file states, the Loader1.Target property points to Struct1 in Targets ("Targets/Struct1").

Once this is set up, the loaders get executed and fill their respective data structure with data.

With this solution, the data structures are isolated from the data sources, all is configured, extensible and customizable.

Busy week-end

Looks like that will be a busy week-end :-)

That's right, two blue boxes...

Method invocation raceway

Eric Gunnerson published an article in which he tests the different ways of invoking a method.

Pierrick Gourlain (no weblog yet...) updated the code to include tests with new cases: virtual, virtual+interface, static, MethodInfo.

I won't publish the results here, you should download the code and run the tests by yourself.
You absolutely have to try running the tests with a Release build and with a Debug build. What do you observe?
BTW, do you deploy your assemblies as Debug or Release builds?

Tips for running a beta test