Opinion: CRM SDK or URL web reference RRS feed

  • Question

  • I've engaged into a friendly debate about using the CRM SDK vs. URL web reference and thought I'd get the opinion of the CRM community here. I've looked online for people's opinion (e.g. Shan's blogpost) about this but was still wondering about pros vs. cons.

    For example, I've create a custom web service by adding a web reference such as: http://crm4:5555/MSCRMServices/2007/AD/CrmDiscoveryService.asmx?WSDL
    By doing this all I have to do is update the web reference and I can get all the custom attributes.
    For example:

    account act = new account()
    act.new_attribute = "this is a custom string attribute";


    Now...my friend says that it is better to use the CRM.SDK reference. He claims that it can also easily update any new custom attributes added in CRM.  I've never done it this way so I'm not sure if this is possible.

    Opinions of what is the better way of referencing the CrmService?

    Friday, October 2, 2009 6:26 AM


All replies

  • Personnaly, I prefer using Sdk because, I'm sure to be able to use my developments with IFD and OnPremise without moving any parts of my code.

    MoreOver, using sdk provides unique method of coding between webapp, plugins and worlklow activities.

    Of course, using Sdk, you need to use DynamicEntity each time you access custom entity or attribute but you really facilitates your life regarding multiple CRM environment possibilities...

    That's my opinion! :)
    My blog : http://mscrmtools.blogspot.com You will find: Form Javascript Manager (export/import javascript from forms) ISV.Config Manager (graphical ISV.config edition - export/import) View Layout replicator (customize one view and replicate to others) And others (use tool tag on my blog)
    Friday, October 2, 2009 6:48 AM
  • I totally agree with Tanguy.

    By using the sdk assemblies, you will be more flexible in developing custom frameworks which can be used on any crm system, despite of the deployed customizations.
    However, you have to use DynamicEntities for any custom entities, attributes, etc. But in my opinion, this is not really a disadvantage.
    Friday, October 2, 2009 7:26 AM
  • Hi Ckeller and Tanguy,

    As you know I'm still relatively new at this and haven't done as much. Translation: need to read up more and understand dynamic entities and custom attributes. So i throw out this question. I could have sworn doing some reading that i could also URL reference the CRM discovery service.  and therefore all references (e.g. crmservice, crm meta service and now crm discovery service) and all web references and can be easily updated. Because i can reference CRM discovery, wouldn't that give me the ability to also connect to IFD environments?

    Thanks for taking the time to answer.

    Friday, October 2, 2009 1:02 PM
  • Since CRM is build by the way it is build, you are almost forced to work with the SDK whenever you are developing a full scale solution for a CRM enviroment (CrmService does not implement ICrmService? are you insane?)

    However, if you are working on an ad-hoc solution, it is better to use web service, for serveral reasons, and main reason is that I rather using:




    when i can. Property bags are fine, but if i can access actual properties, its better.

    Think of a scenario where someone deletes an attribute you are accessing. With dynamic entity, you won't know that until your code starts throwing exceptions on you. When using web reference, a simple "update web referene" will make you application not compile anymore.

    There are several more reasons (don't let me even start about DynamicEntities' propertycollection misbehaviours), but that should do.

    Friday, October 2, 2009 10:02 PM
  • Hi,


    The main purpose of the Discovery Service is the resolution of connection details for a specific crm organization. In a small crm deployment you often now the exact web service endpoints (for the crm service, the metadata service, web application url, ...), but if you think of a larger scale deployment you cannot assume that all services are running on the same box.
    In a larger deployment (hosting for example) it is likely that you split the web application role from the web services, because of performance improvements. If you use the Discovery Service for retrieving the endpoints of the services, you don't have to worry about that because the crm deployment will provide you this information.
    In addition, if you connect to an internet facing deployment (IFD) you have to use the Discovery Service in order to get a CrmTicket which is required for accessing the services. 


    For this reason you should check wether the attribute which you would like to access is available. If you use a web service reference and forget to update it, you will have the same problem.
    Sunday, October 4, 2009 2:36 PM
  • @Moti

    For this reason you should check wether the attribute which you would like to access is available. If you use a web service reference and forget to update it, you will have the same problem.

    It's true that if you forget to update the web reference you face the same problem in production, but that is not the point.

    Basically, it is simply matter of:

    • Using  SDK - fail in integration test.
    • Use web service - fail in compilation.

    What you described is merely protective coding when using dynamic entity.
    Monday, October 5, 2009 8:55 AM
  • Hi @all,

    see this new article in the sdk http://msdn.microsoft.com/en-us/library/ee704593.aspx
    • Marked as answer by GreenWasabi Tuesday, November 3, 2009 3:07 PM
    Tuesday, November 3, 2009 2:03 PM
  • Hey ckeller,

    Thanks for the link. 
    This is something I think everyone has an opinion on.  So it's good to know that there is an "official" article from microsoft.
    Tuesday, November 3, 2009 3:07 PM