Shared Package Container XML Format feedback

%3CLINGO-SUB%20id%3D%22lingo-sub-2324006%22%20slang%3D%22en-US%22%3EShared%20Package%20Container%20XML%20Format%20feedback%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2324006%22%20slang%3D%22en-US%22%3E%3CP%3ESome%20feedback%20on%20the%20new%20Shared%20Package%20Container%3A%3C%2FP%3E%0A%3CUL%3E%0A%3CLI%3EWe%20always%20love%20a%20schema%20file.%26nbsp%3B%20Just%20saying...%3C%2FLI%3E%0A%3CLI%3EIn%20addition%20to%20the%20previous%20feedback%2C%20the%20documentation%20currently%20is%20not%20to%20the%20level%20of%20other%20xml%20formats%20like%20appxmanifest%20or%20appinstaller.%26nbsp%3B%20Details%20for%20validation%20on%20parameters%2C%20and%20limits%20on%20the%20number%20of%20sub-elements.%3C%2FLI%3E%0A%3CLI%3EIn%20an%20enterprise%20environment%2C%20this%20file%20would%20not%20be%20a%20temporary%20xml%20file%2C%20and%20I%20believe%20it%20should%20probably%20have%20it's%20own%20file%20type%20extension.%26nbsp%3B%20Possibly%20something%20like%20.msixspc%3C%2FLI%3E%0A%3CLI%3EThe%20xml%20file%20should%20allow%20for%20a%20version%20field%20on%20the%20root%20node.%26nbsp%3B%20Even%20if%20the%20installation%20silently%20ignores%20this%20field%2C%20we%20will%20need%20a%20version%20field%20to%20keep%20our%20sanity.%3C%2FLI%3E%0A%3C%2FUL%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2332515%22%20slang%3D%22en-US%22%3ERe%3A%20Shared%20Package%20Container%20XML%20Format%20feedback%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2332515%22%20slang%3D%22en-US%22%3E%3CP%3E%5BNo%20sense%20in%20breaking%20bad%20habits%20now%5D%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThe%20associated%20PowerShell%20commands%20could%20use%20some%20work%3A%3CBR%20%2F%3E%3CBR%20%2F%3E1)%20Get-SharedPackageContainer.%20It%20will%20be%20necessary%20to%20be%20able%20to%20query%20for%20all%20container%20sets%20previously%20added%20without%20knowing%20their%20names.%20It%20may%20be%20possible%20this%20in%20the%20intent%20with%20this%20cmdlet%20and%20it%20should%20be%20documented%20as%20%5B-Name%20%5Bname%5D%5D%2C%20possible%20the%20functionality%20should%20be%20added%20to%20this%20cmdlet%2C%20or%20perhaps%20as%20a%20new%20cmdlet%20like%20Get-SharedPackageContainers%3CBR%20%2F%3E2)%20The%20Add-SharedPackageContainer%20cmdlet%20should%20probably%20allow%20the%20path%20to%20be%20specified%20%5B-Path%5D%20%3CPATH%3E%3C%2FPATH%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E
MVP

Some feedback on the new Shared Package Container:

  • We always love a schema file.  Just saying...
  • In addition to the previous feedback, the documentation currently is not to the level of other xml formats like appxmanifest or appinstaller.  Details for validation on parameters, and limits on the number of sub-elements.
  • In an enterprise environment, this file would not be a temporary xml file, and I believe it should probably have it's own file type extension.  Possibly something like .msixspc
  • The xml file should allow for a version field on the root node.  Even if the installation silently ignores this field, we will need a version field to keep our sanity.
6 Replies
[Yeah, replying to my own post...]
Additional feedback. The need to specify the PackageFamilyName does cause the issue of having to install the package to find out the name. It appears that the only way to determine the PublisherId (the hash) used in the PackageFamilyName is to install the package to get the value out or powershell, or write some C++ code to perform the encoding of the publisher field. We should be able to provide the PackageName and Publisher field.

[No sense in breaking bad habits now]

 

The associated PowerShell commands could use some work:

1) Get-SharedPackageContainer. It will be necessary to be able to query for all container sets previously added without knowing their names. It may be possible this in the intent with this cmdlet and it should be documented as [-Name [name]], possible the functionality should be added to this cmdlet, or perhaps as a new cmdlet like Get-SharedPackageContainers
2) The Add-SharedPackageContainer cmdlet should probably allow the path to be specified [-Path] <path>

Hi, thank you for the feedback. We did reach out to some customers and found that the current xml format would work with their current workflow. In particular, version field seams to lead to confusion as the platform doesn't care what version the .xml file is. All we care about is the list of packages that are in the .xml that was deployed to device. If IT Pro would like to change the list of packages inside the container, than they would just need to modify the .xml file and deploy it. If IT Pro need to validate what are the list of apps inside container than they would need to just query the device.
Thanks for the feedback, yes IT Pros will need to know the PackageFamilyName in order to populate the .xml file to define the Shared Package Container. This is currently how we identify packages in the platform. Note that this is not dependent on the version of the app.
Hi, thanks for the feedback, we are looking into this.
Here is the scenario as I see it.
Someone creates an spg file and stores it somewhere central. It gets deployed out to a bunch of users. Then someone updates the file, probably overwriting the existing file. That gets deployed to a bunch of users, likely including all of the original ones, but possibly something goes wrong in that deployment and a user doesn't get the change. This becomes difficult to detect and determine. A version field, even if not implemented for versioning, would be helpful and consistent with how IT Pros manage deployments. It's about debugging issues, not deploying.