As working on converting .NET Core web api to .NET Framework, I had options of couple different ways of achieveing it and I end up reading below links and decide to go with OWIN in IIS.
Difference between OWIN and IIS
ASP.NET Web API 2 hosting differences
Getting started with OWIN in IIS
https://learn.microsoft.com/en-us/aspnet/aspnet/overview/owin-and-katana/getting-started-with-owin-and-katana#host-owin-in-iis
Before I actually put myself into this route, would there be any new updates on .NET Framework (not .NET Core) which beats this solution make it look old?
Related
I need to host my Asp.NET Core gRPC Service on IIS so that I can make it publicly available for others in my team so can you please provide a proper document or steps for hosting my gRPC service on IIS.
Hosting .net core application in IIS is not yet supported. For more details please go through link
This document states that ASP.NET Core gRPC can be hosted on IIS, but it carries extra requirements.
IIS requires .NET 5 and Windows 10 Build 20300.1000 or later.
HTTP.sys requires .NET 5 and Windows 10 Build 19529 or later.
So please check if it meets the requirements before trying to publish it on IIS:
Host ASP.NET Core on Windows with IIS.
I have a wcf service hosted at IIS and multiple clients are already calling it. Now we want to get rid of windows and move our web api to linux therefore we are going for asp.net core gRPC. Now my question is:
Do my clients need to make changes on their side when we shift towards asp.net core?
I am looking for the options to host existing ASP.NET Framework (not .NET Core, and not ASP.NET Core) applications in ServiceFabric hosted on-premise.
We host such legacy applications in IIS, as is the common practice I believe, and we are considering migrating them to an on-prem ServiceFabric cluster without (or at least, as little as possible) modifications.
I see that Visual Studio 2017 SF project templates do not have the "old ASP.NET", which makes me think that using old ASP.NET isn't preferred, if supported at all. I can understand that.
I understand that it is possible to deploy the application in a container with IIS, e.g. with Windows IIS.
Are there other possibilities?
I've been doing self-hosted ASP.Net WebAPI on Service Fabric for three years already. They did remove the .NET Framework WebAPI template when you create a Service Fabric App, but yes, you can still run a Self-hosted .Net Framework API on Service Fabric.
I still have my old code before so I pretty much do same thing over and over. This tutorial would help a lot. it's the basics of doing a self-hosted WebAPI, hosting it on HTTPS is another thing after that.
We have 4 stateless services microservice in service fabrics which are using Kestrel as server. We need to expose those 4 services to the front end and have question regarding either to use WebListener or OWIN as server. Can any one tell which is better for performance. And also we have authentication service which is used to handle tokens.
By OWIN I'm assuming you're referring to Katana with Web API 2, which both implement OWIN.
In that case, the choice is really between "classic" Web API 2 with Katana and the newer ASP.NET Core with WebListener. I always recommend ASP.NET Core with WebListener for a few reasons:
We have official integration NuGet packages for ASP.NET Core in Service Fabric
These packages and their use cases are documented
Katana was largely a prototype for what would become ASP.NET Core. Most, if not all, new feature work is going into ASP.NET Core, not Katana, and ASP.NET Core is officially supported by Microsoft.
I need to create 3 separate and independent versions of my ASP.NET WEB API and host them all at the same port and in the same IIS.
So, let's assume that my current API runs at:
http://xxx.xxx.xxx.xxx/api
I need to replicate it to
xxx.xxx.xxx.xxx/test/api
xxx.xxx.xxx.xxx/dev/api
but it is very important that each one will have it's own configuration on IIS.
The reason for that is that I want each "version" of the API to have a different connection string.
Of course this will have to be done with out any change in my current code, just via IIS setup.
You can create applications under an IIS site to accomplish this. You can even use WebDeploy to deploy them all. Follow this blog post -
http://dotnetcatch.com/2016/03/03/simple-service-versioning-with-webdeploy/