How to control ASP.Net 5 application from console application? All examples of self-hosted application I've found assume that the lifetime of the webserver matches the lifetime of application. Is it possible to have assembly of ASP.Net 5 application with Startup.cs file and main assembly (console app) which allows to start and stop web application using this Startup class when I need?
For example, Node.js allows to initiate new server at any place in code, like this
http.createServer(function (req, res) { /* processing request }).listen(80, '127.0.0.1');
Is it possible to implement anything like this in ASP.Net 5?
When you use the hosting API in your Program.Main, you can achieve the same thing.
UPDATE:
This is the RC1 API:
https://github.com/aspnet/Hosting/blob/1.0.0-rc1/src/Microsoft.AspNet.Hosting/Program.cs
post RC1 is very different
You can (re)create/(re)start the server when you like during the lifetime of the application.
Related
So I'm coming from Xamarin world trying to build a Blazor App. And I'm struggling with a high level understanding of why Blazor Apps ( client side only ) cannot make a basic HTTP get call to say google.com or any other http get/post call to different resources/urls?
Can someone break it down for me, am i crazy? how would i ever implement maps.google.com or other http request I'm going to need to make.
I do notice anything with a package, like SendGrid or B2C or Cosmos Nuget Packages seem to work fine... how do they get around the different domain names ?
Can i simply say on my webserver : (in English) - allow requests to google.com and someoneElsesApi.com
or would i have to contact google and have them allow my Blazor app to make calls?
Just really struggling with how to use Blazor Client Only PWA app if it cant connect or call to anything else on the web... seems pointless if a Blazor app cannot make any http calls to other services.
Ok, so yes... I found an Public Open API to test a request against, and it does work from a Blazor WASM (Client only). More specifically the below works just fine..
#inject HttpClient HttpClient
...
string responsString = await HttpClient.GetStringAsync("https://rickandmortyapi.com/api/character/5");
The problem i was having which seems confusing:
Both
Blazor WASM
Xamarin Forms apps
can both call an open public Web API just fine from HTTP Client.
But...
When I create an ASP.NET core API and publish it allowing anonymous access in azure,
Xamarin Forms can call that API
Blazor WASM cannot call it unless i specify CORS correctly in the Web API
So with my inexperience with Blazor WASM i assumed it could not do this.. while Xamarin can. So this changes to ... how is it that the Web API i created in Azure + ASP.net Core Web API - just allows the Xamarin App to call it (without CORS specification)... while CORS Must be set correctly for a Blazor WASM?
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.
I'm implementing profiler to track http requests coming to .net core applications hosted in IIS. I'm using coreclr profiling api to hook method enter/exit.
Which method I should track to know a new http request coming into my application.
Create a middle ware and configure ASP.NET Core to use it. It should receive requests, process it, then pass it along with the pipeline.
For more information see here: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/middleware/?view=aspnetcore-2.2
Let's start with an example:
I've added mvc core to asp.net core pipeline two times on different branches. See following sample codes:
aspNetCoreApp.Map("/1", innerAspNetCoreApp => { innerAspNetCore.UseMvc(...); })
aspNetCoreApp.Map("/2", innerAspNetCoreApp => { innerAspNetCore.UseMvc(...); })
And I've following services configuration:
services.AddMvcCore().AddJsonFormatters().AddApplicationPart(assembly1ForExample).AddControllersAsServices();
I'd like to have something like this too:
services.AddMvcCore().AddXmlFormatters().AddApplicationPart(assembly2ForExample).AddControllersAsServices();
I'd like to use first configuration for first branch ('/1'), and the second configuration for second branch ('/2')
Note that this is a sample only, I'm not looking for some extensibility solutions in asp.net core mvc, I'd like to find a solution in asp.net core itself.
Imaging that You've developed an middleware to write exception details to response. (I'm aware of AspNetCore.Diagnostics package, this is a sample only).
Based on branching you can write something like this:
aspNetCoreApp.Map("/1", innerAspNetCoreApp => { innerAspNetCore.UseBeautifulExceptionWritter(...); })
aspNetCoreApp.Map("/2", innerAspNetCoreApp => { innerAspNetCore.UseBeautifulExceptionWritter(...); })
Now let's imaging that we've a interface to make exception details writing extensible. For example IExceptionDetailResolver, and there is a default implementation named DefaultExceptionDetailResolver. In services configuration I'd like to register different implementations for each usages of that middleware.
In Owin pipeline, I was able to achieve this using nested containers. I created a root container for the whole application, and I created nested containers for each web api configurations.
I was able to register different implementations for asp.net web api interfaces every time I added http configuration to pipeline. For example I was able to add web api several times to owin pipeline on different branches, one time for odata, one time for asp.net web api itself normal usages, and one time for web hooks. And I was able to provided Different IAssemblyResolver implementations for each of them.
How can I achieve this in asp.net core?
Additional notes: I've managed to do this for owin pipeline on top of asp.net core pipeline, and I've no problem with manually developed asp.net core middlewares too. My main problem is with some middlewares like mvc core, identity server, signalr etc.
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.