WCF issues

WCF - Windows communication foundation - is the way we usually communicate between tiers with MDriven technology.

Turn on WCF-logging

WCF can be tricky since it is rather silent when it fails.

So if you have ruled out other issues and you still cannot get the communication to work turn on WCF-logging.

In most web.config we have left a commented block to turn on WCF-logging.

This is from the MDrivenServer:

2018-05-07 12h44 51.png

You can find more info here:

https://www.capableobjects.com/2011/06/26/wcf-and-eco/

https://www.capableobjects.com/2012/01/06/wcf-trouble-shoot/

WCF and ECO

If you build your own server (Remote persistence server for ECO), either as WindowsService or as a WinForm application (both available from the ECO VS Wizard) we use the WCF class ServiceHost.

In this ServiceHost we set some parameters – like what binding to use and so on. During the beta-phase of ECO6 it became apparent that we also needed to set a lot of other values like MaxReceivedMessageSize and MaxBufferPoolSize etc on the Binding object.

That code came to look like this:


     BasicHttpBinding binding = new BasicHttpBinding();
     
     binding.MaxReceivedMessageSize = maxReceivedMessageSize;
    
     binding.ReaderQuotas = System.Xml.XmlDictionaryReaderQuotas.Max;

     binding.MaxBufferSize = int.MaxValue;

     binding.MaxBufferPoolSize = 0; 

     Uri address = new Uri(uri);

     ServiceHost svc = new ServiceHost(t, address);

     svc.AddServiceEndpoint(typeof(IPersistenceMapperWCF), binding, address);  

The gotcha with this is that if you host your Remote persistence server in IIS – we do NOT use the ServiceHost because then IIS IS provides the ServiceHost for us.

So in this case we need to tune up the MaxReceivedMessageSize and MaxBufferPoolSize etc some other way : web.config.

So in your IIS hosted Remote Persistent Server you need to add something like this to your web.config:


<system.serviceModel>
  <services>
    <service name="Frako.Emvis.PServerWebService.EmvisPMPWCF" behaviorConfiguration="TheBehavior">
 
      <endpoint address=""
                binding="basicHttpBinding"
                bindingConfiguration="TheBindingConfiguration"
                contract="Eco.Wcf.Common.IPersistenceMapperWCF"  />  
 
    </service>
  </services>
  
  
  <bindings>      
    <basicHttpBinding>
      <binding name="TheBindingConfiguration"              
             maxReceivedMessageSize="104857600">
        <readerQuotas maxStringContentLength="104857600"/>
      </binding>
    </basicHttpBinding>
  </bindings>
  
  <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
      <behaviors>
          <serviceBehaviors>
              <behavior name="TheBehavior">
          
        <serviceDebug includeExceptionDetailInFaults="true" />
        <dataContractSerializer maxItemsInObjectGraph="2147483646" />
 
 
      </behavior>
          </serviceBehaviors>
      </behaviors>
  </system.serviceModel>

Here is the same thing as an image with some hints:

  • The green line is the name of your service – this is the name of your subclass of the PersistenceMapperProvider.
  • The blue lines shows where we adjust some values to allow for bigger messages
  • The red lines just explains how reference and definition is separated

WCF & ECO asset img.png

Having your own (enum) types

Another thing that got us stumped for a good 30 seconds was the unexpected server shutdown when trying to transfer types used by modlr-attributes over WCF when these types were not known to the service.

This is common place when you do your own Enumerations for example or any other handy attribute-type you might want to use.

You need to tell the WCF service about these types before the service is started. And you need to tell the client AND the server.

In a IIS hosted server use the Global.asax:


protected void Application_Start(object sender, EventArgs e)

{

    Eco.Wcf.Common.KnownTypesHelper.AdditionalTypes.Add(typeof(OrgeinheitTypEnum));
    Eco.Wcf.Common.KnownTypesHelper.AdditionalTypes.Add(typeof(ECObjectTypEnum));

}

And on the Client add it to Main:


static void Main()

{

    Eco.Wcf.Common.KnownTypesHelper.AdditionalTypes.Add(typeof(OrgeinheitTypEnum));
    Eco.Wcf.Common.KnownTypesHelper.AdditionalTypes.Add(typeof(ECObjectTypEnum));
    

When things do not work – complete darkness

Debugging the WCF issues was initially really annoying and complex – “Unexpected server shutdown” and nothing else…

But luckily it easy to turn on explicit logging in WCF. Go like this in the server web.config:


<configuration>
 
<system.diagnostics>
  <sources>
    <source name="System.ServiceModel"
            switchValue="Information, ActivityTracing"
            propagateActivity="true">
      <listeners>
        <add name="traceListener"
            type="System.Diagnostics.XmlWriterTraceListener"
            initializeData= "c:\temp\WCFTracelog.log" />
      </listeners>
    </source>
  </sources>
</system.diagnostics>
 
</configuration>

This page was edited 141 days ago on 12/20/2023. What links here