A couple of years ago, I finally sat down and converted by hand the Wombat theme I was using in vim for Visual Studio. At the time, I attempted to write a script to do this conversion process for me, but it didn't really work out. Well, just over a month ago, I decided to try again and finally got a script working. Here's some screenshots using the Nick Moffitt's version of the railscasts color theme to give you an idea of how it works:

VIM:

Visual Studio:

I left the ReSharper lightbulb icon there so you would believe me :-)

Now, there are differences - the conversion is not perfect and likely won't be able to be because of differences in how each editor determines things like identifiers and keywords. Still, I consider it a huge headstart in converting a color scheme if you're interested in doing this.

For now, the code is a simple ~200 line PowerShell script (with at least 40 lines of comments taken from the vim documentation for reference) so it is pretty basic. The script also assumes that a starting vssettings file lives next to the script as a starting point for the conversion. The brains behind the conversion is a big hash table in the script that maps Visual Studio color scheme settings to vim color scheme settings.

If you're interested in trying it out or if you'd like to check out the code, I posted it up on github at http://github.com/drmohundro/ColorConverter. My long term goal for this would be to add a GUI to the project so that color schemes could be viewed side by side and allow tweaks to be made before exporting the final vssettings file. Also, I'm not at all opposed to looking into converting between other editors besides vim or Visual Studio.

And... it is big. Really big.

Pictures are worth a thousand words... in this case, they're worth just over 30 GB.

Wow.

? myCoolVar

You can also execute commands at the immediate window by just typing them. It is a nice way to change values at debug-time.

myCoolVar = "some other blah"

What I didn't realize until today is that you can create completely new variables at the Immediate window as well! Just type in the variable declaration as you normally would in code. (note that you need the semi-colon in this case)

string myNewCoolVar = "I'm a brand new variable!";

Here's a screenshot of this behavior in action:

Right now, I'm using this behavior while working with a new WPF application. I've got an IMultiValueConverter and it is a hassle casting my generic array of objects into types, especially when I'm still deciding on the various bindings I'd like to pass in. With this, I can just set a breakpoint and use the Immediate window to play with the code.

This gets me a lot closer to an interactive console (like IRB) with .NET. Though I can do all of this with IronPython, F#, or IronRuby, it is nice to be able to do this at debug time from Visual Studio.

*sigh*

Maybe now I can figure out what the original problem I was trying to debug was in the first place.

I haven't really coded in it yet, but the application itself sure seems snappier. I'm talking about toolbar menus and the general responsiveness, which is very nice. Has anyone else noticed an increase in speed for Orcas from 2005?

Anyway, I thought I'd share a nifty tool that came along with it under the Visual Studio SDK Power Toys name (not to be confused with the Power Toys for Visual Studio... I'm confused, too). Here's a screenshot of Source Outliner:

It acts sort of like the Class View tool window, except that it outlines the currently opened file. It also seems a lot cleaner if you happen to be deep in a namespace hierarchy. Once you have the VS2005 SDK installed, you can access this tool either by selecting Tools -> Power Toys -> Source Outliner or by using the CTRL + \ + O hotkey.

Check it out!

UPDATE: I... uhh... added the link to the download. My mistake on forgetting that :-)

Another update: Don't bother downloading the entire SDK if you're just interested in the Visual Studio SDK Power Toys... you can download them standalone! Check out Aaron Marten's post here!

Open up the project file (which in my case was GUI.vbproj) in a text editor and do a search for your Designer file. You should see some tags that look like this:

<Compile Include="CustomControl.Designer.vb">
</Compile>
<Compile Include="CustomControl.vb">
  <SubType>UserControl</SubType>
</Compile>

Now, what it SHOULD look like is this:

<Compile Include="CustomControl.Designer.vb">
  <DependentUpon>CustomControl.vb</DependentUpon>
</Compile>
<Compile Include="CustomControl.vb">
  <SubType>UserControl</SubType>
</Compile>

Basically, my project file, for whatever reason, was missing the <DependentUpon> tag. If you add that back, Visual Studio should start behaving as expected again.

In one of my forms, I had some background threading work that was started when the form loaded. Like a good programmer, I had wrapped this threading work in a check against Me.DesignMode to ensure that it wouldn't try to do this work while in the designer. What I didn't know at the time is that the DesignMode property isn't set until AFTER the constructor fires. I checked around with some guys at work and I discovered that I wasn't the first one to discover this. They had already put a check against Application.ExecutablePath to see if it was devenv.exe. If it is, then we're in DesignMode. Simple as that!

So, all of my VS crashes and weird WSoD's have now been tracked back to my OWN code. HOWEVER, I would like to say that it would have been nice if Visual Studio had given me a better message to inform me that my designer code was trying to run background threads or something - in much the same way that my own code should work better and give my users better messages.

Ah, the joys of user interaction.

