New CRM SDK, New Developer Experience

Our guest blogger is Microsoft .NET MVP and Regional Director David Yack who is the author of a number of books including the very popular CRM as a Rapid Development Platform. David blogs at

Yesterday, Microsoft released CRM SDK 4.0.12  - before you just download it and think its just another minor update – read on. This update includes what is being referred to as Advanced Developer Extensions.  Before you stop reading saying “I’m not advanced” – “Advanced” I believe is marketing’s way of saying this builds on top of the strong foundation that CRM already provided – not that you need to be a “Super Advanced” developer to use it. 

In reality, it’s advanced because it’s going to simplify how you interact with the CRM data.  More specifically, it will allow you to use the LINQ expression syntax that developers have been using since C#3/VB9 to build queries.  Additionally, this introduces the idea of using the normal .NET data types instead of the CRM specific ones e.g CRMBoolean.  In the past, CRM had specific types for CRM Boolean because at the time .NET didn’t support nullable types.

There are other good things in the new SDK that I will try to cover in future blog posts – but wanted to make sure people didn’t gloss over this new feature. 

Dave’s 10 Minute Quick Start Walkthrough - (SDK download times excluded of course, I can’t help if you have a slow connection!)

1 – Download the updated CRM SDK

2 – Create a new console application in Visual Studio 2008 or 2010 – choose .NET 3.5 as your framework

3 – Create a folder in the new project called Entities – Right click Open Folder in Browser as you can see below


4 – Copy the path name from Windows Explorer – you will need it to provide to the CrmSVCUtil program so it can use it to create the generated classes


5 – From a command line – go to the SDK folder/Microsoft.xrm/Tools and run the following command line – replacing MyCrmServer with your actual server name, replace MyCrmOrg with your actual CRM Org and MyEntitiesFolder with the name you copied in step 4.  Note : This assumes using integrated authentication for on-premise – support is available for many different scenarios – check the docs.

crmsvcutil /server:http://MyCrmServer/MyCrmOrg /out:MyEntitiesFolder

This utility will access the server metadata and build classes for each of the entities and place them in your project folder.

6 – Right click – Add Existing Item on the entities folder, Make sure the browse dialog is in the Entities folder and select all the files and click OK


7 – Add references to the CRM SDK assemblies – using Add Reference – Browse and choosing the following


8 – Add references to the Xrm assemblies from the SDK/Microsoft.xrm/bin folder as you see in the following


9 – Add references to the following .NET assemblies

  • System.Data.Services
  • System.Data.Services.Client

10 – Build your application you should get a clean build at this point – before we add more code

11- Open the app.config file and add the following connection string section.  Modify the server name to match your server name, and the org name to match your org name  - if you don’t have an app.config – just add one via add-new items:

   <add name="mycrm" connectionString="Authentication Type=Integrated;

12 –  In the Program.cs file - Add a Using statement for your entities as you can see below:

using Entities;

13 – The new API uses a concept of a Data Context – you can think of this as the gateway to working with the CRM data – In the Main method add the following – which creates an instance and references the connection string we added to the app.config:

DataContext ctx = new DataContext("mycrm");

14 – Use LINQ to compose a query of accounts.  The following defines the query but does not execute it – with LINQ expressions they get executed when used as we will see later.  The following builds a query looking for all accounts that have an “a” in the name.

var query = from acct in ctx.accounts
                        select acct;

15 – Loop though each of the accounts and print the name – This will cause the actual execution of the query against CRM – Also notice that we can use strongly typed properties no guessing the names of magic strings:

foreach (var acct in query)
                Console.WriteLine("Account Name :" +;

17 – Run the application you should get a list of accounts

18 – See how easy it is to add ordering to a query – add the following to the LINQ query between the Where and the Select



19 – Run the application again to see names sorted

20 – Let’s add a record – Adding a record is also very easy – First create an instance of the account object and set the minimum – This uses the account class that was generated by CrmSvcUtil earlier:

var newAccount = new account(); = "test account";

21 – Add the record to the Data Context – This step advises the context about the new record – but it doesn’t cause the create to happen on the server yet. This means we can do multiple adds / updates and then send them to the server when ready.


22 – Call the SaveChanges method on the context to cause the records to be created on the CRM server:


Note : This will really add a record to your server – you have been warned!

Updating is just as easy – modify a record you retrieved from a query and then call UpdateObject(account) to notify the Data Context of the changes.  And of course DeleteObject(account) will make that account vanish for ever –a great way to get rid of pesky accounts :)  Like Add, Update and Delete do not get sent to the server until SaveChanges is called.


