Using External dll's that can't be packed with my software

[michaelpesin]

Hello,

The problem I'm having is with unrecognized dll paths when using MSIX runtime.

Our SW communicates with external dll's that reside in the `C:/TwinCat` directory. These dll's are external and are used to communicate with our hardware. They are part of an external software called TwinCat. When we try to connect our SW to the HW we use these dll's for communication.

The problem is that when the SW runs in MSIX virtual environment it can't find the paths of the relevant dll's, but when I run everything locally (when debugging) everything works perfectly. 

I tried using the Package Support Framework but had no success. I get the following error:

ADS could not be initialized because the 'TcAdsDll.dll' is not found! Please check DLL search paths!

Can anybody please help? If we won't be able to fix this issue we will have to abandon MSIX.

EDIT:

The path to the dll's is saved in the win environment variables in PATH. 

Thanks in advance!

Michael Pesin.

[#2]

Hi Michael,

If the dll is present in C:/TwinCat, I believe the packaged app should be able to see it. I am dropping you a message for more details.

[#3]

Sorry, not here to offer a solution but rather to add my name to the list of folks that need this. I'm trying to package up a 3rd party component, which we are allowed to distribute, that, in turn, talks with another 3rd party component that we can't distribute (ergo can't package) due to licensing issues (customers acquire it from the vendor). The component I'm packaging seems to rely on the PATH variable to find the next level of 3rd party components, and because MSIX doesn't look at the path this dynamic loading doesn't work.

Unless I'm missing something, there's nothing available to affect the DLL search paths in an MSIX-packaged application beyond redirecting stuff *inside* the container, i.e. no equivalent to PATH/AppPath, so this component can't be packaged without code changes by the 3rd party.

This same issue also stops me from interacting with TWAIN data-sources from inside an MSIX-packaged application (vendor's data-sources often rely on the 'normal' DLL search paths, and there's no way I can package every possible data-source and its dependencies that a customer might want to use).

Being able to specify additional DLL search paths *located outside the container* in the manifest or something would be really useful. I know it goes against the self-contained principle of MSIX, but there has to be some kind of compromise, right? This kind of thing will be a blocker for a bunch of apps/libraries where the package owner isn't the code owner.