Publishing to winget with MSIX Hero

MSIX Hero is a freeware tool used by administrators and packagers for troubleshooting, analysis and debugging of MSIX packages. One of the latest updates introduced a new functionality which can be used to prepare a content for publishing apps in winget.

Winget is the newest approach from Microsoft, which aims to offer a centralized, format-agnostic package manager. While it differs substantially from what Linux/UNIX package managers and even Chocolatey, Scoop etc. are offering, there seems to be rather a positive reception. Once some missing features are there, together with constantly growing number of apps available, it may eventually become a really interesting part of the ecosystem, possibly one of the first thing the user would install to get his beloved apps and stuff on his newly staged computer.

In this blog post, I will show how to get started, create and validate an app definition and finally push it to the repository. Some basic knowledge of git would help you to get started (as the publishing process relies heavily on a proper git-based workflow), but this guide has been written for git beginners in mind. Just make sure you have a free GitHub account – register for a new one if you do not have any yet.

This tutorial is specifically addressed to those, who may not be quite proficient with git and related stuff, but want to still be able to publish submissions to winget. Users working with git on daily basis can certainly skip large parts of sections, describing how to fork and sync repositories.

Preparing

The app that I am going to publish will be the newest version 1.0.5 of MSIX Hero. The app is going to be an update of a previous version which is already in winget, but every submission is more or less following the same steps, regardless of being a completely new app, or just an updated version.

The first step is to prepare the sources. The app must be installable silently (with or without command line switches) and redistributable as a single file. The format itself is less important, most popular choices are:

  • MSI (Windows Installer) (note: because the file must be completely standalone, make sure that all your files and CAB archives are compressed inside the MSI container)
  • EXE (any format would work, some typical would be setups created by InnoSetup or NSIS).
  • MSIX/APPX (preferred choice for the modern deployment).

MSIX Hero is an MSIX app. The steps for other types are mostly the same.

Continue reading →
Posted by Marcin Otorowski, 0 comments

Creating VHD for MSIX app attach with MSIX Hero

In MSIX Hero 0.3.0.0 a new feature has been added. For any MSIX package, it is now possible to create a VHD image and scripts for staging, registering, unregistering and unstaging. This is a foundation for a new cool concept, named MSIX app attach (casing sic!).

MSIX is just a modern Windows app package format. MSIX app attach on the other hand takes the packages in this new format, and dynamically attaches them to Windows Virtual Desktop Session. Since the attached packages are expanded on read-only virtual disks, attaching and using an app is really fast and unnoticable to the user. And yet it still provides all benefits of maintaining minimal number of images, which are dynamically enhanced by the apps the user needs and can access. This all is possible without installing anything, with just only a minimal registration step that takes place. MSIX app attach is still in preview and will be available in upcoming version of Windows 10.

Now back to MSIX Hero. The new version has an ability to create attachable VHD disks + necessary scripts to test app attach out. This just eliminates a few manual steps that the user otherwise must do before getting any app attached. The automation built into the tool closely follows the steps from the following website:

https://docs.microsoft.com/en-us/azure/virtual-desktop/app-attach

Here is a UI for it. The dialog can be found in the GENERATE section > Generate VHD for app attach… accessible from the main ribbon.

Update: In version 0.3.4.0 the ribbon has been changed. The button is now in the EDIT > MSIX app attach VHD generator

The options are really minimalistic and self-explaning, but one or two things are interesting enough that they require a few extra words and comments.

Continue reading →
Posted by Marcin Otorowski in MSIX Hero, 0 comments

Convert HRESULT to a human-friendly error (PowerShell)

In several places in Windows (but especially in functions and calls resolving around COM) the errors/warnings returned by Windows APIs are returned as 32-bit numbers HRESULT. The binary value of HRESULT adds a special meaning for certain bits, like information about the type of the error, origin and much more.

Let’s analyze an example value of HRESULT 0x800706BA, which may be also represented in decimal form –2147023174. When seeing that number being returned by the API, it is usually not quite clear what the actual error really is. Wikipedia has a really simple explanation of how the number is structured:

https://en.wikipedia.org/wiki/HRESULT

Based on the specification and a header file to find out the mappings between facilities and their identifiers, I created a simple PowerShell function, which – given a number representing HRESULT – returns a human-friendly structure. This way you can convert this:

0x800706BA 

into this:

HResult : -2147023174
HResultHex : 0x800706BA
HResultBin : 10000000000001110000011010111010
Facility : FACILITY_WIN32
FacilityCode : 7
ErrorCode : 1722
IsFailure : True
Message : RPC server is unavailable
IsCustom : False
IsServerFailure : False 

