I have a nettcp service which I have to host. I have three options -
IIS 7
Windows Service
A console application
I would be grateful if anybody could give some valuable thoughts on which option is better vis-a-vis other one.
Here are some of my observations:
IIS 7:
Pros:
Ready made hosting environment inside IIS
Will work with pretty much any hosting environment
Cons:
HTTP Only
Configuration slightly more complex
WAS:
Pros:
Ready made and familiar process model to that of IIS
No dependency on IIS
All protocols supported
Cons:
Not all shared hosting environments will support non-http protocol bindings or unusual port numbers.
Configuration slightly more complex
Windows Service:
Pros:
Starts when windows starts
You can start/stop the service via the service control manager
All protocols supported
Cons:
Some extra steps to deploy/re-deploy (installutil)
You need some extra boilerplate code to support the service implementation
Not ideal if you can't have access to the server to install (e.g. shared hosting)
Console Application:
Pros:
Fast and simple to deploy for testing purposes
All protocols supported
Cons:
You need to be logged on to start the process
Loss of session or machine shutdown will kill the service
Console/RDP access required
Related
What is the reason for two separate but similar servers?
What are the differences?
Can I run both in docker?
Do both support same things, like all authentication types?
Kestrel vs HTTP.sys - I've highlighted the fundamental differences below.
(The words are Microsoft's and I've only edited it for brevity and clarity. See the sources linked at the bottom).
Update:
Kestrel previously always required the use of a reverse proxy with edge deployments (exposed to traffic from the Internet) for security reasons. With Kestrel in ASP.Net Core 2.x this is no longer the case. Take a look at the documentation for more information. Kestrel Web Server Documentation
Weblistener was renamed HTTP.sys in ASP.NET Core 2.0
Sources:
Docs.Microsoft.com Web server implementations in ASP.NET Core
Docs.Microsoft.com HTTP.sys web server implementation in ASP.NET Core
HTTP.sys is windows-only HTTP / Web Server for ASP.NET Core that allows you to expose the server directly to the Internet without needing to use IIS. HTTP.sys is built on top of Http.Sys ( the same mature technology that also powers IIS' HTTP Listener) as is as such very feature rich and provides protection against various attacks.
Kestrel on the other hand, is a cross-platform web server for ASP.NET Core that is designed to be run behind a proxy (for example IIS or Nginx) and should not be deployed directly facing the Internet. Kestrel is relatively new and does not have a full complement of defenses against attacks. It's also not as feature rich as HTTP.sys and comes with timeout limits, size limits and concurrent user limits.
In essence, the choice comes down to your web application's Deployment scenario.
HTTP.sys Use Cases :
Kestrel Use Cases :
Following comparison will help you to choose which one is better
The ASP.NET 5 documentation (created by Microsoft on August 25, 2015) found here lists the chart found in the other answer (see page 107 of the bottom right book pages, but page 111 of the PDF): https://media.readthedocs.org/pdf/aspnet/theming/aspnet.pdf
Kestrel in general has better performance, if you used for one of the following below:
Great option if used in conjunction with a reverse proxy for apps exposed to Internet
Internal apps connecting with other internal apps on a private virtual network (not exposed to Internet)
WebListener is more secure, slower, and has more features. It is used in these cases:
Expose app to the Internet but can't use IIS
Require higher security and exposing server directly to Internet.
Additional features: List item, Windows Authentication, Port sharing, HTTPS with SNI, HTTP/2 over TLS (Windows 10), Direct file transmission, Response caching
Lets say that I have multiple internal ASP.NET web api applications. i.e.
http://service1.something.com/bob/bill
http://service2.something.com/pete
http://service3.something.com/dancing/dragon
I would like to expose these different services under a common host name
http://something.com/service1/bob/bill
http://something.com/service2/pete
http://something.com/service3/dancing/dragon
The reason I'm thinking of this setup is to allow each service to run a different set of middleware, but give the client a uniform URL structure to use. Each service can then be upgraded indepently of the others.
Ideally this should be using the latest version of ASP.NET and potentially hosted on Service Fabric. It doesn't have to run on the new core stack, the full .NET framework is acceptable.
I've read that the WebListener supports port sharing, so that is something I'm considering.
Suggestions?
Yes, you can do this with ASP.NET applications in Service Fabric:
service 1: http://something.com/service1/bob/bill
service 2: http://something.com/service2/pete
service 3: http://something.com/service3/dancing/dragon
As long as you use a web stack that supports port sharing. On windows, that means using a web stack that uses the http.sys kernel driver. Here are the web hosting options currently available for ASP.NET on Service Fabric:
The WebListener host in ASP.NET Core 1 is based on HttpListener which uses http.sys, so that will work.
Kestrel in ASP.NET Core 1 is not based on http.sys and to my knowledge does not support port sharing, so that won't work.
Katana uses HttpListener so that will also work.
Even in Azure Fabric every service should have different port - port sharing is available for service replicas (statefull) or multiple instances of the same service (stateless).
https://azure.microsoft.com/en-us/documentation/articles/service-fabric-service-manifest-resources/
Common way to have uniform URL structure is to create Api Gateway, which will call other services.
http://microservices.io/patterns/apigateway.html
Can someone help me in understanding the role of self-hosting in WCF?
Is this only for testing and development purpose? or can this also be useful any sort of real time application??
Why do we actually need service if we self-host it and limit it to a application?
WCF can be self hosted as a windows service (like what SPereyaslov suggested) or as an IIS service. The reason to host the WCF program (or any program) as windows service is so that the program starts and runs no matter who is logged on. In fact, if you have your program running as a windows service, the service can restart automatically if the server is restarted. That's the advantage.
Your question: Why do we need to make code as service when we have both client and service on the same machine? You don't need it to run as a service if both the client and web service are on the same machine. You could run compile and run the WCF program as an executable, but in a normal commmercial environment, you wouldn't have the WCF program and client on the same machine.
For example, you can host WCF service inside Windows Service. I think this case more natural if you need only tcp binding without http binding
There is an intranet based ASP.NET application that is deployed to a server (IIS) and a group of clients (about ten). The end user can then decide to either connect to the local application (deployed to their local machine) or the server version. I do not understand the reasoning for doing this. My question is: is this common practice?
yes, it is a common practice to verify the performance of the application. Each client will have their own settings and as per process, application should not break in any kind of environment. it is always beneficial to put a server version and a local version.
If the clients are laptops, and the application supports disconnected data sets and synchronization, it would make sense. Typically you'd see something like this when the client machines are taken off-network to be used at a remote work site.
I would like to be able to step through an application deployed to a remote location which as yet has nothing bar version 3.5 of the .Net framework.
What steps do I need to go through to achieve this and how long would you envisage this taking?
How to: Set Up Remote Debugging
Screencast for Visual Studio 2008 - Remote Debugging with MSVSMON.EXE
This is also a good KB showing some troubleshooting scenarios..
If you have unrestricted TCP/IP access to the remote location, this will be very easy (as in, 5 minutes tops to get it to work): see How to: Set Up Remote Debugging and How to: Run the Remote Debugging Monitor for the steps involved.
If your development machine is separated from the remote server by firewalls, routers, etc., things get a bit more difficult. Since remote debugging requires Windows authentication, DCOM and other things that are usually (and quite sensibly) blocked by security policies, you'll most likely require some kind of VPN access to the remote network in order to get things to work.
Setting up a Routing and Remote Access service on the target server is a quick way to get PPTP dial-in access to it, but there are significant security implications to doing this. So, this is most likely the step that will take up most of your time (and, depending on the organization that manages the target network, lots of discussions with their network/security people...).
My advice would be to start testing with remote debugging using a test machine on your local LAN first, and deal with the connectivity issues once you're comfortable with the basics.