I got the error with multiple instances of GemBox.PDF with PKCS#11 operations

at Net.Pkcs11Interop.Common.Platform.set_IsWindows(Boolean value)
at Net.Pkcs11Interop.Common.Platform.DetectPlatform()
at Net.Pkcs11Interop.Common.Platform.get_IsLinux()
at Net.Pkcs11Interop.Common.Platform.get_NativeULongSize()
at Net.Pkcs11Interop.HighLevelAPI.Factories.Pkcs11LibraryFactory…ctor()
at Net.Pkcs11Interop.HighLevelAPI.Pkcs11InteropFactories…ctor()
at .(String , Boolean )
at …ctor(String , Boolean )
at GemBox.Pdf.Security.PdfPkcs11Module…ctor(String libraryPath, Boolean performLocking)
Scenario - multiple instances and concurent pkcs11 operations
workaround : in Program.cs - before registration of services with GemBox (with Pkcs11Interop) should be check OS like this ex.
RuntimeInformation.IsOSPlatform(OSPlatform.Windows);
bool is64bit = Net.Pkcs11Interop.Common.Platform.Uses64BitRuntime;
bool isWindows = Net.Pkcs11Interop.Common.Platform.IsWindows;
or something ofcourse
regards
Pawel
Hi Paul,
This shows that, although accessing the native PKCS #11 device might be thread-safe, the managed code of Pkcs11Interop is not.
Your workaround fixes this particular issue, but other multithreading and synchronization issues might happen in the future, unfortunately, in a non-deterministic manner, especially if Pkcs11Interop holds some managed state that is lazily initialized and not protected by any synchronization mechanism.
The best and easiest solution is to protect the communication with the PdfPkcs11Module / Pkcs11Interop with the lock.
Regards,
Stipo