MSIX

Hi

There's 2 critical bugs in InstallShield, MSIX projects, although seems no one monitors this forum :(

1. Installation Designer > Package Payload > Applications > My App > Behavior :: Key Name

From InstallShield help: The unique identifier of the application is within the package. This value is sometimes referred to as the package-relative app identifier (PRAID). The ID is unique within the package but not globally. There may be another package on the system that uses the same ID. The same ID cannot be used for more than once in the same package. This string contains alpha-numeric fields separated by periods. Each field must begin with an ASCII alphabetic character.

Create a new project and set this "Key Name" to anything starting with "A", like "ACME" or "AAAGames" for example! When created .msix, if you inspect the package, "ACME" is renamed to "CME" and "AAAGames" is renamed to "Games", hence you cannot set "App" as Key Name which is a very common scenario, ie:

Calculator: Microsoft.WindowsCalculator_8wekyb3d8bbwe!App

Camera: Microsoft.WindowsCamera_8wekyb3d8bbwe!App

Clock: Microsoft.WindowsAlarms_8wekyb3d8bbwe!App

Photos: Microsoft.Windows.Photos_8wekyb3d8bbwe!App

So you cannot set "App" to have the full AUMID ending with App. Are you using the same developers that worked on Boeing 737 max software to reduce the costs?!

2 . When creating MSIX project and provide Assets AppList.scale, MedTile.scale and StoreLogo.scale pngs, the same png files (3x5=15) are repeated 3 times, resulting 45 png images inside the final msix package, instead of 15, with this pattern:

15 selected png files inside Assets folder.

The same 15 files again copied inside a new folder named "contrast-black" under Assets folder.

The same 15 files again copied inside a new folder named "contrast-white" under Assets folder.

How to disable this behavior? No need to have contrast-black and contrast-white folders and copy the same files under Assets folder to those 2 unnecessary folders! If not possible, that's a bug IMO.

Thanks.

Hello,

If we enable the MSIX build for Basic MSI project, and check the created MSIX package, we'll see:

Under Virtual Registry>

Registry > Machine > SOFTWARE > Microsoft > Windows > CurrentVersion > Uninstall > guid

This registry entry is only for MSI installers, why it is included for MSIX packages?

I hope it's possible to exclude it from MSIX, am I correct? Any solution?

Thanks.

While building your packages is the first step, distributing your packages is the next logical step. You want to make this process very trivial to your users. MSIX. What if your users can directly install from web. Let's learn how !

Microsoft makes this possible by using the protocol activation scheme - ms-appinstaller. When you click on a link referenced by this scheme, Windows invokes the app-installer and makes it really seamless for the app to be installed. The app is not downloaded onto the machine. It's rather streamed directly from the web server

Of course, for this 'hand-shake' to happen, there are a few requirements to be met, on the webserver. Here is some documentation from Microsoft on how to enable this.

However, for the sake of illustrating this simply, I took the route of GitHub pages where the requirements are configured already. Here are some very simple steps through which I created the 'install from web' experience

1. Create a sample GitHub repo
2. Enable GitHub pages in your repo's settings
3. Upload your msix package to the repo
4. Create a simple html file. I created an 'index.html' file here
   • Notice the link. This is where the magic lies
     1. <a href="ms-appinstaller:?source=https://vdonga.github.io/msix-examples/msi-diff/appinstaller/MsiDiff_x86.msix"> Install MSI Diff Package </a>
   • Look at the href for the link. This is how you specify what your link is pointing to
5. That's all !

Now, all you need to do, is to access your page till 'index.html'. Click on the link 'Install MSI Diff Package' link

Don't worry, the package is safe. It's InstallShield's MSI Diff tool signed with our corporate signature.

Thanks for trying !

Microsoft's Documentation

This article provides step by step instructions to add an MSIX extension to your InstallShield MSIX project. An extension is like an agreement between an application and the operating system. Extensions lets application developers extend or customize standard features primarily for use in their applications and potentially for use in other applications. InstallShield supports rich set of extensions for MSIX projects, available in the Declaration s view in the MSIX project.

In this example, we are going to demonstrate how you can add Notepad++ application to a file extension - .rev file from an MSIX project in InstallShield using File Type Associations extension.

1. Launch InstallShield

2. Click on New button. Select MSIX Project type. Provide a project name and click OK

