Uma coisa que me incomoda bastante é ter que executar o Visual Studio como Administrador para poder depurar um web site hospedado no meu IIS local.
Eu entendo perfeitamente o motivo disso, mas para quem não sabe, segue abaixo uma explicação rápida:

• Por questões de segurança, usuários só têm permissão para depurar seus próprios processos, ou seja, não podem depurar processos de outros usuários. Isso acontece para proteger aplicações contra vírus e códigos maliciosos que poderiam interferir em outros aplicativos ou mesmo manipular a memória com intenção de corromper ou obter dados sigilosos.
• Sites no IIS são executados sob o usuário definido em seus Application Pools, portanto o seu usuário que está executando o IIS não tem permissão para depurar esses processos.
• Mesmo que seu usuário faça parte do grupo de administradores do computador, de modo geral ele roda como se não fosse administrador para proteger o sistema e só muda para modo elevado se você tentar executar alguma ação que necessite dessa permissão. Quando isso acontece, aparece aquela modal perguntando se você realmente deseja executar como administrador.

A solução mais comum que se encontra na internet para esse problema costuma ser executar o Visual Studio como Administrador, mas essa solução me incomoda bastante pelos seguintes motivos:

• Perdemos a integração com o shell do Windows, ou seja, não conseguimos mais arrastar e soltar arquivos do Windows Explorer para o Visual Studio (justamente pelo fato de serem processos de usuários diferentes)
• Ao dar um duplo clique em um arquivo qualquer que esteja vinculado ao Visual Studio (.sln, .csproj, .cs, .aspx, etc..) ele será aberto em uma nova instância do Visual Studio, mesmo que já exista uma instância aberta. Se configurarmos o Visual Studio para sempre abrir como Administrador, para cada arquivo que tentarmos abrir a partir do Windows Explorer teremos uma nova instância do VS.
• Sempre que executamos o Visual Studio como Administrador aparecerá aquele prompt de segurança para confirmarmos a operação, ou pior, teremos desabilitado o prompt para parar de incomodar e com isso reduzido a segurança do computador como um todo.

Uma solução que eu tentei uma vez foi configurar o Application Pool dos meu sites no IIS para serem executados com meu usuário, mas nunca consegui fazer essa alternativa funcionar como deveria.
Até que achei uma solução onde não procurava: Remote Debugger!

Pelos meus testes tem funcionado perfeitamente. É bem simples de usar:

• Execute o aplicativo Remote Debugger como Administrador (ele é instalado junto com o Visual Studio).
• No Visual Studio, faça o procedimento normal de Debug > Attach to Process…, mas no campo Qualifier (onde deve estar escrito o nome do seu computador), mude para 127.0.0.1:4020 (ou outra porta qualquer que esteja configurada no Remote Debugger). Para ver a porta, vá em Tools Options no Remote Debugger.
• Agora é só achar o processo do IIS que está executando o site em questão e depurar!

Se esses passos acima funcionarem, há uma opção melhor onde não será mais necessário iniciar o Remote Debugger sempre que for usar.

1. Basta instalar o serviço do Remote Debugger usando o aplicativo Remote Debugger Configuration Wizard, que também é instalado com o Visual Studio. A única pergunta que lhe será feita é para qual tipo de rede você vai permitir o debug. Eu marquei apenas a opção de redes Private.
2. Depois vá ao gerenciador de Serviços do Windows e altere esse serviço recém instalado para que seja executado com seu usuário e não com o usuário LocalSystem. Se não fizer isso, sempre que tentar anexar o processo para depuração será solicitado um usuário e senha.

Meu computador agora está com o serviço do Remote Debugger configurado e em modo automático, assim não preciso mais abrir meu Visual Studio como Administrador para depurar sites hospedados no IIS.

Update 23/05/2017: Link para a página de download do Remote Tools for Visual Studio 2017 e link direto, caso a página seja alterada no futuro: vs_remotetools.exe