I have a web role that hosts 4 MVC 4 sites. One of the sites (let's call it the API site from now on) uses both MVC and Web API. When I upgrade the web role, the Web API controllers from the API Site returns a 500 Internal Server Error to all requests. The MVC controllers work as expected and I know the request is getting at least as far as the Application_BeginRequest method of the global.asax. I'm not seeing anything logged in my Elmah log. The only hint I have of anything being wrong is the following in the event log:
The application '/' belonging to site '1' has an invalid AppPoolId 'DefaultAppPool' set. Therefore, the application will be ignored.
As web roles use App Pools with guids as identifiers I don't know where this is coming from.
What is most confusing is that once I recycle the app pool for the API site (which is a guid) everything starts working correctly.
I've tried recyling the app pools as part of a startup task on the role, but that doesn't seem to make any difference.
Any suggestions about what I can do to get Web API to start correctly?
I never did find what was causing this issue.
It got to a point where I could deploy from my machine and not get the problem, but my colleague could not.
We tried comparing the contents of the .cspkg files that were produced, but didn't find any differences.
We are now both able to deploy the project with no problems.
My suspicion is that this was resolved when we upgraded the Azure SDK and tools on our machines.
Related
I have two Web Apps, inside the same App Service. One is a back-end portion (with API on it, using .NET Core, SSL cert installed) and the other one is the front-end (ReactTS, created using create-react-app).
When I try to call the API method (an Auth method) using my Front-end I got this message as response:
Login failed: The resource you are looking for has been removed, had
its name changed, or is temporarily unavailable.
-404 error
Another fact is, if I run my ront-end solution locally, I can use the API (published on the Web App), normally.
My API URL is set inside the package.json file, as proxy.
My first thought was about an CORS problem, but it throws a 404 error.
Any configuration that I can do on my Azure, or something that I need to change in my application to allow my front-end to communicate with my API?
If we publish two web applications to one Azure Web App, the later one will cover the first one. It will cause that the first web application can't work. I suggest you create different Azure Web Apps for your web applications. You could choose one Azure Web App Plan for your Azure Web Apps. It will not add extra costs except for Shared plan.
If you use Shared App Plan and don't want to increase the extra cost, you could add a virtual directory to your Azure Web App. Then you could publish your second web application to the virtual directory. To create a virtual directory, steps below are for your reference.
Azure portal -> Web App Panel -> Application settings
Seeing 502 error for the past 6 hours.
Tried restarting the server but it didn't do anything.
It is hosted on a VM (instead of being an Azure Web App).
Azure region: North Europe.
App Insights resource didn't report of any problem.
Website is written in mvc core.
What do I do to fix this?
If you have already tried the link suggested by DonNetMatt, then, here is what I would do.
You said you are hosting it in a VM. could you try redeploying the site to another server (web app or VM), and if possible another region. This should tell you if the issue is really with your web app or the server.
In all likelihood, the redeploy should load the site just fine, in which case contacting Azure support is the best way to solve this issue.
I doubt if the issue is on your code. With the error you are getting, its likely a server issue on Microsoft Azure side.
(Note : I am assuming when you say 'Website is writting in mvc core' you mean, website is written in mvc core. Or, is your website designed to write code as part of some automation thing, and generating MVC code?)
I recently discovered that one of my server machines had the same service under different Web Sites and they were managed by different app pools. Something like this:
Custom Web Site
MyWebSite (Managed by CustomAppPool v4)
Default Web Site
MyWebSite (Managed by Default App Pool v4)
The CustomWebSite version is hit on http 28000 port. The default one is just set up on 80 (this is not really hit)
Both the Web Sites are pointing to C:\inetpub\wwwroot. The Default Web Site version should not have been converted to an application in the first place. My question is how bad is it? Should I be separating the service asap?
My understanding is that IIS will handle the requests independently, so there should not be any danger in sharing code files. Other than it being untidy and allowing potential process issues, I don't think you have to remove it. On the same token, I believe you would be fine to remove it.
I have a web application developed in VS2013
ASP.NET MVC 5
NInject for IoC
Sql Server 2008 R2 for a backing store (ADO, not Entity Framework, for DAL)
IIS 7.5 (Not a web garden, max processes = 1)
PostSharp 3.1.46.0
I have been developing and deploying on my local machine this application to a development server for months with not too many issues.
App Pool is .Net 4.0 Integrated, using the ApplicationPoolIdentity
Anonymous and Forms authentication are enabled. Anonymous is set to use the App Pool identity
File permissions are set for the application folder to give IIS AppPool\[mypool] read, list, execute access. (I tried full access, once, and it didn't help)
Last week, the development server reports a 401 (sc-status:401 sc-substatus:0 sc-win32-status:0) instead of showing me any forms from a remote connection. Local connections, that is, when I access the app on the sandbox, or if I log on to the development server and access it locally, work as expected. Any request from a remote machine fails.
401 - Unauthorized: Access is denied due to invalid credentials.
You do not have permission to view this directory or page using the credentials that you supplied.
I tried recreating the app pool and re-assigning the app to it. I tried aspnet_iisreg -ir. I went through most of the "Similar Questions" to the right of this edit box, trying to find something close to my issue. I erased the application from the server and redeployed to a new app, with new name and a new physical folder. KB2545850 hotfix didn't help.
My deployment strategy is an xcopy of everything but the web.config(s) I maintain the web.config separately. Please help diagnose.
In ASP.NET MVC Deploying an app with forms authentication to IIS 7.5 it says:
If you have a path leading to an eventual [Authorize] attribute, that will cause this -
removing the RenderAction or allowing that action to render without [Authorize] fixes it.
That was similar to my issue. I have a global filter to Authorize. I recently added a partial view in a controller to display a serial number. I added that partial to the _Layout, without the AllowAnonymous. Since the login form used the layout, which used this partial, I couldn't log in until I logged in.
Adding an [AllowAnonymous] to the action resolved this issue. I am thinking about how to more easily detect this for when it happens to me again.
just starting to explore Azure and I am still a bit confused regarding the purposes of web roles vs worker roles. In the solution I'm working on mobile apps (iPhone, Android, Windows etc) will be accessing our server product via a REST api. So there is really no public facing web site for our service (as in web pages).
This made me think that I don't need a web role but instead have one or worker roles listening on our http endpoints. I have created a prototype along these lines. When from a mobile device I do I an http post to the endpoint, I get no response back. And I see nothing in the Azure logs that indicate that indeed my worker role was started or is running and responding to it.
Is this an appropriate approach? Is there something I need to do in setup code because I don't have a web role? I read in another thread that web roles run in IIS but worker roles don't.
Thanks for bearing with me. I am still getting to grips with Azure and so have a little difficulty formulating the right question.
You don't need to have a web role in your azure deployment. As you read, a web role has IIS, and your web site is hosted in it. A worker role is basically a plain old W2K8 server without IIS. Honestly, I haven't RDP'd to a worker role instance, so I'm not 100% sure that you don't have IIS or not.
But you don't need a web role in order to expose a WCF service. Here's a nice example (although the background color needs some work) that shows you how to do this.
Good luck! I hope this helps.
Adding to what David Hoerster said: You can host up to 25 externally-facing endpoints (each with its own port number) on any role type, with each endpoint being http, https, or tcp. With a Web Role and IIS, a web application typically grabs an endpoint mapped to port 80. In your case, you'll be creating your own endpoints on your specific ports. You're responsible for creating your ServiceHost (or whatever you're using to host your service) and binding it to one of your endpoints. To do this, you'll need to either map each endpoint explicitly to a specific internally-facing port, or inspect the endpoint's properties to discover which port has been dynamically assigned to it, for you to bind to (might this be the issue you're running into with your prototype code?).
If you're looking for the benefits IIS offers when hosting your endpoint, you're better off with a Web Role, as it's going to be much easier for you to do this since a Web Role enables IIS by default (and it's easy to add WCF services to a Web Role from Visual Studio).
Even if you were to self-host your endpoints, you could still use a Web Role, but now you'd be carrying the extra memory baggage of a running, yet unused, IIS service.