Access SDK outside of MSIX application

[FrankKubis]

Hi,

our application use MATLAB for complex calculations. The MATLAB code is converted to a NuGet package and referenced in our .net application. To get this run, the MATLAB runtime is required, that is normally installed at C:\Program Files\MATLAB\MATLAB Runtime

Try to run our application that is packaged by MSIX fails with "System.DllNotFoundException" of "mclmcrrt9_5.dll", that is part of MATLAB Runtime.

Is it somehow possible to allow the msix container access to this runtime?

[#2]

@FrankKubis  It is not clear if the Matlab code from the nuget package is included in your MSIX package.

If it is included, you should probably try using the Package Support Framework with DynamicLibraryFixup.  Some of the methods used in the traditional runtime of modifying the Path Variable, or using App Paths registration to solve dll not found issues don't work under MSIX.  This fixup allows for the paths to package dlls to be registered in a new way (inside the PSF config.json file) and ensures that if the dll is inside the package it will be found.  If packaging using the Microsoft MSIX Packaging Tool, the free PsfTooling can be used to add in the fixup and will automatically locate all dlls in your package and register them.  If using other third party tooling the process might be different, but should be available.

If the dll is not inside the package, I would guess that manual manipulation of the json might be possible.  I have not tried this and am not sure if full paths (rather than the package relative paths normally used) are supported but they should be.

[#3]

Thank for your reply.

To make it clear: the missing dll is not part of our MSIX package. Its the MATLAB runtime installed on the system. We don't want this be part of our MSIX package.

As I understand this right, there is no easy way to get this work? We want to create the package in our Build Pipeline, a manual manipulation is not possible for us. That would be a lot over overhead in work.

Seems some lake of permission, running the application as administrator does work.

[#4]

@FrankKubis That makes sense, I should have guessed that's what you were doing as soon as you mentioned nuget.

Here is what i believe to be the underlying issue.  A native install of your application would have likely added either a change to the Path variable, or the setting of an AppPaths registration to tell your exe additional folders (the sdk) to look for dlls in.  Those types of entries are not supported inside the package.

The Psf and DynamicLibraryFixup is one solution to help your executable find the dlls.  Another might be a newer manifest entry called LoaderSearchPathOverride, however I have found that it doesn't seem to work (see my posting on this earlier this week:  LoaderSearchPathOverride and the Manifest - Microsoft Tech Community).

Other options available to you would include making the sdk native install solve the problem, by modifying the Path environment variable.  Your application inside the MSIX container will use the Path setting on the native system to locate dlls.  Another option may be to include the SDK inside your package.  This will significantly increase the size of your package and may bring in additional issues - I know that the full install of MatLab needs help but perhaps the SDK only would be OK.

Let us know what you find works for you!

[#5]

We did get managed to fix the dll not found issue using the Psf and DynamicLibraryFixup. But MatLab to do some more stuff in the background that fails.

It seems that the systems tries to write into some location of the file system like:
C:\Users\XXXX\AppData\Local\Temp\XXXX\mcrCache9.5\
C:\Users\XXXX\AppData\Local\Packages\XXXX\LocalCache\Local\Microsoft\WritablePackageRoot\VFS\Local AppData\Temp\XXXX\mcrCache9.5\LSDToo0

Iam not sure why this is not allowed or does not work. Could that require some more permissions?

[#6]

@FrankKubis You probably need to add the FileRedirectionFixup to handle the file write permissions to any file contained inside the package.

Heads up: There is a known issue in the FRF that affects ways that a few apps access files if the user name includes the space character, so avoid that for now until we get it addressed.