I want to have my MVC application to warm up the application after it is being restarted, so the next initial loading will cost almost no time.
The problem is that I do not have the access to the server computer IIS.
I have searched of how to do it, and I found this:
<applicationPools>
<add name="MyAppWorkerProcess" managedRuntimeVersion="v4.0" startMode="AlwaysRunning" />
</applicationPools>
But this code requires access to the server computer.
How can I do it only with my application and web.config?
Related
Is it possible to have some kind of timeout to make sure site is warmed app after website is scaled out or instance was restarted in Azure?
We are hosting Sitecore website on Azure Webapp and wouldn't like any requests to be handled by instance before its warmed up and instead served by other healthy nodes.
You can use application Initialization to warmup the Azure web app. See iis-80-application-initialization
In the web.config this look like:
<web.webServer>
<applicationInitialization>
<add initializationPage="/" />
<add initializationPage="/page-2" />
</applicationInitialization>
</web.webServer>
Since it is for Sitecore see also this blog warmup-your-application-on-azure-app-service-when-scaling-up-and-swapping-slots-using-application-initialization/
Pretty new to .NET Core, and am trying to understand how everything works together when using IIS integration.
A couple of questions: If I want my site to run over HTTPS, do i need to configure my WebBuilder with a certificate, or should i be selecting HTTPS on the binding in IIS manager, or both?
Does the UseUrls WebBuilder method also instruct IIS what port is should listen on? How does IIS know which port it should talk to the .NET Core application on?
When you host your .NET Core app behind IIS, IIS is acting as a reverse proxy to Kestrel web server. IIS will receive the HTTP request and pass it to Kestrel, the magic happen inside a new IIS module called AspNetCoreModule that you have to install on your server. As usual, to configure your IIS application you'll be using a web.config file in which you'll find a description of how IIS is interacting with your app: timeouts, pathes of the application, environment variables and so on... For instance, mine look like that:
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified"/>
</handlers>
<aspNetCore
requestTimeout="00:20:00"
processPath="%LAUNCHER_PATH%"
arguments="%LAUNCHER_ARGS%"
stdoutLogEnabled="false"
stdoutLogFile=".\logs\stdout"
forwardWindowsAuthToken="true">
<environmentVariables>
<environmentVariable name="ASPNETCORE_ENVIRONMENT" value="development" /> <!-- value could be "development", "staging" or "production"-->
</environmentVariables>
</aspNetCore>
</system.webServer>
The reason why you want to set it up that way is that Kestrel is a very light weight and nervous web server but it's missing a layer of applicative features that IIS can add up: Windows authentication via Kerberos, restarting the app in case of a crash, pool management...
I like a lot this article regarding this topic: https://weblog.west-wind.com/posts/2016/Jun/06/Publishing-and-Running-ASPNET-Core-Applications-with-IIS
For HTTPS, it's enough to configure IIS to listen on a secure HTTPS port and to define the certificate only on IIS.
UseUrls() won't be taken into account by IIS, it will work the other way around, IIS will tell your app on which port it should be listening to, UseUrls() will be taken into account if you launch your app directly.
I'm using ASP.NET Core RC1 as server to host my Aurelia app. My app was working just fine but the last couple of weeks something changed so that the app does no longer load when hosted on Azure. I'm not sure if it is something I changed or if it's a change on the Azure side but I'm leaning towards the latter.
I've narrowed down the problem quite a bit. The app runs fine locally, with ASP.NET Core Kestrel server and also other servers (e.g. webpack-dev-server). I have continuous deployment setup from Visual Studio Team Services to an Azure Website. The app is published and a web.config is automatically created in my wwwroot:
<configuration>
<system.webServer>
<handlers>
<add name="httpplatformhandler" path="*" verb="*" modules="httpPlatformHandler" resourceType="Unspecified" />
</handlers>
<httpPlatform processPath="%home%\site\approot\web.cmd" arguments="" stdoutLogEnabled="true" stdoutLogFile="\\?\%home%\LogFiles\stdout.log"></httpPlatform>
</system.webServer>
</configuration>
Nothing happens when I navigate to my site, e.g. http://demo.azurewebsites.net/. When looking at the console I get a 404. Once I actually got this error but I can't seem to bring it back: 502 - Web server received an invalid response while acting as a gateway or proxy server
I have index.html set as default document but it is not loading. If I enter it explicitly, the app works: http://demo.azurewebsites.net/index.html
If I remove the httpplatformhandler from the web.config, then it works as expected (index.html is loaded automatically). The same happens when I remove the web.config entirely. In these cases the MVC 6 WebAPI behind the scenes does not work at all. I assume that's just logical since I remove the platform handler.
So, why is this httpplatformhandler added? Is it necessary? Why is it created? Is there some setting in the Azure portal that I can adjust to prevent this handler to be configured like this?
I also found this link that seems to suggest that things are changing and that this httpplatformhandler is about to be replaced: Closer Look: Hosting ASP.NET Core on Azure App Service
I'm out on deep water here and any and all help is appreciated.
To get default document support with the static file server middleware you need to use app.UseFileServer() instead of app.UseStaticFiles()
My app is being moved from a server running IIS6 to a server running IIS7.5.
The new server defaults to Medium Trust. As this is a shared server and I am consuming some third-party assemblies, I don't want to ask to run my app under Full Trust.
I have copied web_mediumtrust.config to mycustom_mediumtrust.config.
I have added this second line to the root web.config but the new MyCustom trust level remains unavailable.
<trustLevel name="High" policyFile="web_hightrust.config" />
<trustLevel name="MyCustom" policyFile="mycustom_mediumtrust.config" />
<trustLevel name="Medium" policyFile="web_mediumtrust.config" />
Is there a way to force a reload of the root web.config without restarting IIS and all the other apps?
My Asp.net application is hosted over Azure Cloud,
In that application I do have a Java Chat control, which has its server on Linux,
now I have created a HTTPHandler to redirect that chat request to the Linux server, but some how it doesn't work over the Cloud environment (though it works very well on web environment)
it shows the below error
Microsoft Visual Studio
Windows Azure Tools for Microsoft Visual Studio
There was an error attaching the debugger to the IIS worker process for URL 'http://127.255.0.0:82/' for role instance 'deployment16(315).Cloud.AnotherHttpHandler_IN_0'. Unable to start debugging on the web server. See help for common configuration errors. Running the web page outside of the debugger may provide further information.
Make sure the server is operating correctly. Verify there are no syntax errors in web.config by doing a Debug.Start Without Debugging. You may also want to refer to the ASP.NET and ATL Server debugging topic in the online documentation.
I have even put the Handler under System.webServer as well in the web.config file, see below code
<system.web>
<httpHandlers>
<add verb="*" path="http-bind/*"
type="HelloWorldHandler"/>
</httpHandlers>
</system.web>
<system.webServer>
<handlers>
<add verb="*" path="http-bind/*" name="HelloWorldHandler" type="HelloWorldHandler"/>
</handlers>
<modules runAllManagedModulesForAllRequests="true" />
</system.webServer>
I don't know what restricts it over the cloud environment.
Please take a look at this question to see how to configure httpHandlers for running in Azure.
Most importantly - remove the httpHandlers section under the system.web and leave only handlers under system.webServer. Then add also the resourceType="Unspecified" attribute to the handler declaration. This should solve your issue.
I too had same problem.
I fixed it in following way .
The Problem was my machine is 32 bit and the azure server is 64 bit.
In Order to solve the problem i only changed Enable 32 bit option in
the advance setting of application pool. And the Original code worked
out fine.
i got this help from this Link