Introduction
When debugging your application, there are often times when it would be helpful to get a better understanding of what is happening beyond the boundary of your application's source code. For example, your project may reference a 3rd party dll, or maybe you want to step through code in one of the .Net framework dlls.
That's where Reflector Pro's ability to debug a dll comes in. This is a truly wonderful feature - hats off to the team at Red Gate!
This post, however, is not an introduction to Reflector Pro's dll debugging feature. What I am presenting here is a solution to remote debugging a 3rd party dll in an ASP.Net application. This is not as straightforward as you might think, and indeed before I came up with this solution I had thought it may not be possible at all.
The Problem
The core problem is that the symbol files (.pdb) created by Reflector Pro are on the local machine, which is inaccessible to the remote server.
The Solution
Share the local pdb store.
The Solution (in more detail)
The best way to explain is with an example. Here I'm attempting to debug the open source component OSGeo.MapGuide.Web.dll on a remote server named 'web-server'.
In this case, the component is open source so you could go to the OSGeo website, download the source, build in debug mode, copy the dll and pdb to your server to get the ability to debug the dll. But, as you will see, the procedure I have outlined in this post should get you debugging the dll far more quickly, and doesn't require that you download the source code.
The first step is to have Reflector Pro generate debug information for the dll we are interested in. Open Visual Studio and select 'Choose Assemblies to Debug' from the .NET Reflector menu.
You can see in the screenshot below I have selected a dll directly from an administrative share on the web server.

Strong Name Signed dll.
If the dll you are trying to debug is strong name signed, you will probably get this prompt from Reflector requiring that a debugger signature is added and the assembly is regenerated.
I have prepared a separate post to show how you can deal with this situation in an IIS remote debugging scenario.
Fortunately, this OSGeo dll is not strong name signed, so we can proceed.
Populate Reflector Object Browser
If you don't already have a Visual Studio project that references the dll you want to debug, the next step is to create one. Technically this is optional, but it's the easiest way to get the Reflector Object Browser to list the dll we are interested in. I created a Class Library project.
Now switch to Reflector Object Browser. From here you can drill into the dll, open class files set breakpoints.

Now for the real crux of this solution...
First we need to determine the Reflector symbol cache location. This can be seen in VS, Tools > Options > Debugging > Symbols dialog.

What we want is the path to the 'Cache' folder, not including the '0' subfolder. Open in Windows Explorer and create a share of the 'Cache' folder (not the '0') folder.
I named the share ReflectorSymbolCache. Readonly permission is sufficient.

Now go back the Visual Studio Debugging Symbols options dialog. Add a new symbol file location that is the UNC path to the share you have just created, and add the subfolder so it matches the local path. My local pc is called 'dev-pc' so the path I'm adding is:
\\DEV-PC\ReflectorSymbolCache\0
As this is a network location, VS automatically configures a symbol cache folder for you, even though this won't be used in this setup.

Start Your (debugging) Engines...
Login to your web server and start msvsmon (Visual Studio Remote Debugging Monitor).

Back to Visual Studio again, open the Attach to Process dialog. Enter the remote debugging qualifier name to connect to the remote machine and find the IIS worker process w3wp.exe that is hosting the applicaton you want to debug.
In the screenshot below there is only one w3wp.exe process, but there could be more if there are multiple IIS application pools active. You need to determine which one is the correct one for the code you are trying to debug. Sometimes it's easier to simply attach to all w3wp.exe processes.
If no requests for the application have been made since IIS started, the
application pool may not have become active and the w3wp.exe process
you want to connect to may not be present. If so, launch a browser to
start the application and refresh the Attach to Process dialog.

You should get a warning regarding the automatically created symbol cache location, but you can safely ignore it. The local path to Reflector's
symbol cache will be used on the local machine; only on the server will
the UNC path be used. Therefore, the temporary SymbolCache folder won't
be populated at all.

To verify that symbols have been loaded for the dll you are trying to debug, open the Modules window in Visual Studio (Debug > Windows > Modules). If all has gone well, you should see 'Symbols Loaded' for your target dll.

At this point the debugger is attached and your breakpoints should be active, solid red dots.

Happy debugging!