Much better, isnt’t it? Turns out, this particular HRESULT represents an error, code 1722 (RPC Server is unavailable. Some other information, including representation in different formats are also there.

The usage is simple as that:

 Get-ActualError 0x800706BA 

and the full source code is available in the following gist:

https://gist.github.com/marcinotorowski/8c09fc556469b22a9df421be51e370b2

Posted by Marcin Otorowski in PowerShell, 0 comments

How to sign MSIX package (with MSIX Hero)

MSIX deployment stack requires that every package is digitally signed. Not doing it, or modifying an already signed package sooner or later ends with this:

The package is not signed, has a broken signature or the certificate is not trusted.

Package which is not trusted (as seen above) is not installable. The error is shown when trying to install an APPX or MSIX package which either :

  • Is not signed at all, or
  • Used to be signed, but due to unauthorized changes the signature is invalid, or
  • Is signed by an untrusted certificate.

Digital signing on Windows is not a rocket since, but still a bit tricky for APPX and MSIX packages. Aside of complex command-line of signtool and even a simple posessing of a valid certificate, the certificate subject must be kind of “imprinted” into the package manifest. Signing will fail if the publisher (from manifest) and the subject (from certificate) are not equal. And you will sign a lot, in fact after every single change in manifest or package files.

MSIX Hero makes signing and re-signing of packages piece of cake.

Continue reading →
Posted by Marcin Otorowski in MSIX Hero, 0 comments

Be more productive with MSIX with MSIX Hero

MSIX is a modern deployment and packaging format for Windows 10, with – although being relatively new in comparison to some other popular frameworks – plenty of tools and utilities out there. I personally find the ecosystem a bit scattered and a bit difficult for newcomers.

MSIX Hero is an answer to this challenge. This utility with simple GUI integrates several APIs, PowerShell commands and SDK tools in a single tool. Its primary use is management and troubleshooting. It does not try to be a complete authoring tool (for which commercial software like Advanced Installer, RayPack or InstallShield is a better choice) – instead it is rather a complimentary addition which can be used by anyone with any MSIX package, and should help users be more productive whichever of the above they use. It certainly has been driven by my needs, and being done in my spare time I actually managed to get rid of almost all scripts and snippets I was using for MSIX related tasks.

It can be downloaded from the following location: msixhero.net or by using a direct link to online installer. The best of it – it’s completelty free for personal and commercial use.

In the upcoming series of posts, I will show a few use cases and functions of MSIX Hero. In the current version the tool supports the following (the list is not comprehensive, it is just to name a few highlights):

  • Viewing installed packages (for current user or any local user)
  • Identification of packages:
    • Visual identification: translated user-friendly names, icons, colors
    • Identification of tool used to create the package
    • Showing applications and start-up information
    • Showing package dependencies, installed add-ons and users
  • Detection of PSF and visualization of file redirections
  • Adding and removing packages (for current user or all users)
  • Quick access to applets and screens
  • Ability to start installed apps and browse their manifest, folders etc.
  • Packing and unpacking of MSIX packages
  • Signing and changing signatures
  • Building modification packages stubs
  • Creating and editing .appinstaller files
  • Installing, extracting and creating of certificates

Posted by Marcin Otorowski in MSIX Hero, 0 comments

Executing custom commands in MSIX context

Sometimes, for troubleshooting it may be necessary to invoke commands in the context of MSIX, so that all virtualized file and registry resources are available. There are three main use cases for it:

  1. Testing out whether the files and registry entries are visible inside the virtual package in the correct place as defined in the AppxManifest.xml.
  2. Testing out whether Modification Package correctly merges its VFS and virtual registry with the base package.
  3. Executing your app from the MSIX package with custom executables and/or parameters which are not necessarily exposed as entry points.

There exists a really useful PowerShell cmdlet which does the heavy lifting, the only thing the user has to do is to supply the right parameters. Its signature (from MSDN):

Invoke-CommandInDesktopPackage
      [-PackageFamilyName] <String>
      [-AppId] <String>
      [-Command] <String>
      [[-Args] <String>]
      [-PreventBreakaway]

Both PackageFamilyName and AppId are required, as well as the command to be executed. You can get the two values from another cmdlet Get-AppxPackage.

The command that is started in the “bubble” can be pretty much anything (it is validated before running), but some typical examples are:

  • cmd.exe
  • powershell.exe
  • regedit.exe
  • Executables being part of the package (indirectly)

For example, let’s execute a PowerShell session in MSIX container to verify the virtualized file structure.

Continue reading →
Posted by Marcin Otorowski in MSIX, PowerShell, 0 comments

Change UI language in Visual Studio

The Visual Studio Installer for VS2019 automatically pulls the language package that matches the current Operating System. My Windows 10 Operating System language is currently German – there is a thing that always keeps me wondering:

Why is the Tools menu translated to Extras in German Visual Studio?

This and some more pecularities (especially important when working in pairs with non-German speakers) may be a good reasons to switch to old good English UI. Here is how to do it for an already installed Visual Studio 2019 instances (you can obviously apply this for any currently used language).

If target language pack has been already downloaded…

The only thing you have to do is to locate the correct settings. Go to Extras -> Optionen -> Umgebung -> Internationale Einstellungen and select the language from the list.

If target language pack has not been yet downloaded…

  1. Close all Visual Studio windows
  2. Run the Visual Studio installer. You can do this by going to Add/Remove Programs (Programme und Features) and selecting the right item. Press Ändern to bring the setup window.
  3. Go to the second tab and enable English language. You can disable German one if you do not plan to switch to it in future. Leaving just only new language enabled will automatically switch VS to that language. Press Ändern to apply the changes.
  4. In case you didn’t uninstall previous languages first, then after restarting you may need to go to Settings to change to the newly downloaded language pack. Simply go to Extras -> Optionen -> Umgebung -> Internationale Einstellungen and select the language from the list.

Installing language packs from command line

It is possible to automate installing language packs, by using the following command line (executed in directory where the installer resides, usually C:\Program Files (x86)\Microsoft Visual Studio\Installer):

vs_installer.exe modify --addProductLang En-us --path install="C:\Program Files (x86)\Microsoft Visual Studio\2019\Community" --quiet --wait 

Note: The full installation path is required for this to work. I am using VS 2019 community installed in the default location, but you may update the path accordingly.

Instead of En-us for American English, any valid identifier from this list works too.

Posted by Marcin Otorowski in Programming, 0 comments

Windows Sandbox – unable to run .NET apps

I have just updated my daily used computer to Windows 10 1903 May 2019 Update. The update took a while but after all finished with some nice new cool features on board.

I gave it a try and started the new Windows Sandbox mode, which is an out-of-the-box sandbox built in Windows 10 Pro and Enterprise. Launching of sandbox takes just a few seconds, and then the fully functional dummy environment is available, really well done!

One thing that I found interesting was that it was not possible to start a PowerShell window, or any .NET app. Each try finished with an error, for example:

This application requires one of the following versions of the .NET Framework:.NETFramework,Version=v4.5.2 

The error dialog offers a choice to download the runtime, but the framework installer (correctly) prevents it from being installed, because that or a newer version is already there.

It turns out, that not everyone is affected by this problem. The problem is caused by update KB4495620 which is installed on the host machine. This is a cumulative update for .NET Framework fixing a few vulnerabilities. In order to be able to run .NET apps on Windows 10 Sandbox, uninstall this update and reboot your machine (again to repeat myself – this has to be done on your host and not the sandbox!). After that, powershell.exe and .NET apps will run without issues:

Hello World, RayPack 6.1 (.NET 4.5 app) is running on Windows 10 Sandbox mode.

I hope the problem is going to be fixed by Microsoft soon, until then use this workaround to test Windows 10 Sandbox out.

Posted by Marcin Otorowski in Virtualization, 2 comments

Creating MSIX Packages with RayPack 6.1

Last week I was in London, and had a chance to speak to a few MS guys standing behind #MSIX. Also last week, a new version of RayPack Studio has been released, bringing some improvements over MSIX conversion in the latest revision 6.1. With this post I wanted to make a quick walkthrough of going from so-called legacy installations (traditionally all setup.exe and alike, but recently the Windows Installer format has been counted to that group) to the new, modern and native Windows-10 way of installing and servicing apps.

Installing Firefox in MSIX format (auto-conversion from MSI)
Continue reading →
Posted by Marcin Otorowski in MSIX, 0 comments

Displaying installed MSI products with a PowerShell module

Based on my previous post, I created a small project on my github and adjusted existing codebase to provide a simplistic PowerShell module. The code has been reorganized into proper units with exported functions. Here is a sample usage:

$Header = @"
&amp;lt;style&amp;gt;
TABLE {border: 1px solid gray collapse; }
TH { border: 1px solid gray; padding: 6px 4px; background-color: #eaeaea; }
TD { border: 1px solid gray; padding: 4px; }
&amp;lt;/style&amp;gt;
"@
Import-Module MsiClient
Get-MsiClientPackage | where { $_.Publisher -contains 'Microsoft Corporation' } | sort-object -Property ProductName | ConvertTo-Html -Property ProductCode,PackageName,ProductName,VersionString,Language,Publisher -Head $Header | Out-File c:\temp\test.html

The above snippet produces a HTML based report, showing all Microsoft products available on the current system.

There are still lots of TODOs, which I am going to cover soon, for example:

  • More methods supported (install, uninstall, repair etc.)
  • Better exception handling
  • Support for -WhatIf and -Confirm switches

In any case, my design goal is to keep the syntax similar to functions available in the AppVClient module, so that ideally for basic scenarios they have a 1-1 mapping in the MSI counterpart.

Link to my guthub (the project is licensed under MIT):
https://github.com/marcinotorowski/PowerShellMsiClient

Posted by Marcin Otorowski in Programming, 0 comments