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" ?>
            <!-- removed for brevity -->
          <endpoint address="http://localhost/webservices/CoreService.svc/basicHttp_2010"
              binding="basicHttpBinding" bindingConfiguration="basicHttp_2010"
              contract="Tridion.ICoreService2010" name="basicHttp_2010" />

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

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?


Using the following:

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


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.

  • In your service endpoint address is: localhost/webservices/CoreService.svc/basicHttp_2010 however in your client endpoint address is localhost/webservices/CoreService.svc/basicHttp, which are not matching. My understanding is both should be same.
    – Hiren Kaku
    Commented Apr 15, 2015 at 14:51
  • Thanks, Hiren. It looks like I don't have CoreService.svc in the folder for the webservices IIS Web Application (just CoreService2011.svc, CoreService2012.svc, CoreService2013.svc, and ImportExportService2013.svc). Maybe SDL Tridion 2013 (SP1) does not ship with the vanilla CoreService.svc anymore? I don't think basicHttp_2010 applies for CoreService2011.svc--I added the error from trying it to my answer. Commented Apr 15, 2015 at 16:46
  • I'm thinking the answer here is "no, you can't use the AppData inspector with just a configuration change." Either we update the code to use a more recent endpoint or hack 2013 SP1 to use the old endpoint. I'll accept an answer if someone can confirm CoreService.svc was deprecated (and in which Tridion version). Commented Apr 15, 2015 at 16:50
  • 1
    It's also worth noting that there's a working version of the AppData Inspector in the PowerTools. Commented Apr 16, 2015 at 11:53
  • 1
    Command line tools are the ultimate power tools. ;-) Commented Apr 17, 2015 at 0:52

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

  • Perfect. In Visual Studio I was able to replace the old Web Reference with a new one (using localhost/webservices/CoreService2011.svc?wsdl). The tool worked after replacing all references to CoreService2010Client with CoreServiceClient and then using the basicHttp1 endpoint. I like how the code itself is now "version agnostic" without any version years. Commented Apr 15, 2015 at 21:08
  • Nice. You could also have used the OOTB Tridion.ContentManager.CoreService.Client.dll (provided since 2011SP1 release) instead of a Web Reference. Commented Apr 18, 2015 at 9:52
  • 1
    And note that although the client code now looks "version agnostic" (no version numbers in type names), it is not -- you still compile the code for a specific contract version and should use the appropriate Core Service endpoints (URLs) for that version. The reason why the version numbers were removed from the client-side types is to facilitate migration to a newer version (although this remains an explicit, manual action). Commented Apr 18, 2015 at 9:56
  • Good points. Indeed I explicitly had to remove one Web Reference and replace it with a new one against a newer endpoint. Ah, and I forgot about the OOTB client dll--I'll leave that as an exercise for the next AppData Companion contributor. ;-) Commented Apr 18, 2015 at 17:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.