Choose your development style for Dynamics 365 Customer Engagement

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.

.NET Development: Use SDK assemblies

The SDK assemblies provides you with classes that you can use to connect to Dynamics 365 web services to identify your organization and perform common business operations like create, retrieve. update and delete data in Dynamics 365. The SDK assemblies are available as NuGet packages. More information: Subscribe to SDK assembly updates using NuGet and Assemblies included in the Dynamics 365 SDK.

Important

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: FeatchXML, 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.

With the connection string support available in XRM tooling and the deprecation of SDK extensions for Dynamics 365, you must use the XRM tooling assemblies instead of the CrmConnection class to connect to Dynamics 365. More information: Use connection strings in XRM tooling to connect to Dynamics 365 and Sample: Simplified connection quick start using Dynamics 365

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.

More information: Use the sample and helper code, Helper code: ServerConnection class
.NET: XRM tooling assemblies Use the connection string, CrmServiceClient class, or XRM tooling PowerShell cmdlets to connect to Dynamics 365.

More information: Use connection strings in XRM tooling to connect to Dynamics 365, Use CrmServiceClient constructors to connect to Dynamics 365, Use PowerShell cmdlets for XRM tooling to connect to Dynamics 365
Dynamics 365 Web API More information: Authenticate to Dynamics 365 with the Web API

For detailed information about authenticating users to connect to Dynamics 365, see Authenticate users in Dynamics 365

See also

Authenticate users in Dynamics 365
Tutorials for Learning About Development for Dynamics 365
Write Code for Dynamics 365 2011 and Dynamics 365 (online) (Web Services, JavaScript)
Introduction to Programming Models for Dynamics 365 Customer Engagement