Is it possible to add reference to an external dll at runtime with winui 3(packaged)

[NinZeige]

I'm using WinUI 3 to develop a program that uses the HikRobot camera and need to add a dll to use its SDK
I add dll reference in VS and intelisense can recognize the members in that dll, but it throws Unable to load DLL xxxx at the runtime
The reason for this problem is that HikRobot further references other dll files in PATH, and these files, according to the information I found on MS docs, do not seem to be accessible by the packaged application.
(my code works fine in console/WPF/unpackaged WinUI 3)
I also can't import these further DLLs directly, because they are dlls for C++, vs did not recognize them.
If I set it to unpackaged, it will work fine, but I still wander if I can solve this problem without changing the packaging config.

Error:

Additional Infos:

• the dll I imported is MvCamCtrl.Net
• the dll it said cannot find is MvCameraControl.dll, which in C:\Program Files (x86)\Common Files\MVS\Runtime\Win64_x64(there are also many other dlls, and someone says they are also been used)
• HikRobot site
• I can answer in Chinese/ English

[DrusTheAxe]

the dll it said cannot find is MvCameraControl.dll, which in C:\Program Files (x86)\Common Files\MVS\Runtime\Win64_x64

Is the MvCamCtrl.Net dll in that same directory?

[NinZeige]

No, it is in another dir(D:\Program Files\MVS\Development\DotNet\AnyCpu)

[DmitriMilokhov]

@NinZeige Did you mange to find solution? I have almost the same issue...

[NinZeige]

:( I'm sorry, but I didn't make much process on this issue, I finally finished my work with unpackaged WinUI3.

[DarranRowe]

A desktop application packaged up certainly can load libraries from outside of the package at runtime.
As an example, suppose I have a library placed in a directory.

I then use the following code in a C++ Windows API application to load it:

	{
		wil::unique_hmodule test_lib;
#if _M_X64
		test_lib.reset(LoadLibraryExW(LR"(D:\Test\x64\TestLibrary.dll)", nullptr, 0));
#endif
#if _M_IX86
		test_lib.reset(LoadLibraryExW(LR"(D:\Test\x86\TestLibrary.dll)", nullptr, 0));
#endif

		if (!test_lib)
		{
			auto last_error = GetLastError();
			auto fmt_string = std::format(L"LoadLibrary failed: {}", last_error);
			MessageBox(nullptr, fmt_string.c_str(), L"LoadLibrary Error", MB_ICONERROR | MB_OK);
		}
	}

Then this will load*. There are no general restrictions on loading libraries from outside of the package. As long as the library has read and execute permissions then it will load.
There are differences in the packaged application environment compared to an unpackaged application, so one of these differences could be affecting how things work. Really, you should check for any differences that could affect you, like check to see the value of the PATH environment variable, to see if it is what you expect. There are some values, like the current working directory, which are guaranteed to be different. It is possible that you would need to use a tool like Sysinternal's Process Monitor to see where it is looking for any dependencies.

*The big elephant in the room here is that not all packages are made equally. If you are setting the package to be Partial Trust, then you have to be sure that your application has access to the directories that it wants to load libraries from. As an example, using the code from earlier:

LoadLibraryEx fails with error code 5, which is ERROR_ACCESS_DENIED. This comes from the fact that when you specify that the application is partial trust, you are stating that the application runs in an app container. Using the Windows 10 2004 (20H1) terminology, this is equivalent to uap10:RuntimeBehaviour being set as packagedClassicApp and uap10:TrustLevel being set to appContainer.
If you have a look at the permissions on Program Files:

do you notice that ALL APPLICATION PACKAGES security principle? It was named in the Windows 8 era where application packages were all in an app container, but it means that app container applications have permission to access that directory. So, if I add this to the directory where the library is:

This allows my packaged application running in an app container to load this library even from this directory.

[DrusTheAxe]

Here's the root problem:

The reason for this problem is that HikRobot further references other dll files in PATH, and these files, according to the information I found on MS docs, do not seem to be accessible by the packaged application.

The DLL Search Order differs for packaged apps vs unpackaged apps. The loader has ~18 ways to resolve a DLL for unpackaged apps but only 9 for packaged apps and PATH isn't one of them

https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#standard-search-order-for-packaged-apps

One option is to put the DLLs in an MSIX Framework package, declare a static dependency (<PackageDependency> in your appxmanifest.xml) and install the Framework when you are installed.

Another option is to put the DLLs in an MSIX Framework package, install the Framework when you are installed and use the Win11 Dynamic Dependency API at runtime to add the Framework package to your process' package graph.

Another option is to explicitly LoadLibrary(absolutefilename) each DLL needed, from the bottom up e.g. LoadLibrary("a.dll"); LoadLibrary("b.dll") if b.dll has import references to a.dll (happily resolved via the Loader-module list). This is generally not recommended as it requires you have intimate knowledge of the DLLs and they don't change over time. Thus it's possible in theory but much harder in practice.