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.

Why reinvent the wheel?

Because, you would like to.

We have all heard the saying, “Why reinvent the wheel?”, when we were faced with some programming challenge that seemed like a common scenario.  Because of the likeliness that someone else has solved the problem, we use our good friend Google as a knowledge base to seek out articles, blogs, and/or forum posts that will give us “the” answer.  We all have done it (or still do it).  There isn’t anything wrong with that, right?

Wrong.  It can prove detrimental if we’re not responsible enough to understand “the” answers that we find, as well as the pros and cons of their implementations.  See, the saying, “Why reinvent the wheel?”, makes an assumption that all wheels are engineered equally.  We know that is not the case.  In fact, at least one of us don’t even believe humans were engineered equally.

Let’s face it, oftentimes we are pressed for time, and are asked to deliver something functional in very short amount of time.  Our Google knowledge base can be a huge time-saver under those conditions.  But, are we fulfilling ourselves as coders?  Are we satisfying our appetite for innovation?  Most importantly, are we enjoying our work during those times.

This post may seem like an extension of my Developers vs. Coders post.  However, I am simply offering myself public counseling (for your benefit).  In the meantime, I challenge you to reinvent the wheel every once in a while.  You might enjoy it.

However, consider using your Google knowledge base when the solution turns up at http://blog.curtismitchell.com.  🙂

The Significance of Prototype.js and REST

One of my boys sent me a link to an article on Joelonsoftware.com entitled “Strategy Letter VI.” It is a great article that compares the strategy that IBM employed when they were trying to keep Lotus 1-2-3 relevant in the 80s to the challenge web-based software companies faced with keeping their applications relevant today.

Usually, I take Joel’s words with a grain of salt because (ironically) I have interpreted many of his public writings and actions as desperate attempts to stay relevant. However, this article offers true value to the reader. He offered knowledgeable insight that got me thinking about two things that have swept across the web and propelled web development forward by leaps and bounds: Prototype.js and REST architecture.

Prototype.js is the Godfather of Javascript Libraries (RIP James Brown). A large percent of the leading js libraries such as Mochikit, Scriptaculous, Mootools, JQuery, and YUI are either dependent on Prototype or HEAVILY influenced by it. Sam Stephenson, the creator of Prototype, showed the rest of the web that js didn’t have to be stressful. His library gave us an extremely helpful API for easily forging our own js solutions. But, this plain text file also showed the intermediate web developer how to take js and OOP it up; that is, use object-oriented techniques to deliver some advanced cross browser functionality. It was functional and educational at the same time – two attributes stressed out web junkies love.

Similarly, non-groundbreaking but super important, is the emergent REST architecture. REST is an architecture for interfacing with web applications. This increases the interoperability of your web app with other web apps out in the real world. It gives Amazon’s web services a predictable interface so that I, the burned out programmer, can think-less by reusing their chunks of functionality in a very familiar way.

REST does not require you to share your application with other web apps. In fact, the benefits of REST can be reaped by internal applications as well. REST can be a great approach to simplifying any application and making it more maintainable by using a well known architecture. Think of it as REST and relaxation.

Both of these technologies are inherent in Ruby on Rails, the hot young web framework that has all the ladies talking. So, it is no surprise that the management buzzword of the year, Web 2.0, is usually reserved for some RoR application that offers a fairly trivial service, but tons of ways of interacting with it.

In fact, when I think about what Prototype and REST did for AJAX calls, it becomes hard to imagine the term Web 2.0 without them. However, be mindful that the term Web 2.0 only means your web application is relevant today.

Developer vs. Coder

Are you a developer or a coder?  Before you answer that question, I urge you to consider several characteristics about yourself that you may be taking for granted.

First, let me start by saying this:  If you do not write code of any sort, then you are neither developer or coder.  But, you’re still invited to read the rest of my rant and share your $.02 via comments.

Why do you do it?  Why do you write code?  Is it a lucrative career choice you made based on the short-term earning potential?  Or, do you simply like building things because it’s neat?  A developer leans more toward the money.   The diplomat in me wants to point out that developers may also feel rewarded by just building things.  But, the distinction I want to make is that developers give the financial reward priority over the alternative.  On the other hand, a coder does it for the “love of the game” and not JUST for the money.

When do you think about your code the most?  Writing code can be a very stressful job.  Many people that do it pride themselves on being able to leave work (and the subsequent stress) at the office and focus purely on their personal lives.  Those people are developers.  Developers work from eight to five, nine to six, or whatever time they are paid to work.  Alternatively, coders may be in the office for eight to nine hours, but they are very likely to come up with the next killer app while doing something recreational like sleeping or gaming.  Coders may change environments, but they never stop working.  They write code for fun.

How did you write your last great project?  Did you use Google to overcome your programming challenges?  Did you copy code from some coder’s blog, or from an open source project without FULLY understanding what it does and why it does it that way?  Or, did you reach out to friends that write code; or better yet, did you figure it out for yourself?  If you reached out to friends or figured it out for yourself (even if Google pointed you in the right direction), you are a coder.

It is important to distinguish yourself between developers and coders.  As coders continue churning out great tools that are intuitive and fun to use, and our general population continue to become more computer savvy, the number of developers will grow much faster than the number of coders.  Developers will be the commodity while the value of coders make a sharp upwards turn.

In fact, what I am describing is already the reality.  Developers are happy to collect seemingly generous salaries and contract rates that allow them to sustain the status quo.  Meanwhile, coders have automated the collection, sorting, distribution, and storage of their funds in the interest of minimizing distractions while they innovate (for fun).