This is something I’ve been meaning to do for a while, as often I’ll open a Web Application in Visual Studio configured to run under IIS and be met with the following:

Running anything elevated is easy, you just need to call ShellExecute (the .NET equivalent is System.Diagnostics.Process.Start) with the “RunAs” verb, so it’s simply a matter of starting Visual Studio’s devenv.exe passing the path to the current solution.

So here goes: copy and paste this into a Macro Module (ALT+F11) then wire up to a toolbar button as appropriate:

.NET 2.0 introduced partial classes which enables “.designer” files in Visual Studio 2005 and later. That is, all of the visual designer-generated code (control declarations, the InitializeComponent method, etc) can be kept in a file separate from your regular code. When you open up a .NET 1.x Visual Studio 2003 WinForms project up in Visual Studio 2005/2008 it will upgrade your project to .NET 2.0 just fine, but unfortunately it doesn’t migrate your WinForms classes over to the new “.designer” project structure.

Initially I thought this would be a job for a DXCore plug-in (the free framework upon which CodeRush is built) as it provides plug-ins with an object model of the code which could be used to grab all the right members and move them over into a designer file. Before I looked into this though I checked what the options were for simply implementing it as a Visual Studio Macro. I was fully expecting to have to use a regular expression to grep the code file to perform the task, but was pleasantly surprised to find that the Visual Studio extensibility API in available to macros provides a code model (based on the .NET CodeDom I presume) which you can traverse to inspect and manipulate the underlying code.

Locates the first class in the selected project item (DTE.SelectedItems.Item(1).ProjectItem) by traversing the ProjectItem.FileCodeModel.CodeElements

Extracts the InitializeComponent and Dispose methods from the class by traversing CodeClass.Members

Extracts all control fields: that is, all fields whose type derives from System.Windows.Forms.Control or System.ComponentModel.Container or whose type name starts with System.Windows.Forms

Puts all the extracted code into a new “FormName.Designer.cs” file.

This is currently C# only – it could easily be converted to generated VB.NET code or adapted use the FileCodeModel properly and perhaps create the code in an language-agnostic way when generating the designer file. I took a shortcut in just generating the designer file as a string and writing it directly to a file.

To “install”: download the macro text and copy the methods into a Visual Studio Macro Module (use ALT+F11 to show the Macro editor).

To use:

Select a Windows Form in the Solution Explorer

Run the macro by showing the Macro Explorer (ALT+F8) and double-clicking the ‘ExtractWinFormsDesignerFile’ macro. (Obviously you can hook the macro up to a toolbar button if you like.)

You will then be prompted to manually make the Form class partial (another bit I was too lazy to work out how to get the macro to do): i.e. changepublic class MyForm : Form
topublic partial class MyForm : Form

Like most .NET developers, I used to do VB/VBA coding before C# came along. But, one thing I always missed in in the C# code editor was the lines that the VB editor puts between methods. An an avid user of CodeRush and Refactor! Pro, which itself does code structure painting in Visual Studio, I’ve created a DxCore Plugin that draws lines between methods which (IMHO) improves on the ones in the VB code editor.

Here’s a screen shot of it in action:

And here’s the exciting options page:

Even if you’re a VB.NET person you might like to try it to see if it works any better for you than VB’s built-in lines (although I guess you’d need to turn off the built-in method-separating lines somewhere in Tools Options).

The project is hosted on Rory Becker’s DX Core Community Plugins Google Code project, where you can download the source and binaries.

One the first issues that you have to deal with when writing unit tests is – where do I put the the tests? Here’s where I prefer to have them: as close to the code that’s being tested as possible, like so:

The tests class is hooked up to the original source file in the same way that ASP.NET code-behind files are, as a dependent project item.

You can do this by hacking the *csproj file directly using the <DependentUpon> tag, but to automate it I’ve written a Visual Studio macro (works in Visual Studio 2008, should work in Visual Studio 2005) that creates an appropriately-named tests class that can be invoked like so: