Well, it has been a while now since the XRM sdk is out and we have been exploring it.
XRM sdk does make programming a lot more easier and most certainly there are a lot fewer lines of code that need to be written.
With the CrmSvUtil tool you can generate the classes for all the custom entities and customizations that you may have added to you CRM system and this allows you to use strongly typed entity classes instead of the use of Dynamic Entities in the earlier version of the SDK. And this then does away with the need to add Web service reference to your applications.
List of customizations supported by the XRM platform.
1. You can develop custom portal applications that run externally and access CRM data.
2. You can develop custom pages that are called from sitemap and ISV from within CRM. For this you need to copy the following files to GAC
Microsoft.Xrm.Client
Microsoft.Xrm.Portal
Microsoft.Xrm.Portal.Files
Once these files are copied in GAC, your custom pages work just as usual.
3. Support for IFD – In case of pages that were designed to be accessible through CRM IFD access as well, it was earlier required to have the CRM connection created in the context of the impersonator.
Code blocks in this case were executed within the context of “using cmimpersonator()”. The same can be applied for code written using the XRM SDK and these are then available for use in the IFD environment as well.
4. You can use XRM SDK to write code within Workflows as well. The XRMDataContext accepts IWorkflow plugin context as a parameter for establishing CRM connection.
5. However, for reasons knows to MS alone, support for XRM code to be used with plugins has not been provided. This delays the acceptance of XRM sdk as the tool for CRM development.
6. XRM SDK is basically a kind of data layer access to CRM and hence it only provides functionality related to data access such as Create/Update/Delete/Read. It does not support MetaData Service messages.
7. Though it does provide LINQ functionality to read/retrieve data from CRM, it does not match the capabilities provided by the traditional sdk message to retrieve data. We particularly found an issue when reading the display names of lookups or picklist type of attributes that was easily accessible in earlier versions of the SDK.
Given that reading data is an integral part of CRM development I would really appreciate discussion with regards to the above issues noticed.
All said and done… XRM is a great step towards simplifying development, though further improvements might help a great deal. Perhaps it could be our limited understanding of the XRM sdk that might have us believe so. I would like to open the XRM sdk for discussion through this blog for the benefit of the entire community.
We use http://www.xrmlinq.com - it doesn't have the limitations you list.
ReplyDeleteHowever that appears to be a paid SDK... MS has already taken the step to include it in its SDK... shouldnt be long before they fill in the gaps...
ReplyDeleteI prefer the XrmLinq provider as well because it doesn't have the issues you mention above. However, both of these Linq providers are still weak IMHO because they are dependent on the old SDK (QueryExpression or FetchXml). Why Microsoft won't bite the bullet and build a true Linq to CRM provider from the ground up is something I can't figure out. Many of the Linq operators are currently not implemented because of this shortcoming. (Sum, Average, NotIn, certain joins, certain groupings, Any, Complex Where functions, etc.). Also the performance on the current Linq implementation is abysmal. From what I've read, 2011 still has many of these limitations.
ReplyDelete