Bring It On

In the Old Days ^(TM) when we registered COM components, added tons of registry entries, copied files to special directories and did a lot of custom actions (calling functions in our own .dll) having Microsoft Installer (MSI) technology was a blessing. Unlike custom 3^rd party solutions with crude scripting languages support we had a system supported API to install the software and a single package to worry about (.msi file).

MSI was not only good as a unified installation mechanism - machines with MSI installed had system components modified so that they become MSI aware. This means that if you install the my.dll as a part of the package but do not really copy the file to it's final destination the DLL loader will know about this and if the installation file (.msi) is still present it will install my.dll on the fly and let the app load it.

Not everything is as cool though - .msi files are a custom-format databases that are extremely hard to author so we still had to rely on 3^rd party companies to provide (expensive) authoring tools. Only recently we have seen a relatively simple and clean authoring tool based on XML configuration files and straightforward toolset - an Open Source product called WiX.

However, all this is irrelevant with the modern XCOPY model of deployment of .NET applications. Even better, soon we will have ClickOnce and won't need any installation at all (not applicable always, but great for small apps that update frequently). Do we still need MSI for .NET apps?

...you notice season change by new (quarterly) MSDN Library :) [April 2005 is out, download it if you're a MSDN subscriber]

I have been a Visual Assist user longer than I like to admit :) I remember the first time I used it (was it around the time frame of Visual Studio 5?) it changed the way I edit C++ code forever. Microsoft did have some kind of Intellisense at the time but it was slow, slow and did I mention it was slow? One other thing Visual Assist did was spoil me forever in expecting nicely colored code - there's no way I could skim over the code as fast when it is not colored, which is crucial for quick digesting of old code and especially other people's code.

But the time passed and today I work more with C#/.NET than with C++/MFC. I do plan to go “back to roots” once Visual Studio 2005 comes out and start developing types in C++/CLI thanks to great support for mixed language projects. But for the foreseeable future the biggest chunk will be C# based.

Visual Assist does work with C# and if you haven't used any other tool you'd find it quite satisfactory -- it's still better than the built in Intellisense in Visual Studio 2003 for example. But it's built for C++ primarily and does not offer any special features for C# (or any other .NET language for that matter) even though the .NET exposes a lot more metadata perfectly suitable for rich editing support.

Enter the ReSharper. Built from the ground up for C# only (no VB.NET I'm afraid) it blew my socks off after just a few days of work. It goes very far from Intellisense and truly assists you in developing software. Besides from offering smart auto-completion, it has live templates (spits out complete blocks of code with placeholders for you to fill in, very similar to what Visual Studio 2005 will offer), implements missing fields and methods (with skeleton code), performs casting where appropriate, shows you which methods hide and which override base ones, shows you unused types, fields and methods, automatically removed unused elements, reformats your code and offers great support for refactoring. I'm sure I missed some of it's features, but when you see it in action, you'll think it's magic. Highly recommended.

I was quietly reading the latest MSDN article online, minding my own business, when I run into the following sentence: As we go through this article, we'll see just how quick, easy, and flexible this is. (the author is obviously enthusiastic about a new .NET 2.0 data access techniques)

This immediately reminded me of the famous joke -- “Cheap, fast, good - pick two”. Think about it:

• If code is easy to use, rarely is it flexible
• If it's flexible it's almost for sure complex, thus it is not easy to use it
• If it's quick (to start using) it's simple, thus probably not flexible, covering only most obvious cases; if the code itself is quick, it most likely is complex, thus hard to understand and start using

Rarely can one find code that is easy to use, quick to begin with, and remains flexible while requirements change. Small and simple examples are great, but as soon as requirements get complicated (read: real-life) you need to think about scenarios, best practices, modularizing your code, further simplifying library code (abstracting away complexity in favor of your most frequent cases) etc. Once you explore the problem domain you might end up with easy to use and quick to start with code, but it will be code specific to your problem and thus not flexible.

Yeah, just pick two and move on.