David Yack

Comments (11)

  1. Aaron G says:

    I am really excited about being able to use the LINQ syntax. However, I cannot figure out how to convert the code I have for QueryScheduleRequest & Response (see below) to LINQ.  Could you provide any insight?

    var request1 = new QueryScheduleRequest


                   Start = new CrmDateTime { Value = dueDate.ToString() },

                   End = new CrmDateTime


                       Value = dueDate.AddHours(availableDays).ToString()


                   ResourceId = userId,

                   TimeCodes = new[] { TimeCode.Available }


               TimeInfo[] time1 = ((QueryScheduleResponse)_myService.Execute(request1)).TimeInfos;

  2. gkellett says:

    Looks great!

    Does this pick up custom entities and attributes or does it only work on the main CRM entities?



  3. Gary, the crmsvcutil.exe will easily build custom entities and customizable entities as well as the standard out of the box entities.

  4. I love the xRM piece. And Dave Yack’s article is great gentle introduction. Many of us in the development community had already developed something equivalent a long time ago. The xRM implementation seems nicely done and I hope we can begin to transition to it instead of our custom classes.  

    But I got alarmed when I saw the documentation on "Using the Web Services within a Custom Workflow Activity" where it says "It is strongly recommended that all custom workflow activities should retrieve, create, update, or delete data in Microsoft Dynamics CRM 4.0 using the DynamicEntity class. By using DynamicEntity, your code will work with out-of-the-box entity and attribute definitions and with any customizations you have made to entities or attributes. "

    Well, does this mean we cannot use the new xRM DTOs and DataContext classes when coding in a custom workflow situation? I guess we could use the DTOs. But would we need to make a replacement for the DataContext class and its methods that take an ICrm service? The beauty of our homemade strongly typed classes is that we have ONE shared set of classes we use whether we are coding custom workflows, custom web pages, or batch data load console applications.  They can use the workflow context or plugin context or get their own context.

    I’m really looking for a programming model whereby we use the same techniques for coding against CRM regardless of whether it is inside the workflow context or not.  Is the workflow programming model an exception to the nice, new xRM model or am I missing something?

  5. ChrisS says:

    The examples are working nicely.  How "realistic" is it to develop with these strongly-typed objects in a CRM deployment that changes frequently?

    Seems like the generated entities are using Dynamic entities (get/set props) under the covers, so as long as CRM attributes are not removed or type-changed (backward compatibility is not broken) then I can safely uses the generated classes?



  6. silverfz says:

    how do you make this work in ?

    I created a DLL in c# and added to site. the linq is not working and added layer is causing some error which is not being displayed.

  7. dkallen, chriss:

    Related to the new xRM and how it works with dynamic entities.  The library exclusively uses dynamic entities internally, and it exposed both static (ie: code-genned) and dynamic mechanisms that you can use.  I can speak as an ISV already using it, that we exclusively use the dynamic methods in the new SDK so that our ISV libraries can work on any customer implementation without us (the ISV) having to be aware of these customizations.  

    Here is a page with some documentation that will show you how this can be done:

  8. Dirceo Noe Bravo. says:


    I need a team of experts, Microsoft Dynamics CRM 4.0, for a major project with a leading microprocessor company.

    Please Contact.


  9. Erik says:

    Is there any chance the new Advanced Developer Extensions will ever work in a Silverlight project?

  10. Ameed says:

    Hello folks,

    Does any of you needed to query metadata using this xrm sdk. It has been quite useful though with some problems of caching which we managed to get around with. However, just now i have found a need to fetch some metadata and i am amazed to see that there is no support for this. Neither in xrmlinq api. May be i am wrong, but i doubt so.

  11. John says:

    Where did you get "AddToaccounts" method? I see only "AddObject".

Skip to main content