I want to know why we should use Webapi SelfHosted and where it is useful?
Let say we have a console application and selfhosted webapi what is the benefit?
The main benefit is that you do not have to set up IIS and websites when you deploy it. This way, you can simplify the deployment of the service and make it easier for administrators that are not experienced with IIS to install it. Typically, you would not use a Console application for self-hosting an API in a real-world-scenario, but a Windows service that runs whenever the computer is running - without requiring a user to be logged on.
In a less common scenario, you could use a self-hosted Web API for inter-process communication. If you want to exchange data between some processes either on the same or on separate machines, you could host a Web API in the application that provides the data and access it from another one.
Related
Is it possible to make HTTP calls to applications outside of Azure from a web API running in Azure?
I'm trying to connect a ASP.NET web API in Azure to a wpf application that runs on a PC at my company. Both the applications request data from each other using HTTP calls with JSON. This works fine locally because i can use localhost but
when running the web API in Azure the web API can't reach the wpf application
I have looked into Azure Point-to-Site and Site-to-Site connections but most examples that i found show connection with a VM in Azure and nothing about web API's.
Thanks in advance!
I still don't get your scenario even after reading all the comments, however here's a shot in the dark.
First of all, no, there are no restrictions as to what destination you may call from Azure, yes that includes the dark web, although not necessarily a recommended destination for both traffic and tourism alike.
For the second part, if what you're calling is behind a firewall and your API runs in Azure App Service, take a look at Hybrid Connections, it's built as a solution to that exact scenario, no IPsec or firewall rules are in play. The connectivity from on-prem will be outbound.
WCF service can be hosted both in IIS and in Windows service. What are differences? Is there any benefit hosting in Windows service than IIS?
Check out the documentation: https://msdn.microsoft.com/en-us/library/ms730158%28v=vs.110%29.aspx
It is awesome!
And the answer to your questions depends on what kind of application you are building and other requirements on the application/environment...!
Here are some differences (Features of IIS.. Copied from the link provided by #Jocke).
You lose all of the features of IIS (logging, application pool scaling, throttling/config of your site, etc.)...
You have to build every single feature that you want yourself HttpContext?
You lose that since ASP.NET provides that for you. So, I could see that making things like authentication much harder WebDeploy?
IIS has some nice specific features in 8 about handling requests and warming up the service (self-hosted does not)
IIS has the ability to run multiple concurrent sites with applications and virtual directories to advanced topics like load balancing and remote deployments.
If your WCF serivce is self-contained, like a data service, just host it in IIS. Drawback: you'll have to install and configure IIS.
If your WCF service is more of an API or IPC mechanism, used to let other applications talk to your application, it makes more sense to let your application self-host the WCF service, and for that a Windows Service usually is the more sensible approach. Drawbacks: you'll have to install your application as Windows Service, and configure that your application may listen on its configured port.
Please note that self-hosting is not constrained to Windows Services.
Please bear with me as I am beginner to Windows service / WCF service. After much research I have not been able to find satisfactory solution to my problem. Let me describe my problem in brief:
I want to run one Windows service / WCF service on a machine on LAN. I want to make that service to be consumed by applications running on another machines on the LAN, provided following conditions must be satisfied :
1) I should not need to host Windows service / WCF service to IIS.
2) The URL of service should be configurable in the applications running on other machines on LAN. I should not have to hard code the URL anywhere in those applications (e.g. in App.config or so). Service URL should be accepted from the application user. At the best, the application should find the machine on which the service is running and should call the service from there.
(As a side note, the applications running on other machines are in-browser Silverlight applications.)
Is it a tall order? If not, which of the Windows service and WCF service will suit my requirements? Please provide me any resource if you have.
I have a C# application that needs to always be running. I originally planned on making this a windows service but I now have a requirement to make the application host a web admin console.
I haven't played with IIS in quite a few years so my question is this:
What would you recommend I use?
I've thought about making a windows service and embedding a web server such as Cassini but so far I'm not very happy with the open source web servers I've looked at.
Can IIS handle this? Do people use it for this type of scenario, and if so how?
This sounds like a job for two separate projects.
One is the original Windows Service. Windows Services are well suited for what you're doing.
The second is the Web Project that will be used to administer the Windows Service. This is the part that runs in IIS.
It depends on what you mean by always running. An ASP.NET web application deployed in IIS could very well be unloaded by the web server if there aren't any requests for certain amount of time killing all background threads. So if you want an ever running background thread it would be better suited to use a Windows Service. As far as the web admin is concerned, well, here you don't have much choice: ASP.NET in IIS. In order to do something useful those two applications should be able to find a common language to talk. So you could use a database to store the results into which could be used by both applications.
IIS will run your app on first request, not on server boot. So you will still need to run a service to ensure your app is always running.
You can use IIS as a webserver for your web admin part, and link your ASP.net app with your service by means of a configuration database (easy) or webservices (a little more tricky).
Windows and Web services are two very different creatures. A web service will expose external methods that you can implement against an application, while a windows service is an entity within itself. If you're planning on using this service on a timed interval to perform an operation, a Windows service would be the right way to go. If you use a web service, you will need to invoke the method you wish to run from a secondary application.
If you need to queue commands against your windows service, you could always create a database that was accessible by both your website and your windows service. This way you could send commands and query data between the two. Placing a web service in to serve as an intermidary between the two may be overkill.
I am going to be coding up a windows service to add users to a computer (users with no rights, ie just for authentication). (As a side note, I plan to use this method.)
I want to be able to call this windows service from another computer.
How is this done? Is this a tall order? Would I be better off just creating a Web Service and hosting it in IIS?
I have some WCF services hosted in IIS on the calling computer (they will do the calling to the proposed windows service). I have found that Hosting in IIS is somewhat problematic, so I would rather not have a second IIS instance to manage unless I need to.
(I will be using Visual Studio 2008 SP1, C# and Windows Server 2003 (for both caller and service host).
Thanks for the help
If you are thinking of hosting a web service in IIS just to communicate with an NT-service on that same machine, that is definitely more trouble than it is worth in this case.
As other answers have indicated you can make a WCF service with the operations you need and host that within the same NT-service that you want to interact with. You can easily secure this with certificates, or user accounts to make sure it is only controlled by the right people/machines.
If you need to control the NT-service itself, there are existing programs such as sc.exe to start, stop, configure, or query the status of your NT-service remotely.
However, you may want to consider seeking a solution without the overhead of creating an custom NT-service and a custom WCF service to interact with it. If you do, the Net User commands (sorry no link - new user limitation) or the AddUsers (see kb 199878/en-us) utility may be sufficient. If your remote "controller" can invoke these commands directly against the target machine you may not have to create any custom software address this need. Additionally you would have less software to maintain and administer on the target machine. You would just be using the built-in OS capabilities and admin utilities.
Finally, you will need to think about the security aspect, NT-services and IIS are usually run under very restricted accounts, many auditors would flip-out over any service running with sufficient permission to create or modify users locally, and especially on other machines. You'll want to make sure that the service could never be used to create users that do have more than the "authenticate" permission you indicated.
Edit: The net user command may not work against another machine's local users, but check out. pspasswd that along with PsExec to create users, should do what you need remotely.
Simply host a WCF service in the Windows Service. You'll then be able to call it remotely.
You can host a WCF service inside a Windows service. Take a look at the TCP binding (NetTcpBinding class). Both client and server will have to use WCF, but that doesn't sound like it will be an issue with your implementation.
Also, the section entitled "Hosting in Windows Services" in this MSDN article provides a walk-through of the process
If the windows service publishes a remoting interface then it can be accessed via that remoting interface.
Otherwise it's the same as accessing any other process running on a remote machine except that there may be some tools (e.g., sc) with built in support for executing against a remote machine (barring firewall complications).
Any IPC mechanisms applies; sockets, web services, remoting, etc...
You could expose a WCF service directly from your windows service. When you start up your windows service, in addition to spinning up any other background processes, you could create an instance of ServiceHost<T> for your service implementation. This would allow you to not only provide WCF access, but also avoid the extra instance of IIS like you requested, and provide TCP, Named Pipes, and WsHttp endpoints. This should give you some nice flexibility in the performance tuning arena, since it sounds like this service will be consumed internally on your network, rather than externally.
You could create a WCF service which will talk to your Windows service on the remote box. Host the WCF component in IIS (or however you'd like so that you can communicate with it) and then call the WCF component from your remote machine.