02-10-2019 01:26 PM
02-10-2019 01:26 PM
When the MSIX Packaging Tool creates a package, it uses some unknown algorithm to generate the Application Id field in the manifest, presumably from the filename of the exe file.
We can see that characters are set to upper case, and numbers are turned into their English equivalent. I've also noticed that underscores are removed (and possibly other characters). The schema for the Manifest (https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-application ) indicates the actual restrictions to the string and this too must be part of the algorithm. But we can't be sure exactly what the tool does in generating this string.
To include a PSF config.json file in the package to implement a fixup, the config.json file "Application" object must include an entry with an Id field that matches this string. But sometimes we want to generate the json file before the manifest exists so that it is included in the package. Currently this means packaging once to find the correct string, and then packaging it again.
To automate the fixing of packages, I'd like to see this algorithm documented.
02-11-2019 12:40 PM
As you have observed, the operations today are:
1. Find the exe name, strip the extension
2. Convert to uppercase
3. remove all non alphanumeric characters
4. translate the numerals to corresponding English words
I cannot guarantee that this will stay the same over time though. Though we can probably add a note to document any changes here in the patch notes if needed.
For your purposes, would it be simpler if we provided you a way to tell the tool what ID you want assigned in the manifest? I suspect over time that may be easier to script against than trying to match the algorithmic generation?
02-11-2019 01:54 PM
My tool runs during monitoring mode. So the MPT can't programmatically tell me, unless you game me a COM interface to ask and I don't think we want to go there.. And my tool closes before monitoring completes, so me telling the MPT tool is probably not workable either (well, unless you act on my "plugin" idea). If it ends up involving manual entry anywhere, that would be problematic as there may be multiple entry points in the package.
So I'm OK with duplicating your algorithm as long as it is documented. Good start so far, but I know we need the following (unless you are ignoring these possible issues and generating bad packages anyway):
Given the manifest restrictions, what do you do about those restrictions?
* in case of length exceeding 64 characters, do you truncate at 64? (or maybe take last 64?)
* in cast of a disallowed token, what do you do? (like maybe an entry point called "CON.exe"?"
02-11-2019 09:00 PM
To clarify the community notes are not an official doc statement. We will look into make this a public doc, but have to evaluate the need to possibly change it and impacts on breaking changes. So the notes here are not guaranteed, only if it is officially in the support documentation.
02-12-2019 09:21 AM
As those edge cases have not been common, the items to address them are still pending.