View source for Documentation:WCF issues

<html>
<div class="outdated-alert">
<p> <span> ❗🕜 Warning: </span> this article may contain outdated information. Consider before using any descriptions/solutions, otherwise it still can be helpful. <a href="https://wiki.mdriven.net/index.php/MDriven_Product_Line#Synonyms_and_name_changes"> <span> Help : Synonyms and name changes </a>
</p>
</div>
</html>

'''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.

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:
[[File:2018-05-07 12h44 51.png|none|thumb|414x414px]]
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 Trouble-shoot =
Your project looks something like this:

[[File:WCF trouble-shoot asset img.png|frameless|386x386px]]

Is your server running under IIS or DevServer?

Check PersistenceServer project properties:
[[File:WCF trouble-shoot asset img-2.png|none|thumb|634x634px|PersistenceServer project properties]]
Is your Client(s) pointing to this?

Search your project for persistenceMapperClient:

{{Pre2|<nowiki>
this.persistenceMapperClient1.Uri = "http://localhost:52150/EcoProjectWindowsPhone71PMPWCF.svc";
</nowiki>}}'''You may find multiple entries – check them all.'''

'''NOTE''': If you are looking at a PersistenceMapperClient that runs '''on a PhoneEmulator, you should not expect Localhost to work'''. After all, Localhost would be the phone?! Well on the WindowsPhone emulator, Localhost is NOT the phone – it is your dev-pc so you can safely use Localhost. But on the '''Android emulator Localhost will NOT work, instead use the ip: 10.0.2.2''' (so replace localhost with 10.0.2.2 ).

The other half of the URL comes from your persistenceServer projects definition of the WCF Service:

[[File:WCF trouble-shoot asset img-3.png|frameless|359x359px]]

Test if it runs now… If not:

Do you have a ClientAccessPolicy.xml file on your webserver root? Note, “ROOT” not “Directory” – on the devserver, this is the same but in IIS, I really must stress THE ROOT of the webserver and NOT your Virtual directory.

Does it run? If not:

Turn on logging in WCF to see what the holdup is – read about this here and pay extra attention to what is required if you have declared your own enum types.

= 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) 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:

{{Pre2|<nowiki>

     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);  </nowiki>}}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.

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:

{{Pre2|1=<nowiki>

<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>

</nowiki>}}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 show where we adjust some values to allow for bigger messages
* The red lines explain how reference and definition are separated
[[File:WCF & ECO asset img.png|frameless|533x533px]]

=== Having Your Own (enum) Types ===
Another thing that stumped us 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 commonplace 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 tell the client AND the server.

In an IIS hosted server, use the Global.asax:

{{Pre2|<nowiki>

protected void Application_Start(object sender, EventArgs e)

{

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

}

</nowiki>}}

And on the Client add it to Main:

{{Pre2|<nowiki>

static void Main()

{

    Eco.Wcf.Common.KnownTypesHelper.AdditionalTypes.Add(typeof(OrgeinheitTypEnum));
    Eco.Wcf.Common.KnownTypesHelper.AdditionalTypes.Add(typeof(ECObjectTypEnum));
    
</nowiki>}}

=== When Things Do Not Work – Complete Darkness ===
Debugging the WCF issues was initially really annoying and complex – “Unexpected server shutdown” and nothing else…

Luckily, it is easy to turn on explicit logging in WCF. Go like this in the server web.config:

{{Pre2|1=<nowiki>

<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>

</nowiki>}}This will give you a file with a lot of information at c:\temp\WCFTracelog.log.

When I removed one of the AdditionalTypes.Add statements from above, the log looked like this:

[[File:WCF & ECO asset img-2.png|frameless|678x678px]]

[[Category:Advanced]]
[[Category:Outdated]]