Add-AppSharedPackageContainer

[TIMOTHY MANGAN]

[Starting a new item on this]

Feedback:

1. The online documentation does not match the get-help
2. The cmdlet seems unable to use a UNC share path for the filename, it must be a local file.  This would seem pretty much a requirement for the cmdlet.
3. The cmdlet requires elevation, even if only affecting the current user and not picking any fancy options.  Given that Add-AppXPackage doesn't need this elevation, it seems that this shouldn't either.

[#2]

Hi, thanks for the feedback, we are looking into the issue.

[#3]

@Dian Hartono I have learned a bit more on item #2.

• The issue with UNC share filenames only occurs when the PowerShell is run from inside the container.
• I have only seen it on 20H2 and is not a problem from inside the container on build 21345+
• It also affects Add-AppXPackage from inside the container.
• Placing the filename in quotations yields an odd result that might shed light on what is going on. Without the quotes, the PowerShell error is file not found and references the file in the same form as requested (\\server\share\folder\filename). Adding quotation marks around the UNC name results in file not found with a path constructed like C:\Program Files\WindowsApps\PackageFamilyName'\server\share\folder\filename'   In other words prepending either the package root or working directory folder, turning double quotes into single, and loosing the opening slash in \\server.

I am investigating for a workaround to getting this to work from code running inside the container. Who knew MSIX packages would have compatibility issues? For the shared container file making a quick temporary copy locally is a fine workaround, but I'm not interested in doing that for packages and will try to pop the PowerShell outside of the container as a solution..