Desktop App Converterの実態に迫る/配布前にチェックすべきこと

開発担当の橋本孔明です。

前回の記事「従来のアプリをWindows 10のUWPアプリ形式にパッケージングする『Desktop App Converter』」は、おかげさまでDesktop App Converterを試してみたい方などから大きな反響をいただきました。第2回からはその続編として、実用に向け、もうちょっと具体的な内容に迫っていきたいと思います。

Desktop App Converterの実態とは

Desktop App Converterは、説明だけ聞くと「このコンバーターを通さないと従来アプリをUWPアプリに変換することはできない」と思ってしまいますが、実はそうではありません。

この技術の根幹は、Windows10 Anniversary Updateで新たに「FullTrustApplication」というアプリ形式へ対応したことが最も大きなポイントとなっています。FullTrustApplicationは、ものすごく大ざっぱに言ってしまえば「従来のWin32アプリケーションをUWPアプリのようにパッケージ管理し、ある程度(本来のUWPアプリほどではないが)の監視下で動作させられるモード(ただしデスクトップ版Windows専用)」であり、その動作の詳細はアプリケーションに内包されるアプリケーションマニフェスト(AppxManifest.xml)に記述されます。

そして、Desktop App Converterは、従来型アプリのインストーラの動作を解析することで、アプリパッケージ内へのプログラム関連ファイル(およびシステムファイルやレジストリの仮想化データ)の自動配置と、アプリケーションマニフェストの自動生成を行うためのツールなのです。

これを逆に考えると、ファイルの配置がそれほど複雑ではない場合(例えば簡易なオンラインソフトのように、インストール先のルートフォルダに実行ファイルなどを配置するだけでOKなケースなど)、アプリケーションマニフェストを手書きするだけで、Desktop App Converterを通さずにアプリパッケージを作ることが可能です。

同時に、いったんDesktop App Converterでパッケージを生成してしまえば、あとはそれを手動修正していくだけで(毎回変換し直すことをせず)以後のメンテナンスは可能だということでもあります。よほど頻繁にインストール構成が変化するようなバージョンアップを繰り返している場合でもなければ、基本的にはこのスタイル(手動での修正)でパッケージを管理していくのがよいでしょう。

ファイルサイズをより小さく:自動生成されたパッケージの中身をクリーニング

Desktop App Converterは、前回紹介したように、インストーラが実施したシステムへの変更をすべて記録し、変換後のアプリパッケージへと反映します。この検知機構は非常によくできている反面、大半のケースにおいて、余計なデータまで記録を取ってしまい、無駄なデータがアプリパッケージに混入してしまうようです。

そこでまず、生成されたパッケージ内のファイルを確認し、不要そうなデータを削除(クリーニング)してパッケージのスリム化を図ります。

本記事第1回で使用したサンプルプログラムでは、プログラム本体「DACTest.exe」のみがインストーラーに含まれます。このインストーラーを変換した結果、生成されたアプリパッケージフォルダには下記のようなファイルが格納されました。

生成・格納されたファイルの一覧

生成・格納されたファイルの一覧

プログラム本体である「DACTest.exe」、アプリケーションマニフェストの「AppxManifest.xml」、パッケージアイコンなどのリソースが格納される「Assets」フォルダを始めとして、今回使用したインストーラー「EXEpress」がインストール実行時にアンインストーラーとして生成した「epuninst.exe」、および「VFS」というフォルダと「Registry.dat」というファイルが増えていることがわかります。

クリーニングはまず、明確に不要なファイルを削除することから始めましょう。UWPアプリは対話型のアンインストーラーを使用することができませんので、アンインストーラー実行ファイルである「epuninst.exe」は不要です。

次に、「Registry.dat」というのは、インストール処理中にアクセスが発生したレジストリ項目をすべてコピーしておき、UWPアプリの動作時に仮想化したレジストリデータの参照元となる、レジストリハイブファイルと呼ばれるものです。UWPアプリとして動作させると、このファイル内に記録されているレジストリ項目は、本来のレジストリへのアクセスを行う際にオーバーライドされ、優先して参照されるようになります。今回のアプリは、初期状態で特定のレジストリ項目が存在しなくても特に動作に支障はありませんので、このファイルも削除してしまうことができます。

さらに、「VFS」というフォルダは中にたくさんのサブフォルダが生成されていることがわかります。

