Ideablade tips on slow VS 2005 IDE?

#1) Get a machine with the fastest hard drive you can find. Not the most memory ... that doesn't seem to matter much. But drive speed is everything.

I work with a Shuttle that has >10,000 rpm drive. It is portable enough to carry between home and office each day. I love it. Three Visual Studio sessions + Camtasia + Powerpoint is an every day occurrence for me. Every time I try a laptop with a "fast" drive (~7k), I go crazy because it is too slow to do anything.

I haven't tried it yet but I have a feeling that it would be faster still if you could confine VS's attentions to some kind of virtual drive. It's just a drive pig.

The great news is that a tricked out Shuttle costs less than a high end laptop. And you upgrade it as technology advances.

If your time is worth money, look into working with a machine that takes a fast drive.

#2) Small views. You mentioned that it takes "minutes to just show a form in the designer". I've rarely seen that but when I do, it is usually because there is one mondo form with the entire UI crammed into it. This also puts you at risk for high anxiety when the "white screen of death" knocks on your door. As he inevitably does.

The answer is "lots of small views". Of course they have to come together as a rich UI. Which means you should build your UI "by composition". This is something I stress in my CAB classes and CAB certainly supports it well. But you don't need CAB to build by composition; I'd been doing it that way long before CAB (e.g. Funhouse).

Not enough room to go deep but the essence is that you write a UI controller which assembles the UI at runtime by instantiating the views and putting them where they belong within a pre-arranged layout. The layout can be as simple as a UserControl with split containers, tab controls, and panels.

Typically I nest these as well.

#3) UI designer avoidance. I actually don't use the designers very often.

With small views there isn't much reason to do so. I always construct my grids without the designer at all.

#4) Tune your VB. I'm no expert on this. I write everything in C# and then convert to VB so I don't spend much time there. What time I have spent there has convinced me that the VB compiler is simply not well done. I'm not criticizing the language; I'm criticizing the compiler which is balky and fragile and feature poor relative to the C# compiler. It also lacks the simple refactoring features of the C# compiler. I hope they fix it for Orcas.

Meanwhile, if you can kill off that edit-and-continue, things may pick up.

So I have heard.

Or you could always switch to C#. I know it seems like a joke. But I've come close several times to convincing a client to do that ... not by suggesting it but simply by moving back and forth between the two compilers as we worked together. I can't tell you how many times he said "wait ...

what did you just do? ... you mean you can do THAT."

Let me repeat - I'm not campaigning against VB the language - I'm just telling it like it is about the compiler.

Best of luck,