POV-Ray : Newsgroups : povray.off-topic : Adventures with WCF : Re: Adventures with WCF Server Time
28 Jul 2024 16:24:01 EDT (-0400)
  Re: Adventures with WCF  
From: Orchid Win7 v1
Date: 7 Nov 2013 13:15:58
Message: <527bd8de$1@news.povray.org>
On 07/11/2013 08:21 AM, scott wrote:
>> 3. Execute THREE LINES OF CODE in your server's Main() function, telling
>> it what class implements the interface, and where to listen for clients.
>>
>> 4. Write THREE LINES OF CODE in the client, using the interface type as
>> a generic parameter.
>
> Aren't you going to share those three lines of code?

OK, so here's what you have to do.

First, write your interface:

   [ServiceContract]
   public interface IDoStuff
   {
     [OperatioContract]
     double DoTheStuff(double x, double y);
   }

Next, write the server code that actually does it.

   public class RealDoStuff : IDoStuff
   {
     ...
   }

Now, to serve the interface to the outside world, do this:

   var host = new ServiceHost(typeof(RealDoStuff));
   host.AddEndpoint(typeof(IDoStuff), "net.tcp://localhost:1664/DoStuff/");
   host.Open();

Clients can now connect and run any method mentioned in IDoStuff. 
Speaking of which... On the client end, do this:

   var binding = new NetTcpBinding();
   var factory = new ChannelFactory<IDoStuff>(binding, 
"net.tcp://localhost:1664/DoStuff/");
   var proxy = factory.CreateChannel();

The "proxy" object implements IDoStuff. You can call it like any other 
local object. But actually, when you call it, it calls your server.

Actually, the client doesn't attempt to make a network connection until 
the first time you call a method on the proxy - which is a bit annoying! 
You can force it to open immediately, however:

   ((ICommunicationObject)proxy).Open();

A similar technique can be used to explicitly close the connection if 
you want to.

Compare this to, for example,

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
     <startup>
       <!-- specifies the version of WCF to use-->
         <supportedRuntime version="v4.0" 
sku=".NETFramework,Version=v4.5,Profile=Client" />
     </startup>
     <system.serviceModel>
         <bindings>
             <!-- Uses wsHttpBinding-->
             <wsHttpBinding>
                 <binding name="WSHttpBinding_ICalculator" />
             </wsHttpBinding>
         </bindings>
         <client>
             <!-- specifies the endpoint to use when calling the service -->
             <endpoint 
address="http://localhost:8000/ServiceModelSamples/Service/CalculatorService"
                 binding="wsHttpBinding" 
bindingConfiguration="WSHttpBinding_ICalculator"
                 contract="ServiceReference1.ICalculator" 
name="WSHttpBinding_ICalculator">
                 <identity>
                     <userPrincipalName 
value="mig### [at] redmondcorpmicrosoftcom" />
                 </identity>
             </endpoint>
         </client>
     </system.serviceModel>
</configuration><?xml version="1.0" encoding="utf-8" ?>
<configuration>
     <startup>
         <supportedRuntime version="v4.0" 
sku=".NETFramework,Version=v4.5,Profile=Client" />
     </startup>
     <system.serviceModel>
         <bindings>
             <wsHttpBinding>
                 <binding name="WSHttpBinding_ICalculator" />
             </wsHttpBinding>
         </bindings>
         <client>
             <endpoint 
address="http://localhost:8000/ServiceModelSamples/Service/CalculatorService"
                 binding="wsHttpBinding" 
bindingConfiguration="WSHttpBinding_ICalculator"
                 contract="ServiceReference1.ICalculator" 
name="WSHttpBinding_ICalculator">
                 <identity>
                     <userPrincipalName 
value="mig### [at] redmondcorpmicrosoftcom" />
                 </identity>
             </endpoint>
         </client>
     </system.serviceModel>
</configuration>

*This* is the way Microsoft insists you have to do it.

To be fair, this has the advantage that you can change the network 
configuration without recompiling your client or server code. But in my 
case, since this is an internal application which only I will ever use, 
this "advantage" is moot.

>> Now the *real* fun begins! You see, I actually want to use this stuff on
>> a mixture of .NET and Mono.
>
> It wasn't too long ago you were complaining how you didn't even have a
> .net runtime installed and it was a huge bloated monster and didn't
> understand why anyone would want to use it - and you would have told us
> all that it was obviously impossible to get any .net code working on
> anything other than Windows. What a change (for the better)! :-D

Well, when somebody pays you to write .NET code, you spend an hour or 
two installing .NET (Actually, VS takes multiple hours to install...) It 
wasn't my decision to use C#. ;-)

Having said that, C# is basically like Java, but less broken. It even 
has real generics (rather than the fake generics they kludged into 
Java). Hell, you can write *monads* in C#! ;-)

I'm still pretty sure that .NET was invented for the sole purpose of 
vendor lock-in though. And back when I was whining about it, Mono didn't 
exist. :-P

Man, the amount of bugs in the Mono WCF stuff... >_<


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.