Develop Reference

How to control settings of Windows Service from GUI?

I have this Windows Service that communicates with TCP/IP.
What I want to know is a method for a Windows Form Application to able to modify the setting of this service, such as remote host address and port to connect, timeout length, and log settings.
I have researched about NamedPipe, WCF Service, and IPC, but I can't decide what matches my scenario the best.
Will be nice to able to change the service settings by doing something like this from the client side.
[Service].SetTimeout(3000);
Any suggestions?

If you want that kind of programmatic control, then WCF is your best bet. With WCF, you get to define the API yourself, e.g., what methods to call, what messages to pass, etc. The WCF framework takes care of exchanging the data for you. And with the WCF config files, changing the back-end data exchange mechanism is trivial. For example, you could replace a NetNamedPipeBinding used for same-machine communication with a NetTcpBinding for cross-machine communication simply by modifying the config file(s). Full disclosure, though, if you haven't done WCF before, my experience was that the barrier to entry was pretty high. Of course, I took my lumps with Visual Studio 2008. It might be much easier in a more recent version. Here's an answer I gave a while back with some tutorials that helped me.
For me personally, I've replaced the early WCF implementation with a TCP-based version over localhost in the project I work on. The front-end application receives constant information from the Windows service when things are "running," and at the time of our decision, WCF streaming was not documented very well. We also saw evidence of problems, although that might simply be because we did it wrong. In any case, I'm very pleased with the solution we've come up with.
I can't speak to named pipes directly, but from what I've read, they're easy to use.
HTH.

WCF, Windows service - needs to notify client application

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

Workflow Service custom tracking participant that talks to a client-side endpoint(s)?

I'm at the investigative stage for Workflow Service and WPF.
Having State Machine WF Service hosted in IIS and one or more WPF clients talking to the WF Service sounds reasonable choice so far.
However, although days of reading and research it isn't clear to me what would be the best strategy for tracking the transfer between states from WPF app.
There're numerous samples of tracking participants but most of them are based on One process scenario.
So I am thinking of a structure as below.
A server-side WCF operation that any client calls to register its client-side endpoint
A custom tracking participant that goes through all registered client-side endpoints and sends TrackingRecord at it's Track() method.
Advantage of this approach is that it allows real time update of the states without extra layers like ETW. Another advantage is that it allows decoupling of the logic (or maybe model layer) from the presentation layer.
Can anyone share the opinion over the above structure?
I would also welcome any suggestions for achieving the goal.
[EDIT]
To make my idea above more detailed and clear, below steps would be a typical usage.
1) (WPF client) contains and opens a WCF endpoint for receiving TrackRecords.
2) (WF Service) opens a WCF operation (or a simple WF instance with a Receive message) that registers client-side address to an internal store.
3) (WF Service) a custom tracking participant is created and added that will send TrackingRecord to the registered clients' endpoints.
4) (client) connects to the above service and hands out client-side endpoint mentioned at step 1 and consequently receives TrackingRecords.
[ EDIT 2 ]
To put my goal in simple terms, I'd like to know
1) the most efficient way of tracking the StateMachine's state on a WF Service (IIS) + WPF or any types of client app through TrackingParticipant.
2) if my suggestion can be improved
Meanwhile, I have implemented this and works good so far. I also added MvvM Light framework's messaging feature at the client-side so that it propagate the received message to the models easily.

You might take a look at SignalR instead of trying to force WCF to become a pub/sub platform which is not it's strength. There is an example on my blog with the visual tracking example with the tracking participant split out from the tracking application so it's not all in one process. That blog also has links to two other blogs where similar things were done, but all using a messaging architecture more suitable to events like this.
http://panmanphil.wordpress.com/2012/11/05/slides-and-sample-from-the-chippewa-valley-code-camp/

There is an existing mechanism that wraps a lot of the functionality that you are suggesting (If I understand your needs correctly). If you need to utilize a WCF service to communicate in a bidirectional way (i.e. PUSH data to connected clients) I would suggest leveraging the PollingDuplex Binding.
I have used PollingDuplex in the past with various Silverlight clients to exchange data, and I have read articles like this one describing the steps to produce the same behavior in WPF space.
This approach will automate much of the endpoint registration and tracking logic that you apparently are thinking of doing manually.
I hope this helps.

Creating a ASP.NET web service, not WCF

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

is there a way to let the web server (not the Client which is the trivial case) send a messege to a Client application?

I'm about to start to develop and application in C# but I realized that I haven't the enough knowledge to develop it yet :S.
The thing's that I need to find out a way to let the Web server comunicate with my application, i.e., in short, is there a way to let the web server (not the Client which is the trivial case) send a messege to a Client application?
I know that I way to solve it's to make Client applications periodically send messages to the web server but that's not what I want 'cause polling generates overhead
Sorry about my english! I'm not a native speaker.
Thanks in advance!

Generally this type of interaction is achieved with Comet or WebSockets - I'm not sure how your app will be communicating with the server, but I would bet you can do what you're trying to do using one of those.

You could implement a WCF service in your client that could listen for a connection from the server (or anything else). The server can communicate with the client as easy as calling the API.
Getting started with WCF is really easy using the wizards in VS.
Here is a link that talks about using WCF with ASP, but it can be used outside of asp as well.

It seems like you meant "push" messaging, the challenge around this is for the server to keep track of the lost of clients and manage who should recieve which message.
If you want to get it done with minimal overhead you can check out the Amazon Simple Notification Service.
SNS is a cloud-based messaging and notification service hosted and managed for you, SNS is based on a topic/subscriber model and you set it up via a few simple API calls, it is metered but quite inexpensive for the most part.
edit: For C# Libraries and frameworks to do it yourself, I am not an expert in the C# world so I think other answerers will know it better.
Disclosure: I work at amazon so I am naturally inclined to like their product