In this article

Choose your development style for Dynamics 365 Customer Engagement

10/31/2017

6 minutes to read

Contributors

In this article

Applies to Dynamics 365 (online), version 9.x

The SDK offers a variety of methods and technologies to use when you write code to access the Dynamics 365 (online) Customer Engagement web services or to extend the application. This topic provides guidance on the development style to choose depending on your technology area..

.NET vs. non-.NET development

The first thing to consider while writing code to extend Dynamics 365 is whether your code is written using .NET Framework.

If your code is written using the .NET Framework, consider using one of the following depending on what you are creating:

If you are using .NET Framework 4.5.2 or later to write your code, you should use the latest version of the SDK assemblies to create your plug-ins, custom workflow activities, or XAML workflows.

However, if you are using .NET Framework 4 and using the CrmConnection class of SDK extensions (deprecated) to connect to Dynamics CRM 2016 Service Pack 1 On-Premises (on-premises) and CRM Online 2016 Update 1 (version 8.1.0) or later, you will need to use version 6.1.2 of the assemblies. Otherwise, you won't be able to connect. For more information about backward compatibility, see Blog: Dynamics 365 SDK Backwards Compatibility

When using the SDK assemblies to write code, you work with the Organization web service (SOAP endpoint) to connect to an instance of Dynamics 365, and perform the supported web service operations. More information: Use the Dynamics 365 Organization service

Note

The SDK assemblies will eventually be migrated to internally use the Web API instead of the 2011 SOAP endpoint. When this happens, any code written using the SDK assemblies will continue to be supported as it will automatically transfer from the 2011 SOAP endpoint to use the Web API. This update will be fully transparent to you; additional details will be published in future SDK releases. More information: Microsoft Dynamics CRM 2011 endpoint

Create and deploy plug-ins or custom workflow activities: The plug-in and custom workflow activity classes allow you to create event handlers to perform custom business logic that you can integrate with Dynamics 365 to modify or augment the standard behavior of the platform.

If you write plug-ins and custom workflow activities from scratch, you must use the Plug-in Registration Tool to register them. This tool provides a graphical user interface and supports registering plug-ins and custom workflow activities with Dynamics 365. More information: Plug-in Development and Custom Workflow Activities (Workflow Assemblies)

Create and deploy custom XAML workflows: Dynamics 365 on-premises and IFD supports the ability to create custom XAML workflows. Using the Microsoft Visual Studio Workflow Designer, you can create custom XAML workflows, also called declarative workflows, by dragging workflow activities from the toolbox onto the design surface, creating variables, and setting properties of these activities to implement the workflow' functionality. You can use built-in Windows Workflow Foundation activities or the process activities that are specific to Dynamics 365. More information:

Note

The Dynamics 365 (online), version 9.0 release is not available for on-premises deployments.

Early-bound and late-bound programming models for Dynamics 365 entities: When using the SDK assemblies, you can choose between two programming models:

Early bound

Late bound

Use the code generation tool (CrmSvcUtil) to create early-bound entity classes, derived from the Entity class, which you can use to access business data in Dynamics 365. These classes include one class for each entity in your installation, including custom entities. More information: Use the early bound entity classes in code

The Entity class contains the logical name of an entity and a property-bag array of the entityâ€™s attributes. This lets you use late binding so that you can work with types such as custom entities and custom attributes that were not present when your application was compiled. More information: Use the late bound entity class in code

Query data in Dynamics 365: There are three ways in which you can retrieve or query data from Dynamics 365using the SDK assemblies: FetchXML, QueryExpression, and .NET LINQ. More information: Retrieve data with queries using SDK assemblies

.NET Development: Use XRM Tooling assemblies

The XRM tooling assemblies leverage the SDK assembly APIs (Organization service and IDiscoveryService) to provide easy authentication support with fewer lines of code and through Windows PowerShell cmdlets. All the function calls in these classes provide thread-safety for actions performed in Dynamics 365 in a multithreaded environment. XRM tooling provides a common sign-in control with integrated authentication logic and an ability to securely store and reuse the authentication information to provide a consistent and seamless sign-in experience to Dynamics 365 from your Windows client applications. More information: Build windows client applications using the XRM tools

The XRM tooling assemblies are available as NuGet packages; the packages are found under the crmsdk profile. Select any package in the list with "Xrm Tooling" as the name to navigate to the package details page.

Choose how to connect to Dynamics 365

Depending on your development style (.NET vs. non-.NET), you'll choose how your code authenticates users in Dynamics 365. The following table provides you brief information about the authentication model you should consider depending on your development style:

Development Style

Description

.NET: SDK assemblies

The SDK assemblies use Windows Communication Foundation (WCF) technology to establish a communication channel with the Dynamics 365 web services. SDK simplifies use of the WCF technology by providing helper proxy classes that make it easy to write applications that connect to and authenticate with the Dynamics 365 web services.