If you have upgraded from Visual Studio 2003 to Visual Studio 2005, you have probably noticed one of the major annoyances: they took away the sounds.

With VS 2003, you could set things up so that your computer made a happy little sound at you when a build succeeds. This was great because I could turn away from the monitor for a moment, if only to rest my eyes, until the sound brought me back. Or I could check email, get another glass of cold caffeine, etc.

I’d even gone a step further by making my app play the sound of a bell ringing, when it had finished booting itself after a successful build in the dev environment. This extended the time I could gaze out my window at the tangle of weeds we call a lawn.

But in VS 2005, all you can do is hear a sound when you hit a breakpoint. Big deal. I want the cheerful news that everything is copasetic. So why did they take out the sounds? To save a few hundred milliseconds. That appears to be the official word.

And the official word, back in April 2006, was that they were working on fixing this “bug” for the next release. Well, the next release has come and gone. Still no sounds. In the meantime, they suggest, you can write an add-in.

In Service Pack 1, there is a new control called SoundPlayer, which appears to do the same thing a simple two-line function can do. Yes, without it you have to declare an API function, which means unmanaged code and wild-eyed people grabbing you by the collar to tell you what a mistake this is, but I’ve been using API calls very carefully since .NET appeared and have yet to suffer (I am knocking on my desk top with both fists). I guess it comes down to this: I’d rather have my sounds back than a relatively useless control.

I saved much more time when I had that happy sound than the hundreds of milliseconds they were worried about. At least my app still rings a bell when it’s up and running.

But they could have told me.

So I put together my setup project using the in-grown version of MSI (don’t get me started on how cumbersome it is to add files!) and then built it. Looked good.

But when I tested it, the suggested path was “C:\Program Files\Default Company Name”. Whaaa? Where was it getting that from? And how could I get it to show the correct name? I figured I needed to modify some properties somewhere.

I right-clicked on the project in Solution Explorer, and then chose Properties. That brought up the configuration properties, not the project properties. Next I clicked on Project | Properties. That brought up the configuration properties again. So did View | Property Pages.

Then light dawned on Marblehead, as they say in New England. In Solution Explorer, I clicked on the name of the project. Then I clicked View on the menu bar and found the entry for Properties Window and clicked that. There it was—the manufacturer was set to Default Company Name. (Maybe I should buy that domain name….) At least it was an easy fix, once I found the right place.

I also noticed that I could choose an icon for my app’s entry in the Add/Remove Programs applet, as well as pre- and post-build events. I got all excited for a minute, thinking these were pre- and post-install events, but no such luck. Now wouldn’t that be nice!

The Deployment Project Properties window (as it is officially called) is very much like the properties windows for controls such as listboxes and buttons. Controls are objects, and so are projects, so I suppose it makes sense that you’d get to their properties the same way.

But they could have told me.

(Editor’s note: This is the first blog post by Chris Madsen, who will be writing on the .NET Developments blog from time to time. Madsen is a consultant who programs in Visual Basic and Visual Studio 2005. Her first few posts will cover the ups and downs of migrating from VS 2003 to VS 2005; she’ll also write about some of the Visual Studio 2005 features that surprised her. Welcome aboard, Chris!)

The other day I got the latest edition of Visual Studio magazine in the mail. Along with it came a glossy, full-color pirate’s map. Evidently, that’s how Microsoft thinks of Visual Studio 2008 — “made for the likes of developers, and other scoundrels.”

I know the calendar says 2008, but in the real world of developers, it’s barely 2005. And I’m more a captain of a leaky little fishing boat than I am a pirate. It takes everything I have to get my work out the door on time. I upgrade my tools (such as Visual Studio) when I can’t live without a new feature, not when I get glossy maps in the mail.

I’m not alone: I still see plaintive questions begging for help with VB 6 apps, and with upgrading to VB .NET. I’ll leave it to others to reveal all the cool new stuff in VS 2008. I’m going to concentrate on Visual Studio 2005, including the woes of upgrading from VS 2003.

Whenever I run across a juicy bit, I’ll let you know. These are the things they never tell you, the information that’s written between the lines in the documentation, the stuff they leave out. It’s the stuff you find after opening a hundred Google links, buried in the answer to the answer to the answer to a question on some obscure site.

Who is this “they” who never tells me stuff? I’ll leave it up to you to decide.

I program mostly in Visual Basic .NET, so that’s what I’ll be talking about. I work almost exclusively with WinForms, and I’ve done a lot of work using Access, Word, and Excel in .NET apps. I love to write macros to make my life easier. I am a consultant with clients in Florida, Massachusetts and Maine. Just to keep things interesting, I live across country from all of them, in Washington State. So I might throw in some tidbits about telecommuting and consulting. Let me know if you are interested.

I’m sure I’ll write about some things you already know. Maybe they’ll make you smack your head and exclaim, “What sort of idiot is she?” But I figure if it wasn’t obvious to me, it wasn’t obvious to someone else, and that’s who the tidbit is for. I’m glad you have a better grasp of some things than I do.

But they could have told me.