Can't load external DLLs from MSIX packed application

[brontesprocessing]

What works in normal desktop application

When we try to load a dll from a normal desktop application the system automatically checks the directories specified in the environment variable "PATH" and finally, the dll is found. E.g. we are using NVidia CUDA dlls this way.

What doesn't work when application is packed into MSIX?

When we pack this application into MSIX the dlls can't be found any more, because the packed application doesn't check the folders specified in the environment variable "PATH".

In some cases a workaround would be to load the dll dynamically from code, but it only works when the dll has no dependencies. Otherwise the loaded dll is not able to find it's dependecies.

What's the recommended approach to load the dlls to which path is defined in environment variable "path"?

[DrusTheAxe]

What's the recommended approach to load the dlls to which path is defined in environment variable "path"?

To not rely on the PATH environment variable. That's a rather fragile way to find DLLs (too easily changed by installers or users possibly months later only to see "this used to work fine" suddenly doesn't).

There are other options.

How is your application defined? Please share the <Application> definition from your appxmanifest.xml

If you've defined RuntimeBehavior="packagedClassicApp" (or the older syntaxEntryPoint="windows.fullTrustApplication") then you're a DesktopBridge app. [The DLL Search Order for those](https://github.com/microsoft/WindowsAppSDK/blob/main/specs/dynamicdependencies/DynamicDependencies.md#3152-packaged-processes) doesn't include thePATH` environment variable.

In some cases a workaround would be to load the dll dynamically from code, but it only works when the dll has no dependencies. Otherwise the loaded dll is not able to find it's dependecies.

Are these dependencies in the same directory as the DLL you're trying to load? If so you can LoadLibraryEx(fn, ..., LOAD_WITH_ALTERED_SEARCH_PATH) to look in the directory where fn is found (instead of the directory where the calling process' executable is run from).

[ghost]

I'm encountering the exact same issue as @brontesprocessing and the reliance on the DLL Search Order for Desktop Apps defined by Microsoft has worked for our needs in the past. By eliminating the PATH env variable from the DLL search order for MSIX app packaging that @DrusTheAxe linked, to me it breaks this documented understanding for desktop developers who want to move to MSIX. To suggest that we shouldn't rely on PATH env variable is a very broad statement that I don't think holds weight. For our business, the reliance on this feature is critical, and none of the new DLL Search Order options will appear to work for us. It could just be my lack of understanding of what those options mean (APIsets? Known DLLs? Package Graph?). The lack of information on the github description makes it very cryptic to a layman like me.

1. Why is PATH env variable no longer part of the DLL Search Order, when creating an MSIX app package?
2. When can it be added for those who wish to deploy their desktop apps as MSIX packages, but rely on this PATH env to find a dependent dll?

Best regards