Visual Studio 2005 Service Pack 1, part two: installation

Ok, I've installed the bugger... (Umm, bugger? This is actually an interesting attribute for anything related to software development :))

First try: installation on a "clean" machine (no SP1 beta, no CTPs and the like). Forced me to uninstall Web Application Projects add-in: the installation package claims the add-in is included in the SP (although there have been controversies about this on the net). The installation takes a bit more than an hour. I don't remember how much it took to install Visual Studio, but compared to SP1 beta's 3-4 hours, this is nothing.

Upon first installation, I tried randomly opening several forms, controls and our components with our own custom-made designers. Either I was (un)lucky or Visual Studio really started behaving much better, but I couldn't get any of the errors I kept getting earlier (like "path is not a legal form"). I did find one bug from earlier though, and it was the first one I tried: if you try to "Open containing folder"while you're in a exception-breakpoint, Visual Studio will freeze until you force-close your application.

Second try, over a SP1 beta installation. Well, it's also not true that you have to uninstall SP beta, at least on Windows XP. At least in my case... Once again, no problems.

As for the quality of the service pack, it seems satisfactory. Visual Studio does seem to run more smoothly. I haven't experienced any slowdowns, component loading errors don't pop up as often etc. I even noticed that marking of container foreach statements when you type "break;" into the C# editor once again works.

So, the conclusion? Visual Studio works better with SP1 than without. It almost seems to behave nicely, but it's early to say. In any case - recommended.

Visual Studio 2005 Service Pack 1

The Visual Studio Service Pack 1 is here, hooray... We'll see what it brings, but I won't be surprised if its installation disclaimer contains a phrase like "don't expect it to solve any of your problems". According to some bloggers, you should uninstall May LINQ CTP before you install this one... Now, I'm sure I do have some of LINQ CTP's installed, but I haven't the faintest which one it is since LINQ is in its own brand of chaos with various plugins, addins and designers all being of different versions (so, is the september designer CTP the one that works with may LINQ CTP? I think I have a september CTP of something...)

But that's OK, LINQ is a pre-release software and you're expected to have some trouble with it. On the other hand, Service Pack 1 is kind of a post-release, so... We'll see. For the time being, I heard that its installation takes longer than the initial Visual Studio installation. This is because it -- according to Microsoft -- does more tasks than the original installation which just copies files. Makes sense when you say it that way. The Beta 1 had a different explanation, they said it was slow because it's beta. Some guys say you have to uninstall SP1 beta before you install this one, this could mean even more wasted time. Not cool if it's true.

And, last but not least, I'm almost looking forward to having this installation reset my Visual Studio UI again. I've lost my Debug/Exceptions, Attach To Process and various Build menu commands so many times just thinking about it happening again makes me laugh (I haven't restored them this time, so go hide them if you can!) I don't think I care anymore.

Under the hood of Microsoft applications

Several blog posts ("Ankh and AccessViolationExceptions", "Ankh and Exclude From Project", "Losing faith", and others) from Arild Fines, one of AnkhSVN authors, reminded me how peeking under the hood of Microsoft applications can be a horrific experience. Anyone who has ever tried to create a non-trivial plug-in for Office or Visual Studio can confirm this. You work with events that don't get fired or get fired at the wrong moment (like Document.BeforeSave, among many), undocumented features and bugs that will slow your brain to a crawl, let alone your development, and force you to use workarounds so ugly you'll end up hating yourself :). Of course, doing it in C# brings additional interop-related problems and you have to resort to reflection for many operations that would otherwise be straightforward. That is why I'm always suspicious of Visual Studio plug-ins, especially the ones that replace Visual Studio features that didn't work well in the first place, like source control. AnkhSVN is probably a case in point: these guys are struggling to get this thing working, but there's always a danger of triggering a ridiculous bug in the environment that will make a feature unusable. Of course, if AnkhSVN blows, people will blame AnkhSVN, not Visual Studio. It's a bit like the endless argument between Microsoft and device driver makers about whether unstable drivers caused Windows to fail or bad quality of Windows caused instability in drivers. It is sobering, though, once you see how much trash is hidden under the surface of Microsoft applications and how much effort was invested into hiding bugs rather than eliminating them.

Codename whirligig

