How to not waste your time on stupid mistakes?

Ayende made an interesting light-hearted post concerning developers that spend hours chasing a bug in an application only to find out they forgot to do some utterly trivial thing. Well, stuff like that is maddening. The solutions to these kind of mistakes are utterly nonsensically simple yet we don't know the proper way to prevent them but instead lose time debugging.

The contradiction we have today is that we get these all-encompassing frameworks that do a lot of things by themselves, but are so big we almost always miss something when using them. And instead of losing time writing intelligent stuff we get the stuff ready-made but lose time on trivial mistakes :). But how to solve this time-wasting issue? Microsoft's answer is - guidance. It sounds promising as I believe it would generally be helpful to generate more code (at least skeleton code), but that's not so easy. Also, we should be careful when designing APIs, make them as obvious as possible (even if we have to make dozens of method overloads). And validate and assert everything we can... But that's still not enough. And the stuff we are talking about is ridiculously simple to describe: if you use a TransactionScope you should commit it. How to protect ourselves from this simple mistake? Use FxCop to validate code? Use a higher-level language? Stop coding alltogether and use an AI to generate applications?

Silverlight picks on Flash

... as Microsoft attacks Adobe's piece of the cake.

Microsoft has announced the official release of WPF/E under the official name of Silverlight.  The list of announced features is quite interesting (here's Tim Sneath's post), and it seems consistent with the philosophy we already saw with other .Net technologies: borrow everything that's good from the competitors, improve their weaknesses, integrate with .Net and make it develop-able in Visual Studio. If you know how C# stands compared to Java or ASP.Net compared to JSP, you know the answer... It's similar but not the same as SWF. Silverlight looks like a more technologically advanced version of Shockwave/Flash, it has some new ideas (like embedding XAML directly into the html page - which Flash player cannot do because it's SWF format is binary). But this is all on paper. For years Microsoft developers have been victims of unfulfilled promises: features were delivered as broken or incomplete or just silently dropped.

The real question is, will Microsoft Expression Whateveritsname be a better tool than Adobe Flash? If you compare feature lists, this is almost certain. But how will this features be implemented? There are already reports that the even the present Expression version, the Web Designer is far from complete. The other tool that could be WPF/Silverlight compatible, Visual Studio Orcas, is also in the making but if the previous Visual Studio .Net versions are anything to go by, it won't be a high quality or stable tool. For example, a major killer-feature of VS 2005, data binding, is still very much broken, even after service pack 1... And visual inheritance - present but unstable in previous versions - was just dropped in 2005's first release.

There was also some stir because the official announcement failed to mention a Linux Firefox plug-in for Silverlight. Well, I'm quite sure it had been announced at MIX 06: I remember one of the presenters declared that developing a Linux Firefox plug-in was (quite understandably) a great technological challenge for Microsoft people. I may be mistaken, it may have been just Firefox, without Linux :)... One thing should be clear, though: Microsoft's is going cross-platform not because they like Mac or Firefox but because of the antitrust case and because Adobe's already there. So, a Linux plug-in shouldn't be a big surprise at all.

There's also another interesting twist: with Silverlight, Microsoft is essentially entering an arena in which Adobe/Macromedia was the only fighter - seemingly, a benign monopolist. It's somehow strange to see Microsoft actually boosting competition instead of trying to destroy it.

Visual Studio project references

Replacing one project in a Visual Studio 2005 solution with another one is not as simple as it sounds. Partially because of Visual Studio playing smart and/or dumb but partially because of project file structures.

Let's say you have made a new branch for one of projects in your solution. It's in a separate folder than the version you're currently using and you want to change all projects in the solution to reference the new one. If you remove the old project from your solution the smartypants Visual Studio will remove references to it from every single project in the solution. Even if you could save only this changed solution and discard changes to project files (don't know if you can), it wouldn't work. Even if you open the solution file in notepad instead, and change it to include the new project, it's a no-go. The solution would probably build fine and the project references in visual studio would seem ok (no exclamation marks, paths shown in the properties window pointing to the new version) but still the wrong dll will be used.

Why is this? The project file (*.csproj) stores its own path to the referenced project and uses it instead of the solution's (this actually makes sense). It doesn't matter if the referenced project is included in the solution or not: Visual Studio will find the referenced project's dlls and use them without building the project. Only if you go to the old project's bin folder and delete everything will you get build errors for projects referencing this old version. And the curios thing is that again if you inspect the culprit project's references, Visual Studio will still insist that it references the new dll's.

So, in the end, you will use compiler errors to detect which projects reference the wrong version, and then remove-add references to change them. You probably would have saved time if you let Visual Studio remove all references in the first place.