Forum Discussion
michaelpesin
Dec 26, 2021Copper Contributor
Using External dll's that can't be packed with my software
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 ...
JDHIntercede
Jan 10, 2022Brass Contributor
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.
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.