locked
SDK dlls - Which versions are compatible? RRS feed

  • Question

  • Hi,

    We develop plugins for Dynamics CRM 2011 using the Dymancs CRM 2011 SDK and Visual Studio 2012.

    Our Dynamics CRM Visual Studio project containig the plugins references the following dlls:

    • Microsoft.Crm.Sdk.Proxy.dll
    • Microsoft.Xrm.Sdk.dll

    We use Visual Studio to deploy the project to our Dynamics CRM Server.

    Everything worked fine for month or even years.

    We regularly update the Dynamics CRM Server and Dynamics CRM SDK independently.

    Recently we found out that our Dynamics CRM project always referenced the very first versions of mentioned dlls above since we started plugin development, although there were much more recent version of these dlls included in the most recent Dynamics CRM 2011 SDK.

    So we decided to reference the new versions of the dlls from our CRM project.

    As a result were not able to deploy the CRM project anymore. I cannot reproduce the exact error message displayed in Visual Studio, but it was somewhat like "Assembly cannot be loaded".

    So we switched back to the old versions of the dlls.

    Here the questions about Dynamics CRM 2011:

    • Are there any rules or guidelines which versions of the mentioned dlls to reference in a CRM project?
    • How does the version of the Dynamics CRM 2011 SDK and contained dlls relate to the (a) the dlls referenced by a CRM project and (b) the version of the Dynamics CRM 2011 target Server for deployment (from Visual Studio)?

    Another question about compatibility of Dynamics CRM 2011 SDK and Dynamics CRM 2013 SDK:

    • We want to develop a Dynamics CRM solution for Dynamics CRM 2011 AND Dynamics CRM 2013.
    • Which version of Dynamics CRM SDK should we use? SDK 2011 or SDK 2013?
    • Is a solution developed with Dynamics CRM 2013 SDK backwards compatible for deployment on a Dynamics CRM 2011 server?

    I did not include concrete dll version numbers here, because my intent is to get a better understanding of version comatibility in general, rather than solving a concrete version confilct (which probably should not happen anyways).

    Regards,

    Johannes Riemer.

    Monday, February 24, 2014 1:12 PM