Can someone please tell me what needs to be done to debug a asp.net app using IIS7 instead of the Development server with VS2010. I have found multiple resources online that says how to do it and they all have different steps. I cannot seem to get it to work.
Thanks,
Blake
Install IIS 7
Register ASP.NET with IIS (aspnet_regiis.exe -i)
Configure the web project to use IIS instead of the built-in server:
Remark: You could also checkout IIS Express.
If you mean debug a web application that is running in IIS instead of the development server, then "Attach to process" is the way to go. This means selecting in the debug menu "Attach to process" instead of "Start Debugging". You will see a dialog a bit like the task manager and will need to select the process to attach to. For IIS this will be w3wp.exe. There will most likely be more than one instance of w3wp.exe running - so selecting the right one will be the real trick. Set a debug point in the source - if you're connected to the right w3wp instance the debug point will look as normal rather than having the warning sign (and looking flat and white). I was doing this today and used this as a reference.
Related
Our company ships an MVC based product (targeting v4.5) which has stopped working on a customer site for what appear to be environmental issues - a build which worked with no problems once upon a time now gives a 403.14 - The Web server is configured to not list the contents of this directory.
.
What I think is happening...
The user accesses http://server/AppName
Because it's an MVC app, the default route (Reports/Index) should be used.
Instead IIS is looking for a default document...
... and, not finding one, it assumes the user wants to list the contents of the directory...
...which is not enabled so it throws a 403.14.
.
What I've tried so far...
Accessing the route directly.. results in 404 error. So I'm pretty
sure IIS doesn't realise it should use routing.
Use aspnet_regiis to register ASP.Net with IIS. This was done from the Framework64 folder since...
OS is 64 bit - Windows Server 2008 (Standard without Hyper-V)
IIS is 64 bit - though Enable 32-Bit Applications is true
Checked AppPool is targeting v4 of the framework - it is.
Changed AppPool mode to Classic - was pretty sure it should be integrated but was worth ruling it out. It is now back to Integrated
Confirmed RunAllManagedModulesForAllRequests is set to true in the web.config.
Checked permission conditions defined in <system.webServer> section of web.config are met - they are.
Created the simplest of MVC applications and deployed it - same problem.
Running the command shell as Administrator unregistered ASP.Net using aspnet_regiis -ua and re-registered using aspnet_regiis -enable -i. We hit a couple of permission problems - and the Temporary ASP.NET Files directory was missing but once they were address we were back to the same error.
Added a simple default.htm - when present, this is served in response to the http://server/AppName request.
I'm clean out of ideas and all google hits suggest some combination of the above - or enabling directory browsing (which I think is just a symptom rather than the root cause).
Also, not sure if it's relevant but the amount of configurable elements available for the application in IIS seems a bit below what I would have expected...
Have you Checked the user the application pool process is running under? I think Your site needs to run with permissions to execute the .net libraries and I've seen this just change for seemingly no reason (probably related to an overzealous update to the system).
You can try with the Enabling directory browsing .
assuming you are under Windows Server 2012 or Windows Server 2012 R2
On the taskbar, click Server Manager.
In Server Manager, click the Manage menu, and then click Add Roles
and Features.
In the Add Roles and Features wizard, click Next. Select the
installation type and click Next. Select the destination server and
click Next.
On the Server Roles page, expand Web Server (IIS), expand Web
Server, expand Common HTTP Features, and then select Directory
Browsing. Click Next.
On the Select features page, click Next. On the Confirm installation
selections page, click Install. On the Results page, click Close.
if you using the Windows PC try this in your command prompt as follows:
go to C:\Program Files\IIS Express
then press Enter:appcmd set config
/section:system.webServer/directoryBrowse /enabled
Maybe this is your case https://forums.iis.net/t/1157304.aspx
SQL Server Reporting Services creates a folder called Reports by
default if you install it on IIS. If you install SQL 2008 then
Reporting Services doesn't need to use IIS and instead will try to
reserve the URL with the HTTP.Sys service.
I believe this is the cause of the conflict you are seeing. What you
could try is changing the URL that Reporting Services uses via the SQL
Server Configuration Wizard.
Also I found that
Report Manager of SQL Server can use reports path http://<server name>/reports
Configure a Native Mode Report Server for Local Administration (SSRS)
I think the problem is IIS features that are not installed yet. I have met this kind of problem frequently in Windows Pro. Make sure to turn on every feature under Internet Information Service -> World Wide Services because by default IIS is configured to use WebForms. So there might be some features that not installed yet to use MVC, especially ISAPI filters. In my case, that was the solution. I hope it helps.
Something similar i encountered using VS 2017 & ASP.NET MVC.
Was working on the project for long with no problems at all but suddenly the routing started misbehaving & stopped working.
So I changed the Port in Project Properties Page & it started working.
I really don't know what is the relation between a port & MVC routing modules. Someone else can enlighten if at all this helps.
I had the same problem and I just created an application pool out of the Default Web Site in IIS and stoped the default web site. With that difference you will not have the application pool's path
I know it's been a long time since this question but i've had the same problema recently. I've tried every single configuration, just like #amcdermott did, but the only action that solve the problem was reinstalling .NET Framework.
My app was built under .NET Framework 4.5.2. The application server had the version 4.6.1 and 4.5.2 installed. So, i uninstalled all framework versions and installed the one that i needed.
Please, make sure that no other applications use superior versions of .NET Framework if you going to try this solution.
Here are some quote I find on Microsoft official site which I think may help:
For site administrators
This problem occurs because the Web site does not have the Directory Browsing feature enabled, and the default document is not configured. To resolve this problem, use one of the following methods:
Method 1: Enable the Directory Browsing feature in IIS (Recommended)
To resolve this problem, follow these steps:
Start IIS Manager. To do this, click Start, click Run, type inetmgr.exe, and then click OK.
In IIS Manager, expand server name, expand Web sites, and then click the website that you want to modify.
In the Features view, double-click Directory Browsing.
In the Actions pane, click Enable.
Method 2: Add a default document
To resolve this problem, follow these steps:
Start IIS Manager. To do this, click Start, click Run, type inetmgr.exe, and then click OK.
In IIS Manager, expand server name, expand Web sites, and then click the website that you want to modify.
In the Features view, double-click Default Document.
In the Actions pane, click Enable.
In the File Name box, type the name of the default document, and then click OK.
Method 3: Enable the Directory Browsing feature in IIS Express
Note This method is for the web developers who experience the issue when they use IIS Express.
To do this, follow these steps:
Open a command prompt, and then go to the IIS Express folder on your computer. For example, go to the following folder in a command prompt:
C:\Program Files\IIS Express
Type the following command, and then press Enter:
appcmd set config /section:directoryBrowse /enabled:true
I built solution, created application in IIS and mapped it to the application folder. It works fine. Then I go to "Attach to Process", there are two w3wp.exe processes in list, but for one of them I get error "Unable to attach the process. A debugger is already attach." I've googled it but I can't find solution for my problem.
I have installed Debug Diagnostic Tool v2.0 and as a result I have Debug Diagnostic Service which is started automatically and attached to one of w3wp processes. After turning off and disabling this service all works fine.
So the general rule: if you get such error check processes in task manager which can capture your w3wp process.
You have 2 instance of VS and two entries in IIS running on the same application pool, for instance Both Server and Intranet are running on the same application pool.
=> Solution open IIS :
° Select the site and click 'Basic Settings' : Here you can check/select
the application pool used.
° Click on the "Application Pools" node (right under your computer name)
=> You get a list of defined application pools.
° Right click under the last one defined to open the context menu and
select 'Add Application Pool...'
Create a new name and give it the same parameters that the one that was used
by your site.
° Select the 'Basic Settings' of one of your sites and change its application
pool to the new one just created.
=> Now Server and intranet have different application pools and your can
debug the both at the same time.
Hope this helps.
For me, even after disabling the Debug Diagnostic Tool v2.0 this issue didn't fix. So, I rebuild my webservice, pushed the DLLs on the IIS and restarted the it, which fixed the issue for me.
This issue may occur when you make changes in the your web service which is hosted on your local IIS and those changes are not pushed.
Debug Diagnostic Tool v2 Update 2
https://www.microsoft.com/en-us/download/details.aspx?id=49924
Can use this link if the link provided by #mtkachenko above doesn't work
Have this in Visual Studio 2019 but after the debugger crashes on occasion. Without restarting the PC, which can be a slow affair, create a temporary second application pool and switching the site over to the new app pool in IIS also works.
Really odd - but this simple thing works for me:
Go to some file in your main project.
Go to Project menu and choose Set as start-up project.
This might seem redundant if you've already chosen that project as the start-up project before, but it seems to work.
I have searched all the usual but come up empty. I must be doing something silly!
Simply I created a new project, ASP.NET Web App, and wish to use and debug it with the local install of IIS 7.5 on my Windows 7 x64 box.
According to what I have read it should be a simple process; my issue is that Visual Studio will not stop at breakpoints nor at errors etc.
I just don't get it:
Visual Studio is attaching to the w3p process for me automatically.
If I hover over the breakpoints it shows a message saying the same, that it is in the same w3p process.
I am in Administrator context. I manually ran it like so to be sure but in any case if you are an admin it runs like that anyway.
Some notes:
I do not wish to use IIS Express as I require native IIS 7.5 for my tasks, however it does debug in express - no surprise there.
As mentioned above, all this is being done locally.
The path of the virtual directory is pointed towards the project files, as set by Visual Studio 2010. It even set the Network Service as read on the folder structure.
When debugging from VS the web site runs fine, just debugging is the issue.
Maybe it is permissions? The Default App Pool is using the ApplicationPoolIdentity not Network Service... Should it be? I had assumed they we.re one and the same essentially. Although I changed this and no luck unless I didn't do something I should of
Keep in mind here that my issue is semi-unique in that I am not receiving error messages, not even in the event logs... For all intents and purposes it should be working fine, just it isn't.
VS and IIS, and all updates, are applied to date.
Note: I'm familiar with IIS7.5, I run my own public web hosting server. I just never tried to debug
Note: It is Visual Studio 2010 Ultimate
Thanks for your time.
Sigh!
I went back to basics... Uninstalled IISExpress and tested; It worked! Re-installed IISExpress; It worked!.
I guess installing IIS7 native after IISExpress did something screwy? I had ran the register ISS command on IIS7 when I installed it.
Right, so now I have both installed in tandem and they work fine. Thanks for all your help guys, appreciated.
you can try right-click on project in VS go to properties select web from left menu tab. Check if ASP.NET debugger is checked and also you can select Use Local IIS Server and give localhost url there (in project Url textbox) and then Say start debugging from VS and put breakpoints.
I had a similar issue the other day, I attached the debugger to the wrong w3p process, make sure you attach it to the one the app pool identity is running under.
I wanted to write it as comment by I don't think I can add pictures..
Are you sure you are running the same version of dll?
Is your breakpoint filled like this?
or hollow like this?
1st go to ,Program and Feature in control panel and then in that turn on or off windows features. and now check all check boxes(activate features) related to Internet Information server & windows service managers. once this is done run your visual studio as administrator and then attach to right w3p process.
I installed Visual Studio 2003 on Windows 7 but I am getting the following error on when I press the F5 for debugging.
Error while trying to run project: Unable to start debugging on the web server.
Could not start ASP.NET or ATL Server debugging.
Verify that ASP.NET or ATL Server is correctly installed on the server.
What does that mean and how do I fix it?
The cause for this as per microsoft support is -
This problem occurs because the debugger does not send the debug action to IIS when you run the application. The debugger identifies your computer as localhost. However, in IIS, the Web Site Identification of the application is the IP address that you specified
The resolution is as given below -
http://support.microsoft.com/kb/814717
http://forums.asp.net/t/703333.aspx
I found answer :
iis manager -> computer name -> ISAPI and CGI restrictions -> aspnet v1.1... -> select allowed
(dont forget restart IIS.)
I tried all the options but in vain. My solution was:
Go to properties page of the application in VS2010
a. check you have selected 'Define DEBUG constant'
b. check you have selected 'Use Visual Studio development server' under the Server.
i) select 'Auto-assign Port'
c. check you have selected 'Apply server settings to all users'
d. check you have selected 'asp.net' under Debuggers
Mine all the above were messy. I did the same and it worked.
May be you have to install another server on your computer, so it conflict with IIS server. You have to change another server port address or remove from your computer.
Simple steps to solve this error!!
Make sure the following things are intact:
Check if your application pool is stopped. If so, start it.
Also make sure the framework of the pool matches with that of your application.
Virtual directories in IIS need to bear the same name as its
original application directory
Clear Temp files, Temp ASP files, delete the worker process of the application and restart your IIS.
Here's a link that will help you setup ASP.Net 1.1 and its requisites, in case, the above didn't help you.
How to setup asp.net v1.1
There is a post on IIS.net titled "Using Visual Studio 2008 with IIS 7.0", but I don't quite believe that's what people do. (Among other gems, it suggests publishing your web app after every change.)
If you debug your ASP.NET applications in IIS7 instead of Cassini, I would love to hear your methods, tips, and tricks.
Edit: I'm referring specifically to local debugging.
I believe I pointed you toward that guide, but as I look closer at it I think that's a little more elaborate than what I do. I have done the following:
Create a web site in IIS for your project.
Add a custom host header to that site, for example http://mysite:*/ or http://mysite:80/
Open the hosts file located at C:\Windows\system32\drivers\etc in notepad (Run As Admin if you're on Vista) and add the following line:
mysite 127.0.0.1
If you have more than one host header on your website in IIS, you need to have each one represented in the hosts file.
Now, when you press F5 in Visual Studio, the site will open with the url http://mysite and you'll be able to debug, set breakpoints etc as usual, except with no Cassini related problems... ;)
Edit: For clarification, I just want to point out that I have never had to attach any process to VS, as far as I know. At the very least I do not have to do it every time.
I simply attach Visual Studio to the IIS worker process, if you have multiple app pools then you can run "issapp" to get the appropriate PID.
I never debug by clicking "Start Debugging".
This has a nice advantage of working on remote servers as well, if you have installed msvcmon.
Well, setting up IIS 7 for debugging isn't terribly tricky, but what I prefer to do to save time (and if I'm uninterested in debugging from a cold start) is to launch the Web Application/Web Site in a web browser first - let ASP.net precompile etc.
Then I'll attach to the IIS process using Visual Studio. Once attached I can go about setting breakpoints and debugging, I find this is a faster way to get going.
I launch Visual Studio as an Administrator, then Debug > Attach to Process > w3wp.exe.