I am trying with setting a web service without using IIS.
I knew we can use HttpListener to create simple http server before. I am wondering if it is deprecated now since WCF seems provide more advanced features.
Take a look at the HttpListener Class documentation:
This class is available only on computers running the Windows XP SP2 or Windows Server 2003 operating systems. If you attempt to create an HttpListener object on a computer that is running an earlier operating system, the constructor throws a PlatformNotSupportedException exception.
So, if you can use it depends on the operating system you want to run your program on.
Microsoft recommend against using it. I'd go with WCF if you need to know it'll be maintainable for some years.
Alternatively, if you're happy to expose RESTful services rather than SOAP or XML-RPC, there are a few standalone .NET assemblies you can use to host an HTTP server in your app without any dependency on IIS or WCF - they'll run under Mono, too, with no problems:
Nancy - http://nancyfx.org/
Kayak - https://github.com/kayak/kayak
Firefly - http://loudej.github.com/firefly/
We use them to make sure we have complete control over the server stack, and can tweak things outside the parameters of the black-boxes that are .NET's HTTP listeners.
Related
I have a project I am working on where I need to create an app and service package for Windows. I would like the service process to run as SYSTEM or LOCALSYSTEM so that credentials are irrelevant. The application frontend will be installed and executable by any user on the machine. Data from the frontend application will be passed to the service - most likely paths to directories selected by users. Once started the service will listen for a command to do some action while accepting the aforementioned paths.
I'm using C# on the .NET platform and I've looked into creating a standalone service and a standalone application separately as well as creating a WCF service library and host application - that's as far as I've gotten.
All of these methods seem overly complex for what I am trying to achieve. What is modern convention when attempting something like this? I'm willing and able to learn the best method for moving forward.
Edit: This was flagged duplicate. I'm not looking for information on HOW to communicate with a Windows service. That's remedial and not at all what I'm asking. I'm looking for validation that I'm on the right track and if I'm not, I'm looking for suggestions. I've been told that I'm on the right track and pointed towards named pipe binding.
Windows Service is certainly an option for hosting WCF, although it kind of is a deployment nightmare. It really depends on your environment and the capability and support of your system admins as I've had many clients where deploying a windows service, as you need admin rights to install and update it, was simply not practical.
Console applications may sound like a terrible idea but the practicality of being able to drop them on a share and run a powershell script to start them is very compelling.
But frankly IIS hosting has the most advantages in my mind as the product is designed for ease of deployment and up time. And you can use any transport binding in IIS that you can use in a Windows Service or Console.
As for the binding itself named pipe is not really a popular option in many enterprise scenarios as it is incompatible with anything but .NET. Although the same can be said for binary which is one of the more performant bindings. The WSHttpBinding is probably the most popular binding in scenarios that require unknown callers. WebHttpBinding is an interesting option as its HTTP/REST based, although that requires further decoration of your operations and honestly if your going that route you should really be using Web API.
All,
I have been writting Windows Services for a while in C# deriving from ServiceBase.
So far my services are hosted in servers where they usually listen to message queues and process messages.
Is there a new way of creating such services in WCF ?
Thanks,
MK
Yes. Check out Windows Process Activation Services.
From what I understand, it's very much like how you used to host remoting objects under IIS, but with WAS, you don't need to involve the whole huge IIS stack like you used to.
Microsoft Message Queuing would seem to be what you'd want though there are some offshoots like BizTalk Server that may use similar stuff. Just to toss out an idea or two.
I've started using an open source project called TopShelf to easily create applications that run as either a Windows Service or a console app for debugging.
I've also been hearing a lot about Windows Server App Fabric. Here is a quick blurb from the App Fabric white paper.
AppFabric Hosting Services (originally code-named “Dublin”) doesn’t create some entirely new hosting infrastructure. Instead, it builds on what’s already provided by Internet Information Services (IIS) and Windows Process Activation Service (WAS). On this foundation, AppFabric Hosting Services adds extra capabilities for running and managing WCF services, including workflow services. Figure 7 illustrates this idea.
Windows App Fabric Home
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.
Is it possible to create a C# EXE or Windows Service that can process Web Service requests? Obviously, some sort of embedded, probably limited, web server would have to be part of the EXE/service. The EXE/service would not have to rely on IIS being installed. Preferably, the embedded web service could handle HTTPS/SSL type connections.
The scenario is this: customer wants to install a small agent (a windows service) on their corporate machines. The agent would have two primary tasks: 1) monitor the system over time and gather certain pieces of data and 2) respond to web service requests (SOAP -v- REST is still be haggled about) for data gathering or system change purposes. The customer likes the idea of web service APIs so that any number of clients (in any language) can be written to tap into the various agents running on the corporate machines. They want the installation to be relatively painless (install .NET, some assemblies, a service, modify the Windows firewall, start the service) without requiring IIS to be installed and configured.
I know that I can do this with Delphi. But the customer would prefer to have this done in C# if possible.
Any suggestions?
Yes, it's possible, you may want to have a look at WCF and Self Hosting.
Yes, it is possible (and fairly easy).
Here is a CodeProject article showing how to make a basic HTTP server in C#. This could easily be put in a standalone EXE or service, and used as a web service.
One technology you might want to check out is WCF. WCF can be a bit of a pain to get into but there's a great screencast over at DNRTV by Keith Elder that shows how to get started with WCF in a very simple fashion.
http://www.dnrtv.com/default.aspx?showNum=135
You could take a look at HttpListener in the .Net framework.
I would highly recommend WCF. It would fit very well into a product like you are describing. There are a good number of books available.
Sure, you can do that. Be sure to change the Output Type of the project to Console Application. Then, in your Main function, add a string[] parameter. Off of some switch that you receive on the command line, you can branch to ServiceBase.Run to run as a Windows Service or branch to some other code to run a console application.
This question is somewhat older but since I needed something similar some time ago it felt like this question is still relevant.
I wrote a small Rest-API with NancyFx and OWIN. OWIN is a standard interface between .Net applications and web servers. With OWIN it is possible to create a self-hosted WEB-API. Nancy on the other hand is
a lightweight, low-ceremony, framework for building HTTP based
services on .NET ¹
The combination of those two makes it possible to create a self-hosted C# Web service.
I am quite sure that there are many more possibilities to create something like this by now but since I used it like this I thought the Information might be useful to someone.
I would like to embed a light weight web server in a Windows application developed in .NET. The web server has to support PHP.
I have looked at Cassini, but it seems it is ASP.NET only.
The .net class HttpListener exposes the underlying http.sys upon which IIS is built. All machines since Windows XP2 have http.sys installed by default.
Here are some links to get you started.
XML-RPC SERVER USING HTTPLISTENER
HttpListener For Dummies
As for the PHP support, I don't know how you would enable this, but there is no technical reason you couldn't build it in.
I would look at the likes of XAMPP Lite which you could easily start up and shutdown with your application.
There is also AppWeb which claims to be exactly what you are looking for.
You can always use PHP as a CGI application. CGI is well documented, and AFAIK pretty easy to implement. Use Darrel Millers suggestion, and couple it with some CGI magick, and you should be cooking with gas.
Mongoose embedded webserver
https://code.google.com/p/mongoose/
You can build it with VS2012/10/08 as EXE and you can use PHP and also websockets to push data to the client app. Also you can build a DLL you can do this with make or bring the code into a VS DLL project and build out a _DLLMain, DEF file, etc. Then use it direct from C# - see the mongoose.cs and example.cs files.