DLL or Executable Versions for .NET (Assembly Versions)

This section applies to you only if you are programming in .NET.

When Microsoft introduced .NET, one of its goals was to get rid of DLL hell and all the extra setup steps I talk about later in this chapter. In reviewing where .NET is today, it looks like Microsoft has resolved the sideby-side DLL hell problem, but now the problem is "assembly version hell." Without going into too much detail about the .NET infrastructure, let's touch on the difference between file versioning and assembly versioning.

Assembly versions are meant for binding purposes only; they are not meant for keeping track of different daily versions. Use the file version for that instead. It is recommended that you keep the assembly version the same from build to build and change it only after each external release. For more details on how .NET works with these versions, refer to Jeffrey Richter's .NET book. Don't link the two versions, but make sure each assembly has both an assembly version and a file version when you right-click. You can use the same format described earlier for file versioning for the assembly version.

Microsoft Sidenote: "Stupid Versioning Will Never Die" by Scott Parkerson

This isn't a Microsoft story, but Scott's February 2, 2003 blog entry (www.smerpology.org/sprocket/?c=Writing+Software) hits some good points and is rather comical and accurate.

I blame Microsoft for starting the whole damn trend.

Back in the day, computer software was versioned by a steadily increasing number, always starting with 1.0. Computer software makers had no problem with this. Microsoft Windows was even at 1.0, but I bet few of you ever used it, let alone [saw] a copy of it out in the wild. It wasn't until Windows 3.1 that it started catching on.

Meanwhile, back in Redmond, Microsoft was developing a "new 32-bit multitasking OS" that would be the future of computing: Windows NT. The "NT" stood for "New Technology," a fact [that] seemed to elude the marketroids who designed the Windows 2000 splash screen, which proclaimed "Built on NT Technology." Ah, redundancy.

I'm getting ahead of myself. Oh. Right. Anyways, NT was the first "1.0" product that didn't have a 1.0 version number. It was mostly new code, save for the Program Manager interface. Of course, to capitalize on the Windows heritage, marketing decided to name the product Microsoft Windows NT 3.1.

Flash forward to 1995. Microsoft has redesigned the interface for Windows for Workgroups 3.11, added more 32-bit code, streamlined as much as possible. They didn't dub it Windows 4.0, which is what it was. No. It was Windows 95, starting the insane "versioning products after the year in which it was released" trend. Of course, Microsoft Office had to be numbered the same way: Office 95 (not Office 7.0). Other software makers quickly followed suit, releasing things like Lotus SmartSuite 96, Quicken 98, etc., ad nauseam.

Then there was Windows XP and Office XP. Where do they go from there: XP 2.0? NeXtP? The mind boggles.

But the thing that started this whole rant this morning was downloading and installing Microsoft Windows Media Player 9 Series. 9 Series?! I can understand "9," as it is the ninth-release of the venerable media player. But Series? Are they trying to be BMW?

At any rate, all this versioning madness is kept alive by marketing dorks who still say things like, "We can't call this software 1.0... people will think it's not ready for prime time." Well, crap. So, we should raise people's expectations needlessly to make a few bucks more at product launch, but ultimately lose the customers who bought the junk thinking it was mature? Yeah.

So, this is another "Microsoft did it to us again" rant with, at the very least, a valid point. Scott might find it hard to believe, but Microsoft employees hate all of this "marketing versioning confusion" too! It's those people with the MBAs that dream this stuff up.