I have an Azure application that works perfectly on every one of my colleagues machines. On mine, the web application works, but not the azure project, which runs on the local development fabric.
I'm getting a 403 error, which causes a blank page in Chrome. The application_start method gets fired and sets up the routes, but the actual MVC controller never gets called. Again, this works perfect if I run the web application directly. If I use that same azure project and deploy it online, it also works fine.
I've tried repairing visual studio, reinstalling Azure, rebooting, re-fetching source, you name it.
I'm desperate for ideas! What would cause a 403?
Here is the answer. Looks like I wasn't the first to be victimized by this:
http://scottdensmore.typepad.com/blog/2010/05/how-a-checkbox-saved-paving-my-machine.html
What's interesting is that I wasn't even using IIS.
You need IIS for dev fabric. Cloud service projects do not run on the asp.net web server inbuilt in visual studio. Refer this.
So any configuration issues in IIS will affect you.
Related
Trying to migrate a legacy ASP.NET WebForms/MVC hybrid application from Cloud Services to App Services. All runs fine locally in debug Visual Studio (V2022). The app is predominantly webforms but MVC has been retro fitted and is in use for some pages. It's using .NET Framework 4.8.
Deploying directly from Visual Studio. We have created a new App Service and App Service Plan. The site appears to deploy correctly but the endpoint returns the below as raw text, i.e. the web browser doesn't even attempt to render it, presumably as there is no header information specifying html content-type:
Have checked the configuration for the app service, all appears normal (same as other app services that run quite normally). It's set to ASP.NET 4.8 with all the other standard defaults. The default documents includes Default.aspx which matches the application. The application is using Forms authentication and defaults to a Login.aspx page. We have tried removing this and redeploying but we still get the same result. Configuration and Management diagnostics section on the Azure portal shows no significant errors.
In Kudu (advanced settings) if I access the debug console, I find my app is deployed to c:\home\site\wwwroot> as expected, however if I click "Site Root" it flips me to c:\local>
Could it be IIS is pointing to the wrong path for the site?
In the end found some rogue code that was causing the issue. The different paths under Kudo was a red herring.
To diagnose the problem we moved from VS deployment to CI deployment and still had same issue. This meant it was not publishing settings. We compared web config with other solutions that ran fine as app services and found no significant differences. This ruled out IIS settings from web.server section. We checked for errors on the app and found no errors being reported.
In the end we trawled through the code and eventually found something that was URL specific.
I finally got my ASP.NET MVC application hosted on my local Windows/IIS server. I went to the login page but when I try to log in it says,
Error:
An error occurred while processing your request
This is fairly non-descript...
My gut feeling is that when I did the web deploy, I didn't deploy the localdb(?) where the users' credentials are stored. Before I try to re-deploy the entire app, I'd like to see if anyone can offer some guidance. Am I on the right track? Are there other possible causes/solutions I should investigate?
I'm using the default registration/login system that is in the project to start with, and it woks just fine in VS. I did a regular web deploy to my IIS server, and the site works just fine until you go to log in.
Fixed: This issue was caused (as suspected) by the inaccessibility of the LocalDB where all the users' credentials are stored. VS uses this light DB instead of making you install SQL Express or another alternative (much like IIS Express works better for debugging than full IIS). When I push my application to IIS from VS, the database wasn't connecting. I eventually found this other SO question, and the top answer fixed my issue.
How to deploy ASP.NET MVC 4 application using localDB to local IIS on Windows 7?
This will solve the issue, but there is a lot of conflict on the web as to whether or not it is ok to use LocalDB in production, so if you have a lot riding on your project you might want to take a look at that. For my purpose, LocalDB is just fine, so this solved the issue. Thank you to all who responded to my (admittedly) broad question. I'm sure this will be a useful thread for others with the same issue.
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'm using Visual Studio 2010 and working on an ASP.NET 4.0 web application. At the moment, a co-worker and I are tweaking CSS, which means constantly changing and saving CSS files and then refreshing the running page in a web browser.
Every few saves, the application restarts, causing a considerable delay while we wait for the app to start up, log in again, and return to the page we were working on. In an IIS production environment a CSS file wouldn't go through the ASP.NET ISAPI, but apparently when running with VS2010 and the developent web server this doesn't matter... or something.
Is there any way to prevent this from happening? Thanks!
Instead of using the built in web server in Visual Studio (casinni), you can install IIS on your workstation and specify visual studio to use IIS as the development web server that runs your project. I do this for the same reasons. The Casinni server crashes or fails to start pretty regularly for me.
You could also use IIS7 Express. Not only will the server be faster but it will also be more like your production environment. This should help you iron out any issues before you deploy. Its also not hard to get VS to debug a local IIS instance.
I created a Virtual Application in IIS 7 to host my app so I could test it on other machines on the local network, since the development web server will not respond to requests from machines other than the local machine. I had to allow IIS to login as me to get into My Documents, and enabled ASP.NET impersonation through the IIS. That worked fine, but...
Now the ASP.NET Development Webserver won't serve anything at all. I hit debug in VS2008, the dev webserver starts up seemingly fine, but then the IDE launches Chrome and the browser just sits there twiddling its thumbs. It never fails, but never loads. Nothing.
There are no errors from ASP.NET Development Webserver or Visual Studio or Chrome that I can find. I even looked in the Event Log. Nothing.
What did I just stupidly do?
I haven't got Chrome installed at the moment so i can't confirm for sure before i answer this, but IIRC i have seen this before and the VS debugger cannot correctly launch Chrome and serve it pages from Cassini (the VS development webserver).
The way i got round this previously is to just create a virtual directory in the local (dev machine) instance of IIS, and point it to the folder containing your web project. Then you can use Chrome to browse it just like a normal web site. You can then manually attach the VS debugger to the right worker process.
Alternatively, you could start up the debugger as you are now, and when Chrome sits there, you could manually enter the url for the page you want to start with (it will be http://localhost:<some port>/default.aspx or similar). VS won't be able to debug the script in the page, but it should still debug the compiled code just fine (like it does for Firefox).
Holy crap, I know what it was. When I changed the IIS settings to have ASP.NET impersonate me to get into the My Documents folder, it modified the web.config file. Now you're probably thinking, well duh, of course it did. I honestly thought that IIS 7 had some new way of dealing with impersonation other than the web.config setting. Turns out it's just built into the MMC snap-in to manage it now, but it does it in the same way.
Once I reverted back to the original version of the web.config file, ASP.NET Development Server happily worked exactly as intended again. I suppose ASP.NET Development Server craps out if there are impersonation settings in the web.config.