I've been reading and learing about the new Worker Service features provided in .Net Core 3.0. I have been using this link from Microsoft: Background tasks with hosted services in ASP.NET Core
What I don't understand is this, can these worker service concepts be introduced into an existing ASPNET Web Project, like a Razor Pages site? Or must you create a new project and then deploy that project as a service using whatever mechanism the host OS proivdes for that?
Yes, you can host any number of hosted services (IHostedService) within ASP.NET Core applications. With version 3, ASP.NET Core uses the generic host (Host.CreateDefaultBuilder) which is the framework that is hosting these hosted services when the application starts. In fact, the ASP.NET Core web application is an IHostedService itself.
To add additional hosted services to your ASP.NET Core application, just register additional hosted services with your service collection, e.g. within the Startup’s ConfigureServices:
services.AddHostedService<MyHostedService>();
That service will then launch together with the ASP.NET Core web server when the application runs.
The Worker SDK that is mentioned in the documentation is actually a subset of the Web SDK that you are using with ASP.NET Core application. Microsoft.NET.Sdk.Worker is basically Microsoft.NET.Sdk.Web without the web-specific stuff like Razor compilation and wwwroot folder stuff. It basically sets up automatic file globbing e.g. for the appsettings.json and does some other useful things that the core Microsoft.NET.Sdk does not have.
Ultimately this means, that when you are using the Web SDK, then you already have everything the Worker SDK offers. So you do not need to specify the Worker SDK just to host additional background services.
Related
I inherited a project that is a collection of WCF Services that target .Net Framework 4.6.1. I wrote a front end SPA application that targets .Net Core 2.2 not realizing that the hosting model was such that both the UI (.Net Core) and the API (.Net 4.6.1) need to run under one Site on IIS.
I'm trying to get this to work on my local machine. I created a new Site in IIS -- Site A. I published my .Net Core application to Site A and set it up with an application pool set to "No Manged Code".
I then added an Application to Site A called API and added all my WCF services in that folder. I configured API to use an application pool that targets ".NET CLR 4.0".
I updated the web.config in the root of Site A to include all the necessary bits for WCF.
I'm able to hit Site A and get my SPA UI, but when I do anything that attempts to hit the backend API (including trying to hit it directly -- http://localhost:464646/api/test.svc), I get the following error:
HTTP Error 502.5 - ANCM Out-Of-Process Startup Failure
Is what I'm doing even possible? If so, what changes do I need to make in order to get this to work?
I have a large Visual Studio solution with several ASP.NET web sites with a mix of WebForms, MVC and WebAPI. What I'd like to be able to do is add an ASP.NET Core project to this solution to provide MVC, Razor Pages, WebAPI and SPA (Vue.JS in this case) facilities. The plan is to take each WebForms page at a time and convert to the new framework.
I'll target .NET Framework and the Core site will share some assemblies from the WebForms - but no state is shared except a session cookie and any state stored in the database.
I specifically want to be able to serve the new framework from IIS Express on the same port. So for example, an old page such as http://localhost:1234/page1.aspx will be converted to http://localhost:1234/core/page1. However, I'm unable to simply change the Core project to be hosted on IIS Express and change the path to http://localhost:1234/core. I have managed by following instructions to host in IIS but this has several disadvantages for development. I've also tried adding <urlRewrite> configuration to the WebForms site to forward requests to Core running on a different port but I wasn't very successful and I believe POST request are not supported which renders it fairly useless!
As far as I understood the Docs, the .NET Core Hosting Bundle installs the .NET Core Runtime, .NET Core Library and the ASP.NET Core Module.
It seems that there's a Bundle for every version of the .NET Core Runtime (2.0.6, 2.0.7, ...).
If I have a self contained deployment of my app, I still need the ASP.NET Core Module. However I don't see that the Module can be downloaded separately without the full bundle. Is there a place where I can download it ?
If not:
What's the point of having a self contained application, if I still need to install the whole .net core sdk/runtime bundle on my IIS Server?
There is no official download of the ASP.NET Core Module for IIS ("ANCM"), though it can be installed by calling the hosting bundle installer with OPT_INSTALL_LTS_REDIST=0 OPT_INSTALL_FTS_REDIST=0 as arguments (at least for 1.0-2.0 installs).
What's the point of having a self contained application, if I still
need to install the whole .net core sdk/runtime bundle on my IIS
Server?
Apart from the installer being able to install only ANCM, do not forget that IIS is not the only hosting option for ASP.NET Core Applications. People may still opt to host it on linux or as a Windows Service. Either being exposed to the public Internet (which is supported from 2.0+) or behind NGINX/Apache/…
It is also very useful to deploy preview, daily or custom builds of any component inside .NET Core / ASP.NET Core if needed.
Check the docs on this topic.
The ASP.NET Core Module is a fork of HttpPlatformHandler which was modified to work with ASP.NET Core's new system and was previously used to host ASP.NET Applications. related GitHub issue
IIS needs it in order to start up your ASP.NET Core application when the first request arrives and to route requests to the ASP.NET Core application.
With .NET Core (and hence ASP.NET Core), ASP.NET Core comes with its own http server (previously this was only possible with Http.sys aka WebListener self-hosting, i.e. commonly used for WCF services). It also redirects a couple of headers to the application, since IIS with ASP.NET Core only acts as reverse proxy.
In other words, ASP.NET Core is hosted outside the IIS process, and ASP.NET Core Module is there to communicate with it and starts the outside process if not already. This also means, that ASP.NET Core applications hosted in IIS are subject to IIS lifetime cycle (i.e. IIS may and will stop your applications when idle - This doesn't happen when you self-host your application or use something like nginx as reverse proxy).
With ASP.NET Core 2.1 preview1 it will also be possible to host ASP.NET Core application in the IIS process (w3wp.exe) for a improve request throughput. For more information on this, read ASP.NET Core 2.1.0-preview1: Improvements to IIS hosting
When I publish under Visual Studio 2015 CTP 5 then I don't have to do setting for application pool CLR version.
Now for ASP.net core application and as per documentation (http://docs.asp.net/en/latest/publishing/iis.html) we have to do setting for application pool clr to No managed code.
Why it is like that ?
ASP.NET Core applications no longer run inside IIS but run out-of-process and IIS acts only as a reverse proxy. This functionality is provided by the AspNetCoreModule which is a native IIS module. Since no managed code runs in the IIS process it is recommended to set application pool as "No managed code".
I wrote a detailed blog post describing how ASP.NET Core applications are running with IIS. You can find it here.
This is because ASP.NET Core runs as a plain old command line application outside of the IIS. Therefore, IIS is merely a pass-through to Kestrel, which is the ASP.NET Core web server which runs in it's own separate process. This platform is what provides the cross-platform capabilities of .NET Core.
Currently I maintain an application that runs as a Windows service, reads messages from a message queue server, processes them and puts the result back into the message queue server. But it also contains a health monitoring component that is accessible through a web API.
It is implemented as a console app that uses Katana to self-host the health monitoring sub-system.
I'm now trying to figure out if we can move this to .NET Core and ASP.NET Core once they RTM. I know the Windows Service part cannot be ported, but I could also run the console app as a detached Docker container to basically achieve the same thing, in terms of main functionality.
But how will the health monitoring work? From what I can see the Katana project has been updated to ASP.NET 5 (which I guess is ASP.NET Core 1 before the big rename), but it does not run on the .NET Core CLR. Katana will require the full CLR. So that means Katana is out.
Does this mean that the way we build our app is impossible with .NET Core? Or does hosting the app through Kestrel not rule out the possibility of running code before the first request? With IIS the app does not live until the first request (unless you use the auto-start, but it's more of a speed-optimisation than have the app behave like an "allways-running-app") and generally the app is request-based and not continually running. Background threads in a IIS hosted app are a really bad idea.
Is this the same with Kestrel? Or will DNX start your app and keep it running until it's shutdown, much like a console app, so we can run all the background threads we want?
It follows the console app model. Katana is actually more the spiritual predecessor to kestrel. It is invoked for normal ASP.NET Core projects from the Main method with a normal method call. There are countless tutorials how to setup a server in RC1 (see Startup.cs Main method) and some for the upcoming RC2 (there is a builder for it). That would allow you to do both, your app code and your web api based monitoring, in a console app. Kestrel and DNX are not at all an application server like IIS. Kestrel is a plain HTTP server library and nothing more. You start it up and it listens from that moment on.
Nevertheless, you have to adjust your WebApi 2 and Katana based application to the new ASP.NET Core interfaces and middleware concept. But that should be easy compared to your message queuing adaption.