Failed attempts to load Microsoft Appstore Python DLLs

Greetings community,

I am trying to load Python dynamic libraries to interface Python from an application that I am trying to develop. The Python version I am trying to load is the one available in the Microsoft AppStore. Now when I use the “LoadLibraryExW” (which is a WIN32 API: LoadLibraryExW function (libloaderapi.h) - Win32 apps | Microsoft Learn) function to load the path. It throws an error having error code 5 implicating that access is denied. It could work if I forcefully take ownership (which is initially with “TrustedInstaller”) and alter the permissions of the file to allow full control to the current user or permit administrator access, but this does not seem to be an authentic or secure workaround for the same.

This is the path to the DLL I am trying to load.

C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.9_3.9.3568.0_x64__qbz5n2kfra8p0\python39.dll

In order to allow interfacing I also tried building CPython from the public repository (GitHub - python/cpython: The Python programming language) but I could notice that directory structure of CPython code built on Windows is different from the one seen for Microsoft Appstore installation. I want to understand how the Appstore version of Python is built and how is it different from the process adopted by the official website’s Python. So, is there a different way to build Python for Windows AppStore? If yes, can you please point me to the webpage which has instructions.

Thanks and best regards,
Piyush Dubey

Try uninstalling the app store version and install a version from instead. Does that work better?

Yeah, the Store package won’t allow this. It’s really intended for people who want to install Python so that they can use the Python interactive mode (or IDLE or other packages), and not for more complex scenarios.

Depending on what you’re trying to do, you might want to consider including the embeddable package or the package in your app.

If you really want to rely on a copy of Python that the user has chosen and installed without your involvement, I’d suggest letting them provide the path to python.exe and then launch your own script to set up some other kind of interop (such as passing messages over standard input/output or importing an extension module, which will then be “inside” the app and so can reference the Python DLL).

But for most apps where you want to make sure things work reliably, I’d strongly recommend including your own copy of Python. It’s very easy to redistribute, and your users will be happy that your app works.

1 Like

Upon reviewing the Python packages you have kindly suggested, I have noticed that they appear to limit access to a fully built Python version. It seems that these packages are either smaller subsets of Python, or they have been specifically designed to cater to certain use cases.

Regrettably, these limitations may not align with the objectives of the application I am currently developing. The application necessitates access to the comprehensive Python package, inclusive of all its functionalities.

I appreciate your understanding on this matter and look forward to any additional suggestions you may have that could better serve the requirements of this project.

Thank you for your continued assistance.

Could you clarify which functionality you need in your app? The Nuget package should have identical functionality to the Store package, so if it’s missing something then you aren’t going to find it in a Store install either.

The embeddable distro is deliberately missing functionality because it is designed specifically for embedded applications. This sounds like what you are doing, though I have to assume that because it’s missing functionality that you are actually doing something that is not an embedded application.

Providing some actual specifics about your project will help us advise. If opening up the Store package to this kind of external access is legitimately the only way to satisfy your needs, then we can consider it, but given the other options I would be incredibly surprised if this is the case.