Items in this section allow you to control what you want the tool to recommend.  Some of these are changes from original functionality and while we like the new setting, we wanted to allow customers to revert to the old behavior.  On others, we find that some enterprises have different preferences, such as the use of folders in the start menu.

• Psf and the RegLegacyFixup. With all other components of the PSF we can generally deduce their need from the static analysis of the package.  But this fixup can only be deduced by running the package. We believe the RegLegacyFixup is safe and should always be applied if the PSF is added to the package for any other purpose.
• Uninstallers. This new detection removes both the executables and their shortcuts if they appear to be uninstallers or upgrades.
• Start Menu Folders. With this set, we'll add in a fixup to add the folders for shortcuts if present in the original installation.  The exception is if there ends up being only one shortcut, then we'll remove the folder.
• Desktop Shortcuts. Most companies don't want packages adding shortcuts to the user's desktop, and when this is not enabled, we remove them from the package.  Check this item if you don't like that idea.
• Control Panel Applets. Normally when these are seen they will be Available fixups and not automatically applied. Check this item if you want these in the Recommended list.
• VC Runtimes. We will detect VCRuntime components in the package, including those added by the PSF.  You have an option to remove them from the package and replace with a package dependency to the Microsoft maintained MSIX Framework Package.  While this works great for most packages, we have seen a few packages break by doing this, so we are not recommending it yet as a default behavior.

These settings control what to do before building the package.

• Package Version. When set, we'll automatically update the last available field of the package version by one.  Maybe you like this, or maybe not.  You can always set the version in the Properties tab instead.
• Last Version Octet. Microsoft reserves the last field of the version for apps uploaded to the Microsoft Store.  You are probably not doing that, so check this box if you are uploading to the store and cannot use all four fields.
• Analysis Report. Check this to save a copy of the Analysis Report when you save the package. This is a small xml file that contains the details you see on the analysis page, as well as details of the changes made by TMEditX to the package.

These settings control what to do before and after building the package.

• Sign Package should be checked to perform package signing.  Without it, the remaining signing option, and all of the signing Method fields will be ignored.
• With the "Update Package Publisher from cert" checkbox selected, TMEditX will ensure that the Publisher field in the AppXManifest file matches the subject field of your certificate automatically, updating the manifest when you save the package.

Currently, three signing methods are supported.  The additional fields will depend upon the type selected but should be self-evident.  

• You can use signtool with a password protected PFX file.  This could be your self-signed certificate, or if you use a public CA and they still support PFX files.
• Digicert KeyLocker based signing where the actual certificate is securely stored in their cloud-based service.  This technique still uses the signtool is included inside this product, but you must install and configure the KeyLocker tools externally.
• Digicert (or potentially other Token based certificate).  These are certificates stored on an HSM device like a secure USB drive.  We officially support Digicert, and again you'll need to install the DigiCert/Thwate application externally.