Developing applications for multiple versions of Dynamics CRM

As most of you know, I have a several add-on products for Dynamics CRM developers, administrators, and consultants.

They all share common user interface and application frameworks that I developed several years ago.

When I first started writing these tools all I had to worry about was Dynamics CRM 4.0, which was pretty easy. Then Dynamics CRM 2011 shipped, which made things a bit more difficult, but not impossible.

I just had to separate my internal components so that one section worked with CRM 4.0, and the other with CRM 2011.  Once I got the unified connection user interface component working correctly, everything else just fell into place and things were all warm and cozy.

CRM 4.0 and CRM 2011 communicate over very different means so even though you ask for a single set of information from the user, you must appropriately handle the connection specific to the platform on the back-end.  That took a little bit of work to make happen flawlessly every time.

Then Microsoft shipped Dynamics 2013.  Still not a big deal as I could use the CRM 2011 SDK assemblies to communicate without any issue.

Then Microsoft shipped Dynamics 2015 and I started thinking that maybe I need to re-examine my methodology.  And I am quite happy with my solution.

 

Requirements

I need to communicate with Dynamics CRM 2011, 2013, and 2015 while changing the smallest amount of code possible.

I also had to stay with .NET 4.0, since my user interface framework does not support .NET 4.5 and I was not in a position to write the entire UI for a handful of products.

 

Solution

The solution was to upgrade my SDK .NET assemblies to the Dynamics CRM 2013 level. 

That gave me access to all three platforms as long as I kept in mind that I could never ask for something that did not exist on a specific platform. 

Like SLAs or Entitlements from CRM 2011. Since those do not exist until 2013, it would throw an error.

 

Further Thoughts

For some reason, I had never tried connecting to a lower-version environment using the newest SDK assemblies.  Turns out that works just fine. (silly me for never asking the question till a month ago).

If my UI framework was .NET 4.5 compatible, I would have jumped up to the CRM 2015 assemblies because that is what they are written with.

The only side-effect to this is that I am stuck using Visual Studio 2010 because that same UI framework doesn’t work with Visual Studio 2013, my normal environment.

 

Conclusion

This process was quite eye-opening for me and just about as painless as it could be.  The Microsoft SDK team has done a huge amount of really great work that makes our jobs as developers, much less work than it could be, or even once was.

Let me know if you have had similar or even different experiences.

Leave a Reply 0 comments