MicrosoftStore
アプリを Microsoft Store で公開するに当たっては、Store 側の認定を経なければなりませんが、申請してから認定されるまでにかかる時間はどれくらいなのか、まとめてみました。全 12 回のサンプルで、所要時間の割合は以下の通りでした。
| ～6 時間以下 | 16.7 % |
|---|---|
| 6 時間超 ～ 1 日以下 | 16.7 % |
| 1 日超 ～ 3 日以下 | 41.7 % |
| 3 日超 ～ | 25.0 % |
所要時間は、提出ボタンを押してから、結果の通知メールが来るまでの時間で測定しています。最近は通知メールが来なくなってしまったので、最近の結果は含めていません（設定でメール来るように出来るのか探しているのですが見つかりません……）。
申請の際には「通常数時間」「最大 3 営業日」かかると表示されます。数時間が 2～3 時間なのか 5～6 時間なのか分かりませんが、多めに 5～6 時間としても、数時間で結果が来るのは 2 割以下という統計になりました。
1～3 日のパターンが一番多いので、「通常 3 日以内」と表示するほうが適切な気がします。
メールは土日や夜に来ることもあるので、認定作業は割といつでもやっているようです。
関連記事
開発者用ダウンロードとして公開している MSIX パッケージからのアプリインストール方法をまとめました。
PC 操作の知識と管理者権限が必要です。
事前準備
予め、PC の設定を変更しておきます。Windows の設定で「開発者向け」のページを開きます。
開発者モードを「オン」にします。
また、PowerShell（署名無しスクリプトの許可）の適用ボタンをクリックします。アンインストール
対象のアプリが既にインストールされている場合は、アンインストールします。
ダウンロード
配布サイトから zip ファイルをダウンロードします。
zip ファイル名の後半に数字が並んでいますが、その数字の先頭がバージョンを表しています。
例えば、「NicoKaraMaker2_Package_11.53.11.0_Test.zip」であれば、Ver 11.53 ということになります。目的のバージョンのファイルをダウンロードします。
ダウンロードした zip ファイルを解凍しておきます。
アプリのインストール
スタートメニューを右クリックし、PowerShell を管理者権限で実行します。PowerShell で、zip ファイルを解凍したフォルダーからさらに 1 階層深いフォルダーの中にある Install.ps1 を実行します。
エクスプローラーから PowerShell へ Install.ps1 をドラッグ＆ドロップして Install.ps1 のフルパスが入力された場合は、Enter を押して Install.ps1 を実行します。
ドラッグ＆ドロップがうまくいかない場合は以下を行います。
まず、PowerShell の中でフォルダーを移動します。「CD」に続けてスペースを入れ、フォルダーを入れます。
例えば、「C:\Temp\NicoKaraMaker2_Package_11.53.11.0_Test\NicoKaraMaker2_11.53.11.0_Test」フォルダーの中に Install.ps1 がある場合は、
PS> CD C:\Temp\NicoKaraMaker2_Package_11.53.11.0_Test\NicoKaraMaker2_11.53.11.0_Test
Install.ps1 を実行します。PS> .\Install.ps1
新しい PowerShell が開き、証明書のインストールについて尋ねられるので、Y で回答します。
証明書のインストールが終わると、元の PowerShell に戻り、インストールが続行します。
「アプリは正常にインストールされました」表示されればインストール完了です。起動
PowerShell を実行したユーザーのスタートメニューにアプリが登録されているので、スタートメニューから起動して動作確認をします。
注意点
この方法でインストールしたアプリは、バージョンアップ版が公開されても自動的に更新されません。
いったんアプリをアンインストールしたうえで、Microsoft Store から最新版をインストールしてください。
更新履歴
- 2022/06/14 初版。
- 2023/11/12 アプリのインストールの記載を更新。
ニコカラメーカー 2 およびゆかりすたー 4 NEBULA は、Microsoft Store（以降「ストア」と表記）での配布となりました（引き続き無料です）。なぜストアで配布することにしたのかというと、以下のような様々なメリットがあるためです。
インストールがさらに簡単に
これまでもインストールは簡単でしたが、ストア配布によりさらにインストールが簡単になりました。
ストアの「入手」または「インストール」ボタンをクリックするだけでインストールが完了します。
ストアの「入手」または「インストール」ボタンをクリックするだけでインストールが完了します。
スタートメニュー自動登録
インストールすると、スタートメニューにも自動的に登録されます。
（補足）
起動時はスタートメニューから起動してください。
旧 zip バージョンの時に作成したショートカットから起動すると旧バージョンが起動してしまいます。
SmartScreen による妨害がない
これまでは、アプリを起動しようとすると SmartScreen の画面が表示されて、いくつか画面をクリックしないと起動できない場合がありました。
ストア配布により SmartScreen が表示されなくなるため、起動が簡単になります。
ストア配布により SmartScreen が表示されなくなるため、起動が簡単になります。
更新がさらに簡単に
これまでも更新（バージョンアップ）は簡単でしたが、ストア配布によりさらに更新が簡単になりました。
更新版が公開されると、自動的に更新版がインストールされますので、何ら画面で操作する必要はありません。
更新版が公開されると、自動的に更新版がインストールされますので、何ら画面で操作する必要はありません。
（補足）
旧 zip 版からストア配布版への自動更新は行われません。
ストア配布のアプリを最初の 1 回はストアで入手する必要があります。
PC 買い換え時に楽
パソコンを買い換えた時や、あるいは Windows をクリーンインストールした時など、他のストアアプリと一緒にまとめてインストールすることができます。個別にインストールする必要がないので手間がかかりません。
ストア配布リンク
ストアへの移行は大きな変更となりますので、変更内容をまとめました。
なお、アプリ名はこれまで「ゆかりすたー NEBULA」でしたが、世代が分かりやすいようにナンバリングを入れて「ゆかりすたー 4 NEBULA」となりました。
ストアのメリット
なぜストアで配布することにしたのかというと、様々なメリットがあるためです。
メリットの詳細については別記事に整理しましたのでそちらをご覧ください。
インストール
Ver 4.60 以前のゆかりすたー 4 NEBULA からストア配布の新バージョンへの自動更新は行われません。お手数ですが、ストアから新バージョンをインストールしてください。
ストア版から今後のストア版へは自動更新されます。
楽曲情報データベースの引き継ぎ
Ver 4.60 以前のゆかりすたー 4 NEBULA を使用していた方は、ストア配布の新バージョンゆかりすたー 4 NEBULA の使用にあたり、楽曲情報データベースの引き継ぎ（移行）が必要となります。
引き継ぎは、Ver 4.60 以前→ストア版への移行に当たり 1 回のみ行ってください。ストア版からストア版への更新に当たっては引き継ぎは不要です。
同期機能を使用しているか使用していないかで引き継ぎ方法が異なります。お手数ですが、利用方法に合った引き継ぎを行ってください。
同期機能を使用していない場合の引き継ぎ
インポート
新バージョンのゆかりすたー 4 NEBULA はスタートメニュー（「や」行のセクションに登録されています）から起動できますので、起動します。
環境設定ウィンドウの楽曲情報一括操作タブを開きます。インポートセクションでインポート元ファイルとして旧バージョンの楽曲情報データベースを指定します（デフォルトではサンプルファイルが指定されているので変更します）。
旧バージョンの楽曲情報データベースは
C:\xampp\htdocs\YukaLister\Database\NebulaMusicInfo.sqlite3
に保存されています。
「タグ情報をインポートする」「同名の情報も極力インポートする」の 2 つのオプションのチェックを入れます。
インポートボタンをクリックすると、旧バージョンの楽曲情報データベースが新バージョンに取り込まれます。
環境設定ウィンドウの楽曲情報一覧タブで、きちんと引き継ぎができたかどうかを確認します。
旧バージョンの削除
引き継ぎを確認できたら、今後の誤起動を防止するために、旧バージョンのゆかりすたー 4 NEBULA はフォルダーごと削除するか、もしくは、普段使わないフォルダーに移動すると良いでしょう。
同期機能を使用している場合の引き継ぎ
タグ情報以外の引き継ぎ
スタートメニューから新バージョンのゆかりすたー 4 NEBULA を起動し、環境設定ウィンドウの同期タブを開きます。強制的に合わせるボタンをクリックします。
環境設定ウィンドウを閉じると、タグ情報以外の楽曲情報データベースが最新化されます。
タグ情報の引き継ぎ
タグ情報を入力している場合は、タグ情報以外の引き継ぎをした「後」で、同期機能を使用していない場合の引き継ぎのやり方で引き継ぎをすると、タグ情報も引き継がれます。
旧バージョンの削除
引き継ぎを確認できたら、今後の誤起動を防止するために、旧バージョンのゆかりすたー 4 NEBULA はフォルダーごと削除するか、もしくは、普段使わないフォルダーに移動すると良いでしょう。
Win32 Desktop Bridge でアプリを Microsoft Store 配布用に MSIX パッケージ化した場合、デフォルトのままでは、x64 でパッケージ化しても、実際には 64 ビットなアプリにはなりません（Visual Studio 2022 17.0.4 現在）。
状況整理
パッケージプロジェクト（TestMsStoreWpf_Package）の［公開 → アプリパッケージの作成］で MSIX パッケージを作成する際、アーキテクチャを x64 にしただけでは、x64 なアプリは作成されません。
アプリを実行してタスクマネージャーを見てみると、「（32 ビット）」の表記はないので、一見すると 64 ビットアプリのように見えます。しかし実際には、Environment.Is64BitProcess は false が返ってきますし（パッケージ化する前はちゃんと true が返ってきます）、4 GB 以上のメモリアロケートもできません。なんちゃって 64 ビットアプリになってしまっています。
解決方法
【注意】本記事の解決方法は情報が古くなりました。新しい解決方法については、こちらをご覧ください。備忘として以下を残しておきます。
本体プロジェクト（TestMsStoreWpf）のプロパティーで、Platform Target を Any CPU ではなく x64 に変更します。しかしこうすると、本体プロジェクトはビルド・実行できるのですが、パッケージプロジェクトで MSIX パッケージを作成しようとすると、次のようなエラーになってしまいます。
資産ファイル '～\obj\wappublish\win-x64\project.assets.json' が見つかりません。
以降で、きちんとビルド・実行できるように対策していきます。
間違いを防止するために、いったん、本体プロジェクトの bin フォルダー・obj フォルダーを削除します。
本体プロジェクトのプロパティーで Platform Target が x64 になっていることを確認したうえで、Release | x64 で本体プロジェクトをビルドします。
obj フォルダーに project.assets.json を含む 5 つのファイルが作成されます。obj フォルダーの中に wappublish フォルダーを作成し、さらにその中に win-x64 フォルダーを作成します。
作成した win-x64 の中に、project.assets.json を含む 5 つのファイルをコピーします（project.assets.json だけでもいいのかもしれませんが）。
コピーした win-x64 フォルダーの project.assets.json を編集します。先頭付近にある targets セクションの、「"net6.0-windows10.0.19041": {}」の行末にカンマを追加し、その次の行として「"net6.0-windows10.0.19041/win-x64": {}」を追加します（ターゲット OS バージョンが 10.0.19041.0 の場合）。
"targets": {
"net6.0-windows10.0.19041": {},
"net6.0-windows10.0.19041/win-x64": {}
},
その後パッケージプロジェクトをビルドすると、真に 64 ビットの MSIX パッケージが作成されます。パッケージをインストールしても、Environment.Is64BitProcess が true になります。
なお、パッケージプロジェクトビルドの際に「アプリケーション マニフェストが無効なため、アプリケーション パッケージを作成できませんでした。アプリケーション マニフェストのエラーを修正してください。」というエラーになる場合がありますが、構わず再度ビルドするとビルドできます。このエラーは、x64 かどうかに関わらず発生します。
Win32 Desktop Bridge でアプリを Microsoft Store 配布用に MSIX パッケージ化した場合、ストア配布する前にローカルで動作確認する方法を整理しました。管理者権限が必要です。
事前準備
予め、PC の設定を変更しておきます。Windows の設定で「開発者向け」のページを開きます。
開発者モードを「オン」にします。
また、PowerShell（署名無しスクリプトの許可）の適用ボタンをクリックします。アプリのインストール
PowerShell を実行します。
MSIX パッケージが生成されたフォルダー（.msixupload ファイルがあるフォルダー）からさらに 1 階層深いフォルダー（Install.ps1 ファイルがあるフォルダー）に移動します。
PS> CD 目的のフォルダーパス
Install.ps を実行します。PS> .\Install.ps
新しい PowerShell が開き、証明書のインストールについて尋ねられるので、Y で回答します。証明書のインストールが終わると、元の PowerShell に戻り、インストールが続行します。「アプリは正常にインストールされました」表示されればインストール完了です。起動
PowerShell を実行したユーザーのスタートメニューにアプリが登録されているので、スタートメニューから起動して動作確認をします。
関連リンク
WPF（Win32）等の非 UWP アプリを Microsoft Store（旧 Windows Store）で配布する場合、自前のウェブサイトでの配布と比べてどんなメリット・デメリットがあるのか。
ユーザー（利用者）側の視点と、開発者側の視点、それぞれで挙げてみました。WPF アプリを Microsoft Store に申請・登録する一環としての整理です。
ユーザーにとってのメリット
インストールが簡単
ストア配布の場合、ユーザーは「入手」ボタンを押すだけでアプリをインストールできるため、とても簡単です。スタートメニューにも自動的に登録されます。自前配布の場合でもインストーラーの出来が良ければワンクリックでインストールできますが、中にはステップが多かったり、余計なアプリも一緒に入れさせようとするインストーラーもあります。
zip 配布の場合、解凍するだけで良いのであれば操作は簡単ですが、スタートメニューには自動登録されません。また、解凍先を Program Files にしてしまうと Virtual Store が悪さをする恐れもあります。同梱されている exe ファイル数が多い場合など、どれを実行すれば良いのか迷うこともあります。
SmartScreen による妨害がない
ストア配布のアプリは、起動すると問題なく起動できます。
自前配布のアプリは、初回起動時に SmartScreen によって起動がブロックされ、いくつか画面をクリックしないと起動できないことがあります。
更新が簡単
ストア配布の場合、アプリの新バージョンが公開されると自動的に更新されるため、ユーザーは特に操作は必要ありません。自動更新まで多少のタイムラグはあり、それが嫌な場合は手動で更新することになりますが、それでも更新ボタンを押す程度です。
自前配布の場合、自動更新機能がないアプリも多いので、更新版があるかを自分で確認し、更新版があれば再度インストールする形になります。
自前配布の場合、自動更新機能がないアプリも多いので、更新版があるかを自分で確認し、更新版があれば再度インストールする形になります。
アンインストールが簡単
ストア配布の場合、「アプリと機能」からワンクリックでアンインストールできます。自前配布の場合、アンインストール機能がないアプリも多いので、手動でのアンインストールを余儀なくされます。
PC 買い換え時に楽
PC 買い換え時や Windows のクリーンインストール時など、ストアから過去にダウンロードしたアプリを、まとめて新しいデバイスにインストールできます。
なお、本節の主な内容を抜き出し、ユーザー向けに別ページに整理しています。
ユーザーにとってのデメリット
知らないアプリを探しづらい
ストアでアプリを探す際、キーワード検索しかできないため、アプリを事前に知っていないと入手は困難です。
アプリのカテゴリー分けはされているのですが、ストアアプリで探すときはカテゴリーから探せません。ストアの Web 版はカテゴリーによる絞り込みができますが、他の条件との複合絞り込みになってしまうなど、使い勝手がイマイチです。
ストアアプリでもカテゴリー表示ができるようになったり、あるいはユーザーが付与するタグによる類似アプリ検索ができるようにするなど、知らないアプリと出会える仕組みがあると良いのですが。
アプリの新旧が分からない
ストアで表示されるリリース日は、アプリが初めて登録された日のようです。アプリが更新されてもリリース日は更新されないため、現在も開発が続いているアプリなのか、古いアプリなのかが分かりません。
Microsoft アカウントが必要
ストアアプリをインストールするには、Microsoft アカウントが必要です。
とはいえ、多くの Windows ユーザーは Windows インストール時に Microsoft アカウントを作成しているはずなので、これは大したデメリットではありません。
開発者にとってのメリット
配信基盤整備が不要
開発者はアプリ自体を開発すればよく、インストーラー・アンインストーラーの開発、配信や自動更新の仕組みの用意は不要です。
無料・有料アプリ両対応
ストアでは、無料アプリも有料アプリも配信できます。
無料アプリ配信時の手数料は無料です。
有料アプリ配信時の手数料は標準で 15% のようです。キャンペーン価格の設定など柔軟な設定が可能なようです。
使用状況の把握
配布しているアプリがどのくらい取得されたか、どのくらい使用されているかをグラフで閲覧することができます。tsv 形式でダウンロードすることもできます。取得はまだしも、使用については自前で把握しようとするのはかなり労力がかかりますので、ストアならではのメリットと言えるのではないでしょうか。
不正コピーの低減
ストア配布のアプリは不正コピーが困難になると Microsoft は主張しています。
とはいえ私が自分で配布しているストアアプリを、ストアを経由せずにコピーしてみたら普通にコピーできました。無料アプリだったので特に制限がかからなかったのか、それ以外の要因があるのかは不明です。
開発者にとってのデメリット
配布に手間がかかる
アプリ開発時、ストアの審査に合格するように開発する必要があり、自前配布よりも手間がかかります。
アプリ本体の開発後も、MSIX パッケージの作成、ストアへの各種情報入力など、新規配布や更新の度に手間がかかります。審査に不合格になると修正の手間も発生します。
配布までのタイムラグがある
ストア審査の分、配布までに時間がかかります。審査は最短でも 1 時間弱、長いときは丸 7 日近くかかったこともありました。審査に不合格になって修正となれば、さらに時間がかかります。
配布できないリスクがある
ストア審査に合格できなければストア配布できません。
今まで配布できていたアプリが Microsoft の胸ひとつで配布できなくなってしまうリスクもはらんでいます。
自前サイトは無くせない
ストアでのアプリ配布ページから、アプリ紹介ページやプライバシーポリシーへのリンクが必須です。このため自前サイトを維持し、これらの情報を掲載する必要があります。
ストアアプリが保持できない機能がある
UWP ほどの制限ではありませんが、管理者権限への昇格が必要なアプリはストアで受け入れられないという記述があるなど、一部の機能があるとストアでの配布ができないようです。
とはいえ、Visual Studio など、インストール時に管理者権限が必要なアプリも登録されていたりするのが謎です。
しょぼいアプリだと思われるリスクがある
これまでストア配布のアプリは UWP アプリだったため、機能にかなり制限があり、しょぼいアプリがほとんどでした。
Desktop Bridge により非 UWP なフル機能のアプリを登録できるようになりましたが、ユーザーからは UWP なのかフル機能アプリなのか見分けはつきません。
ストア配布のアプリはしょぼいというイメージは根強いと思われ、フル機能のアプリを配布しても先入観でしょぼいと思われてしまうリスクがあります。
古いアプリだと思われてしまう
前述のように、リリース日として表示される日付が登録日のため、更新版をリリースしてもリリース日が更新されず、古いアプリだと思われてしまいます。
開発者登録費用がかかる
ストア配布するには、開発者（パートナー）としての登録が必要で、その際に 2,000 円程度の費用がかかります。
とはいえ、一発ものの費用で、維持費はかからないので、これは大したデメリットではありません。
ストア配布事例
個人（っぽい人）でストア配布しているアプリを探してみました。非 UWP っぽいと思われるものと中心にしていますが、見分けは付かないため、UWP が混じっているかもしれません。
他にも事例がありましたら是非教えてください。
日本
- SHINTA：ニコカラメーカー 2、ゆかりすたー 4 NEBULA、ゆっこビュー 2
- Atsushi M. Ito 氏：NowType
- beditor 氏：BEditor
- Crystal Dew World 氏：CrystalDiskMark
- masakazu matsubara 氏：A5:SQL Mk-2 (x64)
- Nia Tomonaka 氏：WSB Manager
- Tatsuro Shibamura 氏：Toy Camera、WinQuickLook
- だるやなぎ氏：Tonjiru
海外
- Irfan Skiljan 氏：IrfanView64
- Nicke 氏：ScreenToGif
関連記事
参考資料
前回配布したアプリのバージョンアップをします。
アプリ更新編 目次
更新版アプリのパッケージ作成
アプリのソースコード（XAML）の「Ver 1」の部分を「Ver 2」に変更します。
動作を確認したら、更新版のアプリで再度パッケージを作成します。パッケージ作成前に、ソリューションのクリーンをしておくほうが良いようです。
後でパッケージをアップロードする際、「お客様の申請には、パッケージのコンテンツは異なっているが、提供されている他のパッケージと同じフルネームを持つパッケージが含まれています」というエラーになり、パッケージのバージョンは上げているのに何故だろうと悩んだのですが、クリーンすることでエラーが出なくなりました。
パッケージ作成時の処理で初回と異なるのは、配布方法選択時に、既存のアプリ名を選択することです。また、バージョン番号も上げておきます（デフォルトでは自動で末尾が上がります）。
パッケージ作成後、WACK が合格になることを確認するのは初回と変わりません。
更新申請
Microsoft パートナーセンターのアプリケーションの概要ページで更新リンクをクリックします。更新申請の場合は、変更のあるページのみ処理すれば構いません。
「パッケージ」ページで、Ver 2 のパッケージをアップロードします（スクリーンショットは Ver 4→Ver 5 の時のものですが、Ver 1→Ver 2 でも操作は同様です）。初回のパッケージ（Ver 1）も引き続き存続しているので、パッケージが 2 つになります。新しいほうが 1（青色）、古いほうが 2（橙色）で示されます。新しいパッケージを利用できない環境では古いパッケージにフォールバックするようですが、フォールバックが不要なら古いパッケージは削除しても構わないと思います。
古いパッケージを存続させても、表示されるアプリサイズは増えません。Ver 1 も 2 も 140 MB ほどのサイズが表示されました。
「Store 登録情報 - 日本語（日本）」ページで、「このバージョンの最新情報」欄に更新内容を記入します。必要に応じてスクリーンショットも更新しておきます。
申請ページが更新したページだけ「更新済み」となるので、そのまま「Microsoft Store に提出」ボタンをクリックすれば、更新版を申請できます。ストアからの更新
認定が終わった後、Ver 1 をインストールしている環境で再度ストアを開くと更新ボタンが表示されるので、そこからアプリを Ver 2 に更新できます。
、表示されているアプリサイズは 140 MB ですが、ダウンロードは 400 KB 程度でした。ユーザーが自分でストアで更新しなくても、自動更新も行われます。ただし、タイムラグはかなりある印象です。
旧バージョンを起動した際、バックグラウンドで更新が行われ、次回起動時には新バージョンになるようなのですが、自動更新されるまでに丸 1 日近く（23 時間程度）かかった場合もありました。
所感
開発者登録～更新までの一連の作業をしてみての感想としては、
- やはり労力は今までより多くかかる……が、許容できないほどではない。
- Microsoft パートナーサイトでの手続き自体は分かりやすい。
- しかし謎のエラーに悩まされることもある（同じフルネームエラー以外にも、ストアページから何回やっても更新できない現象にも遭遇、最終的には再度更新申請した）。
- パートナーサイトの応答が全体的にもっさりしている。
- やむを得ないが、各所でタイムラグがある（申請～認定、自動更新等）のでまどろっこしい。
という感じです。
こちらで整理したように、開発者としてはデメリットも多いものの、逆にメリットもありますし、また、ユーザー側から見ればメリットは多いので、本番アプリのストア配布も前向きに検討しようかと思います。
WPF アプリを Microsoft Store に申請・登録する（全 4 回）
関連記事
前回アプリのパッケージを作成したので、いよいよストア配布の申請をします。
ストア配布編 目次
申請
Microsoft パートナーセンターのホームで「アプリとゲーム」をクリックします。
予約したアプリ名（ストアテストアプリ）が表示されているのでクリック。
「申請を開始する」ボタンをクリック。
未開始になっているすべてのステップのページ内容を埋めていきます。
「価格と提供の状況」ページ。今回はテストアプリなので、表示範囲をプライベートユーザーにしました。これにすると、グループ（今回は「ストアテスト」）として指定するメアドのユーザーにだけアプリが表示されます。
グループ作成ページで自分のメアドだけを指定すれば、自分だけがストアからダウンロードできるようになります。なお、グループ作成ページに遷移すると、価格と提供の状況ページで入力途中の内容は失われるようなので、最初にグループを作っておく方が良いようです。
価格は無料にしています。
「プロパティ」ページ。カテゴリとサブカテゴリは、テストアプリなので、開発者ツール・開発者キットにしておきました。
問題になってくるのがプライバシーポリシーです。
画面にバージョンを表示するだけのアプリなので、当然個人情報の収集はしていないのですが、後続のパッケージアップロードあたりまで進んだ段階でこのページに戻ってくると、個人情報の収集が勝手に「はい」にされていました。そうなると、プライバシーポリシー URL の入力が必須になります。
つまり、どんなアプリでもプライバシーポリシーを書いたページを用意しておく必要があるということです。
とはいえ、こちらの記事にあるように、ページの内容としては、ごく簡単に「収集してません」程度のもので良いようです。今回は GitHub のアプリページの末尾に記述をしておきました。念のために英語にしてみましたが、日本語で構わないようです。
システム要件もそれっぽいのを入れておきます。
「年齢別レーティング」ページ。質問に答えていくと、各種レーティングシステムでのレーティングを生成してくれます。
年齢制限すべき内容ではないので、全年齢にしておきました。
「パッケージ」ページ。作成したアプリパッケージ（パッケージプロジェクトフォルダーの中の AppPackages フォルダーにある msixupload ファイル）をドラッグ＆ドロップしてアップロードします。
デバイスファミリの利用可否のところで、どの Windows で使えるかを指定します。今回はノーマルな Windows のみにしておきました。
「Store 登録情報」ページ。ストアでのアプリ配布時の表示（アプリ説明）を管理します。
「日本語（日本）」をクリックすると、日本語でのアプリ説明を編集できます。用意されている入力項目は多いのですが、必須なのは
- 製品名（アプリ名）
- 説明
- スクリーンショット
の 3 つだけです。
アプリ名を予約する際、英数名と日本語名の両方で予約した場合は、製品名でどちらかを選べます。
ここまで入力すると、申請に必要な内容がすべて揃いました。右側のマークがすべて緑色の完了になっています。
申請オプションは特に変更しなくて大丈夫です（タイミングを遅らせることもできます）。
「Microsoft Store に提出」ボタンをクリックすると、申請が行われます。
認定待ち
申請すると審査が行われますので、認定されるまでにはしばらく時間がかかります。
プログレスバーはリアルタイムの状況を反映しているわけではないようです。「この申請の確認」ページに遷移してから再度「進行状況を確認」すると、いつの間にかプログレスバーが進んでいます。再確認があったのかバグなのかはわかりませんが、プログレスバーが「公開処理中」から「認定」に逆戻りしたこともありました。
認定には通常、1～3 日程度かかります。長いときは丸 7 日近くかかったこともありました。
認定に要する時間についての詳報はこちらをご覧ください。
認定されるとメールが届き、アプリケーションの概要ページでも「Microsoft Store で取扱い中」になります。コラム：認定作業は平日のみか？
認定作業は土日も行われるのでしょうか？
ストア自体は、土日だろうが夜中だろうが、アプリのダウンロード等はできます。物理的なアイテムの出荷については「営業日は、月曜日 ～ 金曜日の午前 8:00 ～ 午後 5:00 (祝日を除く)」と記載があります。
パートナーサイトでは認定について「最大 3 営業日かかることがあります」と表記されています。「3 日」ではなく「3 営業日」なので、お休みの日もありそうな雰囲気で記載されています。
しかし、これまで 7 回ほど認定されたメールの送信日時を見る限りでは、土日や夜中も認定作業は行われているようです。日本時間でも 23 時台にメールが来ましたし、土曜日もメールが来ました。マイクロソフト本社があるレドモンドは太平洋時間ですが、太平洋時間の 21 時台や、日曜日にもメールが来ました。
ストアからのダウンロード
認定されたアプリがきちんとストアで公開・配布されているか確認します。
今回はプライベートユーザーのみの配布ですが、検索可能なオプションにはしました。しかしながら、実際には検索しても表示されません。タイムラグの問題かなとも思いましたが、3 日経った今も検索できません……。仕方がないので、URL 直打ちします。
Microsoft パートナーセンターのアプリのページの中に「製品 ID」ページがあります。
プライベートユーザーのみの配布の場合、「特定の人だけにアプリが表示される場合の URL (認証が必要)」の URL をブラウザに打ち込めばストアのアプリページにアクセスできます。
入手ボタンをクリックするとストアアプリが起動し、そこから配布したアプリをダウンロードできます。
ストアに表示されているアプリのサイズは 143 MB なのですが、ダウンロードは 60 MB 程でした。MSIX の差分更新機能により、既に持っているパーツは除いてインテリジェントにダウンロードしてくれているようです。
スタートメニューにもきちんと登録されました。
無事に起動。
Windows 設定のアプリと機能にも登録されていて、ここからアンインストールもできました。WPF アプリを Microsoft Store に申請・登録する（全 4 回）
関連記事
更新履歴
- 2021/12/04 初版。
- 2022/11/20 認定所要時間について追記。
前回開発者登録を終えたので、今回は WPF アプリを作ります。Windows 10/11、Visual Studio 2022、.NET 6 で動作確認しています。
アプリ作成編 目次
準備
ストアでアプリを配布するには、作成したアプリを MSIX パッケージにする必要があります。Visual Studio にパッケージツールが入っているかを確認しておきます。
Visual Studio のインストーラーを起動して変更モードに入り、「.NET デスクトップ開発」ワークロードのインストール詳細に「MSIX Packaging Tools」がオンになっていることを確認します。もしオフになっていたら、オンにしてインストールします。
なお、MSIX については WPFアプリのmsixによるweb配布、自動更新方法という記事が分かりやすくまとまっていて、大変参考になりました（自前サイトでの配布向けのため、後半のやり方は異なります）。
（メモ）非 UWP アプリを UWP 風にしてストア配布できるようにする仕組みを Desktop Bridge と呼ぶようです。Desktop Bridge のやり方はいくつかあり、昔は Desktop App Converter(DAC) を使っていましたが、その後継が MSIX Packaging Tools のようです。
WPF アプリ作成
適当に WPF アプリを作成します。
上記のサイトに倣い、ウィンドウにバージョンを表記するアプリです。MainWindow.xaml の中身をほんの少しだけ追加するくらいのものです。最初は Ver 1 にしておきます。
<Grid>
<Label Content="Ver 1" FontSize="50" HorizontalAlignment="Center" VerticalAlignment="Center" />
</Grid>
一応、ソースコードは GitHub に上げてあります。
高 DPI 対応宣言
ディスプレイが高 DPI なものでもちゃんとした表示になりますよ、という宣言をしておきます。
これをしておかないと、後でアプリを検証する際に警告が出ます。あくまでも警告であって不合格ではないので、宣言しなくても審査は通るかもしれませんが。
ソリューションエクスプローラーのプロジェクトを右クリックし、［追加 → 新しい項目］を選びます。
アプリケーションマニフェストを選んで追加します。プロジェクトに app.manifest ファイルが追加されるので開き、<assembly> セクションの中に以下を追記します。
<application xmlns="urn:schemas-microsoft-com:asm.v3">
<windowsSettings>
<dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true/pm</dpiAware>
<dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2, PerMonitor</dpiAwareness>
</windowsSettings>
</application>
DPI のためのマニフェストについては、こちらに解説があります。
64 ビット設定
64 ビットのアプリとしてパッケージングしたい場合は、パッケージプロジェクトを作る前に予め 64 ビットの設定をしておく必要があります。そうしないと、似非 64 ビットパッケージになってしまいます。
プロジェクトのプロパティーで、Platform target を x64 にします。また、念のため、ターゲット OS バージョンとサポートされている OS バージョンを、後述のパッケージターゲットバージョンと揃えて 10.0.19041.0 にしておきます。
［ビルド → 構成マネージャー］メニューで、プラットフォームを新規作成して x64 にします。既に作成されていますという旨のエラーが出て x64 を新規作成できない場合は、いったん Visual Studio を閉じて、ソリューションファイルをバックアップしたうえで、テキストエディタで開き、preSolution の欄にある Any CPU 以外のものを削除してから、再度 Visual Studio で開くと、x64 を新規作成できるようになるかと思います。
MSIX パッケージプロジェクトの追加
パッケージを作る時、Visual Studio のログインは前回登録した開発者アカウントと同じアカウントでのログインが必要です。
ソリューションエクスプローラーのソリューションを右クリックし、［追加 → 新しいプロジェクト］を選びます。
Windows アプリケーションパッケージプロジェクトを選んで追加します。
ウィザードが走ります。プロジェクト名は適当で構いません。
ターゲットバージョンは 2004 にしました。こちらによれば、2004 では最新の MSIX アプリ パッケージ形式がさらにサポートされるようになったとのことです。
ウィザード完了後、パッケージプロジェクトの依存関係を右クリックしてプロジェクト参照の追加を選びます。
WPF アプリを追加します。
依存関係に WPF アプリが追加されました。ロゴの作成
パッケージプロジェクトの Images フォルダーの中に、ストア公開時にロゴとなる StoreLogo.png が作成されています。
このロゴがデフォルトのままだと、後でアプリを検証する際に不合格となるので、適当にロゴ画像を作成して上書きします。推奨サイズは 400x400 ピクセル以上です。ストア向けのロゴは様々なサイズが必要なので、Visual Studio にリサイズしてもらいます。
パッケージプロジェクトの中にある Package.appxmanifest をダブルクリックし、ビジュアル資産タブを開きます。ソースとして作成したロゴ画像を指定し、資産はバッジロゴ以外のすべて、スケールはすべてのスケールを選択します。
生成ボタンをクリックすると、サイズ違いのロゴが山のように生成されます。
ロゴについてはこちらが詳しいです。
アプリケーション名の予約（簡単な方法）
（補足）
こちらは Visual Studio から簡単に予約する方法です。パッケージ名にこだわりたい場合は次節をご覧ください。
ソリューションエクスプローラーのパッケージプロジェクトを右クリックし、［公開 → アプリケーションをストアと関連付ける］を選びます。
アプリケーション名を選択の画面の「アプリケーション名を予約」のところに、公開したいアプリの名前を入れます。この名前はストアで表示される名前になります。
予約した名前を選択して次へをクリックします。
関連付けボタンをクリックして関連付けを完了します。アプリケーション名の予約（パッケージ名にこだわる方法）
前節の方法で予約すると、特にアプリ名が日本語の場合に、製品 ID の「パッケージ/ID/名前」（パッケージ名）がアルファベットの羅列になります。パッケージ名は通常は利用者の目に触れないので、アルファベットの羅列でも全く問題無いと思いますが、Get-AppxPackage コマンドレットでパッケージ名を取得した時などに気になるということであれば、読みやすいパッケージ名を付けることもできます。
Microsoft パートナーセンターのホームから「アプリとゲーム」に進み、新しい製品のアプリを選びます。
名前を予約する画面になりますが、必ず半角英数で入力します。そうすることでそのままパッケージ名になります。例えば、日本語のアプリ名が「ほげふが」なら、「Hoge Fuga」で予約します。
スペース等はパッケージ名から除外されます。また、パッケージ名の先頭には開発者名が付与されます。「DevName.HogeFuga」のようなパッケージ名になります。
予約後、パートナーセンターの製品 ID ページでパッケージ名（パッケージ/ID/名前）を確認できるので、意図しているパッケージ名になっているか確認します。
しかしこのままでは、アプリ名が英数になってしまいます。日本語のアプリ名を付けたい場合は、アプリ名の管理ページで、追加で日本語名も予約します。新規アプリとして予約するのではなく、Hoge Fuga のその他の名前として予約します。
再度アプリ名の管理ページを開くと、ページ下方に「Hoge Fuga」と「ほげふが」が併記されています。日本語のほうをダッシュボード名に設定しておくと分かりやすくなります。これで、アプリ名「ほげふが」のパッケージ名が「DevName.HogeFuga」となり、読みやすいパッケージ名になります。
その後、前節と同様のやり方で、Visual Studio でアプリケーションをストアと関連付けますが、アプリケーション名選択の画面では、新しいアプリケーション名を予約するのではなく、先ほど予約した「Hoge Fuga」を使用します。Visual Studio からは常に最初に予約した英数名で表記されますが、ストアで公開する際は日本語名も選べます。
MSIX パッケージ作成
ソリューションエクスプローラーのパッケージプロジェクトを右クリックし、［公開 → アプリパッケージの作成］を選びます。
「新しいアプリ名で Microsoft Store に」を選びます（先ほど予約したアプリ名が表示されている場合はそちらを選びます）。
先ほど予約した名前を選択して次へ進みます。
予約した名前で Microsoft Store に配布する方法を選択します。
パッケージの選択と構成で、最低 1 つ以上のアーキテクチャを選びます。今回は x64 にしました。
作成ボタンをクリックしてしばらく待つと、パッケージが作成されます。パッケージの検証
作成したパッケージに問題がないか、Windows アプリ認定キット（Windows App Certification Kit：WACK）で検証します。
パッケージ作成完了画面のボタンから WACK を起動します。
次へボタンをクリックすると検証が行われます。しばらく時間がかかります。
結果が合格となれば問題ありません。不合格の場合は、詳細を確認して原因を取り除きます。
WACK を閉じてしまった場合、結果ファイルは
C:\Users\（管理者ユーザー）\AppData\Local\Microsoft\AppCertKit\ValidationResult.htm
にあります。
作成したストア向けパッケージを、ストアに登録される前に動作確認したい場合、やり方はこちらにまとめてあります。
WPF アプリを Microsoft Store に申請・登録する（全 4 回）
更新履歴
- 2021/12/03 初版。
- 2023/03/05 WACK 結果パスを記載。
Microsoft Store（旧 Windows ストア）で UWP 以外のアプリ（以降「非 UWP アプリ」）も公開できるようになったので、WPF（Win32）で作成したアプリを公開してみました。その時のやり方を整理し、以下にまとめました。画像はクリックすると拡大します。
ちなみに、Electron アプリについては ElectronアプリのMicrosoft Storeアプリ申請という記事が既にあります。
開発者登録編 目次
メモ：なぜ Microsoft Store？
今まで私が作ったアプリは私のホームページで公開してきたのですが、Microsoft Store（以降、ストア）に興味を持ったのは、ユーザーから見るとアプリの扱いが簡単になるかもしれない、と思ったからです。私のアプリをユーザーが利用する場合、zip をダウンロードして解凍すればいいだけなので、もともと難しくはありません。しかし、どのフォルダーに解凍しようかちょっと迷ったり、あるいはうっかり Program Files に解凍してしまうと Virtual Store が悪さをする可能性も否定できません。
また、そのようなフリーソフトが 1 つ 2 つならまだしも、たくさんあると Windows 再インストールの時などは大変です。ストアでアカウントに紐付いていると、まとめて再インストールできるので便利です（スマホと同様の動き）。
それから、WPF アプリは現状ならまだなんとか 1 つの exe ファイルにまとめられますが、Windows App SDK（WinUI3）あたりになってくるとまとめられなくなってきそうな感じがして、ファイルの多さにユーザーが辟易してしまうかも、というのも気がかりです。
初回起動時、SmartScreen による邪魔が入るのも鬱陶しいところです。
ストアでの配布であれば、ユーザーは「入手」ボタンをクリックするだけで良く、スタートメニューにも自動的に登録されたりして、迷わず簡単です。また、あまりして欲しくはありませんが、アンインストールもボタン 1 つで簡単です……。
メリット・デメリットの詳細な検討はこちら。
必要なもの
ストアでのアプリ配布に必要なものは、
- 2,000 円程度の費用（初回のみ）
- （自前配布と比較して）少し多めの労力
です。
ストアでのアプリを配布にあたり、Microsoft パートナーとしての開発者登録が必要で、登録料がかかります。あくまでも「開発者」としての登録料であり、アプリごとの登録料はかかりません。維持費も無料です（2021 年 12 月時点）。
懸念事項のトップクラスに挙げられる証明書問題については、ストア側で良きに取り計らってくれるので、開発者側での対応は不要です（オレオレ証明書を作る必要はありません）。
労力については、やはり今までよりは多少かかります。アプリ自体に手を加える必要もありますし、ストア申請時にはいろいろな項目に入力しなければなりません。申請すればすぐに配布に至るというわけではなく、審査があって不合格になると修正を余儀なくされます。
パートナー登録
何はともあれ、パートナー登録しないことには始まらないので、パートナー登録を進めていきます。ストアウェブサイトの下の方にある「Microsoft 開発者プログラム」リンクから登録ができます。
既に持っている、あるいは新規に作成した Microsoft アカウントでログインすると Microsoft パートナーセンターに遷移するので、開発者として登録します。
アカウント情報ページでアカウントの種類を選びます。個人であれば「個別」を選べば登録料は 2,000 円程度ですし、また、登録作業はオンラインですぐに終わります。法人の場合は登録料も高く、また、登録時に書類が必要というウワサです。ちなみに公式には個別の登録料は「約 19 米国ドル」と表記されています。リアルタイムの為替だと 1 ドル 113 円程で、19 ドルだと 2,147 円程度になるのですが、表示された金額は税込 1,847 円でした（後日カード明細に記載された金額も 1,847 円でした）。
ここで登録する「パブリッシャーの表示名」がストアで表示される開発者名です。
その他に住所や電話番号なども入れる必要がありますが、こちらはどうやらストアで晒されるというわけではないようです（もし晒されるということでしたら教えてください）。
入力を終え、次へボタンをクリックすると、支払いページになります。課金方法（実質クレジット払いのみ）を選び、クレジットカード情報を保存します。
なぜか再び住所の入力を求められます。アメリカ仕様なのでしょうか。
最後の確認ページで完了ボタンを押すと、支払いと登録が完了します。WPF アプリを Microsoft Store に申請・登録する（全 4 回）
翔星グループ
月別アーカイブ
記事検索
最新記事
最新コメント
タグクラウド
- ACF
- Android
- AQUOSPAD
- ASPNET
- BitLocker
- Blazor
- CBuilder
- CSharp
- csv2resw
- FactoryTown
- Fantia
- GPS
- H264
- H265
- HaikuOS
- HANASU
- HDD
- IIJ
- LTE
- MicrosoftStore
- MVNO
- MVVM
- NAS
- Nexus7
- PetitKara
- PHP
- RaspberryPi
- SQLite
- SSD
- SymphonyOfWar
- TYPINGMANIA
- USB3
- UTAU
- Vegas
- VisualStudio
- Wi-Fi
- WiMAX
- Windows
- Windows10
- Windows10Mobile
- Windows11
- WinUI3
- WPF
- うたりす
- お知らせ
- お願い
- その他無線
- ちょちょいとファイル合併2
- ちょちょいと自動更新
- ちょちょいと自動更新2
- はじまるA列車
- へなぽらんど
- ゆかり
- ゆかりすたー
- ゆかりすたー4
- ゆっこビュー
- ゆっこビュー2
- アニメ
- アンケート
- イベント
- オーディオ
- カラオケ
- ゲーム
- サンプルコード
- サービス
- スピード測定
- スーパーバレットブレイク
- セキュリティ
- ソフトウェア
- タブレット
- トトリのアトリエ
- ニコカラ
- ニコカラりすたー
- ニコカラメーカー
- ニコカラメーカー2
- ニコカラメーカー3
- ネットワーク
- ハードウェア
- プラグイン
- プログレスバー素材メーカー
- ヘッドセット
- ボーカルカット
- マシンスペックまとめ
- マシンベンチマークまとめ
- ライザのアトリエ2
- ライザのアトリエ3
- ラングリッサー
- ルフランの地下迷宮と魔女ノ旅団
- ロロナのアトリエ
- 動画
- 募集
- 唄詠
- 唄詠2
- 唄詠利用
- 挨拶
- 簡易キーチェンジャー
- 考察
- 開発
- 鼻歌採譜プラグイン
