.NET Framework errors with Workflow 2.0

Hello all!

We have seen and worked through a handful of .NET errors received when working with the new Workflow 2.0 feature. Some of these errors can occur during an upgrade to GP 2015 from a previous version, since part of the upgrade process is to put various DLL’s into SQL as CLR assemblies, and some are received during troubleshooting this. The others are received upon the submission of a workflow.

A .NET Framework error occurred during execution of user-defined routine or aggregate "GetAssignedUsers": System.ArgumentNullException: Value cannot be Null

The most common culprit for the “Value cannot be null” error is that the Manager field is blank on the workflow setup. The Manager is set per Workflow type. If the manager field is populated, but the NULL error is still occurring, check a SQL trace and/or the Workflow logs to determine exactly what value is being passed as null.

CREATE ASSEMBLY for assembly 'System.IdentityModel' failed because assembly 'System.IdentityModel' failed verification

This error occurs usually during an upgrade, or during the running of the wfDeployCLRAssemblies stored procedure. The error is stating that the SQL server can’t load the System.IdentityModel DLL from Windows as an assembly in SQL. https://social.msdn.microsoft.com/Forums/sqlserver/en-US/d4001fe4-98ab-446b-bef7-1b62ea104c47/sql-server-2012-error-when-creating-assembly-from-systemidentitymodeldll?forum=sqlnetfx

 The resolution is a hotfix for .NET:

http://support.microsoft.com/kb/2742595

If the hotfix doesn’t resolve the issue, you’ll need to repair .NET on the server.

 Method 1: Run the .NET Framework Cleanup Tool.

http://blogs.msdn.com/b/astebner/archive/2008/08/28/8904493.aspx

Method 2 : Repair the .NET Framework.
http://support.microsoft.com/kb/976982

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

The resolution for this error is to run the following statement in SQL Management Studio:

exec wfDeployCLRAssemblies

Chances are, you have copied the databases from another SQL instance, likely the SQL instance where the upgrade was performed and the assemblies were first inserted into SQL. Anytime you move your databases, you have to run this statement in order to refresh the assemblies.

 This statement SHOULD return the following results:

(1 row(s) affected)

Configuration option 'clr enabled' changed from 1 to 1. Run the RECONFIGURE statement to install.

Warning: The Microsoft .NET Framework assembly 'system.directoryservices, version=4.0.0.0, culture=neutral, publickeytoken=b03f5f7f11d50a3a, processorarchitecture=msil.' you are registering is not fully tested in the SQL Server hosted environment and is not supported. In the future, if you upgrade or service this assembly or the .NET Framework, your CLR integration routine may stop working. Please refer SQL Server Books Online for more details.

(This warning statement repeats for each other assembly and dependancy)

If you get any red text, then you’ll have to manually drop all the objects related to the wfDeployCLRAssemblies proc. Here is a list of the assemblies, procs, and functions that are created by running the wfDeployCLRAssemblies proc:

Procedures:

GetAssignedUsers

SendWorkflowAssignmentEmail

SendWorkflowCompletionEmail

Functions:

IsValidUserByObjectGuid

IsValidUserByUser

GetUserByObjectGuid

GetObjectGuidByUser

TestEmail

Assemblies:

Microsoft.Dynamics.GP.WorkflowGP.WorkflowEngine

Microsoft.IdentityModel.Clients.ActiveDirectory

Microsoft.Azure.ActiveDirectory.GraphClient

Newtonsoft.Json

System.Web

System.IdentityModel

System.Runtime.Serialization

System.DirectoryServices

An error occurred in the Microsoft .NET Framework while trying to load assembly id 65536. The server may be running out of resources, or the assembly may not be trusted with PERMISSION_SET = EXTERNAL_ACCESS or UNSAFE. Run the query again, or check documentation to see how to solve the assembly trust issues. For more information about this error:
System.IO.FileLoadException: Could not load file or assembly 'AssemblyName, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.

This error is documented in the following KB, and the issue is that the login you used to create the database on the old server doesn’t exist on the new server.

https://support.microsoft.com/en-us/kb/918040

We have also seen this error resolved with a reboot of the 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, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Assembly in host store has a different signature than assembly in GAC. (Exception from HRESULT: 0x80131050) See Microsoft Knowledge Base article 949080 for more information.

An update to .NET on the SQL server can cause this issue. Try uninstalling KB2901982 if it is installed, then reboot the server.

Msg 6517, Level 16, State 1, Line 1

Failed to create AppDomain "master.dbo[ddl].2".

Could not load file or assembly 'System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. Not enough storage is available to process this command. (Exception from HRESULT: 0x80070008)

This issue is also usually resolved with a reboot of the SQL Server. Autogrowth or SQL storage settings can cause this, as well as low-memory scenarios that may occur on the SQL server. Make sure you have an upper limit set for the SQL instance and that there's enough RAM to process everything else running on the server.

DROP ASSEMBLY failed because the specified assemblies are referenced by assembly 'System.Runtime.Remoting'.

We’ve see this error come up if the customer has previously or currently uses Nodus, which shares a few .NET assemblies with GP. The core shared assemblies are .NET DLL’s pulled from the local GAC of the SQL server. You can usually just drop the assembly and dependent assemblies, and allow GP to re-add the .NET assemblies on behalf of Nodus.