Mister Goodcat

Peter's home of all things life

Wednesday, 9/15/2010 12:52 AM
by Peter Kuhn

Firefox Debug Helper (Visual Studio Add-in)

Wednesday, 9/15/2010 12:52 AM by Peter Kuhn | 19 Comments

A newer version of this tool can be found here.

Ever since the release of Firefox 3.6.4 (and its new plug-in isolation feature), a smooth debugging experience for Silverlight developers who use that browser went away. The problem is that Visual Studio attaches correctly to the Firefox process; however, all Silverlight applications now run in a separate process called 'plugin-container.exe', and so the debugger is not able to find them. You're now left with three options:

  1. Either attach to the correct process manually each time you want to debug a Silverlight application or
  2. Disable the feature altogether or
  3. Switch to a different browser

Option 1 is pretty tedious work if you have to do it over and over again, all day long. Option 2 on the other hand is a dangerous thing to do, because disabling that feature is not straight forward, which means that you're now testing your application in a different environment than 99,9% of all your users. Unfortunately, Silverlight behaves differently with or without that option enabled in some scenarios, so turning that feature off is not recommended - unless you want to risk that serious bugs slip through undiscovered and in the worst case surface only at your users. Finally, Option 3 was not an option for me out of personal taste.

Manually attaching to the plugin-container process

(Manually attaching to the plugin-container process of Firefox)

So what now? The idea was to write a simple Visual Studio add-in that does nothing else but attach to that process automatically when you start a debugging session. That turned out to be harder than I thought. If you're interested in some of the details, I'll discuss them in this follow-up post. If you're only interested in the add-in itself, you can download it directly here.

Update 2010-10-02: Two packages are available. If you only are interested in using the add-in, download the VSI package. A simple double-click launches the Visual Studio Content Installer and leads you through the process of installing the add-in. The zip archive contains the source code, for those of you who are interested in the implementation details.

[The old download links have been removed. A new version can be found here.]

Disclaimer:This add-in comes as-is, without warranty of any kind. You use it at your own risk, and I'm not liable for any damages caused by the use of this add-in. I only tested this software in my own development environment, which is Visual Studio 2010 and Windows 7 64-bit (both English versions).

Now that the official part is done, here is a short description of what the add-in does: when you start a debugging session, it first looks if your solution contains one or more Silverlight projects. If it does, it checks whether Visual Studio attaches to the Firefox process. Then it searches through the local processes for the plugin container process of Firefox and picks the right one if there is more than one by determining which one has loaded the Silverlight runtime (there may be additional of these processes for Flash etc.). If the process is found, it attaches the Silverlight debug engine to it.

The add-in outputs messages to the debug pane of Visual Studio's output window. If anything goes wrong, that should be the place to look for. You can also disable the plug-in in Visual Studio's Add-in Manager. If you want to remove it completely, simply delete the .dll and .AddIn files from the folder MyDocuments/Visual Studio 2010/Addins. On the next startup, Visual Studio will notify you that the plugin could not be found and offers to remove it from the plug-ins list.

Visual Studio's add-in manager

Happy debugging! :)

Comments (19) -

I was previously using the 'disable' method in order to debug SL running in FF but would much prefer this method.  I downloaded the solution and had to change the working directory and the path to the IDE since I am running VS in a 32 bit Win7 environment.  The solution compiles and a new instance of VS is launched.  However debugging fails to attach to 'plug-in container.exe'.  When I look at the plug-in manager the problem is that the helper is not available.  I went ahead and used the extensibility wizard to create another project and copied your connect.cs & extensions.cs source files.  Voila - The plugin is available.  However, it still isn't working.  I'll get a chance later to do further debugging, but for now I have to go back to disabling the container.

Hi Mark. Thank you for your comment. I've now added a VSI package that should install the add-in automatically, without the need to manually recompile and run it at least once. I've successfully tested that on some computers here (unfortunately all of which are running on 64-bit).

The VSI does make the helper available in VS, unfortunately, it still doesn't attach to 'plugin-container.exe'; I should have some time this afternoon to nose around and see what is failing in the 32 bit world (do weird, it is usually the other way around).

After a system reboot I had both the original & my renamed versions available in VS & trying to attach to the the plug in container.  The second failed of course since the first was already attached.  Simply disabling one solved the extra log message.  In any case, thanks for figuring out how to do the auto attach.

Great that you figured it out, and glad I could help Smile.

Thanks for the add-in, but it didn't work fully for me. If I disable the FF option, then when a WCF exception occurs (which is what I was trying to debug), VS stops me in the code. With your add-in, I can set breakpoints, and they'll be hit, but if an exception happens, I'm left sitting twiddling my thumbs. VS doesn't seem to do anything.

Any ideas? Thanks again

I use the add-in to debug WCF services all the time (without problems), so maybe I don't fully understand the scenario. Do you have a small sample project for me that shows the issue?

Hello again. I just tried a brand new Silverlight/WCF solution, and noticed the following message in my output window when I tried to debug...

"Firefox Debug Helper: Could not find Firefox's plugin container process for Silverlight after 10 attempts. Taking no further action."

