I have a strange load behavior when a LabVIEW-built native DLL calls into a C# .NET assembly.
Setup:
- SM.dll – Native DLL generated by LabVIEW 2021 (64-bit).
- Contains a single exported function that internally uses LabVIEW’s .NET Constructor Node to create an object from my .NET wrapper DLL.
- scard.dll – C# .NET 4.8 assembly (x64) wrapping winscard.dll for smart card operations.
- In deployment, scard.dll is placed in a common folder (C:\Card) so multiple LabVIEW applications can use it.
- LabVIEW project references C:\Card\scard.dll during build.
- The application has been built and deployed successfully for a long time without changes to the LabVIEW project or build process.
- In the current build, however, the .NET loader fails to find scard.dll on some test PCs (others run fine), even though the file is present in the expected location.
Observed behavior:
- If scard.dll is in the same folder as SM.dll, everything works.
- If scard.dll is in C:\Card (as designed), on some PCs the call fails with “Library not found or failed to load” (LabVIEW error 1003).
- Fusion logs show two load attempts:
- Reflection-only load of scard.dll with version 0.0.0.0 → fails
- Normal load with version 1.0.0.0 → succeeds only if DLL is in same folder as SM.dll
- In the failing cases, the 0.0.0.0 reflection load failure prevents the 1.0.0.0 load from running.
- The scard-assembly is strong-named; target framework is 4.8; platform target is x64.
- Same binaries work on some machines but fail on others, even with identical .NET versions.
What I’ve checked:
- corflags shows correct architecture (x64)
- Dependencies are fine (Dependency Walker, ProcMon show no missing modules)
- Strong naming and assembly binding redirects tried — no effect
- LabVIEW build settings unchanged between old working builds and new failing builds
Key detail:
SM.dll is not a .NET assembly — it’s native LabVIEW code that uses the LabVIEW .NET interop layer to load scard.dll.
All .NET loading here is done from LabVIEW’s runtime, not from another .NET assembly.
Question:
Why would LabVIEW’s .NET interop attempt a reflection-only load with version 0.0.0.0 first, and why would that fail unless the DLL is in the same folder as the native LabVIEW DLL?
Is there a way to configure the load so that it doesn’t rely on reflection with 0.0.0.0, or so that it can find the assembly in a shared folder consistently across machines?
