Configuring AppData Inspector for SDL Tridion 2013

Question

Frank van Puffelen's AppData Inspector lets you browse App Data using a command-line tool.

It comes with a XML configuration file that defines the WCF service client endpoint. For a Tridion 2011 setup this looks like:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
            <!-- removed for brevity -->
            </basicHttpBinding>
        </bindings>
        <client>
          <endpoint address="http://localhost/webservices/CoreService.svc/basicHttp_2010"
              binding="basicHttpBinding" bindingConfiguration="basicHttp_2010"
              contract="Tridion.ICoreService2010" name="basicHttp_2010" />
        </client>
    </system.serviceModel>
</configuration>

In Tridion 2013, I understand the endpoints were updated. Rather than an endpoint address with http://localhost/webservices/CoreService.svc, we now reference a specific version as in: http://localhost/webservices/CoreService2011.svc

The documentation describes the endpoints, but I'm not sure on attributes like contract.

Trying the following:

  <endpoint address="http://localhost/webservices/CoreService2011.svc/basicHttp"
      binding="basicHttpBinding" bindingConfiguration="basicHttp_2010"
      contract="Tridion.ICoreService2010" name="basicHttp_2010" />
</client>

Gives the following error:

Unhandled Exception: System.ServiceModel.ActionNotSupportedException: The message with Action 'http://www.sdltridion.com/ContentManager/CoreService/2010/ICoreSe rvice2010/ReadAllApplicationData' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver. Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).

Can we use the AppData inspector on a 2013 setup by updating AppData.exe.config?

Edit:

Using the following:

      <endpoint address="http://localhost/webservices/CoreService2011.svc/basicHttp_2010"
          binding="basicHttpBinding" bindingConfiguration="basicHttp_2010"
          contract="Tridion.ICoreService2010" name="basicHttp_2010" />
    </client>

Gives:

Unhandled Exception: System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at http://localhost/webservices/CoreService2011.svc/basicHttp_2010 that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. ---> System .Net.WebException: The remote server returned an error: (404) Not Found. at System.Net.HttpWebRequest.GetResponse() at System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpC hannelRequest.WaitForReply(TimeSpan timeout) --- End of inner exception stack trace ---

Update: based on Rick's explanation, to make the AppData Companion work for Tridion 2011 SP1 and later, we need to update the Service Reference and code.

So this endpoint (with code and service changes) works:

<endpoint address="http://train1/webservices/CoreService2011.svc/basicHttp"
                binding="basicHttpBinding" bindingConfiguration="basicHttp1"
                contract="Tridion.ICoreService" name="basicHttp1" />

I added the updated project and .exe. to SDL Community and placed the updated project in the TridionWorld repository.

Answer 1

Core Service endpoints and contracts are side-by-side versioned. That is: with each new Tridion (point) release, we introduce new contracts and endpoints, but the old ones are also kept (hence the version numbers in the URLs). Clients compiled against an older contract will remain working without recompiling or changing the endpoint URL (as a matter of fact, if you only change the URL to a newer version, you'll get the error you encountered).

This side-by-side versioning policy was introduced in the 2011 SP1 release (2011 contracts/endpoints). The 2010 contracts stem from the 2011 GA release and these were not forward compatible (it wouldn't be able to deal with future data contract changes). That is why the 2010 contracts/endpoints were dropped in 2013 SP1 and why you will have to change tools that use these 2010 contracts/endpoints.