To enable this feature, you need to uncheck “Disable script debugging (Internet Explorer)” in the “Advanced” tab of the “Internet Options” dialog in IE:

Debugging is now enabled:

Doing this will also give you access to Visual Studio’s Script Explorer which allows you to view and trace through the stack of scripts that are running within your ASP.NET application behind the scenes:

Warning: Client-side script debugging does slow down the application quite a bit during development. It would be wise to only have this feature enabled when you need to debug javascript.

Note: This information assumes that you are using IE as your default development browser. If you would like to change default browsers, select your website project in the Solution Explorer, and then select “Browse With…” from the File menu:

Alternatively, while the application is running in Debug mode, you can attach the process to another browser and run the two browsers in tandem. Select “Attach to Process…” from the Debug menu to accomplish this:

Global Assembly Cache
The GAC is special because it allows a pc to store multiple versions of the same .NET assembly. This is made possible by strong naming. More importantly, it provides a centralized location for .NET assemblies that need to be shared across multiple applications.

When viewing the GAC via the Windows shell, you go here: C:\Windows\Assembly. However, the Explorer-like UI actually represents an aggregate of files and folders. Windows is just trying to make it look nice and user friendly for us.

Tricking Visual Studio
To trick Visual Studio into referencing a GAC assembly, you can do the following:
1.) Reference a copy of the assembly that is located outside of the GAC via the Add Reference dialog. You can throw a copy on your Desktop and then reference it from there. It doesn’t matter what the file’s location is.
2.) Install the assembly into the GAC. There are a number of ways to do this. The easiest way is to use the “Microsoft .NET Framework 2.0 Configuration” app. You can find it by going to Control Panel –> Administrative Tools. Once in the app, click “Manage the Assembly Cache” and then “Add an Assembly to the Assembly Cache.”
3.) Delete the assembly file that you referenced in step 1. Go into Visual Studio and refresh the project. The path of the reference should have automatically changed over to its GAC location (C:\Windows\assembly\…).
4.) You may want to set the reference’s “Copy Local” property to False so that the build does not produce a copy of the GAC assembly in the bin folder (to avoid confusion). In doing so, you can be confident that your app is in fact hitting the GAC!