If I do Debug->Attach to process, I don't see the plugin-container.exe process there. It was there yesterday, before I discovered your plug-in. I was manually attaching to debug.

Any ideas? No idea if it's anything to do with your plug-in, but since I installed it, I don't seem to have a plugin-container.exe process, so I can't attach manually and your plug-in can't do it for me.

Don't know if it's relevant, but I had set dom.ipc.plugins.enabled.npctrl.dll to false, but have since set it back to true, and restarted FF.

Thanks for any help

OK, just to follow up, I restarted FF again and the plugin-container.exe process was there. I was able to set a breakpoint in the .xaml.cs code and break on it.

So far so good. However, if there was an exception, I didn't get anything. Normally if an unhandled exception occurs when debugging, VS breaks at the line that caused it. In this case it didn't. It just sat there doing nothing.

Now this could be due to the way WCF and Silverlight handle exceptions. I don't know enough about either yet to say. The exception was sent back from the WCF service. Should I be able to see this in VS?

Thanks again

Regarding the missing plugin-container.exe process: sometimes FF is not able to shut down correctly or in a timely fashion. If you re-open the browser then, it can be that a changed dom.ipc.plugins.enabled.npctrl.dll setting is not picked up. I've seen that happen and it's probably what happened to you too.

I've just create a fresh sample application that uses a Silverlight-enabled WCF service which throws an exception. When I start debugging, the add-on attaches to the plugin-container.exe process. As soon as the service throws an exception, Visual Studio breaks. It then automatically breaks again when the client receives the exception. So my guess it's either a particular parameter in your VS options or project that prevents this from happening.

I'll send you my email contact details, maybe you can send over a sample project I can analyze.

I just want to publicly express my thanks to Peter for a great add-in, and his fantastic support. As you can see from his reply to my comment, he was willing to take a sample project and have a look at it for me.

Not only that, when it turned out that my problem was nothing to do with the add-in, but was my VS settings, he helped me with that as well.

Thank you again Peter. If more developers were like you, the world would be a better place!

See: timheuer.com/.../...-in-firefox-visual-studio.aspx

In "about:config", set "dom.ipc.plugins.enabled.npctrl.dll" to "false", restart FFX.

Hi Peet. I'm aware of that. The problem with changing that setting is (like I wrote in the beginning of this post) that you're now running the browser with different settings than the average user, and serious bugs may slip through undetected on your developer machine (take a look at the Firefox crash I've investigated in the previous post).

These are not empty words by the way. I have seen just that in real life. A solution worked fine in IE, Chrome and FF with the mentioned setting set to false. It was not until support requests regarding crashes dropped in from users (e.g. the application was already rolled out!) that a bug on FF has been discovered.

Thanks for the plugin. I have created a ria service/sl4 application using the silverlight business app template from vs2010. It seems the debug helper cannot find my silverlight project in the solution. This is the output window:

"Firefox Debug Helper: No Silverlight project found. Taking no further action."

Any ideas?

Best regards,

Hallo Joe. I've just tested this with an empty SL4 application and the business application template, and it works here.

Apparently the detection of Silverlight projects fails for you. I'm using the extender names to check for Silverlight projects, because there's a specific extender name for Silverlight. Are you able to debug the add-in? If so, can you check what extender names your projects have in the "IsSilverlightProject" extension method? If you cannot debug the add-in, can you provide a sample project that demonstrates the issue?

Thank you for bringing this to my attention,
- Peter

Hi Mister Goodcat,

I tried installing your add-in but get a warning from VS2010 that it failed to load: error message- unknown, error number- 80131515. Nothing in the output window. Any ideas?


Hi Ian. Apparently that error says that a dependency (referenced assembly) might be missing. Can you check that these are present on your system?

Extensibility (belongs to the VSTO, I suspect maybe that's the one)

Alternatively, you can also download the source code and try to compile it yourself. That should also give you a clue what the problem is.

Hey Peter. Great add-in and it works with SL4 just fine, but when i tried it with a SL3 project it did nothing, and no error message showed up... So I've found myself digging in the source code, trying to find out why.

After an hour or so I've noticed that if the add-in does not find Firefox at it first attempt, it won't try again (so probably it has nothing to do with the SL version. but still, something did not work correctly).
And why's that? When the "AttachToPlugInTimerTick()" method is fired, it disables the timer, and after failing to find Firefox in the "if" condition, the method quits because of the "return" inside the "if" condition. Afterwards the add-in won't try finding Firefox again, as it should, because the timer is off.

Next thing I did is making sure the timer will be enabled again if needed. Fixing this solved my problem, if you need the edited source code you can contact me. An other option is to fix it yourself as it is an easy fix.


Hallo Idan. Thank you very much for this reply and the issue you've found. Working on the add-in to improve some aspects is on my list for the near future, and I'll definitely think about adding your fix too. One of the reasons this is missing at the moment is that if you're not using Firefox (can also be temporary, e.g. when you test other browsers etc.) this needs a stop condition of some sort or else it will try to find the process indefinitely. But adding it still shouldn't be a problem.

Thank you again,

Pingbacks and trackbacks (2)+

Comments are closed