3.  Navigate to Files and Folders view and add your Application files. So for this MSIX project, add all files and folders from the <Program Files>\Notepad++ folder.

4. Navigate to ‘Declarations’ view, where you can declare the extensions required for your Application. To add an application extension, right click on the ‘Application Declaration Sets’ and then add a ‘New Declaration Set’. Then right click on the ‘Declaration Set’ created, it lists all the application declarations supported by InstallShield. Add File Type Association declaration from the list. One Declaration Set can contain multiple declarations. This will allow to map unique and separate declarations to each application entry in the MSIX manifest.

5. Enter the File Type Association declaration details, like the file type (. rev here ) to be registered and Name. Likewise, need to provide the application specific details for all the declarations added under the Declaration Set.

6. Navigate to Visual Assets view, where you can configure the visual aspects of the MSIX application. Here, you can configure the application icon image, various tile images, background color and the package logo. For the sample package, Application icon image is configured to a Notepad++ image as shown in the below. Likewise, Visual Assets view supports creating user defined visual assets to configure against each application entry.

7. Navigate to 'Applications' view, right click on 'Applications' in the center pane and select 'New Application' and browse the application added in the Files and Folders view (Notepad++.exe in Step 3) and select the ‘Declaration Set’ configured in the Declaration View for the ‘Declaration Set’ entry as in the below image to map to the application.  Now, select the ‘Visual Asset’ to the configured visual asset for this application entry in the Visual asset view. This will ensure that the icon is associated to the file extension when the package is installed.

8. MSIX Packages need to be digitally signed. So, now head over to 'Releases' view and click on ellipses for 'Digital Certificate Information' and provide your digital signing information

9. Click on Build in the ribbon bar

10. Click on Run in the ribbon bar

11. Click on Install and the installation should be successful, and the Notepad++ app should launch after installation is done as the checkbox 'Launch when ready' is checked.

12. Check the File association before and after installing the MSIX package

Before the Installation, the .rev file extension was not associated with any application:

After the installation, the .rev file extension is registered with the application (Notepad++.exe in this case) installed in the MSIX package, the file icon got changed to the application icon configured in the ‘Visual Assets’ view, and double clicking on the ‘TestFile.rev’ file open the registered application (in this case, ‘TestFile.rev’ opened in the Notepad++.exe).   

That's it !! You just built and installed your MSIX app with ‘File Type Association’ extension!!

In the previous article , we talked about Package Support Framework and how MSIX solves the problem of running traditional Win32 apps by a community driven route. In this article, let's focus on another important piece of MSIX - Modification Packages and why they are important to you, if you are an ISV developing software or an IT Pro, as a software consumer.

Before we jump into what a modification package is, let's start with Why ! If you are an IT Pro, you would have repackaged hundreds of packages. While repackaging a vendor setup is one side of the story, adding your enterprises customizations is a totally different story. It could be a simple enterprise branding or a complex feature customization. IT Pros have been managing this for ages now without actual access to the source code. When you have your customizations for a given vendor app ready, you definitely don’t want to do this over again when a new version of the vendor app is available. So, there is a pressing need for isolating customization from the core app. Traditionally, transform files (.MST) is mostly how you have applied customizations to your setups. The question is - if MSIX is the next standard, how do you do the same without access to source?

While customizations are for IT Pros, from an ISV point of view, there is an increase in developing modular applications where the base app is kept separate from any plugins. Imagine you are developing an editor app and over a period of time, you want to add PDF editing capabilities. Best practices suggest, keep the base and plugins separate.

Enter Modification Packages !

Modification package help you apply customizations on a given base app or add plugins/addons without changes to the base app.

To put it simply, if your base app has say 'settings.xml', you can have a modified version of settings.xml in the modification package to tweak the app settings in your enterprise. MSIX runtime, will honor the 'settings.xml' from the modification package instead of the base package allowing your customization to take effect.

Modification packages are always bound to a base app. In fact, both of them share the same identity. This is what helps MSIX runtime to pick the customizations. They can't be installed standalone. So, while creating a modification package, you need to mention the base app in your manifest file in the Dependencies section.

Before installing the modification package, the base app should be installed. Else, you will be presented with an error.

You can find all the modification packages to your base app from Apps and Features (Windows Settings --> Apps & Features). Select your app and navigate to 'App add-ons & downloadable content'. You will find them.

