If you get this error trying to set and hit a breakpoint, there are a couple of things to look for to resolve it. Typically what this error means is that the compiler cannot find debug information for the file you are trying to set a breakpoint in.

The first thing to check is that you have compiled the assembly in debug mode.

If you build the assembly in Release mode it will not generate the necessary debug information. Also be aware that there are two modes the compiler can use to generate the necessary program database (pdb) file for debugging, but only one of them actually enables incremental linking of the debug info.

/debug:full or /debug:pdbonly. Building with /debug:full generates debuggable code. Building with /debug:pdbonly generates PDBs but does not generate the DebuggableAttribute that tells the JIT compiler that debug information is available.

Depending on how you are building your solution you either need to look at the msbuild file or if you are building from within Visual Studio you can right click the project file and select properties. Then select the Build tab, and then the Advanced button. You will get the following dialog (VS2008, 2005 may look slightly different.)

Notice under Output the line for Debug Info, make sure this is set to full. The other values available are none, and pdb-only. Neither of the latter two values will result in debuggable code.

The next most common cause is that the [assemblyname].pdb file is not being copied or updated correctly to the bin folder of the startup project in a multi project solution.

You can manually copy the assembly file and the pdb file from the bin folder of the assembly you want to debug into the bin folder of the startup or calling project. Or into the web application bin folder if you are calling the assembly from a web application.

Thanks to Adam McKee of Ironworks who recently reminded me of the fix for this problem. I have put the information here to hopefully help the next person.

Cheers,

Robert Porter

There are a number of add-on's for Fiddler, and every time I have to install Fiddler on a new machine I am always surprised when I go to use an inspector only to find out it is not there.

The best source of information for Fiddler Add-On's is the Fiddler Web Site itself. There is an Add-On link from the home page.

My favorites are:

The Syntax View Inspector

This add-on shows you syntax colored views of the captured session traffic.

The Web View Inspector

This inspector shows you the session data as it would be rendered via IE's rendering engine.

These are only two of the many available add-on's for Fiddler. But they give you a feel for what is available, and of course if there is a feature you want or need that is not already available, you can always write your own inspector!

Step by step instructions on building your own inspector are available here. Fiddler can be extended with .NET code or by using it's own built in Fiddler Script engine.

Cheers,

Robert Porter

I love Fiddler, it is a great aide in developing web applications, web tests and in general figuring out what is happening between your browser and server.

That said, it can be rather frustrating to get Fiddler working under certain circumstances. Over the years I have collected the following answers to the most common annoyances. Most of the following information I found on blogs, forum posts, and newsgroups. I have collected it here for convenience.

Two of the most common errors and fixes when trying to use Fiddler for a proxy debugger.

1. [Fiddler] Connection to localhost. failed:

[Fiddler] Connection to localhost. failed.
Exception Text: No connection could be made because the target machine actively refused it

Go to Fiddler Options and uncheck 'enable IPv6'

The alternative would be to configure your local IIS to listen to IPv6 traffic but this won't help if you are using the built in dev server that comes with Visual Studio

2. If you are not seeing any traffic on your local machine:

IE7 and the .NET Framework are hardcoded not to send requests for Localhost through any proxies, and as a proxy, Fiddler cannot intercept such traffic. There are several fixes to this problem.

The quickest fix is to substitute your machine name for localhost in the url so instead of http://localhost:1841/MyPage.aspx use http://mymachinename:1841/MyPage.aspx.

Another fix is to insert a '.' (period) right after the localhost in the url. e.g. http://localhost.:1841/MyPage.aspx

You can also edit your local hosts file to alias 127.0.0.1 to something like 'local'

A great deal of information on specific configuration issues in a variety of client systems is available on the Fiddler web site on the Configuring Clients page.

Enjoy!

Robert Porter

Hmmm