Reputation: 1217
I can´t run visual studio 2012 debug for asp net using IIS7.
I have already tried the following
ASP NET Settings in IIS
.NET Compilation: Changed Default Language to c#
IIS Settings
ASP:
Script - Language: c#
Also I am using Asp Net v4.0 app pool
Is there any other settings I can change to try make it work?
EDIT:
My user is part of Debbuger Users
The error is the following:
Unable to start debbuging on the web server. The web server is not configured correctly. See help for common configuration erros.
EDIT 2:
This is the log
Software: Microsoft Internet Information Services 7.5
Version: 1.0
Date: 2012-12-18 11:29:55
Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken
2012-12-18 11:29:55 ::1 DEBUG /tgpwebged/debugattach.aspx - 443 - ::1 - 403 7 5 43
EDIT 3:
I have manually configured the compilation element in web.config. This is the actuall config:
<compilation batch="true" debug="true" defaultLanguage="C#" explicit="false"
maxBatchGeneratedFileSize="10000" maxBatchSize="10000"
numRecompilesBeforeAppRestart="100" strict="false"
tempDirectory="C:\Windows\Temp" urlLinePragmas="false"> </compilation>
Also just for test purpose changed the user ASP NET V4 app pool runs under to my account. Not the SYSTEM.. my personal account. No success yet.
Upvotes: 1
Views: 8795
Reputation: 1
I've just had the same situation. I have solved it and here's how I did it:
Classic mode
.Upvotes: 0
Reputation: 5087
I'm running into something similar on VS2010 with a site hosted on IIS7.5. I'm trying to hit F5 and get my website to start up an automatically attach a debugger.
I think the key is this line in your log:
2012-12-18 11:29:55 ::1 DEBUG /tgpwebged/debugattach.aspx - 443 - ::1 - 403 7 5 43
As far as I know, debugattach.aspx is some sort of hook that VS will try to invoke before it can actually start up and run your app. Details are a bit sketchy on the interwebs about what this thing actually is, however it does seem that if you don't get a 200 (success) VS won't be able to automatically attach. Basically it fails on step 1. In your log, you have a 403 (authorization error) for this request, I have a 404 (not found) in my log.
In your specific case, you might have something in your IIS config that's blocking the DEBUG verb. It's a common security practice to block uncommon verbs or anything other than POST and GET. In my case, it's probably similar - the aspx extension is probably being filtered out. It could also be the default authentication settings for the app in question.
Update: I did solve this on my end, and two separate things were wrong. First, I was using UrlScan.dll for security and it was blocking the DEBUG verb. Also, I was using a UrlRewrite rule to go from HTTP to HTTPS and the 302 redirect it generated also blocked this VS request. I was able to find both issues using the IIS Failed Request Tracing feature. The logs from that tool give some insight on what various modules and handlers in the pipeline are doing.
Hopefully this helps!
Upvotes: 0
Reputation: 11
Typically you have to run Visual Studio as a local administrator for debugging to work.
Upvotes: 0
Reputation: 758
I have had this issue before (although not with VS2012) and the following things have worked:
http://localhost
is in your trusted sites in your web browser.Upvotes: 1
Reputation: 32541
Try to run the following in the command line:
cd %windir%\Microsoft.NET\Framework\v4.0.30319
aspnet_regiis.exe -i
Upvotes: 0
Reputation: 1185
Can you attach your debugger to the w3wp process and debug that way ?
Here is an article: Attatch debugger to an IIS process
Upvotes: 0