VFSフォルダの内容

VFSフォルダの内容

これは変換時のインストール処理中にDesktop App Converterがアクセスを検出した、システムフォルダ内のファイルをコピーしたもので、UWPアプリからのアクセス時にリダイレクト対象となります。詳細は変換先のlogsフォルダにログが入っています。

レジストリ同様、ファイルへのアクセス検出もかなり細かく行われるため、実際にはアプリの動作用としては不要なファイルが相当な数含まれてしまっています。初回起動するにあたって特に必要なファイルが存在しないようであれば、個々のフォルダあるいはVFSフォルダまるごとを削除してしまって構いません。ちなみに、アクセス権限を継承したままファイルをコピーしたりする関係か、このフォルダを削除する際にエラーメッセージや確認・警告などが表示される場合がありますが、そのまま続行しても大丈夫です。

今回のテスト プログラムでは、これらのクリーニングを行った結果、実に約30MB(29,071,995 バイト)ものデータをパッケージから削除する結果となりました。規模の大きなアプリになると100MB~GB単位のクリーニングが行えるケースもありそうですので、できれば入念に確認するようにしてみてください。

特に注意すべきこと

このほか注意事項ですが、前述のように、インストール中にアクセスのあったレジストリやファイルが丸ごとコピーされるということは、例えばレジストリやAppDataフォルダ内のファイルにユーザー情報や登録ライセンスなどを記録しているようなアプリの場合、アプリを使い込んだりライセンス登録を行った状態から変換したりすると、それらの個人情報や登録情報などがまるごとパッケージにコピーされ、配布対象となってしまう可能性もあるということになります。Registry.datやVFSフォルダを削除せずに運用したいのであれば、Desktop App Converterでの変換は、アプリがクリーン インストールされるよう、なるべくまっさらなWindows 10環境で実行するようにしたほうがよいでしょう。

アプリケーション マニフェストを手直しする

変換で自動生成されたAppxManifest.xmlの内容は、必要に応じて手直しすることができます。

例えば、パッケージ アイコンとして生成されるファイルは「SampleAppx.50×50.png」という名前になりますので、このファイル名を変更したい場合、マニフェスト ファイル内の記述(<Package> – <Properties> – <Logo> タグ内)も修正することになります。

各項目の詳細は、MSDNにドキュメントがありますが、本来のUWPアプリ向けの内容となっているため、使えない項目も多いことに注意してください。基本的には、今後紹介予定の拡張機能を追加したりしない限り、新しい項目を増やすことはせず、文字列の修正程度にとどめておくのが無難だと思います。

パッケージを単体でインストールできるようにする

UWPアプリは、最終的にはMicrosoftストアに登録して配布することが目標となりますが、自前で署名を行うことにより、パッケージ単体(.appx)でのインストールも可能です(AndroidでいうところのAPK配布と同じです)。一般配布を行う場合は適切な証明機関から発行された証明書が必要となりますが、社内配布や動作検証目的など、とりあえず動作すればよいという場合は、自前で生成した証明書(「オレオレ証明書」などとも呼ばれます)を用いて署名を行い、証明書と共にappxを渡すことでインストールができるようになります。

* 自分で試した限りでは、Microsoft ストアへの登録にはこのような手動での署名は不要で、未署名のappxを提出して申請することができるようです。

証明書の生成および署名の方法については、MSDNにドキュメントがあります。

* 上記の手順中、「CN=<publisher_name>」として発行者を指定する部分には、AppxManifest.xml内の発行者指定(<Package> – <Identity> タグの”Publisher”属性)と同じ文字列を記述するようにします。

署名が完了したら、appxとともに証明書(.cerファイル)を渡し、証明書をPCに登録することでappxからアプリのインストールが可能になります。

その方法ですが、アプリをインストールしたいWindows 10環境上で.cerファイルをダブルクリックすると「証明書」というページが開きますので、「証明書のインストール」をクリックします。「保存場所」を「ローカル コンピュータ」に変更して続行し、「証明書ストア」ページでは「証明書をすべて次のストアに配置する」を選択、「参照」で「信頼されたルート証明機関」を選んで続行すればOKです。

なお、前述しましたが、自分で証明書を生成する方式はセキュリティ的にまったく安全ではありませんので、社内配布や動作検証目的などにとどめるようにしてください。

タグ , , , , | 2020/06/16 更新 |