People inventing codenames at Microsoft had finally gone mad. Microsoft's implementation of AJAX, formerly codenamed ASP.Net Atlas has now been renamed to ASP.Net AJAX. What an original idea! I have a hunch that the same guys named Microsoft Expression, formerly codename Acrylic, formerly Fractal Expression. It's a pity that court order prevents them from renaming Microsoft's implementation of Java to "Microsoft Java (formerly codenamed C#)" :).

Subversion support in Visual Studio 2005

Oh, while we're at it... I've been experimenting with Subversion support for Visual Studio 2005. Tried these:

AnkhSVN - the "official" plugin, and probably the most advanced of the bunch. Open source, too. Works nicely with two caveats: if you create a new file, it won't allow you to delete it or rename it until you've committed it to SVN. Which is either stupid or I'm unaware of SVN rules (and I am). The second one is that if you rename a file, it will get irretrievably lost, and you'll have to juggle around with SVN just to get the previous version back. I understand that SVN is trying to make the best of its capability of tracking files across renames, and that the error is due to a bug in Visual Studio, but I'd be satisfied to lose the rename capability in order not to lose any files. Also, you should be aware that this is a beta version: you have to use the beta in order to get the plugin working in VS 2005. http://ankhsvn.tigris.org/.

Update (2006-11-22): the cleaning up of bugs in AnkhSVN has gotten into the RC4 phase. It works considerably better, but still has bugs. I'll be keeping an eye on this one for sure.

Visual SVN - this is a proxy between Visual Studio 2005 and TortoiseSVN, and costs $19. It's not very integrated in the Visual Studio. While AnkhSvn shows status icons on all of the files in solution view, VisualSVN does no such thing. And once you click on Commit or Update or whatever you want, it just opens TortoiseSVN with the requested command. So you still have to work with folders, not projects, and add new project files manually to the repository (AnkhSvn does this from the IDE, although I'm not sure whether it behaved strangely or I don't know how to work with SVN). http://www.visualsvn.com/

PushOK's SVN SCC proxy - this one is a bridge between the Sourcesafe API and SVN, so it looks to Visual Studio just like another SourceSafe. I couldn't get it to work, though: it said there has to be a windows service for making the files under source control read-only (I suppose Visual Studio expects that) and that the service should reindex my files in order for the plugin to work. I let the service do its magic, but nothing happened. The other PushOK's plugin, CVS for VS 2003 worked nicely for me, though, so I guess this is not a general quality issue (come to think of it, I haven't checked if the plugin was VS 2005 compatible at all). Oh yeah, this one is not free but almost: it's around $20. http://www.pushok.com/soft_svn.php

Visual Studio .Net: long-forgotten features

It's an absolute beauty how Microsoft can pleasantly surprise you when you find out that a feature you'd given up long ago has actually started working in a new version. We on the Microsoft platform are humble persons. And we learned to be like that the hard way.

For instance, who other than Microsoft can give you a mail client that doesn't allow you to send or receive any attachment you like? So gradually you give up on even trying to send EXE's, when one day you find out there's a configuration parameter that lets you turn this "feature" off. By then, it's too late, you've already set up your FTP server for sharing files, or whatever ;).

Of course, I'm exaggerating a bit, but it's much worse in Visual Studio world. For example, when you walk through the call stack, does the debugger in VS 2005 display the correct line of code instead of displaying the next one? I haven't noticed: stopped paying attention long ago. Don'trust that mangy debugger no more since the time it used to enter both the if and the else branch (it actually did, in VS 2002).

Hey, there are even new features in this version: press F1 in Visual Studio 2005 and you'll be doomed to biting your nails down to the bone while you watch MSDN explorer reindexing the gigabytes of its documentation for the umpteenth time. I'm stumped as to how they managed to screw up a simple document viewer, at least this should be easy to get right? Nevermind, I'm now using my Firefox for .Net class reference: Google is much better at finding stuff on the MSDN site than MSDN is. I don't know if the MSDN site also reindexes it's contents on every access (it probably does, but they have helluva fast machines there in Redmond, they're high-tech guys). Oh, while we're at it, the MSDN search is one of the dumbest search engines in the universe. I hear they're working on a new super intelligent version. If it will be super intelligent compared to the previous version, then don't bother guys. I'm used to living without it, anyway.

