Flat directory structure for WPF application packaged into MSIX

[RomainBraussen]

Hi,

I have a WPF application packaged into a MSIX using the "Windows Application Packaging" template project, and other cpp dll files used by that project. Everything is building fine, BUT the resulting installed MSIX application is creating a subfolder for each project.

Simple example below :

The executable is in the WpfTestApp, but if I want to use my Dll1.dll from it I now have to use a relative path to import it.
Considering my real project is using several of those dlls, and also a Shell Extension Handler whose path must be specified directly into the application manifest, well let's just say it's extremely prone to bugs.

What I want to achieve is a flat directory structure, not a subfolder per project.
This should be possibIe, if I create a regular C++ WinUI3 packaged project the resulting folder structure is indeed flat, like this :

This is what I want to achieve. The executable is directly into the package folder, with the other project files.

The subfolders seems to only happen with the WPF project for some reason. I searched everywhere into the solution/projects settings or the manifests files, I can't find what is making that happen.

Any ideas ?

[#2]

Not directly answering the request on getting VS to provide the structure you wanted, but...

You can add https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-uap6-loadersearc... to the manifest to tell dll loading to search for an additional folder. There is also an API call that the app can make, but uap6:LoaderSearchPathOverride is easier as you can define the path as relative to the package root folder.

[#3]

Thank you for you answer, that could definitely help.

I also found another workaround, I am now only referencing the WPF project in the MSIX packaging project, and in the WPF project I am adding my other DLLs using 'Add existing Item', 'Add as link' (dropdown on 'Add', it is a bit hidden). Then 'Copy if newer' in the item properties.
That way the dll are copied into the WPF project output directory automatically when building it, and the packaging project put everything into the WPF subfolder.
This is still not entirely flat, I still have the WPF subfolder, but I have no relative paths for DllImport anymore.
Using your solution on top of that could also help.