BUG with native .NET lib dependencies in editor

Editor: Exception.
Exported app: works.

Microsoft.ML.OnnxRuntime contains native dlls and depends on Microsoft.ML.OnnxRuntime.Managed.
But actual symbols located in Microsoft.ML.OnnxRuntime.Managed.

Something wrong how Editor works with such native dependencies.

Editor finds onnxruntime.dll in system32 dir, that is wrong.
Native onnxruntime.dll should be loaded from Microsoft.ML.OnnxRuntime package.

Also normal C# Visual Studio project works fine.

Reproduced in: Gamma 5.2

Reproduce steps:

  1. place fake onnxruntime.dll to C:\windows\system32 directory , if file does not exist. In my current windows this file is installed by TrustedInstaller so I cannot remove it.

  2. Download OnnxRuntimeTest.vl OnnxRuntimeTest.vl - Google Drive

  3. Open in editor

  4. Install only dependency Microsoft.ML.OnnxRuntime (and Microsoft.ML.OnnxRuntime.Managed will be installed automatically as dependency)

  5. Restart app.

  6. You will see exception in [Create SessionOptions] node.

  7. Export app as Console x64. Run it. You will see no exception and properly written string.

Thanks. Fix in upcoming.


I’m very sorry, but we had to revert this “fix”. Turns out it broke various other libraries which depend on the default dll search order. You’ll either have to uninstall that particular software which placed that dll in the sys32 folder, or put the dll beside the vvvv.exe

It’s not “particular software”.
It is Microsoft.ML.OnnxRuntime nuget package.

Then you should remove statement that vvvv works with nuget packages. It does not.
Seems like fundamental architecture of vvvv is broken.

You’re right, it seems Windows is delivering some version of that dll - other projects running into the same issue, for example see comment in Loading onnxruntime.dll from path crashes on Windows build 19025 · Issue #932 · microsoft/Azure-Kinect-Sensor-SDK · GitHub where they actually talked to the OS team about it.

Here is some more info, seems it’s a WinRT thing: Windows | onnxruntime

In any case, the proper fix here would be to load the dll (and probably its dependencies as well) explicitly from the nuget package folder.

Ok, gave this another shot. Upcoming build should work for the onnx package as well without breaking other existing packages. Fingers crossed.

1 Like