You will be able to uninstall them without affecting the base app.

Additional Resources

In the last article , we talked about how MSIX is the next gen deployment package. We touched upon few perks of using MSIX. One item we didn’t go into detail is how MSIX manages to run Win32 apps with breeze and what the shortcomings are.

Well, if MSIX needs to achieve true application isolation or security among other benefits, it needs to restrict few operations. For instance, it can’t allow apps to write files to the installation directory or current working directory. If you are an IT Pro, at first glance this strikes as a real non-starter. But, what if there is a solution?

PSF, short for Package Support Framework is the solution to how you can overcome issues with Win32 apps running in a containerized environment. The framework is built on Microsoft’s Detours technology which basically ‘redirects’ API calls to a different location the app has access to.

Once you know the issue, PSF will allow you to apply a fix up to the app which makes it MSIX compatible. The way PSF works is, MSIX replaces the main exe with something called PSF Launcher which reads a configuration file (config.json) and injects the fixups into the main exe. For more detailed documentation on how PSF works, you refer to Microsoft's documentation here .

There is still a catch though. For IT Pros, there is no way of knowing of an issue without actually running into it. There is no magic wand that runs on a bunch of files and comes up with issues. Because the problems that we are dealing with here, are runtime issues. 

Microsoft has open sourced Package Support Framework and is inviting developers to contribute to more fix ups, so that the community can take advantage of them faster. With Microsoft actively managing this and independent developers contributing to more fixups, over long term, we should have a healthy set of fixups that cover most common issues.

In a future article, we’ll illustrate how to use PSF with an example.

Additional Resources

MSIX was announced during Microsoft Build 2018 conference as the next generation deployment package. Ever since, there has been a lot of buzz on this format. After trying various formats over years, Microsoft seems to get most things right with technology which reflects in the heavy investment they are putting in this technology and rightly so. Why do I think so? Let's look at the problems it's trying to solve

Typical deployment types like .exe or .msi or even App-V have some problem or the other.

Application Compatibility Issues - For years enterprises have been fighting the application compatibility battles. It has been a nightmare for IT Pros to test for compatibility whenever there is an org decision made, to move to the latest Windows platform. While Windows 10's incremental updates solves this problem partially, it doesn't eliminate it completely.

Unreliable Deployments - Different deployment types means different standards for each. Multiply that with the amount of software that gets installed and uninstalled daily. Some work, some don’t. Reaching out to the software vendor means more support costs.

Complicated Updates - Every software vendor has their own standard of publishing updates and delivering to end users. Some perform major upgrades, some minor. Some of them just want them to co-exist with an older version. If you are a software vendor or an IT Pro, you know what I'm talking about, unless you have a very established process of managing updates.

Winrot and DLL Hell - If you are a seasoned Windows user, chances are high that you heard about these terms. In very simple terms, Winrot refers to a degradation in OS performance caused by multiple software installing, uninstalling and leaving tons of useless junk behind, taking a huge toll on the machine performance.

AppX limitations - While AppX looked promising, the technology was limited by the APIs that developers could exploit.

If these are not enough reasons for a super hero to rise, I don't know what else is. That's where MSIX emerges as the super package that comes to the rescue of ISVs and IT Pros at the same time.

By running apps in their own containers MSIX solves most of these problems. While application virtualization promised to do the same, MSIX makes it more appealing because it brings plenty other advantages

Containerized Apps - which solves compatibility issues at one shot

In addition to these, there are several other pros like network and storage optimization, file block level updates and others which I'll cover in another article.

Stay tuned for more…

Other Resources

This article provides step by step instructions to get started with building your first MSIX package using InstallShield

1. Launch InstallShield
2. Click on New button. Select MSIX Project type. Provide a project name and click OK
   •  
3. Navigate to Files and Folders view add your files
   • 
4. Navigate to 'Applications' view, right click on 'Applications' in the center pane and select 'New Application'
   • 
5. MSIX Packages need to be digitally signed. So, now head over to 'Releases' view and click on ellipses for 'Digital Certificate Information' and provide your digital signing information
   • 
6. Click on Build in the ribbon bar
7. Click on Run in the ribbon bar
   • 
8. Click on Install and installation should be successful and app should launch after installation is done as the checkbox 'Launch when ready' is checked

That's it !! You just built and installed your first MSIX app !!