What else is new in Visual Studio 2005. Well... The tool windows sometimes refuse to auto-hide. But that's not new, we had that in VS 2002 beta, only it seemed to have been fixed. How about user-defined controls still not showing up in the toolbox? I don't use the toolbox anymore, just go to the InitializeComponent method and add two lines: new MyControl() and this.Controls.Add(myControl). I don't have time to "Customize toolbox" and wait while VS scans all dll's on my hard drive and do it again when I recompile. Does VS lock the DLL's when you Get Latest from SourceSafe? Glad to say I don't know. I'm using Subversion now. It even has a Visual Studio plug-in which is somewhat buggy (alergic to file renames) but I don't really need it because there's always TortoiseSVN which is great (I'm probably not being fair to Ankh plug-in here, to get something to work right with the Visual Studio add-in API, you need extraterrestrial or para-abnormal capabilities).

So, where's the light at the end of the tunnel? We had Visual Studio 2003 service pack 1 scheduled for june and coming out in august (hopefully), and we had Visual Studio 2005 SP1 scheduled for august (you already guess where this is heading), then scheduled for sometime in the late summer, then not scheduled at all. There's a page at MSDN that says "This service pack is currently targeted for final release in Q3 of 2006. A more detailed schedule of external interim milestones (e.g. customer beta period) will be posted when it has been finalized." Which means there will soon be a beta. Or maybe not. Who cares, by then we'll get used to working without Visual Studio ;).

Did you also wish for an ObjectBuilder or a Spring or...?

I find it strange how some parts of the infrastructural code I've written in the last couple of years resemble what I see in the Composite UI Application Block. And while I'm looking at alternatives to CAB, I find that many application frameworks have sprouted in the .Net world since the last time I checked (which was around the mentioned couple of years ago). And they all offer similar solutions to the same problems.

One illustration - I had a sort of "deja vu" feeling looking at SmartPartInfo structure, because this is one of the things I felt I successfully resolved while working on my company's application framework: a class that carries enough information to allow the infrastructure to create a control and display it in a standard way: in its own window or as a part of another window. Be honest, how many times have you wished you could display a form within a form? With CAB the programmer has the option to say "I don't care, just show this control, you know, in a standard way".

What depresses me somewhat is the fact that all this time people have been trying to create the same things in a same way. And the reason for this is that the same infrastructural deficiencies were troubling all of them, and that the solutions were obvious enough. I mean, for chrissakes, why do I have to instantiate a container form for to show a control, why can't I just display the control directly? Why can't the infrastructure do this for me? Why can't it track forms and prevent me from opening duplicates? I can easily provide it with an ID to do this. Etcetera. And then you end up with a bunch of forms which all have a single control inside, but if you want to access the control from the outside you either have to make it public (which is Bad Practice) or write accessor methods on the form (which is TEDIOUS).

Depending on your ambition, developing an answer to these questions can be a huge effort (at its simplest form, it's not at all easy), so you're forced to either stamp out mind-bogglingly dumb code or roll up their sleeves and build a solution to it. Oh, yes, but it's not that simple: if you want to instantiate "some control" (e.g. depending on parameters or context), you can't do it in an officially endorsed way. One could use reflection to make things easier - but dey say not to use reflection 'cause it slow and not type-safe. So we obey: but lo and behold, CAB is built on reflection! And it's the only logical solution, if you ask me: you really need to have a way to replace certain types with certain other types (which is effectively overriding whole classes, is it not?) You really need to have automatic coupling of events with event handlers if your code is going to be modular. You really need command objects that can be fired from whatever UI component can fire them. Etc. The problem here is not reflection, the problem is C#, it's stuck trying to be both type-safe and dynamic, and all that using C syntax rules.

I feel we're still using prehistoric mechanisms for validating our code. We have ultra-powerful visual tools that can figure out by themselves what code to generate where, what references we need to compile the code etc, and they tell us of errors in code while we're typing it. Yet, none of these advanced techniques exist in the compiler. I mean, why isn't the compiler aware of the attributes the ObjectBuilder is aware of? Why couldn't the compiler check if I'm using the CAB attributes in a proper way? Why couldn't it emit dependency injection code at compile time, why does the infrastructure need to employ reflection at runtime and slow everything down? And - well, why the syntax with attributes in the first place, why not a real language feature? Attributes are not neraly structured enough to provide really complex metadata we require today. Although the dependency injection attributes look somewhat cool, using strings to identify event topics is really ugly. That's probably because you can't provide anything other than simple data types as attribute parameters.

A case in point:

[State("customers")]
public List Customers
{
 set { customers = value; }
}

Now, this is quite cool, having your property automatically bound to a value in the shared state... But it's also contrary to all type safety principles Microsoft boasts with when talking about C#: who is to check if the state really contains a "customers" item of type List? (And what if I wrote "cusomers" here, I'd get a null value and wonder what happened). Remember, this is a highly modular application, and the modules get loaded and bound only when it runs. So it's a unit testing nightmare. Even the tiniest bit of type safety would help greatly.

