You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Quoting Hui on the problem this presents:
"Not in the same folder, the app doesn’t know what resource file to use. MRTCore doesn’t support “..\resources.pri”."
This is a possible customer scenario. Quoting Hui:
"A customer may have an app, then decide to package it."
BTW, it is as of yet unknown if this issue exists only when the to-be-packaged win32 app project is "external".
We suspect it is though because of this: WinUI solutions are also WAP projects and they don't have this issue. In that case though, the .vcxproj/.csproj project isn't external.
The text was updated successfully, but these errors were encountered:
rohanp-msft
changed the title
If a WAP project references an external win32 app .vcxproj, the PRI is placed one directory above the EXE.
[MRTCore] If a WAP project references an external win32 app .vcxproj, the PRI is placed one directory above the EXE.
Mar 5, 2021
rohanp-msft
changed the title
[MRTCore] If a WAP project references an external win32 app .vcxproj, the PRI is placed one directory above the EXE.
[MRTCore] In a packaged win32 app, the PRI is placed one directory above the EXE.
Mar 5, 2021
I think, generally, this decision of putting every project in its own folder for MSIX packaging should be reconsidered, or made an option, considering normal VS output puts all artifacts in the same folder but the .wapproj does not. This means many common scenarios (a .exe with an associated .dll for example) break by default with .wapproj.
Quoting Hui on the problem this presents:
"Not in the same folder, the app doesn’t know what resource file to use. MRTCore doesn’t support “..\resources.pri”."
This is a possible customer scenario. Quoting Hui:
"A customer may have an app, then decide to package it."
BTW, it is as of yet unknown if this issue exists only when the to-be-packaged win32 app project is "external".
We suspect it is though because of this: WinUI solutions are also WAP projects and they don't have this issue. In that case though, the .vcxproj/.csproj project isn't external.
The text was updated successfully, but these errors were encountered: