CRM 2016 Onpremise plugin or custom workflow - Docusign

1
votes

I have created CRM 2016 on-premise custom worklow and referenced DocuSign.eSign dll.

I used ILMerge to merge DocuSign.eSign.dll and deployed via plugin registration tool

Isolation Mode = sandbox assembly location = database

I get following error when i run the custom workflow, Let me if anyone has integrated DocuSign.eSign within CRM 2016 on-premise custom worklow or plugin

Could not load file or assembly 'DocuSign.eSign, Version=4.3.0.0, Culture=neutral, PublicKeyToken=7fca6fcbbc219ede' or one of its dependencies. The system cannot find the file specified. An Error occured in the workflow: Microsoft.Xrm.Sdk.InvalidPluginExecutionException: CreateEntityEmailAttachmentDocuSign() issue - Could not load file or assembly 'DocuSign.eSign, Version=4.3.0.0, Culture=neutral, PublicKeyToken=7fca6fcbbc219ede' or one of its dependencies. The system cannot find the file specified.

2
c#dynamics-crmdocusignapi
I think you have to register isolation mode as none. Try that, btw ilmerge is unsupported in dynamics crm. - AnkUser
this dll depends on a few other dlls. You will need to get them loaded too. the details are in here - nuget.org/packages/DocuSign.eSign.dll - Inbar Gazit

2 Answers

0
votes

This DLL depends on other DLLs, they may depends on yet other DLLs. I can give you the first list of dependencies, but to get the full list you can create a simple console app and check which DLLs are being imported. Here is the list of direct dependencies:

Microsoft.CSharp (>= 4.5.0)

Microsoft.IdentityModel.Protocols (>= 5.4.0)

Newtonsoft.Json (>= 11.0.2)

RestSharp (>= 106.3.1)

System.ComponentModel.Annotations (>= 4.5.0)

System.IdentityModel.Tokens.Jwt (>= 5.4.0)

I would also suggest you look into using Microsoft FLOW and its connector to DocuSign (or you can build your own) as this can serve as a middle layer and save you all the work of merging the DLLs.

0
votes

Merging a lot of of DLL's into a plugin is unsupported, and arguably an abuse of the D365 plugin model.

Instead, you might want to consider "escaping the sandbox" by hosting the app that does your DocuSign stuff in Azure and creating an Azure-aware plugin.

The basic idea is that when your plugin fires it sends its context to a listener in Azure (of which there are many possible architectures). The listener processes the context, which in your case would mean running the custom DocuSign logic on the record(s) in question.

If a connection back to D365 is available (e.g. IFD) it could update D365 accordingly, but if you're strictly on-premise, you might have to make the workflow wait a while (e.g. 90 seconds) and then call back to the Azure app to get its result.

More info here and here