I am making a little excursion into the WCF land: I need to control my Windows Service from my ASP.NET server. While experimenting, I found that new NamedPipeBinding(NetNamedPipeSecurityMode.None) on the client is not compatible with new NamedPipeBinding() on the server. If you mix them, you’ll get a ProtocolException: The requested upgrade is not supported.
Apparently, default security is “Transport”, which (theoretically) allows to encrypt and sign transmitted messages. More details in Chris Dickson’s blog. Since named pipes are local to the machine, most likely we don’t need all this security anyway.
Incredibly, whether to encrypt/sign or not to encrypt/sign a message is decided on the interface (service contract) level. I am not sure why it is so, but it smells like a leaking abstraction.
What I generally don’t like about WCF, that it feels like foreign language. It is too complex and rich with non-trivial concepts. You can study and perfect it, but if you don’t use it for couple of years, you begin to struggle and feel helpless without a dictionary.
“No usé WCF por un tiempo” or “No utilicé WCF por un tiempo”? Or is it neither?
Permalink
Microsoft was pushing message “forget about WCF” for years now. Does your Windows Service require non-standard control that cannot be done with sc.exe?
Permalink
sc.exe has problems. First, it can pass only a single number, from 128 to 255, and it can get nothing in return. Chronologically, I would put this level of software sophistication at around 1965. Second, in order to use custom control codes, the calling user must have special rights to the service, which ASP.NET application pool user is unlikely to have by default.
I must have missed the message about WCF. What is it supposed to be replaced with, especially for cases other than web client to web server communication?
Permalink
Well, that’s the issue – “for cases other than”. They want everything to be RESTful these days. So 2017 approach would be self-hosting something based on asp.net core in your Windows service. 🙂
Permalink
Like, OWIN self host? Ouch. I am glad you put a smiley there.
Besides the obvious problem of footprint, the biggest issue with HTTP is choosing a unique port to listen on. In theory OWIN has a way to configure multiple hosts to share the same port, but it is ridiculously complicated, and anyway does not help to coexist with other servers that are not based on OWIN.
Permalink
In order to pass signals from Web app to Winservice app we use standard Socket class.
We had to write a small framework in order to make actual calls easier.
Permalink
Wow. Two questions:
1. How do you choose the port?
2. Have you considered existing frameworks? If this is .NET, WCF and Remoting immediately come to mind.
Actually WCF code to organize communication is surprisingly small, albeit full of annoying attributes and other non-trivial details.
Permalink
> 1. How do you choose the port?
Just picked fixed port number.
How is that a problem?
> WCF and Remoting immediately come to mind.
What do you mean under “Remoting”?
Something like that:
https://msdn.microsoft.com/en-us/library/c2swb8ah(v=vs.100).aspx
?
Seems to be obsolete and quite ugly (especially Web.config and Client.exe.config parts).
WCF, unfortunately, have a lot of stupid overhead.
I am not happy with our own SocketHelper either, but now it works, seemingly, without problems.
I wish there was a good framework that would allow for quickly setup calls between applications on the network.
Permalink
> Just picked fixed port number. How is that a problem?
The probability of collision is too high to be ignored. There are only 65534 available port numbers. The machine I am posting this from has over 200 registered services, 103 of them actually running. If each service picks port number at random, probability of collision for 103 services is about 8%, and for 200 services it is over 25%. Besides, the ports are not really picked at random, which makes probability of collision even higher.
> What do you mean under “Remoting”?
.NET Remoting. I am surprised you rushed into creating your own framework without even considering it. It may be obsolete, but this is mostly marketing hype. It works and it is not going away anytime soon. I don’t agree about ugly. Your example talks about IIS integration. In reality it may be used without any configuration with just a few lines of code. I intend to publish a sample code for both WCF and remoting connectivity in a few days.
One real reason not to use remoting is poorer performance compared to WCF, but WCF is much more invasive (requires attributes on interface contracts, etc.).
Permalink
> has over 200 registered services, 103 of them actually running
Why have so many services?
Why not have a single service that runs multiple threads (similar to a web app)?
> It may be obsolete, but this is mostly marketing hype.
Marketing hype actually affects the ability to evaluate technical products.
Evaluating technical product is time consuming, and if marketing is misleading – it is hard to find a good working product.
Permalink
> Why have so many services?
They are not mine. Most of them come standard with Windows. But if everyone just picked a port at random…
> Why not have a single service that runs multiple threads (similar to a web app)?
You don’t get the point. The services come from different vendors. If each vendor behaved like you and picked a port at random, it would have been an administrative nightmare. Thankfully, they don’t do it, at least most of them.
> it is hard to find a good working product.
Marketing hype changes over time. 15 years ago remoting was the coolest kid on the block. So, if you are around long enough, you know about many products.
Permalink
> The services come from different vendors.
Why do vendors provide their functionality in form of a standalone service and not a library that can be plugged into your project?
Are you currently in the position of one of such vendors and designing remoting interface for your service (that you are going to ship to your customers)?
> 15 years ago remoting was the coolest kid on the block.
I remember that hype. I did not have a need to architect my own remoting solution back then.
Then few years later I was surprised to discover that “.NET Remoting” hype is gone. So I did not seriously consider that legacy “.NET Remoting” when I actually needed a remoting solution.
Permalink
I’ve been having decent success with these settings. (Which involved removing my Transport-Security settings mentioned in this post.
CLIENT
SERVER (below)
If you make a remark, please specify client-settings or server-settings (or both-settings). Nothing drives me nuttier with wcf when people post config-settings and its ambiguous as to which side of the “wire” the settings exist. #rantOver