Andrew Arnott : Visual Studio

Visual Studio 2010 editor vs. gVim over Remote Desktop

andarno — Mon, 19 Oct 2009 08:00:00 GMT

For those of you who may think WPF is too slow, you gotta check this out. Visual Studio 2010's new WPF-based code editor is lightening fast, especially when compared over a fast FiOS Remote Desktop connection to gVim!

If the MS Office team wrote Visual Studio

andarno — Tue, 05 Aug 2008 09:29:21 GMT

Some humorous pros and cons to Visual Studio, if the Microsoft Office team were ever to take over. (disclaimer: this is a tongue in cheek post. No offense -- only laughs intended)

Visual Studio 2008 would be able to load VC7 projects, modify them in any way VC7 allowed, and save the project back to VC7 format, allowing you to work with others still using VC7.
You could download an extension to VC7 that would allow you to work with VS2008 projects in a limited way.
Your projects would open in any copy of Visual Studio just fine, until you added any code to it. Then VS would refuse to load it until you changed the security settings in Tools -> Options from High to Low. And you'd still get a security warning at every load.
To send your codebase to someone else without allowing them to change it, you would Save to PDF.
Source control would be integrated into each individual source file (but you'd have to turn it on first, per file), and merging changes from others would involve Track Changes with ~~strikethroughs~~ and underlines instead of yellows and reds.
Source files would become programmable with embedded macro scripts, allowing a change in one part of the source file to affect other areas, perhaps with some intermediate calculation.
Compilation would occur in the background, or instantaneously on demand.
No build breaks. Ever. But the spell checker might point out some possible areas of improvement.
Methods would be phrases and have spaces.
Shakespeare would be the default programming language.

Visual Studio trick to quickly find any file in solution

andarno — Sat, 02 Aug 2008 22:04:37 GMT

You know that Find text box in the toolbar of Visual Studio? Those of us who are keyboard-inclined probably never use it because Ctrl+F is quicker than moving your hand to the mouse. But there is a hidden gem of a feature inside it that really makes me feel like a power user that I wanted to share.

That find box doubles as a Command Window prompt if you just start with a '>' sign. The feature in this that I use the most is this:

First jump up to that box using the keystroke Ctrl+/. Now type ">of " and follow with the start of a filename. As fast as you can type, Visual Studio searches your entire solution for a file or path that starts with the characters you type and you can quickly select that file (with the keyboard using the arrow keys if you wish) and open it. If you're working in a solution with several projects or folders, this can be a significant time saver.

For those of you unfamiliar with the Command Window, you can think of it like an Immediate Window that you use with the debugger, except that instead of controlling the debuggee, you're controlling Visual Studio. It's like the VS macro editor, except that everything you type takes immediate effect. To have this conveniently just a Ctrl+/, > keystroke away, especially when ">of " (short for Open File) is such a convenient acronym to search across your entire solution is awesome.

Why your Visual Studio add-in fails to load with error 0x80004005

andarno — Fri, 15 Feb 2008 19:43:31 GMT

Writing Visual Studio add-ins gives you the power to do some impressive things within the IDE to enhance your productivity. Unfortunately getting your add-in to load into Visual Studio can sometimes be a pain. Here's just a tip you should know about the .AddIn file that Visual Studio generates for you.

The path you provide to the add-in assembly .dll should be relative to the location of the .AddIn file itself. Absolute paths do not work. If you try using one, you get an unhelpful error dialog that mentions error code 0x80004005.

Hopefully we can get some more useful error messages in future versions of Visual Studio.

Why double-clicking on an .SLN file doesn't always launch Visual Studio

andarno — Wed, 13 Feb 2008 23:32:42 GMT

Well this is my first post as a member of the Visual Studio Platform & Ecosystem team. My second full day on the job, and I've found some less-than-ideal areas of Visual Studio that I'm eager to improve for myself and for you, our customers. How exciting. I'll do my best to post to my blog whenever I run across some unexpected scenario that is likely to hit customers and how to work around it.

So on to the first scenario...

Scenario

You have Visual Studio 2008 installed, but some Visual Studio Solution files (.sln) don't open when you double-click on them. In fact, nothing happens.

Analysis

When you double-click on a .sln file, a small program called vslauncher.exe is called with the path to your .sln file as its first argument. The job of vslauncher.exe is to read enough of your .sln file to determine which version of Visual Studio to use to open your file. Since you may have several versions of Visual Studio installed (VS2003, 2005, 2008, Express SKUs, etc.) you probably want to open the solution with the same copy of Visual Studio that you used to create it.

The issue comes up when your .sln file signature (the first two lines of your file) don't match any known release of Visual Studio. Visual Studio 2008 .sln files typically start with these two lines:

Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio 2008

But suppose you have a .sln file that was created with a Visual Studio 2008 beta. You might have a .sln file that starts with this instead:

Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio Codename Orcas

When Visual Studio 2008 RTM reads this, it doesn't recognize its earlier beta versions' solution file signatures and just quits. It would be nice if a user-friendly message telling what happened would pop up. Alas, it does not.

Workaround

Simply open your .sln file in Notepad and change "Codename Orcas" to "2008" on the second line.

[Update 2/16/08] This blog was featured on Channel 9, and as a result a couple of people wrote up a PowerShell script and a C# program to automate updating all your .sln files at once. Very cool.