You are viewing limited content. For full access, please sign in.

Discussion

Discussion

Workflow 11 can not load license or assembly 'LicenseManagerObjects'

Workflow SDK
Updated February 2, 2024
posted on January 3, 2022

I am having trouble loading this assembly in Workflow 11. Was getting this error in version 10 last week and other answers posts seem to indicate it was a problem with limited workarounds in verison 10, I updated to the latest version 11 over the weekend.

I am still getting the below error when trying to reference the LicenseManagerObjects SDK in Workflow

Could not load file or assembly 'LicenseManagerObjects, Version=11.0.2102.0, Culture=neutral, PublicKeyToken=3f98b3eaee6c16a6' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

This is the file that comes with the SDK  located under 

C:\Program Files\Laserfiche\Directory Server\Web\LFDS\bin

Workflow has access to the entire disk, why can't it load the assembly?

0 0
replied on February 1, 2024

Found this thread when I hit the same issue. However my problem is the script complaint about "Newtonsoft.Json.dll ver 11" used with LMO but the workflow directory has an old version which doesn't match. I can't just replace it that may cause other existing module broken.

Oh well, unless the workflow get the same version Newtonsoft.Json as LFDS/LMO module uses.

0 0
replied on February 2, 2024

This is has been addressed in newer versions of Workflow 11. Please patch to the latest version.

0 0
replied on April 14, 2022

Place the library in the workflow folder on the workflow server.

This got it to work for me.

0 0
replied on April 14, 2022

No luck for me, this was one of the very early troubleshooting steps we tried. When referencing a DLL we do reference the location, and in our environment workflow has access to the entire drive.

This issue with neededing to move DLL files to the workflow folder is more specific to environments and has been around for a long time. In some enviornments I have to do this for every DLL I want to refernce.

There are other factors that lead to this error with this specific DLL, but thanks for posting your results.

0 0
replied on April 14, 2022 • Show version history

We may have too simple an environment to be relevant but here is what I have:

  • Library placed in the workflow folder and RegSrv32 registered
  • The Workflow admin console is used to add the workflow directory access under File Browser Options (I did not test if this was really required).
  • The assemblies/libraries were added under Custom Activities and that made them selectable in the browser list when adding them as references.
  • The workflow that contains scripts with references to the library gets its final edit using the designer on the workflow server where all the references are re-created to the workflow server locations (because the process will run on this server).  It is complied on the workflow server.
0 0
replied on April 6, 2022

Thanks Chad.  I am escalating the problem and will post a reply if I get an answer.

0 0
replied on April 6, 2022

Do you know what domain account is associated with the workflow process running a script?

 

0 0
replied on April 6, 2022

The account configured on the Laserfiche Workflow Server serivce, by default it uses Local System

0 0
replied on April 6, 2022

Did you get an answer to this?

I cannot seem to avoid this error as well.

0 0
replied on April 6, 2022

No, and after a month of trying to find someone who could answer this I gave up. The error simply is not specific enough to help me help the machine.

 

All I know is it works on my Windows 10 home edition laptop and throws this error on my Windows Server 2019 box

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...