Deploying my ASP.NET MVC 2 application to an IIS7 staging server leads to a blank page, regardless of the action called. Attempts to access controller actions that require authentication are correctly redirected to /Account/LogOn, but this page too shows only a blank page on both my local machine and the remote server.
I have checked my site permissions and I think it is an assembly issue, but no errors show up in the Application log.
How do I determine the cause of the error?
I recently installed ASP.NET MVC 3 on my dev machine, but made no changes to this project and I am using StructureMap for DI, if that makes a difference.
You could try installing Elmah from Nuget.
In the Package Manager Console, type install-package elmah. Then run your app.
Also, if you're not actually getting any errors, have you checked the rendered source in your browser? Your master page could have something commented out in it. Probably not though!
Another suggestion would be to empty the bin directory completely after doing a Clean Solution, rebuild, and try again.
In cases like this, it generally helps breaking the problem down to the smallest steps needed to replicate the problem. In your case, remove all routes, barring the one/s you need, empty out your master page and view to just a very simple 'hello world' and also comment out any code in your action so that it's not going off to the database or whatever else.
If you have an Application_Error handler in the Global.asax, maybe that hides the error.
When I got this problem, there was an error in the web.config
Related
I created an ASP NET Core application with React template and I didnt change anything there. When I am starting it I am getting error 400 in browser. There are no errors in Output window.
If you copy the address which your application starts e.g. https://localhost:44371/ and your app loads there, then you have cache issue or some conflict.
I have cleaned my browser cache from here:
chrome://settings/clearBrowserData?search=cache
Good idea is to set a proper time period, otherwise you will erase cookies that you don't need to.
Hope this helps. It did in my case.
I have created a new website and published it (via Visual Studio) to Azure.
Initially, everything worked fine.
But, after republishing the website a few times, the website stopped responding - i.e. it shows a "Server not found" error in Firefox or "This page can't be displayed" in IE).
Now, any new website I publish shows the same error. (Here's a basic test site I published, so you can see the message: http://www.test-website.azurewebsites.net)
The previously published websites are still working; it is just new websites that are failing.
Does anyone know why this would be happening?
Additional Info:
The website was created using Visual Studio 2012 C# ASP MVC .NET 4.5
The websites are using Microsoft's 'Free' pricing tier.
There are a total of 3 websites on the Azure account.
Claies brought this up in a comment, and I'll take it a step further. Your link should not start with www. when you're visiting a .azurewebsites.net domain.
If you're just typing this, then that's the issue.
On the other hand, given that you're asking this, I'm wondering whether maybe your configuration file is a bit messed up in VS. When you run the publish wizard, try going back a couple pages to the page with the textboxes, and double-check that none of those refer to the www. version. If they do, simply drop that.
That settings shouldn't affect the publish itself, but it will determine which URL to go to when publishing completes, so you'll definitely want to get that fixed if it is wrong, or else this will just keep happening.
I have an old ASP.NET intranet application where the forms login page is demonstrating unusual behavior. If any version of IE has a cleared history (history, not cookies) when they submit to log in the page executes a blank post back and remains on the login page.
If they refresh the page or had been redirected to the login page from trying to directly access another page then they are logged in without trouble.
I have published additional copies of this application to the same IIS server and they initially did not exhibit this behavior however after some number of hours they began acting the same way. Republishing to the same instance does not "fix" the issue like publishing to a new site does and neither does removing the old application and then publishing to the same name.
I'm not sure where to go from here so any help would be appreciated.
To me these are the key observations I have made:
This only effects our production server. The same code published to two other servers do not exhibit this defect. This code has worked for years until recently.
I replaced the button click code with a Response.Redirect to Google. When the button is not behaving correctly this redirect was not being fired. This indicates to me that the button code is not being executed. After the page is reloaded/refreshed it redirects properly since the button code is now firing.
When the same code is published to this IIS server under a different name it does not exhibit this defect for a number of hours. What could happen after a few hours to cause this behavioral change? Republishing to the same IIS site does not fix the issue for a few hours like publishing to a new IIS site does.
I have removed the button code from this posting because it is in my opinion a red herring as the code doesn't appear to be being executed at all.
This is what the cookies looked like in the network tools when the site is working
The difference here from when the site is working to when it is not working is that the Form1 key is marked as Sent and not Received.
Something new I have also noticed is that when the site is not working the favicon shows as (aborted). I now believe that the request is being completely aborted because I have overriden the page's OnInit and the code I entered is not being executed when the site is not working.
Today my work opened a ticket with Microsoft to help get this problem resolved and they have said it was a "head scratcher."
I disagree with Nick's thought that there is a problem in the code because of your assertion:
This only effects our production server. The same code published to two other servers do not exhibit this defect. This code has worked for years until recently.
This suggests there is a difference between servers, the way they are configured or the code is deployed that is stopping it from working. As it is a forms authentication problem, I am reminded of the bug that screwed up forms authentication in IE10 - see IE10 User-Agent causes ASP.Net to not send back Set-Cookie (IE10 not setting cookies)
Are your servers identical? Running the same OS, .NET versions, patches, hotfixes etc?
Microsoft saved the day.
They told us that the older versions of IE will look for the favicon in the root folder in IIS and not the application path regardless of where you're pointing it to look. There we found that the root folder's authentication settings were set to Windows Authentication only. For whatever reason this was causing the forms authentication to be aborted until we added Allow Anonymous to the root folder.
This is just strange. There could be other issues, but here's the deal. I'm making an application that simply gathers information and redirects to a URL with the info passed as parameters on the URL. I'm using the ASP.NET MVC 3 (.NET 4.0) framework and I've never had to redirect to a URL outside the application before.
My initial attempt, I did:
return RedirectPermanent("http://www.google.com?" + qrystring);
This redirected to google, but I didn't see the parameters. I work at it a bit and change the URL to one inside the application but I'll still be using the full URL and not the routing because I want to ensure the values get there. Now, when I debug the application locally and mouse over my breakpoints it says:
"The breakpoint will not currently be hit. No symbols have been loaded for this document."
Also, no matter what I change the URL to in my call to "RedirectPermanent", it always loads the Google page.
I've cleared out the Temporary Internet file history & ensured the ASPNET user has access to the folder. I've also closed & reopened the solution. I've also tried changing "RedirectPermanent" to "Redirect", but that didn't fix it. Breakpoints worked fine in this application before hitting that RedirectPermanent statement the first time.
FYI: I'm running Windows XP and am using IIS Express (ASP.NET Development Server). I'm also running the application locally in debug mode as opposed to on a server machine.
Thoughts?
This was a rather simple thing in the end.
Chrome cached the RedirectPermanent url. Debug symbols are loaded until later in the application when other initialization is done. Visual Studio loaded my application and chrome seeing the url being used performed the redirect.
I cleared out my cache in chrome and, presto, it all works fine again.
I have a MVC application and I can't get it working on IIS 7. Debugging in VS2010 works fine, but when I publish the website to my local IIS7, I see nothing but blank pages.
Here is what I have done:
On the project, right click and click Publish. In the Publish Web window I set these settings:
Publish method: Web deploy
Service URL: localhost
Site/application: Default Web Sit\Africa
both, Mark as IIS application on destination and Leave extra files on destination (do not delete are checked.
In IIS, my application runs under a application pool with supports .net 4.0 and managed pipeline is set to integrated.
I don't get any error while publishing, but when I navigate to my site I only see blank pages. Nothing happens.
What goes wrong?
EDIT:
When I navigate to http://localhost/Africa/ I see a blank page. When I navigate to http://localhost/Africa/Views/Home/ I get a 500 error.
How can I solve this?
I ran in to the same exact problem, it took quite a bit of digging to solve.
I finally found the solution to it on this page: Getting an ASP.MVC2/VS2010 application to work in IIS 7.5
Yeah, I know that this is an old thread but for the sake of saving someone else's time I'm adding this. Also make sure you have HTTP Errors, HTTP Redirection, and Static Content enabled in IIS.
In your application pool advanced settings, make sure you have Enable 32-bit applications set to true.
Some other things to try:
Change the application pool to classic.
Make sure you have the correct version of MVC installed on your server.
If you are getting 500 errors, you can turn on Failed Request Tracing and check the logs. If you are getting 500 errors and no logs are being created, you need to check your web.config.
Blank page normally doesn't necessary mean it's not working, if you default page doesn't have anything, it will be blank.
If you run into some error, you normally will see an error page.