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 ;).