"Windows Application Project" to create MSIX in Visual Studio issues

%3CLINGO-SUB%20id%3D%22lingo-sub-2072575%22%20slang%3D%22en-US%22%3E%22Windows%20Application%20Project%22%20to%20create%20MSIX%20in%20Visual%20Studio%20issues%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2072575%22%20slang%3D%22en-US%22%3E%3CP%3EI%20am%20finding%20the%20project%20type%20interesting%2C%20but%20flawed%2C%20and%20want%20to%20provide%20some%20feedback.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E1)%20The%20project%20type%20is%20limited%20to%20having%20only%20one%20entry%20point.%26nbsp%3B%20Multiple%20entry%20points%20are%20often%20required.%3C%2FP%3E%0A%3CP%3E2)%20Referenced%20projects%20are%20placed%20in%20subfolders%20off%20of%20the%20root%20of%20the%20package%20based%20on%20the%20name%20of%20the%20referenced%20project%2C%20rather%20than%20at%20the%20root.%26nbsp%3B%20If%20the%20referenced%20project%20contains%20dependency%20dlls%2C%20these%20dlls%20might%20not%20be%20found.%3C%2FP%3E%0A%3CP%3E3)%20A%20possible%20solution%20is%20to%20add%20the%20PSF%20nuget.%26nbsp%3B%20This%20turns%20out%20to%20be%20a%20bit%20of%20a%20nightmare.%26nbsp%3B%3C%2FP%3E%0A%3CUL%3E%0A%3CLI%3EThe%20instructions%20include%2017%20steps%2C%20including%20adding%20two%20new%20projects.%26nbsp%3B%3C%2FLI%3E%0A%3CLI%3EOne%20of%20those%20new%20projects%20is%20a%20shell%20of%20a%20dll%20project%20for%20someone%20to%20write%20their%20own%20fixup.%26nbsp%3B%20There%20is%20no%20integration%20to%20bring%20in%20the%20existing%20fixup%20dlls%20of%20the%20PSF.%3C%2FLI%3E%0A%3CLI%3EThanks%20to%20%232%20above%2C%20the%20exe%20project%20for%20PsfLaunchers%20will%20be%20in%20a%20subfolder%20of%20the%20package%20based%20on%20the%20name%20of%20that%20package.%26nbsp%3B%20The%20launcher%20can%20either%20specify%20(in%20the%20config.json)%20that%20the%20working%20directory%20of%20the%20launched%20process.%26nbsp%3B%3CUL%3E%0A%3CLI%3EIf%20you%20choose%20the%20folder%20for%20the%20launched%20process%20(so%20that%20it%20could%20see%20its%20own%20dlls)%2C%20the%20launcher%20will%20fail%20to%20find%20PsfRuntimeDll.%3C%2FLI%3E%0A%3CLI%3EIf%20you%20choose%20the%20folder%20for%20PsfRuntimeDll%2C%20then%20the%20app%20doesn't%20see%20its%20own%20dlls%20again.%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3C%2FLI%3E%0A%3CLI%3EYou%20cannot%20add%20a%20reference%20to%20a%20dll%20project%20to%20the%20WAP%20project%20to%20just%20add%20a%20build%20dll%20from%20another%20project.%26nbsp%3B%20This%20should%20be%20allowed%20and%20the%20dll%20added%20to%20the%20root%20folder.%26nbsp%3B%20If%20the%20Psf%20exe%20project%20output%20was%20added%20there%20(rather%20than%20the%20folder%20of%20the%20PsfExe%20project%20name)%20also%2C%20we'd%20have%20a%20workable%20solution.%3C%2FLI%3E%0A%3CLI%3EPublish%20is%20not%20an%20obvious%20build%20action.%20The%20actions%20taken%20by%20publish%20should%20be%20able%20to%20be%20included%20directly%20in%20the%20build%20actions.%3C%2FLI%3E%0A%3CLI%3EThe%20AppID%20in%20the%20manifest%20seems%20to%20be%20hardcoded%20to%20%22App%22%20and%20not%20editable.%20As%20this%20is%20needed%20in%20the%20config.json%20file%20this%20should%20be%20editable%20in%20the%20appxmanifest%20editor%20from%20solutions%20explorer%20or%20better%20documented.%3C%2FLI%3E%0A%3C%2FUL%3E%0A%3CP%3EVisual%20Studio%20needs%20to%20have%20a%20better%20solution%20if%20you%20want%20developers%20to%20release%20to%20MSIX.%3C%2FP%3E%3C%2FLINGO-BODY%3E
MVP

I am finding the project type interesting, but flawed, and want to provide some feedback.

 

1) The project type is limited to having only one entry point.  Multiple entry points are often required.

2) Referenced projects are placed in subfolders off of the root of the package based on the name of the referenced project, rather than at the root.  If the referenced project contains dependency dlls, these dlls might not be found.

3) A possible solution is to add the PSF nuget.  This turns out to be a bit of a nightmare. 

  • The instructions include 17 steps, including adding two new projects. 
  • One of those new projects is a shell of a dll project for someone to write their own fixup.  There is no integration to bring in the existing fixup dlls of the PSF.
  • Thanks to #2 above, the exe project for PsfLaunchers will be in a subfolder of the package based on the name of that package.  The launcher can either specify (in the config.json) that the working directory of the launched process. 
    • If you choose the folder for the launched process (so that it could see its own dlls), the launcher will fail to find PsfRuntimeDll.
    • If you choose the folder for PsfRuntimeDll, then the app doesn't see its own dlls again.
  • You cannot add a reference to a dll project to the WAP project to just add a build dll from another project.  This should be allowed and the dll added to the root folder.  If the Psf exe project output was added there (rather than the folder of the PsfExe project name) also, we'd have a workable solution.
  • Publish is not an obvious build action. The actions taken by publish should be able to be included directly in the build actions.
  • The AppID in the manifest seems to be hardcoded to "App" and not editable. As this is needed in the config.json file this should be editable in the appxmanifest editor from solutions explorer or better documented.

Visual Studio needs to have a better solution if you want developers to release to MSIX.

0 Replies