Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, PowerApps, Microsoft Flow, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates to Dynamics 365Release overview guides and videos Release Plan | Early Access Availability
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Talent TechTalks
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:
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.
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:
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=184.108.40.206, 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:
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.
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=220.127.116.11, 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=18.104.22.168, 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.
If anyone receives this error message when approving: "[Microsoft][SQL Server Native Client 11.0][SQL Server]A .NET Framework error occurred during execution of user-defined routine or aggregate "SendWorkflowAssignmentEmail": System.NullReference Exception: Object reference not set to an instance of an object"
Check to see if doc attach is enabled for the company. I don't know exactly what that stored procedure does since it's encrypted or if there are other potential issues from this message, but enabling doc attach for the company resolved my problem after I did some digging while tracing the process.
Just a suggestion for some more error handling :) Object reference errors are the worst.
Sheri - Did you get this resolved? I just wen through again last night. In the past it was fine because we didn't have Workflow installed so removing the System.Remoting assembly was straight forward. With Workflow installed many more dependencies needed to be removed first. Almost all were restored by running EXEC wfDeployCLRAssemblies against the Dynamics database. Here's a link I found helpful listing all the related assemblies and stored procs.
We have the .net assembly issue on a system that is running GP2015R2 with Nodus on it. It looks like a windows .net update damaged the Nodus encryption last week . Nodus can't reload their code onto this system without dropping the dependent assemblies. This system does not use and will never use workflow. In your last thread you said that "you can usually" drop the 'System.Runtime.Remoting' dependent assemblies. It sounds like you think it’s fairly safe to drop those? Thank you
Hi Dan! Nice meeting you at GPUG this year. I just had a client run into this issue. She had created a new server for "testing" GP and copied everything over, I helped her run all the migration scripts and stuff. However, the transfer GP to a new server document doesn't talk about running the deployclrassemblies so should I add this to my standard operating procedure whenever creating a GP "test" server, or doing a server migration (not upgrade)?
Business Applications communities