Apple macOS and Dataverse Plugins

We've probably come to the topic that sooner or later every developer working with the old .NET Framework wonders: does it work on Mac?

As we saw in the previous posts the recent .NET versions are cross-platform and they work on Mac (like the one I have that is ARM based) but older .NET Framework versions (4.x) are meant to run on Windows.

Dataverse Plugins still require .NET Framework 4.6.2 (as stated in the tutorial), so what are our options?

Let's separate in three main topics:

• Write the Plugin
• Build the Plugin
• Register the Plugin

Writing the Plugin is not an issue, technically we can use just a simple text editor to write the code but we have Visual Studio Code. In addition if we install the Microsoft Power Platform CLI (as we did for PCF development) we have a command to create a Plugin project:

pac plugin init

This command is very important for one reason, it creates the .snk file (signing file), as far as I know it's not possible to create the signing file inside Visual Studio Code as a standalone action.

After we can open the project folder we see a familiar structure:

This wireframe contains a PluginBase.cs file, for my tests I prefer to have a simpler structure, so I create my plugin classes implementing just the IPlugin interface.

Sample code:

using Microsoft.Xrm.Sdk;

using System;

namespace MacPlugins

{

public class Example1 : IPlugin

{

public void Execute(IServiceProvider serviceProvider)

{

IPluginExecutionContext context =

(IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));

Entity currentEntity = null;

if (context.InputParameters.Contains("Target")

&& context.InputParameters["Target"] is Entity)

{

currentEntity = (Entity)context.InputParameters["Target"];

if (currentEntity != null &&

currentEntity.LogicalName != "account") { return; }

}

if (currentEntity == null) { return; }

string name = currentEntity.GetAttributeValue<string>("name");

currentEntity["name"] = $"{name} - UPDATED BY PLUGIN Example1";

}

}

}

We will register this plugin on the Create message of Account Pre-Operation, it will change the name to confirm the plugin is working.

We now have the project, how we build it?

Over the last few days I've been thinking about how to do this: virtual machine, creating something on Azure, etc etc.

Let's try first the simple approach: build it inside Visual Studio Code. I ran the command

dotnet build

and under the folder "bin/Debug/net462/publish" a dll file was created.

Ok, it compiled, but this dll is ok to be registered?

Let me be crystal clear: I will never register a plugin using the pac plugin push command, I wrote plugins and registered them using Plugin Registration Tool for over a decade, I know that on Mac I can't have the same experience as Windows but at least should be comparable, not a complete downgrade.

So I started the virtual machine (check the first post if you need to setup it), opened XrmToolBox and launched the Plugin Registration Tool. I selected the dll generated by Visual Studio Code on Mac and it worked, I was able to register it. I quickly added the step, I created an account and the plugin worked!

This result opens new questions:

• How can I debug a Plugin?
• How can I generate Early Bound classes?
• What about Plugin Packages and Managed Identity Plugins?

Let me explain how I usually work: I rarely debug plugins (I tend to keep them short and I prefer to write a small console application with the logic and debug the console application instead of debugging the plugin directly) and I prefer to use late bound (sometimes I use the tool Latebound Constants Generator) instead early bound (sorry Daryl!).

If I have time I can explore these topics but they are not my priority.

The setup (building the plugin on Mac and registering them using Windows) works but it's not ideal.

What will solve this situation? Simple: a cross-platform version of the Plugin Registration Tool.

It does not exist today but I hope it will exist in the future ("in the fullness of time"?).

If you are familiar with Mac/Linux you may be aware of a software called WineHQ, I wanted to test if it can run the Microsoft Plugin Registration Tool or XrmToolBox itself. Sadly they do not, but was interesting and I discovered some insights.

First of all I tried the Microsoft Plugin Registration Tool, I downloaded the NuGet package, renamed it to a zip file and extracted the content. Tried to launch it with WineHQ and it doesn't load, patience.

After I copied the XrmToolBox folder from the virtual machine to Mac and launched it with WineHQ, it opens but it returns often a GDI+ error, plus it's not able to connect to Dataverse environments:

Note: if you download the zip folder from the site and launch it directly on WineHQ it doesn't work, so a copy of an already launched Windows folder is required, plus you will need to copy the content of the AppData folder inside a specific .wine folder.

The main issue for me is the connection to Dataverse, a Windows Forms application connecting to Dataverse can actually works with WineHQ?

I switched to Visual Studio 2022 on my Windows machine and I quickly created a Windows Forms application to connect with OAuth or with Client Id/Client Secret.

My first test was with .NET Framework 4.8.1 and the .NET 4.x CRM SDK, under WineHQ it's not able to connect.

My second test was with .NET Framework 4.8.1 and the Dataverse SDK, under WineHQ it's not able to connect.

My third test was with .NET 8 and the Dataverse SDK, WineHQ advised me I need to install .NET first (so I downloaded the runtime and launched it with WineHQ) and this time it worked:

So theoretically it's possible to build a version of XrmToolBox compatible with WineHQ, however this doesn't mean all the tools will work automatically without problems, it will depend on how the tool is written or if it uses some libraries not compatible with WineHQ.

I really hope Microsoft will build a Plugin Registration Tool that I can launch on a Mac because it's possible to do it.

Why I don't do it by myself? Because I know it takes time and honestly we cannot always ask the community to build something and maintain it. The developers behind the Plugin Registration Tool for XrmToolBox are already doing an amazing job for having such important tool inside XrmToolBox.