gRPC : Running Multiple processes on the same port in .NET Core 3.1 - wcf

I am migrating an application from .NET Framework 4.7.2 (WCF) to .NET Core 3.1 (gRPC), and my current architecture has two processes running on the same port. I wanted to ask if there was a way to run two gRPC processes on the same port in .NET Core 3.1.
It is important to me that these be two individual processes, rather than two services in the same process. Thanks in advance.

Related

Can .net core 2.2 and 3.1 application slots coexist in the same app service?

We currently have two slots in azure app service: staging and production. We just migrated .net core 2.2 to 3.1 and tested it in a separate dev app service. We are about to publish the 3.1 app to staging.
Does anyone know if there are any issues with having one slot running 2.2 and another one 3.1?

Azure web app is a PaaS service, and we cannot modify the content in it. Because of this, it integrates many environments by default, or supports all our common SDK versions by default.
If you are not at ease, or when an exception occurs, you can add an Extension to solve possible future problems.
Test steps:
Create an app service (jasonp2core22) which version is .net core 2.1.
Run dotnet --info.
Create an app service (jasonp2core31) which version is .net core 3.1.
Run dotnet --info
Slot is essentially an app service, so your worries are non-existent, and it can all run normally.
Also run dotnet --info.

Performance improvements from ASP.NET Core 2.1 for full .NET framework?

I have an existing project basing on ASP.NET Core 2.0 running on full .NET framework. Microsoft doc of my case is here. The application is using Kestrel with libuv to serve incoming connections.
Theoretically, how does ASP.NET Core 2.1 improve/demote the performance of my case?
My project is running on full .NET Framework 4.7.2. It seems to me it will not benefited by the Performance Improvements in .NET Core 2.1. Right?
Also ASP.NET Core 2.1 release note mentioned.
Managed sockets replace libuv as Kestrel's default transport.
Does that make a lot of difference to the app running on full .NET framework?

You are correct. Since you are running on the .NET Framework, you are not affected by the performance improvements that were made with .NET Core 2.1. While the changes there are general changes that will eventually reach the .NET Framework as well (at least partially), we simply aren’t there yet.
If you want the best performance, then you should use .NET Core, which will always be the runtime where the most improvements will be made and where improvements will happen first.
However, that does not mean that the .NET Framework is slow or anything. Countless applications have been built on the .NET Framework in the past and that includes lots of really performance-critical things as well. Even Stack Overflow currently runs on the .NET Framework. So just because .NET Core can be faster, that does not make the .NET Framework bad. It’s perfectly fine to run on the full framework.
That being said, ASP.NET Core 2.1 of course also includes changes that may affect the performance. While most of the announced speed improvements come from the .NET Core 2.1 changes, it wouldn’t be surprising if there are other changes that will also show noticeable improvements. The Sockets transport layer is one of those.
Regardless of performance improvements, you should upgrade from 2.0 to 2.1 anyway. .NET Core 2.0 and ASP.NET Core 2.0 will reach EOL on October 1st 2018. So by that time, you should have upgraded if you want support from Microsoft.

Need advice: SignalR support for Windows XP (.NET 4.0)

I am developing some kind of communication and data-interchange system to use in various applications that my company is producing. There will be SignalR hub for messaging and WCF service for file streaming.
I was thinking of developing a Hub library in .NET 4.5. Also I plan to enable Hub hosting in some windows process and IIS.
Thing that bothers me is that I have to support Windows XP clients, so I cannot use .NET 4.5 for developing a client library.
My question is: Are there bad effects of providing a .NET 4.0 client library for all clients, even though there are more clients with Windows 7 or Windows 8? My concern is about performance and features - am I going to lose any of that if I go with .NET 4.0 client?

System Requirements for to host the wcf service in iis?

i am developing the wcf services in .net framework 4.0.for to host the service in server what are the minimum requirements of the system i.e minimum iis version etc.
what are the minimum requirements the system should have?

WCF is part of the .NET Framework as of 3.0. I would assume that any Windows system that can run .NET 3.0 should be able to run WCF. Having said that, a little googling provides the following information:
For minimum requirements, I would say (based on experience and some googling):
Windows XP SP2/Windows Server 2003 R2/SP1
IIS 5.1
WCF System Requirements
However, with versions of IIS prior to version 7.0 - the absence of WAS will prevent you from using any of the non-HTTP bindings. This could be a significant limitation, depending on what bindings you intend the service to use.
Hosting in Internet Information Services

Host ASP.NET ( C# 3.0 ) on Mono

I have site implemented in ASP.NET ( c# 3.0). Can I host that on Mono ?
If I can, do I need to change something in my code ( except communication with database) ?

Due to the Mono Compatibility page the latest stable version of Mono (version 2.8) has complete support to the ASP.NET 4.0 and ASP.NET MVC 2. There is some useful links to read about porting and establishing your site to Mono:
Mono ASP.NET Section
Mono ASP.NET FAQ
Porting ASP.NET Applications
Walkthrough: Porting Asp.Net MVC Website

Can I host that on Mono ?
You can host your application either on Apache with mod_mono or through FastCGI on web servers like nginx or lighttpd.
do I need to change something in my code
Only if some parts of your application use technologies/libraries which are not supported by mono.