Is there any way of starting a HTTP WCF service from a regular, non-admin application manually? All I want is my regular desktop application to listen on a port where some things can be controlled remotely.
I could go the manual route and use my own TcpListener, parse HTTP (or any other protocol), go through some reflection, then respond back on TCP, but I'd like to use WCF to avoid boilerplate.
A partial workaround is to use http://localhost:80/Temporary_Listen_Addresses/ if that's acceptable in your situation (not in mine though). This URL magically doesn't require additional permissions. source
Related
I am a newbie developer to WCF and Windows services. I do know c#. The scenario requires various custom applications running on Windows 7 to call methods in another application. It is a client/server relationship, all running on the same computer. The server must be able to notify each client (one at a time) when a specified condition occurs.
I need to develop the server code only.
Would the following be an acceptable solution:
Make the server a windows service that uses WCF. The server could notify the clients by using a different named pipe for each client ?
Thank you...any suggestions would be appreciated.
Just use duplex communication over tcp/named pipes/msmq/http (WSDualHttpBinding) channel.
AFAIK you need two ports (in/out) for duplex over http
I would ditch wcf altogether. Although as Brian says, you can use the duplex bindings, these are complicated at best.
If it's all going to run on the same computer, why do you even need client/server? Just build a single client which does everything you need.
That is a acceptable solution and should work fine.
Other option for consideration (in the spirit of learning) is creating a Routing Service as an intermediary service which spawns the calls to multiple services. So in your scenario, your client would call the routing service and the routing service will in turn call each of your service
The following link should provide more information on routing service...
[Routing Service][1]
http://msdn.microsoft.com/en-us/library/ee517423.aspx
I would like to have a client application and web application (or service, no UI) and I would like to connect to said web service from within my desktop application and to have two simultaneous network stream, one of them for uploading data and reading them on server and the other one for sending stuff to the client application.
I am not looking for a solution that uses anything more than that like WCF or anything, I just want a way to create connection between web server and my client application and exchange pure binary data. I would implement the protocol myself, I am not looking for any entities or encapsulation like WCF provides.
I don't even know what project type is the best choice here. I thought about empty ASP.NET application maybe that I'd upload on FTP but I have no idea what I should do next to make the application connectible to. I am not asking for complete solution of course, rather some articles that focus on how to make a plain and simple connection between server and client. I want server to be able to immediately update client and vice versa, that's why I am looking for a way to have stream.
Edit: I may as well say that the service is meant to be placed on ASP.NET hosting and I don't know how ports work on these, if there are any restrictions or anything.
"Web service" and "Network stream" are incompatible concepts. Web-services are (ideally) stateless and disconnected - so they work regardless of how the underlying network works. Messages are exchanged only from client-to-server and are encapsulated in HTTP request/response pairs. Hence "web service".
If you want to exchange "pure binary data" (as you put it) then you just need to work with sockets (or use .NET's TcpClient, which wraps up sockets in an easier-to-use API). ASP.NET would be inappropriate for this.
You can technically have an application that uses sockets that runs within an ASP.NET host process but this might not work depending on how security is set-up and it's also bound by the ASP.NET process lifecycle (so it is activated by IIS and can be shut-down or recycled at any time without warning).
You do not want to use ASP.NET Web Services for this (ASMX). That is a legacy technology, and should not be used for new development.
Why do you not want to use WCF? Do you believe it's too complicated? The thing about WCF is that it removes the complication of creating your own protocols.
Also, which version of .NET are you using? WCF get a lot easier to configure with .NET 4.0.
Here is simple duplex example using WCF.
Try it, check if performance you've got is enough, try to use alternative bindings ( like net.tcp). WCF is really neat tool to use. Once become more familiar with it you will love it.
Also check chapter on bindings in WCF from Learning WCF
Have a look at the MVC4 APIController. It works much like stock MVC except that methods return XML or JSON (or anything else you like).
Eg
/api/Users/Get
would could return something like
{
{"Username":"Bob", "Id":3},
{"Username":"Steve", "Id":4}
}
You can also return files and other streams by using special return types. You even get strongly typed, validated input through the use of models.
There's an example here which shows a full CRUD controller and sample AJAX calls from JS which you can replicate in your desktop app
I would like to handle HTTP on very low level - at the moment I'm stuck with HTTP CONNECT verb. It looks like HttpListener doesn't have access to these request because they are handled somewhere inside HTTP API or HTTP.SYS. I'm able to handle such requests with native TcpListener but in such case I would lose all HTTP functionality = I would implement HTTP from scratch.
I also checked FiddlerCore but it also handles these requests on some Win API layer. Is there any pure .NET HTTP stack?
Edit: I'm working on HTTP proxy with some additional request analysis and statistics so I don't want to lose HTTP parsing and in the same time I want to know about SSL connections.
Use Tcp* ans Socket*, not Http* related classes to use really low level in .NET.
TCP is at the bottom of HTTP protocol stack.
Use TCP sockets if you want it to, just use "winsock2.dll" interop calls form c#, and all related stuff like structure definitions etc, or use native C++
Well, if you are building your custom HTTP/HTTPS server or proxy and you don't mind third-party components, then our SecureBlackbox includes HTTP/HTTPS server components which let you do almost anything with any verb. Pure .NET, use any socket classes.
Ok. Again the problem is not in API but in developer :)
I have some test suite to test my implementation but the test suite was connecting directly (not as to a proxy) - that was the first problem. The second problem was that this test suite should use TcpClient instead of HttpWebRequest if I want to test Connect verb separately because HttpWebRequest uses it only internally when using proxy for HTTPS.
I have a server client application.
The clients sends the server http posts with info every second or so.
The server is implemented using C#, there server doesn't need to respond in any way to the client.
Whats the easiest and most practical way to get this done? Is there some kind of library that is easy to use that I can import into my project.
Why not just use a regular old web service? It sounds like you have simple functionality that doesn't need to maintain a connection state. With a web service, you can simply expose the methods to your client, accessible via HTTP/S. If you're already using .NET for your client, you can simply add a web reference to your project and have .NET do the heavy lifting for you. There wouldn't be any need to reinvent the wheel.
You can use http.sys to create your own http listener without IIS or additional overhead. Aaron Skonnard has a good article here.
Because of certain limitations of uhttpsharp (specifically no support for POST forms and file uploads and it using threads to process requests), I've made NHttp available at github which supports full request parsing like ASP.net and processes requests using the asynchronous TCP model.
I want to watch all the HTTP requests going out of a certain application and cancel them if needed.
Is there a way to do this in C#?
If you can touch the system's proxy configuration (which is used by many applications) or, if the app doesn't heed that setting, touch the application's configuration to use a proxy of your choice, you can create a HTTP proxy that would do the job for you.
If you just want to profile, there is a ready made tool that behaves like this and is very nice, Fiddler.
Else you'd have to go deeper into the network stack and implement something like a sniffer/firewall, for instance using WinPcap. That's a lot harder to do.
If you're working with Windows, it is possible to hook the WinInet API calls and do whatever you want with them.
FreeCap (or its commercial version, WideCap) does that: allows you to send TCP traffic through a proxy server. That proxy might then do the filtering (e.g. Fiddler).
I know this brings more stand-alone applications into the system, but it works.