• [アーティクル]

June 2019

Volume 34 Number 6

[DevOps]

MSIX:Windows でデスクトップ アプリを配置するための最新の方法

Magnus Montin Montin |2019 年 6 月| サンプル コードのダウンロード

MSIX は、Windows 10 の 2018 年 10 月の更新プログラムで導入された新しいパッケージ形式です。これは、MSI や ClickOnce など以前のインストール テクノロジすべての良い点をまとめることを目的としたもので、将来、Windows でアプリケーションをインストールするための推奨される方法になります。この記事では、.NET デスクトップ アプリケーションをパッケージ化する方法と、Azure Pipelines を使用した継続的インテグレーション (CI)、継続的配置 (CD)、サイドロードされた MSIX パッケージの自動更新を設定する方法を紹介します。

まず、背景情報に少し触れておきます。Microsoft では、Windows 8 において、Windows ランタイムと呼ばれる API およびランタイムを導入しました。これは、元は「モダン」、「Metro」、「イマーシブ」、または単に「Windows ストア」アプリと呼ばれた新しい種類のアプリケーションに一連のプラットフォーム サービスを提供することを主目的にしたものでした。この種類のアプリはモバイル デバイスの革命から生まれました。多くの場合に携帯電話、タブレット、ノート PC など、複数のデバイス フォーム ファクターを対象としたもので、通常は Microsoft Store から一元的にインストールおよび更新するものでした。

このクラスのアプリはその後かなり進化し、今ではユニバーサル Windows プラットフォーム (UWP) アプリと呼ばれるようになりました。UWP アプリは、他のプロセスから分離された、AppContainer と呼ばれるサンドボックス内で実行されます。これらのアプリは、正常に動作するために必要なアクセス許可を要求する機能を明示的に宣言し、これらの機能を受け入れるかどうかはユーザーが決定します。これとは対照的に、従来のデスクトップ アプリケーションは、現在のユーザーのすべての読み取りおよび書き込みアクセス許可を持つ完全に信頼されたプロセスとして実行されるのが通例です。

Windows 10 の Anniversary Update では、デスクトップ ブリッジが導入されました (Centennial プロジェクトとも呼ばれます)。これを利用すると、従来のデスクトップ アプリケーションを UWP アプリとしてパッケージ化することができますが、依然として、完全に信頼されたプロセスとして実行されます。パッケージ化したアプリケーションは、Microsoft Store またはビジネス向け Microsoft Store にアップロードすることができ、ストアによって提供される配置、組み込みライセンス、自動更新のための洗練された機能を利用できます。アプリケーションをパッケージ化した後は、Windows 10 の新しい API を使い始めて、あらゆるデバイスにわたって顧客を獲得するためにコードを UWP に移行することもできます。

Microsoft Store や UWP に関心がない場合でも、Windows 10 で導入された新しいアプリ モデルを活用するために、基幹業務のデスクトップ アプリケーションをパッケージ化することができます。そうすると、アプリのクリーン インストールおよびアンインストールが可能になります。これは、レジストリや一部の既知のシステム フォルダーに対するすべての操作が、インストールされるアプリケーションのローカル フォルダー (そこに仮想のファイル システムとレジストリがセットアップされる) に自動的にリダイレクトされることで実現されます。それを行うためにソース コードで何かをする必要はありません。Windows によって自動的に処理されます。パッケージをアンインストールすると、ローカル フォルダー全体が削除され、アプリの痕跡がシステムに残らないということです。

MSIX は基本的にデスクトップ ブリッジの後継機能であるため、MSIX パッケージの内容と、パッケージ化したアプリに適用される制限事項は、デスクトップ ブリッジで使用される APPX 形式とほとんど同じです。bit.ly/2OvCcVW にある公式ドキュメントに要件が記載されているので、アプリケーションをパッケージ化するかどうかを決定する前にご確認ください。要件の一部は、Microsoft Store に公開するアプリにのみ適用されます。

