Writing Dynamics C# Console App With Only Two Dependent Packages

Writing Dynamics 365 C# code can unlocks many possibilities within the platform. Writing C# code that can be used to update data in Dynamics (Dataverse). It helps with integration scenarios like connecting external systems with Dynamics. One of the challenges we usually face is the dependency on the .NET version that Dynamics uses. Currently, .NET 4.6.2 is required and there are many dependencies. These dependencies can cause problems in large projects. Even for simple C# application, the list of dependencies is very large. What’s worse, one of the dependencies Microsoft.IdentityModel.Clients.ActiveDirectory is deprecated.

How do we get around so many dependent packages? What if we want to run our code under a newer .NET version like 6.0 or .net core 3.1? The good news is that we now have a great solution called Dataverse Client. The code is available on: GitHub PowerPlatform DataverseServiceClient

What’s really nice is that there are only two dependencies to run a simple console application:

DataverseCRUD.cs

Here is a sample CRUD program that connects to Dynamics 365, then create an account, read the account, update it and then delete it.

using System;
using Microsoft.PowerPlatform.Dataverse.Client;
using Microsoft.Xrm.Sdk;
using Microsoft.Xrm.Sdk.Query;
using Microsoft.Extensions.Configuration;

namespace DataverseClientCRUD
{
    class Program
    {
        static void Main(string[] args)
        {
            var builder = new ConfigurationBuilder()
                     .AddJsonFile("appsettings.json", true, true);
            IConfiguration config = builder.Build();
            string connectionString = config["ConnectionStrings:MyCRMServer"];
            using var serviceClient = new ServiceClient(connectionString);

            CRUD(serviceClient);
        }

        private static void CRUD(ServiceClient serviceClient)
        {
            //Create
            Console.WriteLine("**** Create ****");
            Entity account = new Entity("account");
            account["name"] = "ABC Corporation";
            account.Id = serviceClient.Create(account);

            //Read
            Console.WriteLine("**** Read ****");
            Entity readAccount = serviceClient.Retrieve(
                entityName: account.LogicalName,
                id: account.Id,
                columnSet: new ColumnSet("name")
            );
            Console.WriteLine("Retrieved account name: {0}", readAccount["name"]);

            //Update
            Console.WriteLine("**** Update ****");
            account["name"] = "ABC Corp";
            serviceClient.Update(account);

            //Delete
            Console.WriteLine("**** Delete ****");
            serviceClient.Delete(account.LogicalName, account.Id);
            serviceClient.Dispose();
        }
    }
}

appsettings.json

Create an appsettings.json file in Visual Studio and set the file to copy to output directory:

 

{
  "ConnectionStrings": {
    "MyCRMServer": "AuthType=ClientSecret;Url=https://XXXX.crm.dynamics.com;ClientId=XXXX;ClientSecret=XXXX"
  }
}

A big thanks to Marius Pothmann for his blog post: Access Dataverse Web API from .NET Core with Microsoft.PowerPlatform.Dataverse.Client

Dynamics 365 Interactive Dashboard Showing Inaccurate Data

Interactive Dashboards in Dynamics 365 are very useful and provide business insights into the data. Recently I ran into an issue where the chart counts didn’t match the stream counts. The dashboard showed the correct data on the development server, however the production server was not showing the correct chart counts compared to the stream (Grid on the left side). To be clear, the stream did show the correct counts, however the individual chart components did not.

Creating a new interactive dashboard fixed the problem, however I had end-users creating customized filters and I didn’t want to have to train them on how to recreate the filters. 

I decided to create a new solution with just the dashboard component and compare the solutions between the development copy and production copy. My handy Notepad++ compare utility showed me what’s different. Somehow during the deployment to production, the default view was pointing to a different GUID. I repackaged the solution and deployed to production and it started working again. Hopefully this will help others.