tags:

views:

594

answers:

2

The method that I am trying to call has the following signature:

Results GetPerformanceData(MyEntity entity, bool recurse);

I set a breakpoint at the beginning of the method, but the exception is thrown before code execution gets to the breakpoint.

Tracing the WCF service gives me the following info:

System.NullReferenceException, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 Object reference not set to an instance of an object. StackTrace: at System.Runtime.Serialization.CodeGenerator.VerifyParameterCount(MethodInfo methodInfo, Int32 expectedCount) at System.Runtime.Serialization.CodeGenerator.Call(Object thisObj, MethodInfo methodInfo, Object param1) at ...

How can I determine what the null variable is? I have my debugger set to break on all exceptions, but it isn't breaking for this particular problem. It looks like the "entity" parameter to the method I am trying to call cannot deserialize properly.

Sample invocation call

var results = client. GetPerformanceData(entity, true);

WCF service config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.diagnostics>
    <sources>
      <source name="System.ServiceModel"
              switchValue="All"
              propagateActivity="true">
        <listeners>
          <add name="traceListener"
              type="System.Diagnostics.XmlWriterTraceListener"
              initializeData= "trace.svclog" />
        </listeners>
      </source>
    </sources>
  </system.diagnostics>
  <system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding name="basicHttpBindingSettings" closeTimeout="00:01:00"
          openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
          allowCookies="false" bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard"
          maxBufferSize="5242880" maxBufferPoolSize="52428800" maxReceivedMessageSize="5242880"
          messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
          useDefaultWebProxy="true">
          <readerQuotas maxDepth="64" maxStringContentLength="8192" maxArrayLength="16384"
            maxBytesPerRead="4096" maxNameTableCharCount="16384" />
        </binding>
      </basicHttpBinding>
    </bindings>
    <services>
      <service name="Company.Service.Engine"
               behaviorConfiguration="ServiceBehavior">
        <host>
          <baseAddresses>
            <add baseAddress="http://localhost:8000/Engine"/&gt;
          </baseAddresses>
        </host>
        <endpoint address=""
                  binding="basicHttpBinding"
                  bindingConfiguration="basicHttpBindingSettings"
                  contract="Company.Service.IEngine"/>

        <endpoint address="mex"
                  binding="mexHttpBinding"
                  contract="IMetadataExchange" />
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="ServiceBehavior">
          <serviceMetadata httpGetEnabled="true"/>
          <serviceDebug includeExceptionDetailInFaults="True"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>
A: 

There could be several issues here. Make sure your datacontracts have the proper attributes. Make sure your service references are up to date, and if not reusing your datacontracts by referencing the assemblies make sure the generation of the objects is correct (the generated code is usually in a file called Reference.cs). also try placing a try catch block around every service operation and wrap those exceptions in FaultExceptions. This could help you find a better answer.

try
{
 ...
}
catch (Exception ex)
{
 // The generic argument might be unnecessary
 throw new FaultException<Exception>(ex);
}
Khalid Abuhakmeh
How would the FaultException help? This is what WCF does normally.
John Saunders
The only thing that the WCF generated client code is bubbling up is the NullReferenceException mentioned above, because I have includeExceptionDetailInFaults set to true in the service's app.config.
opadilla
by putting the try catch block around your service methods you might catch an exception that might be triggering your other FaultException. WCF is a strange animal, I've run into these situations before.
Khalid Abuhakmeh
+3  A: 

It turns out that I had some properties tagged as [DataMember] that had getters but no setters.

Usually, I'd get a descriptive error by looking at the trace file on the service, or in a pop-up window when adding the service reference on the client project. This time around I did not.

I had to search for ALL instances of [DataMember] and looked at them one by one to find the properties that were missing a setter.

opadilla
oh my god thank you I spent way too much time trying to figure this out
Bill Casarin