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

Discussion

Discussion

SDK Runtime Installation for use in Workflow

SDK Workflow
Updated December 2, 2014
posted on December 1, 2014

From my understanding DLLs should be called from the workflow program files directory. Is it best practice to copy the DLLs from the run time to the workflow directory after installation?

Where does the run time store the library files?

0 0
replied on December 2, 2014

I have been trying to get DocumentProcessor82 and LFSO82 to work. It works in Visual Studio on my dev machine from any directory. On the customer's server in WF from either the default install directory or after moving to the Workflow directory I get an incorrect side-by-side configuration.

0 0
View 3 previous replies
replied on December 2, 2014

I'd recomment matching the version of DocumentProcessor and LFSO to the version of Workflow (or if using 9.1 or higher, using RepositoryAccess and DocumentServices instead).

You can reference Interop.DocumentProcessor from C:\windows\Assembly and LFSO from C:\Program Files\Common Files\Laserfiche\LFObjects, you don't need to move them into Workflow's install folder. In fact, due to how Windows loads .Net files, the copy in C:\Windows\Assembly will be loaded even if you reference a local copy.

0 0
replied on December 2, 2014

I am unable to browse the assembly directory with Workflow, even when adding it to the allowed directories.

I need the following methods. I think they are only included in the LFSO libraries and the document processor.

LFApplication, LFDatabase, DocumentImporter, LFDocument, LFConnection.

Are these all available with the new libraries? The integrator training doesn't reference much RepositoryAccess usage.

 

0 0
replied on December 2, 2014

Once you allow browsing on the WFServer's security, you should be able to see the Global Assembly Cache (aka, C:\windows\Assembly for .Net 3.5 and lower and C:\Windows\Microsoft.NET\assembly for .Net 4 and higher) as "GAC" in the file browser.

There are equivalents to those methods in RA. There is a DocumentImporter class in Laserfiche.DocumentServices (which is the .Net equivalent of DocumentProcessor).

Please don't make your own connections to the repository from scripts.

0 0
replied on December 2, 2014

I see what you mean, that does allow me to choose those DLL files and they are all there. It still says the side-by-side configuration is incorrect though. I am not sure how to configure this, I am beginning to think I might have installed it correctly but their OS is corrupted or there is a software conflict. This is just based on articles about Side-By-Side, it appears a lot of C++ devs have problems with this. I assume the libraries I am referencing are written in C++.

0 0
replied on December 2, 2014

Yes. I'm not seeing any bugs in our system about SideBySide issues with SDK Runtime 8.2. But i might be an issue with installing it after newer versions of the files have already been installed.

If this is Workflow 9.0 or 8.3, use the corresponding versions of the SDK. If it is 9.1 or higher, then you can use LFSO from the 9.1 SDK runtime, but it would be better to use RepositoryAccess.

LFSO is a COM library, while RepositoryAccess is a .Net assembly. Since Workflow is also a .Net application, it is more efficient to use the native .Net assembly.

0 0
replied on December 2, 2014

I don't recall if WF requires the VC++ runtimes, but RA/DS do and the SDK runtime installation in unable to automatically include them. If those are not present, you will indeed get winsxs errors, so I'd suggest checking that. The deployment section of the SDK docs should indicate the specific prereqs that everything might need.

0 0
replied on December 1, 2014

Some of them go to C:\Windows\Microsoft.NET\assembly, some go to Common Files. Is there one in particular that you're thinking of?

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

Sign in to reply to this post.

Details
Related Posts
Loading ...