Debug an IE Add-On in Visual Studio 2008

I’m working on a project that involves creating an IE Add-On in C#.  It is an inherited project that was created in Visual Studio 2005 targeting the .NET Framework 2.0.

Well, times have changed.  I am now doing most of my development in Visual Studio 2008, and (when lucky) I am using the features of the .NET Framework 3.0 or higher.  When I first made the switch, I tried to use 2008 to continue my work on the toolbar, but I failed miserably.  I was shocked to find out that my process of registering my assembly in a post-build action and launching IE as a Start Action did not work in 2008.  At the time, I quickly got over it, and preserved 2005 just for that project.

Luckily, in a more recent attempt to use 2008 for this type of development, I was able to solve the problem.  Check it out.

Problem:

Whenever I tried to debug my IE Toolbar project in Visual Studio 2008, I would get a nasty exception that says, “Error while trying to run project.  Unable to start debugging”

My project is configured to register the assembly using regasm in a Post-build step.  Then, as you can see below, the VS Debugger is configured to start Internet Explorer (and subsequently attach to the process).

Well, that was the wrong way of doing it.  I was able to get it to work successfully by modifying the Start Action like such:

And it worked!

UPDATE:  I still had issues on a separate computer.  Adding “about:blank” to the command line arguments fixed the issue.

Advertisement

Not really a Fan, but still kind of Groovy

Fan is a very young programming language with some promise.  The features of the language are more pragmatic than theoretical.  This means, Fan, like Python and Ruby, should allow you to be productive in a concise manner.  The syntax of Fan left a lot to be desired.  It is not the prettiest language, but hopefully, syntactic sugar will be added in the future to facilitate Fan’s adoption.The killer feature that Fan promises to deliver is the interoperability with both the Java Virtual Machine and the .NET Runtime.  Currently, one or the other are required to compile Fan source code.  However, Fan currently does not offer much in terms of interoperability with Java and/or any of the CLR languages.  That is disappointing for now, but the language is extremely young.  Powerful features like that take time.

While a more developed Fan will find its niche audience of developers, I wonder about the true utility of such a language.  The JVM already has the well-known scriptingly awesome language known as Groovy.  I do not qualify as a Java developer, but I hold Groovy in high regard because of its performance, language features, and *gulp* use of the JVM.  Java reservations aside, Groovy is a language I look forward to learning.

.NET is not absent of nice scripting languages either.  Boo is one such language, noted for its Python-like syntax. Oh, and did I mention IronPython?  It is also noted for its Python-like syntax, but .NET-like performance.  Perhaps, the most awaited .NET language is IronRuby, a dynamic language with the features of ruby and the power of the .NET Framework.  It is going to be great.

There is one other .NET language that I think deserves mention.  It is called Nemerle.  Nemerle is a static language, much like C#.  However, Nemerle implemented features like type inference long before the release of C# 3.0.  Since the latest release of C#, Nemerles advantages have become less pronounced.  But, it still differentiates itself from C# with features like Macros that allow you to customize the syntax of Nemerle (think domain specific language).

Nemerle is a pretty mature language.  It has some integration with Visual Studio 2005.  Also, the Nemerle compiler is written in Nemerle.  That could be a sign of a pretty usable language.

Nemerle is open-source.  I don’t know if it is actively developed today.  However, I recently came across a blog post that sums up some of the features of Nemerle.  That post was the inspiration for this post actually.  Onur went as far as to call Nemerle “C# glorified.”  I’m not sure I agree with that.

However, I believe Groovy is definitely “Java glorified.”   Maybe Nemerle is a little Groovy.

SnippetCompiler is great, but…

…we don’t have to use it for quick compilable chunks of .NET goodness.  As detailed on marlongrech.wordpress.com, we can use TestDriven.Net to run small parts of code in the Visual Studio.NET debugger.

The code is not required to be a test case for use in a unit testing framework.  It can be an arbitrary method that just does some processing.  The key to using this technique, is to make sure you set a breakpoint.  That way you can manipulate parameters and actually get feedback about what the method is doing when it executes.

This is yet another reason we should buy TestDriven.Net.  It can pay for itself within a day or two.

In addition to SnippetCompiler and TestDriven.Net, Powershell is very useful for this kind of snippet testing as well.  But I’ll have to defer that post for another time.

Fix Visual Style of Tab Control in .NET

I was having an issue with my tab contols looking very ugly:

These controls did not look anything like other fancy tab controls that I have seen recently in XP and Vista.    My tab control sucked.  Looking at it took away my desire to use my application.

I made several attempts at remedying the issue.  I tried one combination of property changes after another to no avail.  I was on the verge of creating a new owner-drawn tab control ( I had created a new project in Visual C# Express and everything) when I stumbled upon a CodeProject article.

I didn’t follow the article all the way through because it seemed to be written for an older version of the Framework and IDE.  But, it reminded me that there is an Application.EnableVisualStyles() method*.

I swiftly made sure I called that method before any controls were drawn, saved my hard work, and clicked the VS “Play” button with the excitement and anticipation of a child in line at Chuck E. Cheese.  That all died quickly when I received a screen containing the same ugly tabs staring back at me.

I checked the return value of the Application.RenderWithVisualStyles property and discovered my application was not using visual styles.  Thanks to the MSDN documentation, I quickly found the problem.  I had XP’s Appearance set to Windows Classic style.  Doh!!!

After changing XP’s Appearance back to Windows XP style, I had beautiful tabs:

To recap the solution:

1. Call Application.EnableVisualStyles() before any controls get rendered.  In Program.cs just before Application.Run is a good place.
2. Make sure you are allowing your OS to use visual styles.
3. Don’t judge me for being absent-minded most of the time.  I’m trying to get it out of the way so that I won’t be absent-minded when I’m older.

* I probably saved over that memory with a Mitch Hedberg joke or my wedding anniversary date.