search

microsoft / msix-packaging

MSIX SDK
MIT License
963 stars 163 forks source link

How to take dependency on a library that loads non-packaged DLLs in a packaged application? #632

Closed MoodieG closed 3 weeks ago

MoodieG commented 1 month ago

Hey,

My packaged application has a dependency on ONNX runtime and requires to run machine learning models on the GPU with Nvidea Cuda. The ONNX runtime library loads the DLL at runtime, however the MSIX packaged application cannot find the DLL because it only looks in the installed path of my packaged application.

What is the recommended approach to resolve this issue?

MoodieG commented 3 weeks ago

Just bumping this thread.

DrusTheAxe commented 3 weeks ago

The ONNX runtime library loads the DLL at runtime_

What DLL?

Where's it live?

MoodieG commented 3 weeks ago

The user is expected to download cudNn on their machine and have an environment variable path to the installation folder containing the DLLs which is usually in C:/Program Files/NVIDIA/CUDNN\v9.1\bin.

ONNX runtime assumes it can import the DLLs since the path is set as part of the environment variables. However, MSIX applications only search the directory of the MSIX application itself. Unfortunately cudNn does not have a MSIX package to take dependency on.

DrusTheAxe commented 3 weeks ago

Unfortunately cudNn does not have a MSIX package to take dependency on

That would be the ideal answer. Have you shared your feedback with Nvidia?

ONNX runtime assumes it can import the DLLs since the path is set as part of the environment variables

That's unwise these days, for security as well as reliability reasons.

have an environment variable path to the installation folder containing the DLLs which is usually in C:/Program Files/NVIDIA/CUDNN\v9.1\bin.

After MSIX framework package or redistributables shipped as a private copy with your app (and everyone else's), there's no good answers. There's some mechanisms that may seem to work, in limited scenarios, but all have (notable) weaknesses.

Unpackaged apps use a DLL search order encompassing some 18+ mechanisms. Packaged apps' DLL search order is intentionally different (subset of the classic mechanisms, plus package graph) to avoid problems some of the classic mechanisms bring to the table. Years back, DLL Hell was a persistent and painful problem across the industry. This was largely solved by unpackaged apps avoiding classic mechanisms like PATH to find DLLs*, or packaged apps using MSIX's designed runtime which avoids them.

* PATH, current directory and System32 (aka dumping-ground-mosh-pit) were some of the more popular and egregious offenders the industry has largely moved away. Thankfully.

MoodieG commented 3 weeks ago

Thanks for the information.

Until Nvidia has a package we can depend on, I believe our best bet is to package the cudNn DLLs as part of our application after we figure out all licensing issues that come with that.