Depending on the version of CRM you are working on you will most likely want to use the relevant SDK – why? Well as developers we need to move with the changes, Microsoft especially are great at deprecating assemblies and features. At times we get lucky in that we can use older SDK assemblies and point them at new versions of CRM (thereby not having to refactor helper code necessarily) but eventually this will stop working.

Try for example to run the CRM 2011 SDK Query sample against a Dynamics 365 organisation and you will quickly see what I am saying. In addition the .NET Target frameworks are different so it makes sense to use the appropriate SDK for the specific version of Dynamics which you are targeting as a general rule of thumb. Just to emphasize the point further you wouldn’t use .NET Framework 4.6 to target CRM 2011, one primary reason being it’s not compatible.

SDK assemblies being removed between releases can be a pain, for example the Microsoft.Xrm.Client.dll has been around for a while now and simplifies the connection process but was removed from the SDK in 2016. It’s not the end of the world but it does signal to developers whenever this occurs they probably should no longer be using those library going forward which is something the comparison diagram illustrates quite well. The new tooling API’s were first released in 2013 and those developers who picked up and adopted the change of direction quickly in the long run had the least headaches. That said it doesn’t help much when working on an existing/older CRM implementation as often you won’t be in a position to justify the additional effort and resource to move from one assembly to another one.

As mentioned from CRM 2013 onwards the SDK was updated with several assemblies all part of the new XRM Tooling API library:

  • Microsoft.Xrm.Tooling.Connector.dll
  • Microsoft.Xrm.Tooling.CrmConnectControl.dll
  • Microsoft.Xrm.Tooling.CrmConnector.Powershell.dll
  • Microsoft.Xrm.Tooling.WebResourceUtility.dll
  • Microsoft.Xrm.Tooling.PackageDeployment.Powershell.dll

The features of the new set of API’s introduced in 2013 is the subject for another article but they essentially take the SDK helper classes and connection dialog found in 2011 SDK along with the Microsot.XRM.Client.dll to the next level. These API’s basically sit on top of the core assemblies and provide the developer with more options to quickly get applications built that need to integrate with CRM in summary the new tooling assemblies provide:

  • Interface for CRM API’s
  • Common Login Control
  • Web Resource Utility

Microsoft’s Unified Service desk application for example was built using the new set of tooling API’s. Then we see after 2013 Microsoft made further changes and removed Microsoft.Xrm.Tooling.Ui.Resources.dll from the SDK assemblies. It is a frustrating thing when you have leveraged the libraries only to find they are soon likely to be deprecated and not work with newer versions of the platform.

Since CRM 2016… all of this has changed considerably with the introduction of the Web API and such many of the libraries mentioned here will soon become legacy at least in there current forms.

Connecting to CRM

This section quickly became a beast so needed a separate article  you can read about how to do this and the differences in a related article: Connecting to Dynamics 365 and Earlier CRM Versions

Advertisements