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

Question

Question

"Assuming assembly reference" error in Workflow SDK Script

asked on October 20, 2022

Hi all,

We're on Laserfiche Workflow 11.  In the designer, I've got an SDK script that is generating the following warning.  It still compiles and runs, but does anybody know how to get rid of this?

Warning    1    Assuming assembly reference 'Laserfiche.RepositoryAccess, Version=10.4.0.0, Culture=neutral, PublicKeyToken=3f98b3eaee6c16a6' matches 'Laserfiche.RepositoryAccess, Version=11.0.0.0, Culture=neutral, PublicKeyToken=3f98b3eaee6c16a6', you may need to supply runtime policy

 

Eric

 

 

0 0

Replies

replied on October 20, 2022

Was this copied from an older workflow? Does it says RAScriptClass110 or RAScriptClass104 at the top?

0 0
replied on October 20, 2022

It says RAScriptClass110.  And that's what appears as the default when I create a new SDK Script in the Workflow designer.

0 0
replied on October 21, 2022

If you right click on the Laserfiche.RepositoryAccess reference in the left pane, does it point to version 11?

Can you post the script? Something else must be attempting to use RA 10.4.

0 0
replied on October 21, 2022 Show version history

I ran the workflow in the designer as is and it crashed.  Now my workflow service won't start.  Need to be able to stop the workflow service from trying to run my bad workflow when it starts up.  How would I do that?

0 0
replied on October 24, 2022

I see your reseller opened a case with Tech Support and has stopped your server from crashing.

The issue seem to be caused by mixing Laserfiche.DocumentServices 10.4 (which has a dependency on Laserfiche.RepositoryAccess 10.4) with the default reference for Laserfiche.RepositoryAccess 11. Please update your reference to Laserfiche.DocumentServices 11 (from Workflow's install folder).

As far keeping the service from running the bad work, Workflow does what it can, but it's not always possible to catch scripts before they crash. Tech Support has a utility that can clean up the instance from the database.

0 0
replied on October 25, 2022

Thanks for your reply.  We solved this by updating the status column of the workflow_task_queue table for the broken task (in the Workflow database) from "2" to "8"  (8 means completed?) and this has allowed the workflow service to run.  I'll look into updating the DocumentServices reference.

 

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

Sign in to reply to this post.