We either need a programming language that will support CAB-like features from the ground up, or a development environment that will be CAB-aware so we can't make mistakes like mistyping event topics. From what I hear, some such languages exist and are quite popular, but I haven't heard of an IDE (although I didn't look much). Now I'm not being unrealistic here: just like in bridge building (a profession that is very popular lately in the software development comunities ;)), a comprehensive infrastructure makes your job easier, but you have to know how the infrastructure works. We shouldn't expect a magic wand IDE or compiler, but some consistency would make things much more predictable.

I suppose the IDE will be what Microsoft pushes for. Just like the Enterprise Library 1.0 became part of .Net 2.0, the new application blocks will probably be a standard part of a future .Net framework, and one day (hopefully) there will be design-support for them. For example, it would be nice if the form designer could detect ObjectBuilder-aware classes, and generate ObjectBuilder calls to instantiate them. Also, the design-time environment should be coupled with the dependency injection framework so that components could be properly instantiated in the designer.

What I am sure, though, is that Microsoft will never manage to cover all the possibilities for visual tool usages. Look at what they're doing now with windows data grids: they have three instead of one, one of the three is buggy and one obsolete, and in WPF there won't even be a data grid (which is probably good because it would have been the fourth one). Compare this to third-party data grids which look like space shuttles, and you'll see what I'm driving at (ok, data grids are not typical average components, but they're at the extremely successful end of the same category).

So Visual Studio Orcas could be a third-party component developer heaven (that is, if you abstract the terribly buggy Add-in API which will probably stay the same). There we'll have a standard way to represent a database model using LINQ components (which for ex. means that the IDE could automatically generate code for filling all those godawful stupid combo boxes), an ultra-advanced vector and 3D graphics interface (which means an easier way for develping advanced visualisation and an unlimited room for third party controls because WPF will have next to none), and CAB (along with existing data-binding and similar mechanisms) will provide a base framework for integrating various components. And then we'll start waiting for whatsitcalled (Hawaii?) where they'll finally have the tools finished. Are you prepared to wait for 2010? I've already made my own modelling component, and in the next couple of days I'll be using the detected foreign keys to automatically fill the combo box items.

Nevertheless, it will be interesting to see where it all ends. My guess is that all of this is only a prototype for a future environment which will be fundamentally different. We're currently just trying out to see how it all works. Once we have the mechanisms and requirements figured out, we'll see what is the best way to implement them. And at that point we'll be able to take for granted much more than we can now, from a vector-based interface to data-modeling support built into the framework. But will Microsoft be prepared to write Visual Studio from the ground up? I don't think so. So, third party developers, start making your own ultra-futuristic IDEs. But please: this time, don't everyone write the same code ;).

How to get the type of the component being designed in Visual Studio .Net

What is the proper way to get, from within your designer component, the type of the component being designed? (Hm, if that one is the designer, the other one is surely the designee?)

1. this.Component.GetType() doesn't work because Visual Studio sneakily instantiates not the class you design but the base class (why does it do this? Beats me).

2. Wow, there's a RootComponentClassName in IDesignerHost, beautiful! Or maybe not.

The guys at msdn say that RootComponentClassName "Gets the fully qualified name of the class being designed". Oh, wait... No, they say it's property value is "The fully qualified name of the base component class". On the same page. So which one is it? When you access the property, you discover that the name isn't qualified at all. So you get the unqualified name of the class being designed (not the base one). Super, but what good is an unqualified class name?

3. Ok, so it's an undocumented/badly documented feature. This guy has it figured out:
http://blogs.vbcity.com/hotdog/archive/2006/03/31/5943.aspx

The RootComponentClassName is not initialized until the designer host has completed loading (which means, when IDesignerHost.LoadComplete is triggered). So, that's it: handle LoadComplete, and from LoadComplete get the RootComponentClassName.

How to detect design mode from non-interface code

It's an annoying problem: you write code inside your business logic classes that does something that is illegal (or simply cannot be done) when run inside Visual Studio. Like calling a web service whose url is read from the registry when the application starts: you simply don't have the url if the application wasn't started. And then, through a sequence of complicated circumstances, you are unable to avoid triggering this code when you open your control for design in Visual Studio. This is quite common, any code that exists in the control constructor will be executed in design time: if you must put your code inside the constructor (which is also quite common), you risk disabling the control's design time functionality.

Now, within a windows control you do have a DesignMode property which indicates what mode you're running in. It isn't valid when called from inside the constructor (since the object is being created, nobody had the chance to set this property's value) and you can't reach it from within your business logic classes, so it's a partial solution. I tried to find other ideas on the net, but it seems that from this point on things just get more complicated.

But wait, if we can't find an elegant and automated way to solve this problem, there is a killer simple solution: if your web service's url is being set when the application starts, why don't you simply detect if the url value was initialized? If it isn't, you can assume that you're inside Visual Studio design time. Or, even simpler: put a public static bool DesignMode property somewhere, set it's default value to true, and put DesignMode = false in your application's initialization code. Quite ugly but dead simple.

Avoid sql reporting services 1.0 if you can

A word of warning, because nobody seems to make it clear enough: avoid the first version (2003? 2004?) of Microsoft SQL Reporting Services if you can, it's beta quality (or pre-beta, translated into Microsoft-speak). A lot small bugs cause you to lose precious time trying to tweak untweakable things and wondering what is it you did wrong. Not to mention that you'll have trouble explaining to the customer how it's not your fault that you cannot turn off page breaks in the report viewer or fully control the widths of your columns, or set the background color of table cells that contain subreports or... Even worse, it will turn out you recommended the technology to them ;).

Visual Studio 2005: Adventures in dependent project items

Being a perfectionist programmer today is dangerous to your health. When confronted with the real world, the two (perfectionist and the programmer) tend to be driven into opposite directions, resulting in a split personality. And straying from the well-treaded path of tutorials in the Microsoft world can bring you into unknown perils.

A case in point: Visual Studio (in this case, 2005) has a nice treeview showing the contents of your projects and solutions. In it, dependent files are shown as child nodes of their parents and it all works... Until you try to use this handy mechanism on your own files. Then you notice it's mostly a facade that looks nice but doesn't support anything beyond what's already there.

For example: if, in addition to the *.Design.cs files in which designer-generated code is stored, you want to add your own child file to a component, say *.PublicProperties.cs. How do you add a new child file? You have to edit the .csproj file and add tags. Not nice.

If you double-click your child file it won't behave like the *.Design.cs file. It won't be opened in the source code editor but instead opens the designer - and an empty one, too, because it shows your part of the partial class, not the whole class. It turns out that Visual Studio doesn't really have a clue (or doesn't care) if your file is only part of a multi-file partial class.

So, we draw a conclusion that Visual Studio is hardwired to recognize files named *.Design.cs and not care about anything else, no matter how obvious it is (in other words: it's dumb). This is further confirmed if you try to convert your multi-file class into a visual studio project item template (you know, for the item types that get shown when you click Add->New Item). Your DependendUpon tags will vanish from the template never to return. When you Add->New your multi-part item, the item will show up as several unconnected (and un-parented) files.

Even worse - let's say you want to tidy up your NHibernate projects and have the *.hbm.xml mapping files become children of the persistent classes. No go: the NHibernate mapping will stop working because the compiler will cut off the hbm.xml extension! If you eliminate the DependsUpon relation, it will leave it as is.

So, the conclusion? Leave it. If it's ugly, it's ugly. Can't do a dang thing about it.

Windows forms designer cannot do [...]

I should have expected it: windows forms designer in Visual Studio 2005 cannot load controls derived from generic classes. In addition, of course, to not being able to load controls derived from abstract classes. Well, I know it's pretty hard to do a two-way synchronization between generated code and design surface and cover all the variations in the way classes can be created, but Microsoft could at least stop fooling us into thinking everything can be done easily in VS. Developers should really be aware of the choice they have to make: if you want to have a serious architecture in your software, forget about design-time functionality. Design-time is for VB developers: if you want it, you're doomed to casting types (instead of using generics) and throwing a NotImplementedException (instead of making a member abstract). In my opinion developing design support for generics and abstract classes was more important than building an NUnit-clone into the IDE, but Microsoft management's priorities seem to gravitate towards stuff that makes for cool screenshots in feature lists. But what really frustrates is that MS has written volumes on software design, coding standards, practices etc. and has a number of tools that enforce them, only to be let down by inadequacies in the form designer, the one thing that was invented ages ago.