.NET errors encountered when using Workflow module in Microsoft Dynamics GP

Hello Dynamics GP Community!

The Workflow 2.0 feature in Microsoft Dynamics GP has relied on CLR assemblies stored in SQL Server since it was introduced in GP 2015.  These assemblies are used to make calls to Active Directory and drive the email notification functionality in Workflow.  I'm sure several of you have experienced an error like the following if you have been a Workflow user or someone who supports the module:

[Microsoft][SQL Server Native Client 11.0][SQL Server]A .NET Framework error occurred during execution of user-defined routine or aggregate 'GetAssignedUsers'. System.IO.FileLoadException: Could not load file or assembly 'System.DirectoryServices, Vers

We've recently become aware of a .NET Framework patch that is automatically being installed on several different OS versions that appears to be causing the above error to occur in Dynamics GP.  One example of this is the following patch for Windows Server 2019:

2022-05 Cumulative Update for .NET Framework 3.5, 4.7.2 and 4.8 for Windows Server 2019 for x64 (KB5013868)

Because of this we wanted to make sure we have something published to address the issue as we are seeing an uptick in reports of this type of error.

The recommended solution for this, or any similar .NET error encountered while submitting, approving, rejecting or otherwise acting on a Workflow task is to redeploy these CLR assemblies.  To accomplish this you simply need to:

1) Open SQL Server Management Studio and connect to your Dynamics GP instance

2) Open a new query window for the System (e.g. DYNAMICS) database

3) Run the following to execute the necessary stored procedure:

exec wfDeployCLRAssemblies

You can do this while other users are in Dynamics GP, but if anyone is attempting to act on a Workflow task while this is running they may experience other issues.  When this successfully executes the Results pane in SSMS will return several lines of text.  You can then test Workflow again and you should see better results.  

Often times it is not clear what caused these assemblies to suddenly become in a bad state, so preventing it from happening can be difficult.  We do have customers who schedule this stored procedure to execute on a regular basis to prevent the error from happening.

As always, let us know if you have any questions or feedback!