Note: This fixed the problem suggested after sending error reports that link to this hotfix (http://support.microsoft.com/?kbid=915038). If you're running into this, check and double-check the code in your UI constructors, INCLUDING base class constructors!

I had a BackgroundWorker that could potentially throw an exception (can't everything?) that was doing some remoting to another process. As additional information, the BackgroundWorker exposes any exceptions that might occur in the Error property off of the RunWorkerCompletedEventArgs. I didn't want to just throw e.Error because, as Karl points out, this modifies the call stack making it look my code was the source of the exception. At the same time, I couldn't just use throw, because the exception had basically already been caught and been given to me to handle.

I ended up pulling up the Object Browser in Visual Studio and filtered the list down by searching on "exception" - a nice trick to see all currently accessible exceptions. I ended up using the System.Runtime.Remoting.RemotingException, because it described exactly what I was looking at. Here's the description for it:

Public Class RemotingException<br /> Inherits System.SystemException<br /> Member of: System.Runtime.Remoting<br /> Summary:<br /> The exception that is thrown when something has gone wrong during remoting.

If you exclude the "during remoting" part, it basically describes any exception that can be thrown. It's almost funny in a way, because that's exactly the type of thing I was looking for. I was able to set the InnerException to my e.Error which provided me with all the information I needed.

In his post VS2005 PowerShell Prompt, Robert details how to create your PowerShell profile script which will add the VS2005 environment variables to the PowerShell process. Quite nifty.

As a note, after setting this up, you may get a message about how your script isn't signed so it won't run. One solution is to run Set-ExecutionPolicy RemoteSigned. I wouldn't recommend going farther than that, though. It will allow local scripts to run unsigned and will warn you if a script that was downloaded tries to run. There are still vulnerabilities, so be careful. The other alternative is to sign your script.

Finally, we were getting ready to start work on the internals. The three of us met in a conference room with a projector and I pulled up the Class Designer in Visual Studio. I've done team-coding a few times before, where one person is typing while everyone else is yelling out bugs or typos. While the process can be annoying, it also tends to produce less-buggy code. Doing the same thing with the Class Designer worked out really well. It helped us visualize how everything would tie together. We were drawing out our code, but behind the scenes, the Class Designer was also spitting out workable code!

I don't think I could use the Class Designer in all cases, but it really does force you to think about design issues and it makes for a good team development product. It also helps ease developers who aren't as comfortable with OO concepts see how inheritance is working. Give it a try and let me know how it works for you.

I've seen it all too often and it is really annoying.

However, I did find a possible fix today. I was working in a project that had multiple assembly references. One of the references was using a 1.1 assembly, so it came along for the ride. By simply removing that reference, I was able to view my form without any problems. If I tried to add the reference back, I would get the designer error again. I reworked the assembly being referenced to not use any 1.1 components and... lo and behold... the designer errors stopped.

Is this just a really random bug or is this a subtle way to push people to migrate to .NET 2.0?

Second, as she says, tracepoints ARE awesome. I had used a few of the new breakpoint features in VS2005 such as Condition and Hit Count, but I seen the "When Hit..." option yet. All I can say is, you can say goodbye to Debug.WriteLine'ing (aka "the poor man's debugger"*).

* If you're unfamiliar with "the poor man's debugger," it is basically using output statements to determine values and flow of code. If used correctly, it can actually be very useful. It just isn't fun to remove all of that code after you're done debugging (particularly the Response.Write variety in webpages... ouch).

As you can see with my hastily scribbled red circle and arrow, I'm attempting to draw your attention to the 65.94 number. It is telling me that devenv.exe was spending about 66% of its time in doing garbage collection.

WHAT?!? 66%? That explains why my process was barely responding to me, but it doesn't tell me why it was doing that. I will say that I had a code file up that was about 7000 lines long, but I would still expect it to be able to handle that. Maybe I'm wrong, though. Since then, I've significantly cut that file down in size and I haven't run into that issue again, but it was pretty weird.

If anyone knows anything about getting that working for VB, I'd appreciate it.

Here, I'll show you how!

Public Class Form1
  Public Shared Sub Main()
    Application.Run(New Form1)
  End Sub

  Public Sub New()
    ' This call is required by the Windows Form Designer.
    InitializeComponent()
    ' Add any initialization after the InitializeComponent() call.
    Dim p As New Person()
    With p
      ' CRASHHERE: If you want to crash, take your mouse and
      ' click inside .StreetAddress.... BOOM!
      With .StreetAddress
        .Street = "123 BOOM"
      End With
    End With
  End Sub

  Public Class Person
    Private _streetAddress As New Address
    Public ReadOnly Property StreetAddress() As Address
      Get
        Return _streetAddress
      End Get
    End Property
  End Class

  Public Class Address
    Private _street As String
    Public Property Street() As String
      Get
        Return _street
      End Get
      Set(ByVal value As String)
        _street = value
      End Set
    End Property
  End Class
End Class

There, that was easy, huh? (In case you're not seeing it, look for the CRASHHERE note.)

Kids, don't try this at home.

Chances are, it will work for you anyway. I just checked with one of my co-workers and it works just fine for him. Great.

And I wasn't even in the designer. And yes, I rebooted. It still happened.

I don't know exactly what I did to fix it, though. Let's just say heavy use of the save button and having another instance of devenv up and attached to the other process. Just in case I needed to copy and paste a call stack somewhere. Of course, that's when it began working.

Oh well.

NOTE: Don't take this the wrong way. I still love VS2005 as an IDE. However, it still has quite a few issues. The most annoying of which is the flickering while in the designer. And no, I never got that one up in the debugger either.

UPDATE: For more information on this, see my new post here.

Note: I'm not sure if it shows up in every VS configuration. I'm using the default view (see Tools -> Import and Export Settings).