I created simple dummy service which I have deployed into my testing SF cluster, but when I check the deployed application/service in SF Explorer and its instances all of them does not have assigned Endpoint's URL. Instead, there is:
(none) http://[::]:8322
I spent a half day trying to find a solution but I am not sure where is the problem.
The Service is Stateless service which uses ASP.NET Core 2.0 and Kestrel WebListener (it is basically slightly modified the template Service generated by Visual Studio when creating new ASP.NET Core Stateless service).
Make sure you're using version 2.7.198 (or greater for all you future readers) of the Service Fabric NuGet packages. This is the version that officially begins to support ASP.NET Core 2.0, which handles issues like this.
Related
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 have 2 applications:
NetCore 2.2 web-application
.Net Framework 4 web-application (owin, nancy-framework). For some reasons I cant upgrade target net framework version in this
application.
There is a requirement to provide two-way connection. In other words, I want to send commands from 1st app to 2nd app.
More about the situation:
With current network organization I can make request from 2-app to 1-app, it works successfully.
But I can't make request from 1-app to 2-app (host of 2nd app is not pingable from 1st app). I was hoping to solve the problem with SignalR library, but it has platform-depend limitations (signalR Core client library in old applications, Microsoft.AspNetCore.SignalR.Client package).
How can i solve this problem? Maybe I have some alternatives?
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
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.
One of our C# ASP.Net projects has some dependencies on the Microsoft WSE 3.0 library, in order to consume a WSE3.0 web service. However, we're migrating the project to Windows Server 2008, which does not support WSE3.0.
So I need to refactor the code to remove the dependency to WSE 3.0 but still maintain its functionality. The code is simply adding a username security token to the SOAP context and then invoking the web service. I'm not sure where to start though. I suspect I switch to WCF, and if so, is there any tutorial available online to help?
I'd start by creating a simple application, maybe a Console application, to be a test consumer of the existing web service. Create client proxy classes for this application by using "Add Service Reference", and pointing it to the existing WSE service. That should take care of most of the problems.
Once the simple console application works, you can do the same for your ASP.NET project.
Needless to say, it's way past time to update that WSE service to WCF, which is supported, and which will continue to be supported for a long time to come.
This article is a pretty good rundown of the differences between WSE 3.0 & WCF and migration recommendations. I'd start by getting the migrated service to run under the basicHttpBinding configuration (without user name/password authentication).
Once the service is running as expected and look at this article to see how to get the migrated service configured for user name/password authentication. The article is written for Silverlight use but there should be enough in it to get you going.