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

Question

Question

LF SDK Web Application Fails in 64-bit

asked on March 26, 2018 Show version history

Hello,

We recently developed a RESTful Laserfiche Web API (.NET) that provides programmatic access to Laserfiche documents/services. We deployed the application and testing has been mostly successful.

However, we found we were getting out of memory exceptions despite having plenty of available memory and eventually figured out that the app pool is defaulting to 32-bit and will not run if that is disabled.

When attempting to debug the application in 64-bit we receive an error related to the LaserficheImaging dll.

The part that has me stumped is that I see a 64-bit version of LaserficheImaging in the GAC, yet DocumentServices (10.2.1.492) is still referencing the 32-bit version internally.

What do we need to do to get the LaserficheImaging reference working in 64-bit?

0 0

Answer

SELECTED ANSWER
replied on March 27, 2018

Now that I think about it a bit more, I think your screen shot supports this as the cause.  When a web application starts initially, it will immediately load all of the dlls in the bin directory.  So if you get this error just from loading the first page of your site, it's likely because Visual Studio pulled in a 32-bit version of a dll.  On the other hand, if Document Services was getting loaded out of the GAC and for some reason was pulling in the wrong LaserficheImaging.dll, I wouldn't expect you to run into this problem until your application attempted to use functionality from that library and had to load it in to the process.

Visual Studio lets you set a "Copy Local" property on the project references, which may help prevent this.

1 0

Replies

replied on March 27, 2018

What you want is definitely possible in general - it's exactly what applications like WebLink and Web Access do.  One thing you'll want to look out for is Visual Studio pulling in incorrect versions of files into your bin directory.  If there's anything that you want to load from the GAC you should make sure there isn't already a copy in the bin directory.

1 0
SELECTED ANSWER
replied on March 27, 2018

Now that I think about it a bit more, I think your screen shot supports this as the cause.  When a web application starts initially, it will immediately load all of the dlls in the bin directory.  So if you get this error just from loading the first page of your site, it's likely because Visual Studio pulled in a 32-bit version of a dll.  On the other hand, if Document Services was getting loaded out of the GAC and for some reason was pulling in the wrong LaserficheImaging.dll, I wouldn't expect you to run into this problem until your application attempted to use functionality from that library and had to load it in to the process.

Visual Studio lets you set a "Copy Local" property on the project references, which may help prevent this.

1 0
replied on March 27, 2018 Show version history

Thanks for the reply. I think the issue you described may have been is exactly what we were experiencing.

We actually got it working earlier today with the following steps and we noticed that it had deployed with a 32-bit version of the LaserficheImaging dll in the bin.

  1. Set the project to explicitly target 64-bit
  2. Build > Clean Solution
  3. Re-deployed as 64-bit
  4. Verified the bin did not bring in any 32-bit dlls

 

UPDATE: After further testing/investigation I found that one of the secondary API components was set to store a local copy of the reference(s). I disabled that, then cleaned the solution, and now it seems to work in 64-bit even with the project set to Any CPU.

0 0
replied on July 9, 2019

I have the following error when using sdk 10 only when I publish it in IIS, I have even created a blank webapi and only referencing the dll and I have the same error. thank you for your support.

 

0 0
replied on July 9, 2019

@████████ , please stop posting the same message in multiple threads. The error message already has instructions on how to enable .Net's logging for assembly resolution (HKLM\Software\Microsoft\Fusion!EnableLog) so you can see what it tried to load and why it failed.

0 1
replied on July 9, 2019

Yes, this sounds like the same problem and should be fixable in the same way.

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

Sign in to reply to this post.