Launch the program and make sure it launches as expected.If using Endpoint manager as deployment system, make sure the test installs using SYSTEM account, as to control for data in the user directories like %Appdata% or HKCU.After repackaging, install the program on an equivalent OS that you need the package to work with.Does the program integrate into other products, then make sure to test the integrations. Build requisites in your deployment system.Find out if you need to build a script to make sure they get to the client.If not installed, do they install together with your package?.If the program has dependencies, find out how they should de delivered to the client.Find out what it does and make sure you have eyes open in regard to file associations, right click context menu items, services, pre-requisites and other stuff which could be a limitation of MSIX. Always get to know the program you are dealing with.Software and package changes going back and forth are expensive and we should have process that avoids exactly that.

Having a stable process for this kind of automation / development is crucial to save everyone’s time and in the end money. Some companies use a lot for resources on this area and other not so much. User acceptance test comes in many flavors. MSIX Package with context menu (like notepad++).This blog post is being written based on Timothy Mangan reaching out to me. Someone must to take responsibility for the applications we tamper to make sure they work. Most companies introduce user acceptance test (UAT) to their process of automating software, and I also think that makes sense. There is more to packaging like testing and make sure the application work as intended after we changed how the bits and bytes flow to the device. In the last “ MSIX Modern Packaging – Part 3” we transformed Notepad++ from a legacy installer to MSIX.

Notepad++ msi package