MSIX では、変更パッケージと呼ばれる新しい機能が追加されました。これは、IT 管理者が (多くの場合、サードパーティ ベンダーから提供される) アプリを、新機能またはバグ修正がリリースされるたびにゼロから再パッケージ化する必要なしにカスタマイズできるようにする、MST 変換と似た考え方です。変更パッケージは実行時にメイン アプリケーションとマージされ、たとえば一部のレジストリ設定を変更することで、アプリの一部の機能を無効にすることができます。このことは、開発者の観点からすると、アプリのソース コードとビルドおよびリリース パイプラインの両方を所有している場合には大きな意味を持ちませんが、大規模な企業の場合は、コストの削減につながり、パッケージ麻痺と呼ばれる状態を回避できます。

MSIX 形式の定義は GitHub にオープン ソースとして公開されており、Microsoft では MSIX パッケージのパックとアンパックに使用できる SDK を、Linux と macOS の両方を含むすべての主要な OS 上で提供する予定です。MSIX は、2018 年 10 月に Windows 10 バージョン 1809 で正式に導入され、その後、Microsoft により、以前のバージョンである April 2018 Update (バージョン 1803) と、2017 年 10 月の Fall Creators Update (バージョン 1709) 用にサポートが追加されました。

パッケージ

既存のインストーラーがある場合は、それを MSIX に変換する MSIX Packaging Tool を Microsoft Store で入手できます。これにより、管理者は、元のソース コードにアクセスできない場合でも、既存のアプリケーションをパッケージ化できます。開発者向けには、Visual Studio 2017 バージョン 15.5 以降で、既存のアプリケーションをパッケージ化するプロセスを簡略化できる Windows アプリケーション パッケージ プロジェクトが提供されています。これは、[ファイル] | [追加] | [新しいプロジェクト] | [インストール済み] | [Visual C#] | [Windows ユニバーサル] にあります。これに含まれる [アプリケーション] フォルダーをソリューション エクスプローラーで右クリックし、パッケージ化する Windows Presentation Foundation (WPF)、Windows フォーム (WinForms)、他の任意のデスクトップ プロジェクトへの参照を選択して追加します。その後、参照先アプリケーションを右クリックして [エントリ ポイントとして設定] を選択すれば、これまでと同様にアプリケーションをビルド、実行、デバッグできるようになります。

元のデスクトップ プロセスではなくパッケージ プロジェクトを開始した場合の違いは、モダン アプリのコンテナー内でアプリケーションが実行されることです。背後では、Visual Studio によって Windows SDK の MakeAppx および SignTool のコマンドライン ツールが使用され、まず .msix ファイルが作成され、次いで証明書を使って署名されます。この手順は省略できません。すべての MSIX パッケージは、パッケージ化したアプリをインストールして実行するマシン上の信頼されたルート証明機関にチェーンされている証明書で署名する必要があります。

デジタル署名 パッケージ プロジェクトには、パスワードで保護された Personal Information Exchange (PFX) 形式の既定のファイルが含まれていますが、このファイルは独自のものに置き換えることができます。自社でコード署名証明書を提供していない場合は、信頼された証明機関から購入するか、または自己署名証明書を作成することができます。Visual Studio には [テスト証明書の作成] オプションとインポート ウィザードがあります。これらは、既定のアプリ マニフェスト デザイナーで Package.appxmanifest ファイルを開くと、[パッケージ化] タブの下に見つかります。ウィザードやダイアログを使用しない場合は、New-SelfSignedCertificate PowerShell コマンドレットを使用して証明書を作成することができます。

> New-SelfSignedCertificate -Type CodeSigningCert -Subject "CN=MyCompany,
  O=MyCompany, L=Stockholm, S=N/A, C=Sweden" -KeyUsage DigitalSignature
    -FriendlyName MyCertificate -CertStoreLocation "Cert:\LocalMachine\My"
      -TextExtension @('2.5.29.37={text}1.3.6.1.5.5.7.3.3',
        '2.5.29.19={text}Subject Type:End Entity')

コマンドレットから出力された拇印 (ここに挙げる A27...D9F のような形式) を別のコマンドレット Move-Item に渡し、信頼されたルート証明書ストアに証明書を移動することができます。

>Move-Item Cert:\LocalMachine\My\A27A5DBF5C874016E1A0DEBF38A97061F6625D9F
  -Destination Cert:\LocalMachine\Root

さらに、パッケージ化したアプリをインストールして実行するすべてのコンピューター上のこのストアに証明書をインストールする必要があります。また、これらのデバイスでアプリのサイドローディングを有効にする必要もあります。管理されていないコンピューターでは、設定アプリの [更新とセキュリティ] | [開発者向け] の下でその設定を行えます。組織によって管理されているデバイスでは、モバイル デバイス管理 (MDM) プロバイダーを使用してポリシーをプッシュすることにより、サイドローディングをオンにすることができます。

拇印は、Export-PfxCertificate コマンドレットを使用して新しい PFX ファイルに証明書をエクスポートするためにも使用できます。

>$pwd = ConvertTo-SecureString -String secret -Force -AsPlainText
>Export-PfxCertificate -cert
  "Cert:\LocalMachine\Root\A27A5DBF5C874016E1A0DEBF38A97061F6625D9F"
    -FilePath "c:/<SolutionFolder>/Msix/certificate.pfx" -Password $pwd

この場合、生成された PFX ファイルを使用して MSIX パッケージに署名するように Visual Studio に指示するには、デザイナーの [パッケージ化] タブでそのファイルを選択するか、手動で .wapproj プロジェクト ファイルを編集して <PackageCertificateKeyFile> および <PackageCertificateThumbprint> 要素の値を置き換えます。

パッケージ マニフェスト Package.appxmanifest ファイルは、デジタル署名された AppxManifest.xml ファイルを生成するためにビルド プロセスで使用される XML ベースのテンプレートで、これにはパッケージ化されたアプリを OS が配置し、表示し、更新するために必要なすべての情報が含まれています。アプリの表示名とロゴをこのファイルに指定すれば、アプリのインストール後に Windows シェルにそれが表示されます。

MSIX パッケージに署名するために使用する証明書の Subject プロパティが、Identity 要素の Publisher 属性の値と正確に一致していることをご確認ください。パッケージ化したデスクトップ アプリケーションを実行できるのはデスクトップ デバイス上のみであるため、Visual Studio によって生成される既定のテンプレート内の Dependencies 要素から Windows.Universal の名前を持つ TargetDeviceFamily 要素を削除する必要もあります。

MinVersion および MaxVersionTested 属性は、パッケージ プロジェクトを作成するときに表示されるダイアログでは最小バージョンおよびターゲット バージョンと呼ばれている属性です。どちらも UWP の概念で、前者はアプリと互換性のある OS の最も古いバージョンを指定し、後者はアプリをコンパイルするときに使用できる API のセットを識別するために使用されます。Windows 10 API を 1 つも呼び出さないデスクトップ アプリケーションをパッケージ化するときは、同じバージョンを選択する必要があります。同じバージョンを選択しない場合は、最小バージョンをターゲットとするデバイスでアプリを実行するときに例外の発生を回避するランタイム API のチェックをコードに含める必要があります。

実際の MSIX パッケージを生成するには、Visual Studio の [プロジェクト] | [ストア] | [アプリ パッケージの作成] でウィザードを使用できます。エンド ユーザーが MSIX パッケージをインストールするには、生成された .msix ファイルをダブルクリックするだけで済みます。そうすると、図 1 に示すカスタマイズ不可の組み込みダイアログが表示され、アプリのインストール プロセスが案内されます。

Windows 10 のアプリ インストーラーと MSIX インストール エクスペリエンス
図 1 Windows 10 のアプリ インストーラーと MSIX インストール エクスペリエンス

継続的インテグレーション

MSIX パッケージに CI を設定する場合、Azure Pipelines に優れたサポートが用意されています。YAML ファイルの使用によるコードとしての構成 (CAC) がサポートされていることに加え、MSIX パッケージを作成するために必要なすべてのソフトウェアが事前にインストールされたクラウド ホスト型ビルド エージェントが提供されます。

パッケージ プロジェクトをビルドする前に、ビルド プロセスでは、Visual Studio ウィザードで MSBuild コマンド ラインを使用して行われたのと同じ方法で、Package.appxmanifest ファイル内の Package 要素の Version 属性を編集すれば、生成される MSIX パッケージをバージョン指定できます。Azure Pipelines でこれを実現するには、ビルドのたびに 1 つずつ増加するカウンター変数を設定する式と、.NET の System.Xml.Linq.XDocument クラスを使用して属性の値を変更する PowerShell スクリプトを使用します。図 2 は、ビルド エージェントのステージング ディレクトリにコピーする前に、パッケージ プロジェクトに基づいて MSIX パッケージをバージョン指定して作成する YAML ファイルの例です。

図 2 MSIX ビルド パイプラインを定義する YAML ファイル

pool: 
  vmImage: vs2017-win2016
variables:
  buildPlatform: 'x86'
  buildConfiguration: 'release'
  major: 1
  minor: 0
  build: 0
  revision: $[counter('rev', 0)]
steps:
- powershell: |
   [Reflection.Assembly]::LoadWithPartialName("System.Xml.Linq")
   $path = "Msix/Package.appxmanifest"
   $doc = [System.Xml.Linq.XDocument]::Load($path)
   $xName =
     [System.Xml.Linq.XName]
       "{https://schemas.microsoft.com/appx/manifest/foundation/windows10}Identity"
   $doc.Root.Element($xName).Attribute("Version").Value =
     "$(major).$(minor).$(build).$(revision)";
   $doc.Save($path)
  displayName: 'Version Package Manifest'
- task: MSBuild@1
  inputs:
    solution: Msix/Msix.wapproj
    platform: $(buildPlatform)
    configuration: $(buildConfiguration)
    msbuildArguments: '/p:OutputPath=NonPackagedApp
     /p:UapAppxPackageBuildMode=SideLoadOnly  /p:AppxBundle=Never /p:AppxPackageOutput=$(Build.ArtifactStagingDirectory)\MsixDesktopApp.msix /p:AppxPackageSigningEnabled=false'
  displayName: 'Package the App'
- task: DownloadSecureFile@1
  inputs:
    secureFile: 'certificate.pfx'
  displayName: 'Download Secure PFX File'
- script: '"C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x86\signtool"
    sign /fd SHA256 /f $(Agent.TempDirectory)/certificate.pfx /p secret $(
    Build.ArtifactStagingDirectory)/MsixDesktopApp.msix'
  displayName: 'Sign MSIX Package'
- task: PublishBuildArtifacts@1
  displayName: 'Publish Artifact: drop'

Windows Server 2016 で Visual Studio 2017 を実行するホスト型仮想マシンの名前は、vs2017-win2016 です。この仮想マシンには、必要な UWP と .NET 開発ワークロードが、SignTool も含めてインストールされています。SignTool は、MSIX パッケージが MSBuild によって作成された後、その MSIX パッケージに署名するために使用されます。PFX ファイルはソース管理に追加するべきでないことにご注意ください。それは、既定では Git によっても無視されます。代わりに、Web ポータルの [ライブラリ] タブの下にシークレット ファイルとして Azure Pipelines にアップロードするべきです。このファイルには会社の ID とデジタル署名を表す証明書の秘密キーが含まれているため、必要以上に多くの人に配布するのは望ましくありません。

さまざまな段階で複数の環境にソフトウェアをリリースする大規模な企業では、リリース プロセスの一部としてパッケージに署名を行うようにして、ビルド パイプラインでは署名がないパッケージを生成するようにするのがベスト プラクティスであると考えられます。こうすれば、異なる環境で異なる証明書を使用して署名できるだけでなく、パッケージを Microsoft Store にアップロードして Microsoft 証明書によって署名することもできるようになります。

さらに、PFX ファイルのパスワードなどのシークレットを YAML ファイルに含めるべきではないことにもご注意ください。ターゲット プロセッサ アーキテクチャとパッケージのバージョンを指定する変数とは異なり、それらのシークレットは Web インターフェイスで定義され、設定されます。

図 3 は、Visual Studio の既定のプロジェクト テンプレートを使用して作成し、Windows アプリケーション パッケージ プロジェクトを使用してパッケージ化した WPF アプリケーションのソリューション エクスプローラーを示しています。YAML ファイルがパッケージ プロジェクトに追加されており、コードの残りの部分と一緒にソース コード リポジトリにチェックインされています。

ソース管理にプッシュする準備のできた、パッケージ化された WPF アプリケーション
図 3 ソース管理にプッシュする準備のできた、パッケージ化された WPF アプリケーション

実際のビルド パイプラインを設定するには、dev.azure.com/<組織> の Azure DevOps portal にアクセスし、新しいプロジェクトを作成します。アカウントがない場合は、無料で作成できます。サインインし、プロジェクトを作成した後、https://<組織>@dev.azure.com/<組織>/<プロジェクト>/_git/<プロジェクト> に設定された Git リポジトリにソース コードをプッシュするか、GitHub などその他のプロバイダーを使用することができます。ポータルで最初に [パイプライン] ボタンをクリックし、次いで [新しいパイプライン] をクリックして新しいパイプラインを作成するときに、リポジトリの位置を選択することになります。

次に表示される構成画面では、[既存の Azure Pipelines YAML ファイル] オプションを選択し、リポジトリにチェックインした YAML ファイルへのパスを選択します。図 4 のとおりです。

パイプラインを構成する Web インターフェイス
図 4 パイプラインを構成する Web インターフェイス

ビルドによって生成された MSIX パッケージは、必要な証明書がインストールされている任意の Windows 10 互換コンピューターにダウンロードし、ダブルクリックでインストールすることができます。または、Web サイトかファイル共有にパッケージをコピーする CD パイプラインを設定して、エンド ユーザーがそれをダウンロードできるようにします。これについては、後ほどまた説明します。

自動更新 MSIX パッケージは、それ自体を抽出し、インストール時にマシン上に存在するパッケージ化された前のバージョンのアプリを自動的に置き換えることができますが、.msix ファイルから既にインストールされたアプリをユーザーが開いたときに自動的にアプリを更新する組み込みサポートは、MSIX 形式で提供されていません。

ただし、Windows 10 の April 2018 Update 以降では、自動更新を可能にするアプリ インストーラー ファイルをパッケージと一緒に配置するサポートが提供されています。そのファイルに含まれる MainPackage 要素の Uri 属性は、元の、または更新された MSIX パッケージを参照しています。図 5 は、最小の .appinstaller ファイルの例を示しています。ここで、ルート要素の Uri 属性に、更新されたファイルを OS が検索するファイル共有への URL または UNC パスが指定されていることにご注意ください。現在インストールされているバージョンと新しいアプリ インストーラー ファイルの間で URI が異なる場合、配置操作は "古い" URI にリダイレクトされます。

図 5 \\server\foo 上の更新されたファイルを検索する .appinstaller ファイル

<?xml version="1.0" encoding="utf-8"?>
<AppInstaller xmlns="https://schemas.microsoft.com/appx/appinstaller/2018"
              Version="1.0.0.0"
              Uri="\\server\foo\MsixDesktopApp.appinstaller">
  <MainPackage Name="MyCompany.MySampleApp"
               Publisher="CN=MyCompany, O=MyCompany, L=Stockholm, S=N/A, C=Sweden"
               Version="1.0.0.0"
               Uri="\\server\foo\MsixDesktopApp.msix"
               ProcessorArchitecture="x86"/>
  <UpdateSettings>
    <OnLaunch HoursBetweenUpdateChecks="0" />
  </UpdateSettings>
</AppInstaller>

UpdateSettings 要素は、更新を確認するタイミングと、ユーザーに更新を強制するかどうかをシステムに通知するために使用します。Windows 10 のバージョンごとにサポートされている名前空間を含む完全なスキーマ リファレンスは、bit.ly/2TGWnCR のドキュメントをご覧ください。

図 5 の .appinstaller ファイルをパッケージ プロジェクトに追加し、[パッケージ アクション] プロパティを [コンテンツ] に、[出力ディレクトリにコピー] プロパティを [新しい場合はコピーする] に設定した場合は、ルート要素と MainPackage 要素の Version 属性の更新と、更新済みファイルのステージング ディレクトリへの保存を行う、別の PowerShell タスクを YAML ファイルに追加できます。

- powershell: |
  [Reflection.Assembly]::LoadWithPartialName("System.Xml.Linq")
  $doc = [System.Xml.Linq.XDocument]::Load(
    "$(Build.SourcesDirectory)/Msix/Package.appinstaller")
  $version = "$(major).$(minor).$(build).$(revision)"
  $doc.Root.Attribute("Version").Value = $version;
  $xName =
    [System.Xml.Linq.XName]
      "{https://schemas.microsoft.com/appx/appinstaller/2018}MainPackage"
  $doc.Root.Element($xName).Attribute("Version").Value = $version;
  $doc.Save("$(Build.ArtifactStagingDirectory)/MsixDesktopApp.appinstaller")
displayName: 'Version App Installer File'

その後、.appinstaller ファイルをエンド ユーザーに配布し、.msix ファイルではなく、このファイルをダブルクリックしてパッケージ化されたアプリをインストールしてもらいます。

継続的配置

アプリ インストーラー ファイル自体はコンパイルされていない XML ファイルなので、必要な場合はビルド後に編集可能です。そのため、複数の環境にソフトウェアを配置する場合や、ビルド パイプラインをリリース プロセスから分離する場合に使いやすくなっています。

図 6 に示したように [空のジョブ] テンプレートを使用して Azure portal でリリース パイプラインを作成し、最近設定したビルド パイプラインを、配置する成果物のソースとして使用する場合は、.appinstaller ファイルにある 2 つの Uri 属性の値を、アプリの発行先となる場所を反映するように動的に変更する図 7 の PowerShell タスクをリリース ステージに追加できます。

Azure DevOps ポータルの [パイプライン] タブ
図 6 Azure DevOps ポータルの [パイプライン] タブ

図 7 .appinstaller ファイルの Uri を変更するリリース パイプライン タスク

- powershell: |
  [Reflection.Assembly]::LoadWithPartialName("System.Xml.Linq")
  $fileShare = "\\filesharestorageccount.file.core.windows.net\myfileshare\"
  $localFilePath =
    "$(System.DefaultWorkingDirectory)\_MsixDesktopApp\drop\MsixDesktopApp.appinstaller"
  $doc = [System.Xml.Linq.XDocument]::Load("$localFilePath")
  $doc.Root.Attribute("Uri").Value = [string]::Format('{0}{1}', $fileShare,
    'MsixDesktopApp.appinstaller')
  $xName =
    [System.Xml.Linq.XName]"{https://schemas.microsoft.com/appx/appinstaller/2018}MainPackage"
  $doc.Root.Element($xName).Attribute("Uri").Value = [string]::Format('{0}{1}',
    $fileShare, 'MsixDesktopApp.appx')
  $doc.Save("$localFilePath")
displayName: 'Modify URIs in App Installer File'

図 7 のタスクで、URI は、Azure ファイル共有の UNC パスに設定されます。これはアプリをインストールして更新するときに OS が MSIX パッケージを検索する場所であるため、xcopy コマンドを使用して .appinstaller ファイルと .msix ファイルをコピーする前に、私は、まずクラウド内のファイル共有をビルド エージェント上のローカルの Z:\ ドライブにマップする別のコマンドライン スクリプトをリリース パイプラインに追加しました。

- script: |
  net use Z: \\filesharestorageccount.file.core.windows.net\myfileshare
    /u:AZURE\filesharestorageccount
    3PTYC+ociHIwNgCnyg7zsWoKBxRmkEc4Aew4FMzbpUl/
    dydo/3HVnl71XPe0uWxQcLddEUuq0fN8Ltcpc0LYeg==
  xcopy $(System.DefaultWorkingDirectory)\_MsixDesktopApp\drop Z:\ /Y
  displayName: 'Publish App Installer File and MSIX package'

もちろん、独自のオンプレミス Azure DevOps Server をホストしている場合は、独自の内部ネットワーク共有にファイルを発行して構いません。

Web インストール Web サーバーに発行することにした場合は、バージョン管理された .appinstaller ファイルと、ダウンロード リンクとパッケージ化したアプリに関する情報を含む HTML ページを生成するように MSBuild に指定するため、いくつかの追加の引数を YAML ファイルに提供できます。

- task: MSBuild@1
  inputs:
    solution: Msix/Msix.wapproj
    platform: $(buildPlatform)
    configuration: $(buildConfiguration)
    msbuildArguments: '/p:OutputPath=NonPackagedApp /p:UapAppxPackageBuildMode=SideLoadOnly  /p:AppxBundle=Never /p:GenerateAppInstallerFile=True
/p:AppInstallerUri=http://yourwebsite.com/packages/ /p:AppInstallerCheckForUpdateFrequency=OnApplicationRun /p:AppInstallerUpdateFrequency=1 /p:AppxPackageDir=$(Build.ArtifactStagingDirectory)/'
  displayName: 'Package the App'

図 8 は、前のコマンドを実行した後のビルド エージェント上のステージング ディレクトリの内容を示しています。これは、Visual Studio でサイドローディング用のパッケージの作成を選択し、[自動更新を有効にする] チェック ボックスを選択した場合にウィザードから取得されるのと同じ出力です。このアプローチを使用すると、更新の動作を構成する際の柔軟性がいくらか犠牲になる可能性がありますが、.appinstaller ファイルを手動で作成する必要がなくなります。

Azure DevOps ポータルのビルド成果物エクスプローラー
図 8 Azure DevOps ポータルのビルド成果物エクスプローラー

生成された HTML ファイルには、ブラウザーに依存しない ms-appinstaller プロトコル アクティブ化スキームが前に付いたハイパーリンクが含まれます。

<a href="ms-appinstaller:?source=
  http://yourwebsite.com/packages/Msix_x86.appinstaller ">Install App</a>

格納フォルダーの内容をイントラネットまたは他の Web サイトに発行するリリース パイプラインを設定した場合、Web サーバーがバイト範囲要求をサポートしており、かつ正しく構成されていれば、エンド ユーザーは最初に MSIX パッケージをダウンロードせずに、このリンクを使用してアプリを直接インストールできます。

まとめ

この記事では、Visual Studio を使用すれば、.NET デスクトップ アプリケーションを MSIX として簡単にパッケージ化できることを説明しました。また、Azure Pipelines で CI および CD パイプラインを設定する方法と、自動更新を構成する方法も説明しました。MSIX は、Windows 上にアプリケーションを配置する最新の方法です。安全性と信頼性が高く、セキュリティで保護することができます。アプリを Microsoft Store にアップロードしたり、企業内のコンピューターにサイドロードしたりするかどうかに関係なく、Windows 10 で導入された新しいアプリ モデルと最新の API のメリットを自社と顧客の両方で活用することができます。すべてのユーザーが Windows 10 に移行を完了しているのであれば、存在するほとんどの Windows デスクトップ アプリをパッケージ化するために MSIX を活用できるはずです。

Magnus Montin氏は、スウェーデンのストックホルムで自営ソフトウェア開発者およびコンサルタントとして働く Microsoft MVP です。.NET と Microsoft スタックを専門とし、10 年以上の実務経験を持ちます。ブログは blog.magnusmontin.net​ で公開されています。

この記事のレビューに協力してくれたマイクロソフト技術スタッフのMatteo Pagani 氏 (Matteo.Pagani@microsoft.com) に感謝します
Matteo Pagani 氏は、クライアント開発と Windows プラットフォームに並々ならぬ情熱を傾けている開発者です。世界中のカンファレンスで定期的に講演を行い、書籍を執筆し、テクノロジ Web サイトとブログに定期的にテクニカル記事を投稿しています。Windows 開発のカテゴリで 5 年間 Microsoft MVP を務めた後、Microsoft に入社して Windows AppConsult チームのエンジニアとして働いています。

この記事について MSDN マガジン フォーラムで議論する