PowerShellコンソールから以下です。
Get-AppxPackage
これをファイルに記録するには、デスクトップにpackages.txtというファイル名で保存するとして、こうです。
Get-AppxPackage > $env:USERPROFILE/Desktop/packages.txt
ちなみに、UWPをVisual StudioからLocal Machineで実行したときに自動インストールされたものは、IsDevelopmentModeがTrueになるようです。
2023/04/14
インストールされたアプリの情報取得
別に新しくも何ともないですが、パッケージされたアプリをインストールした後、登録された情報はPowerShellで簡単に確認できます。
PowerShellコンソールから以下です。
これをファイルに記録するには、デスクトップにpackages.txtというファイル名で保存するとして、こうです。
ちなみに、UWPをVisual StudioからLocal Machineで実行したときに自動インストールされたものは、IsDevelopmentModeがTrueになるようです。
PowerShellコンソールから以下です。
これをファイルに記録するには、デスクトップにpackages.txtというファイル名で保存するとして、こうです。
ちなみに、UWPをVisual StudioからLocal Machineで実行したときに自動インストールされたものは、IsDevelopmentModeがTrueになるようです。
2022/11/30
パッケージされたアプリのファイルの保存場所
AppDataフォルダーへのファイル作成について、発見があったのでメモしておきます。
1. 基本
Microsoftストア用にパッケージされたデスクトップアプリの場合、設定情報等の保存場所としては基本的に以下の3通りがあります。
これらのファイルはアプリのアンインストール時に自動的に削除されます。つまり、アプリの実行ファイルのみならず、その作成する情報・ファイルもOSがまとめて管理することで、ゴミとなるファイルを残さずきれいに削除できるようにしているわけです。
ちなみに、AppDataフォルダー以外にもアクセス権に応じてファイルは作成できますが、あえてやることでもなし。
2. 発見
ここまではDesktop Bridgeの基本ですが、3番目について、ふとしたことから例外があるのに気づきました。
1. 基本
Microsoftストア用にパッケージされたデスクトップアプリの場合、設定情報等の保存場所としては基本的に以下の3通りがあります。
- WinRTのApplicationData.LocalSettings
- WinRTのApplicationData.LocalFolderに作成したファイル
- AppDataフォルダー（に作成したフォルダー）に作成したファイル
これらのファイルはアプリのアンインストール時に自動的に削除されます。つまり、アプリの実行ファイルのみならず、その作成する情報・ファイルもOSがまとめて管理することで、ゴミとなるファイルを残さずきれいに削除できるようにしているわけです。
ちなみに、AppDataフォルダー以外にもアクセス権に応じてファイルは作成できますが、あえてやることでもなし。
2. 発見
ここまではDesktop Bridgeの基本ですが、3番目について、ふとしたことから例外があるのに気づきました。
すなわち、アプリをインストールした後、最初にAppDataフォルダーにファイルを作成しようとした際に、
- AppDataフォルダーに指定のフォルダーが存在しない場合、自動的にリダイレクト先の場所が作成され、以後のアクセスはその場所になる。実際のAppDataフォルダーには何も作成されない。これは公式情報どおり。
- AddDataフォルダーに指定と同名のフォルダーが既に存在する場合、そのフォルダーにファイルが作成される。このファイルはアプリをアンインストールしても削除されない。
この2通りのどちらになるかは、最初にアクセスしたときに決まるようです。一旦、1.になった後は、AppDataフォルダーに同名のフォルダーを作成しても、ファイルはそこに作成されません。
開発環境では、パッケージされた状態で実行するときもあれば、されていない状態で実行するときもあり、2.のようなケースがあるのには何となく気づいていましたが、改めて確認したところ、こういうことだったと。
これがどういう意味を持つかというと、例えば、ユーザーごとのTempフォルダーであるAppData\Local\Tempに作成するファイルはリダイレクトされないし、作成された後はアプリをアンインストールしても自動的に削除されないということになります。
他人のことはあまり言えませんが、説明が足らないと思います。
2022/06/03
.NET 5でのアプリの更新
Microsoftストアで公開したアプリはストアのAPIを使って更新できますが、.NET 5以降は変わった点があるので、メモしておきます。
更新の際に出るダイアログのために、このオーナーとなるWindowを先に登録する必要がありますが、これは.NET 5より以前は以下のようなものでした。
見てのとおり、COMのIInitializeWithWindowを定義しておいて、StoreContextのインスタンスをこれにキャストするものですが、.NET 5以降はInvalidCastExceptionが出て実行できなくなります。
このための修正としては、usingにWinRTを加えた上でAsでIInitializeWithWindowキャストする。 もしくは、WinRT.Interop.InitializeWithWindow.Initializeを使う。これが公式に出ている方法で、StoreContextをキャストする必要がなく、したがってCOMの定義も要らなくなるので、やるならこちらだと思います。 これを含めた更新のためのヘルパークラスの全体は以下のようになります。
このための修正としては、usingにWinRTを加えた上でAsでIInitializeWithWindowキャストする。 もしくは、WinRT.Interop.InitializeWithWindow.Initializeを使う。これが公式に出ている方法で、StoreContextをキャストする必要がなく、したがってCOMの定義も要らなくなるので、やるならこちらだと思います。 これを含めた更新のためのヘルパークラスの全体は以下のようになります。
2021/10/08
Winget 1.1
CUIからソフトウェアパッケージのインストールができるWindows Package Manager、別名WingetのVer 1.1がリリースされています。
Wingetは活発に開発が進められていますが、今回の大きな変化としてMicrosoftストアのアプリにもアクセスできるようになっています。これがどういうことかというと、従来はアプリをWingetでインストールできるようにするには、Wingetのレポジトリに登録する作業が必要だったのですが、Microsoftストアにあるアプリはこれが不要になり、そのままでWingetから見えるようになりました。
したがって、Wingetが使える環境であれば、例えばMonitorianをインストールするのに、コマンドプロンプトから以下を実行するだけでできてしまいます。
超簡単！ 便利！ 楽！
まあ実用的に使うには、どうオプションを付けるか考えて詰める必要はありますが。
既存のChocolateyもありますが、追加的な手間がかからないというのは大きいです。
Wingetは活発に開発が進められていますが、今回の大きな変化としてMicrosoftストアのアプリにもアクセスできるようになっています。これがどういうことかというと、従来はアプリをWingetでインストールできるようにするには、Wingetのレポジトリに登録する作業が必要だったのですが、Microsoftストアにあるアプリはこれが不要になり、そのままでWingetから見えるようになりました。
したがって、Wingetが使える環境であれば、例えばMonitorianをインストールするのに、コマンドプロンプトから以下を実行するだけでできてしまいます。
winget install Monitorian
超簡単！ 便利！ 楽！
まあ実用的に使うには、どうオプションを付けるか考えて詰める必要はありますが。
既存のChocolateyもありますが、追加的な手間がかからないというのは大きいです。
2021/08/04
Microsoftストアからのアプリの更新
Microsoftストアで公開したアプリは、Desktop Bridgeの場合も含めて、新しいバージョンが公開されているときは「Microsoft Store」アプリでそのアプリのページを開くと自動的に更新がかかります。ただ、これは往々にしてエラーになり、一旦アンインストールしての再インストールを強いられたりします。
一方、ストアのAPIには、アプリからアプリ自身の更新ができるAPIが用意されています。
このAPIはてっきりUWP用かと思っていたのですが、Desktop Bridgeでも使えるようなので、試してみました。
上のページにあるサンプルを必須部分だけにして、Desktop Bridge用の処理を加えると以下のようになります。
見てのとおり、
1.は、常にパッケージ情報が1つ返ってくるが、このパッケージのバージョン（StorePackageUpdate.Package.Id.Version）は、新しいパッケージのバージョンではなく、現在実行中のパッケージのバージョンを示すので、新しいパッケージがあるかは判別できない。
2.は、このパッケージ情報を使って実行しても現在のパッケージが再インストールされるだけのようで、更新にならない。
これは使い物にならないかなと思いつつ、数少ない先例を見てみると、少し気になることが。
その結果、この状態であれば期待どおりに更新に使えることが分かりました。
1.は、新しいパッケージがないときはパッケージ情報が返ってこないので、その有無を捉えればよい。すなわち、以下のように、上のメソッドの前半だけで判別可能。
2.は、このパッケージ情報を使って実行すると新しいパッケージがインストールされる。
ということで、Desktop Bridgeでも使えることが確認できました。このAPIを利用すればアプリに手動/自動での更新機能を付けられるので便利、なのですが、デバッグを本番環境でやらなければならない、そのために修正の度にパッケージをSubmissonとして公開しなければならないのは、時間的に勘弁してほしいとこです。
一方、ストアのAPIには、アプリからアプリ自身の更新ができるAPIが用意されています。
このAPIはてっきりUWP用かと思っていたのですが、Desktop Bridgeでも使えるようなので、試してみました。
上のページにあるサンプルを必須部分だけにして、Desktop Bridge用の処理を加えると以下のようになります。
見てのとおり、
- StoreContext.GetAppAndOptionalStorePackageUpdatesAsyncメソッドで新しいバージョンのあるパッケージ情報（StorePackageUpdate）を取得して、この有無をチェックする
- この情報を使ってStoreContext.RequestDownloadAndInstallStorePackageUpdatesAsyncメソッドを実行する
1.は、常にパッケージ情報が1つ返ってくるが、このパッケージのバージョン（StorePackageUpdate.Package.Id.Version）は、新しいパッケージのバージョンではなく、現在実行中のパッケージのバージョンを示すので、新しいパッケージがあるかは判別できない。
2.は、このパッケージ情報を使って実行しても現在のパッケージが再インストールされるだけのようで、更新にならない。
これは使い物にならないかなと思いつつ、数少ない先例を見てみると、少し気になることが。
- GetAppAndOptionalStorePackageUpdatesAsync Still Broken
- How Can we Check the New Version of app update is available in store [UWP] programmatically.
その結果、この状態であれば期待どおりに更新に使えることが分かりました。
1.は、新しいパッケージがないときはパッケージ情報が返ってこないので、その有無を捉えればよい。すなわち、以下のように、上のメソッドの前半だけで判別可能。
2.は、このパッケージ情報を使って実行すると新しいパッケージがインストールされる。
ということで、Desktop Bridgeでも使えることが確認できました。このAPIを利用すればアプリに手動/自動での更新機能を付けられるので便利、なのですが、デバッグを本番環境でやらなければならない、そのために修正の度にパッケージをSubmissonとして公開しなければならないのは、時間的に勘弁してほしいとこです。
2020/12/31
アプリ実行エイリアス
Microsoftストアにアプリを出すときに、app package manifestで「アプリ実行エイリアス」というものを指定できます。この効能はストアからインストールしたアプリ（デスクトップアプリを含む）をコマンドプロンプトからファイルパスなしのファイル名だけで起動できるというものです。
一応OSの設定にも出てきます。
ストアからインストールしたアプリの実行ファイル等はOSが管理するので、アプリの起動は基本的にスタートメニューに作成されるアイコンからか、自動起動に登録するか以外にはできませんが、そのコマンドプロンプト向けの救済策のようなものです。
これだけならコマンドプロンプトを使わせたいケース以外には関係ない話ですが、Hash Padを開発しているときに別の利用法があるのを見つけました。すなわち、これを宛先に指定することでアプリを起動するショートカットを自由に作成できます。
このアプリ実行エイリアスは以下のパスに自動的に作成されるようです。
C:\Users\[ユーザー名]\AppData\Local\Microsoft\WindowsApps
タネ明かしとしては、PATHを一覧表示するとこのパスが入っているので、それでパスなして起動できるというわけですね。
これはフルパスとしては以下のコードで取得できます。 これ自体はエイリアスというかシンボリックリンクみたいなもので、実体のあるファイルではないですが、これから直接アプリを起動できるほか、ショートカットのターゲットパスに指定してアプリを起動することもできます。
もう一つ重要な点は、WinRTのAPIにはパッケージされたアプリからしか利用できないものがありますが、これから起動するとパッケージからの起動になることです。実行ファイルを探し出して直接起動した場合はパッケージからの起動にならないので、この点は大きな違いです。
というわけで、アプリ実行エイリアスを使うことでストアにアプリを出すときの難点の一つを解決できます。Hash Padでは、これによりコンテキストメニューの「送る」フォルダーにショートカットを作成しています。
これだけならコマンドプロンプトを使わせたいケース以外には関係ない話ですが、Hash Padを開発しているときに別の利用法があるのを見つけました。すなわち、これを宛先に指定することでアプリを起動するショートカットを自由に作成できます。
このアプリ実行エイリアスは以下のパスに自動的に作成されるようです。
C:\Users\[ユーザー名]\AppData\Local\Microsoft\WindowsApps
タネ明かしとしては、PATHを一覧表示するとこのパスが入っているので、それでパスなして起動できるというわけですね。
これはフルパスとしては以下のコードで取得できます。 これ自体はエイリアスというかシンボリックリンクみたいなもので、実体のあるファイルではないですが、これから直接アプリを起動できるほか、ショートカットのターゲットパスに指定してアプリを起動することもできます。
もう一つ重要な点は、WinRTのAPIにはパッケージされたアプリからしか利用できないものがありますが、これから起動するとパッケージからの起動になることです。実行ファイルを探し出して直接起動した場合はパッケージからの起動にならないので、この点は大きな違いです。
というわけで、アプリ実行エイリアスを使うことでストアにアプリを出すときの難点の一つを解決できます。Hash Padでは、これによりコンテキストメニューの「送る」フォルダーにショートカットを作成しています。
2019/05/12
Microsoftストアのサブスクリプション情報の取得
Microsoftストアでは、しばらく前からアプリのアドオンのサブスクリプション販売が可能になっています。アプリ自体を販売する場合は、アプリ側の対応はそれほど手間ではないですが、アドオン（アプリ内販売となる）でかつサブスクリプションとなると、割と面倒な対応が必要になります。
ストアの販売用のAPIは新旧の2種類ありますが、Desktop Bridgeのアプリを前提とするならば、新しいWindows.Services.Storeの方を使うことになります。このAPIはStoreContextオブジェクトのメソッド群で構成され、それなりにサンプルがありますが、肝心な情報の取得方法が抜けているので、その補完がお題です。
サブスクリプションの状態によってアドオンの動作を切り替えるだけなら、
ただ、使用期間といっても、サブスクリプションのライフサイクルを考えると、以下のような期間に分かれます（サブスクリプションは自動更新が既定で、現在の期間の使用期限までにキャンセルされない限りは自動更新され、また、キャンセルされた後も現在の期間の使用期限までは使用できる）。
これだけなら簡単で、GetAppLicenseAsyncメソッドで可能です。
これで取得できるStoreAppLicenseオブジェクトのうち、アドオンのライセンス情報はAddOnLicensesプロパティのStoreLicenseオブジェクトにあります。ここに目的のアドオンのものがあれば、使用権があるということです。なお、このSkuStoreIdプロパティはStore IDの後にSKU番号が引っ付いたフォーマットで、Store IDそのままではないので要注意。
このメソッドだけは結果がキャッシュされていて、オフラインでも使うことができます。したがって、使用権の確認だけできればいいという場合は、アプリの起動時にこれを実行するだけというシンプルなやり方もあり得ます。
これにはGetUserCollectionAsyncメソッドが使えます。
これで取得できるStoreProductオブジェクトに含まれるStoreCollectionDataオブジェクトのIsTrialプロパティが目的のものです。サンプルは以下のとおりです。
この方法に辿り着く前にStack Overflowで質問したのですが、答えを付けたMSFTの人には理解されなかったようで。
このメソッドは経験的には、有償期間に入った後にキャンセルされた後は使用期限前であっても（上記の期間4.のケース）そのStoreProductを返してきません。また、オフラインでは使えないので（実行の度にストアのサーバーと通信するらしい）、必要ならローカルに記録しておく必要があります。
上記のStoreLicenseにあるExpirationDateプロパティがいかにも使えそうに見えますが、これが曲者で、これ単体では使えません。経験的に整理したところでは、サブスクリプションの自動更新が有効のときは正しい日時から3日後の日時になり、無効のときは大体正しい日時（1日のズレあり）になるようです。
この点からすると、自動更新が有効のときは課金処理の遅延を見越して数字をいじっているのではないかという合理的な疑いがありますが、こういう辻褄合わせのために大元のAPIのデータをいじるのはやってはならないことだと思います。さらに問題なのは、StoreCollectionDataのEndDateプロパティも含め、他のメソッドで取得できる使用期限の日時にも同じ問題があり、どれも信用できないことです。
したがって、自前で計算するしかないわけですが、そのためには、
まず現在の期間の開始日は、StoreCollectionDataのStartDateプロパティが使えます（上記サンプルのとおり）。なお、これにはAcquiredDateプロパティもありますが、これは実際に購入した日時を指すようで、StartDateとは微妙にズレがあります。このズレの法則性はよく分かりませんが、この計算のための開始日としてはStartDateの方が正しいようです。
次に現在の期間の長さは、先に現在が試用期間か有償期間かを判別する必要がありますが、これは上記のとおりStoreCollectionDataのIsTrialプロパティで分かります。期間の長さは、GetStoreProductsAsyncメソッドで取得できるStoreProductオブジェクトで分かります。
なお、この例にあるGetAssociatedStoreProductsAsyncメソッドでは有償期間の長さは分かりますが、一旦試用期間に入った後は試用期間の長さは分かりません。というのも、このメソッドが返すのは現在の期間の次に購入可能なSKUだけなので、一旦試用期間に入った後は、次にはもう試用期間はなく、試用期間のSKUは取得できないからです。
この2つが分かれれば、後はStoreDurationUnitに気を付けて計算するだけです。
なお、上記のとおり期間4.のケースではUserCollectionDataは取得できませんが、このケースでは自動更新が無効となっている結果、StoreLicenseのExpirationDateプロパティが大体正しい日時を示すので、それをそのまま使えばいいでしょう。
[追記]
自分で計算した日時とMicrosoftのサーバーで期限切れまたは自動延長の処理が行われる日時にはズレがあるので（1日以内）、アプリで期限切れに伴う処理を行う前にはこのズレを考慮する必要があります。
これはどこにも説明はないですが、情報はあります。
このAPIで取得できるオブジェクトにはExtendedJsonDataプロパティがあり、ストアのサーバーから取得したらしきJSONが格納されています。この中にはそのオブジェクトのプロパティに出てこないものもあり、そういうのはこれを直接見て使えということですね。
StoreCollectionDataのJSONはこのスキーマのcollectionDataに相当するようですが、この中にautoRenewの要素があります。これが経験的には自動更新の状態を示していて、これが存在してtrueなら有効、存在しないかfalseなら無効です。上記のサンプルでは、JSON全体をパースする必要もないので、該当部分を正規表現で抽出して判別しています。
以上のように必要な情報は取得できるようになりましたが、ここに至るまでの試行錯誤に相当な時間を費やさざるを得なかったので、正直どうかと思います。わざわざ新APIを作ってサンプル等もそれなりに用意したにもかかわらず、詰めが甘いというか。結局、ストアのサーバーにある情報をどう引っ張ってくるかという問題なので、一発で必要な情報が揃うようにした方がクエリ数も減っていいと思いますが。
こんな当てにならないAPIに頼るより、購入日をローカルに記録しておけば後は何とでもなるのではないか、と思ったこともありましたが、調べていくにつれそのやり方ではむしろ色々なケースで整合性を保つのが大変すぎると気づいて断念しました。
なお、Desktop Bridgeのアプリの場合でも、Windows Application Packaging Projectを使えばこのAPIのデバッグ実行はUWPと同じようにできるので、それ自体は難しくないです。
ストアの販売用のAPIは新旧の2種類ありますが、Desktop Bridgeのアプリを前提とするならば、新しいWindows.Services.Storeの方を使うことになります。このAPIはStoreContextオブジェクトのメソッド群で構成され、それなりにサンプルがありますが、肝心な情報の取得方法が抜けているので、その補完がお題です。
1. サブスクリプションのライフサイクル
サブスクリプションの状態によってアドオンの動作を切り替えるだけなら、
- 使用権があるか否か
ただ、使用期間といっても、サブスクリプションのライフサイクルを考えると、以下のような期間に分かれます（サブスクリプションは自動更新が既定で、現在の期間の使用期限までにキャンセルされない限りは自動更新され、また、キャンセルされた後も現在の期間の使用期限までは使用できる）。
- 試用期間
- 試用期間中にキャンセルされた後の使用期限までの期間
- 試用期間/有償期間後の自動更新により開始された有償期間
- 有償期間中にキャンセルされた後の使用期限までの期間
- 現在が（無償）試用期間か有償期間か
- 現在の期間の使用期限
- 自動更新が有効になっているか（キャンセルされていないか）否か
2.1. 使用権があるか否か
これだけなら簡単で、GetAppLicenseAsyncメソッドで可能です。
これで取得できるStoreAppLicenseオブジェクトのうち、アドオンのライセンス情報はAddOnLicensesプロパティのStoreLicenseオブジェクトにあります。ここに目的のアドオンのものがあれば、使用権があるということです。なお、このSkuStoreIdプロパティはStore IDの後にSKU番号が引っ付いたフォーマットで、Store IDそのままではないので要注意。
このメソッドだけは結果がキャッシュされていて、オフラインでも使うことができます。したがって、使用権の確認だけできればいいという場合は、アプリの起動時にこれを実行するだけというシンプルなやり方もあり得ます。
2.2. 現在が試用期間か有償期間か
これにはGetUserCollectionAsyncメソッドが使えます。
これで取得できるStoreProductオブジェクトに含まれるStoreCollectionDataオブジェクトのIsTrialプロパティが目的のものです。サンプルは以下のとおりです。
この方法に辿り着く前にStack Overflowで質問したのですが、答えを付けたMSFTの人には理解されなかったようで。
このメソッドは経験的には、有償期間に入った後にキャンセルされた後は使用期限前であっても（上記の期間4.のケース）そのStoreProductを返してきません。また、オフラインでは使えないので（実行の度にストアのサーバーと通信するらしい）、必要ならローカルに記録しておく必要があります。
2.3. 現在の期間の使用期限
上記のStoreLicenseにあるExpirationDateプロパティがいかにも使えそうに見えますが、これが曲者で、これ単体では使えません。経験的に整理したところでは、サブスクリプションの自動更新が有効のときは正しい日時から3日後の日時になり、無効のときは大体正しい日時（1日のズレあり）になるようです。
この点からすると、自動更新が有効のときは課金処理の遅延を見越して数字をいじっているのではないかという合理的な疑いがありますが、こういう辻褄合わせのために大元のAPIのデータをいじるのはやってはならないことだと思います。さらに問題なのは、StoreCollectionDataのEndDateプロパティも含め、他のメソッドで取得できる使用期限の日時にも同じ問題があり、どれも信用できないことです。
したがって、自前で計算するしかないわけですが、そのためには、
- 現在の期間の開始日
- 現在の期間の長さ
まず現在の期間の開始日は、StoreCollectionDataのStartDateプロパティが使えます（上記サンプルのとおり）。なお、これにはAcquiredDateプロパティもありますが、これは実際に購入した日時を指すようで、StartDateとは微妙にズレがあります。このズレの法則性はよく分かりませんが、この計算のための開始日としてはStartDateの方が正しいようです。
次に現在の期間の長さは、先に現在が試用期間か有償期間かを判別する必要がありますが、これは上記のとおりStoreCollectionDataのIsTrialプロパティで分かります。期間の長さは、GetStoreProductsAsyncメソッドで取得できるStoreProductオブジェクトで分かります。
なお、この例にあるGetAssociatedStoreProductsAsyncメソッドでは有償期間の長さは分かりますが、一旦試用期間に入った後は試用期間の長さは分かりません。というのも、このメソッドが返すのは現在の期間の次に購入可能なSKUだけなので、一旦試用期間に入った後は、次にはもう試用期間はなく、試用期間のSKUは取得できないからです。
この2つが分かれれば、後はStoreDurationUnitに気を付けて計算するだけです。
なお、上記のとおり期間4.のケースではUserCollectionDataは取得できませんが、このケースでは自動更新が無効となっている結果、StoreLicenseのExpirationDateプロパティが大体正しい日時を示すので、それをそのまま使えばいいでしょう。
[追記]
自分で計算した日時とMicrosoftのサーバーで期限切れまたは自動延長の処理が行われる日時にはズレがあるので（1日以内）、アプリで期限切れに伴う処理を行う前にはこのズレを考慮する必要があります。
2.4. 自動更新が有効になっているか否か
これはどこにも説明はないですが、情報はあります。
このAPIで取得できるオブジェクトにはExtendedJsonDataプロパティがあり、ストアのサーバーから取得したらしきJSONが格納されています。この中にはそのオブジェクトのプロパティに出てこないものもあり、そういうのはこれを直接見て使えということですね。
StoreCollectionDataのJSONはこのスキーマのcollectionDataに相当するようですが、この中にautoRenewの要素があります。これが経験的には自動更新の状態を示していて、これが存在してtrueなら有効、存在しないかfalseなら無効です。上記のサンプルでは、JSON全体をパースする必要もないので、該当部分を正規表現で抽出して判別しています。
3. まとめ
以上のように必要な情報は取得できるようになりましたが、ここに至るまでの試行錯誤に相当な時間を費やさざるを得なかったので、正直どうかと思います。わざわざ新APIを作ってサンプル等もそれなりに用意したにもかかわらず、詰めが甘いというか。結局、ストアのサーバーにある情報をどう引っ張ってくるかという問題なので、一発で必要な情報が揃うようにした方がクエリ数も減っていいと思いますが。
こんな当てにならないAPIに頼るより、購入日をローカルに記録しておけば後は何とでもなるのではないか、と思ったこともありましたが、調べていくにつれそのやり方ではむしろ色々なケースで整合性を保つのが大変すぎると気づいて断念しました。
なお、Desktop Bridgeのアプリの場合でも、Windows Application Packaging Projectを使えばこのAPIのデバッグ実行はUWPと同じようにできるので、それ自体は難しくないです。
2018/11/25
MicrosoftストアとPrivacy Policy
先月、Microsoftストアの管理用のダッシュボードで、Monitorianの更新のサブミッションを出そうとしたとき、Propertiesの項が前回から変えていないのにIncompleteになって、サブミッションの提出ができないことがあった。
何かと思ってPropertiesの項を開いてみると、個人情報の取扱いについてNoを選択していたら、そのせいで設定が完了していないことになっていた。
大前提としてMonitorianは個人情報に触らないので、ここは最初のサブミッションからNoを選択してきた。前回のサブミッションが通過したのが10月10日、この時が10月17日だったので、この間に何らかの変更があったのか、その前の変更の影響がこのタイミングで現れたのか、その辺は不明。
いずれにせよ、Privacy policy URLの入力が必要なのはYesを選択したときだけのはずで、ダッシュボードの動作としておかしいので、インシデントとして報告した。
過去の他の経験から、まず問題をサポートに理解してもらうのが手間かなと思っていたら、サポートの反応は迅速で、かつ、一発で問題を正確に理解していたので少し驚いた。前回と変えていないのに引っ掛かったことについて調査してもらった結果、以下のことが判明。
ともあれ、このアプリは個人情報を取得しないという一文であっても、Microsoftストアのシステム上必要なのであれば書くが、Yesを選択すると事実と異なる虚偽の記載となって、後でペナルティ等はないのかと質問したところ（しつこく聞こえるかもしれないが、虚偽の記載は何であれ後で不利に利用されかねない）、以下の回答。
以上、デスクトップアプリをMicrosoftストアに出すにはDesktop Bridgeが必要、Desktop BridgeはrunFullTrustが必要、MicrosoftストアはrunFullTrustだとPrivacy policyが必要、よって、導き出される結論は、デスクトップアプリをMicrosoftストアに出すにはPrivacy policyが必要ということになる。
その後、ダッシュボードは修正されて、11月25日現在、以下のようになっている（Wifinianのもの）。
CapabilitiesとPrivacy policyの関係が明示されたので、その点は分かりやすくなった。
何かと思ってPropertiesの項を開いてみると、個人情報の取扱いについてNoを選択していたら、そのせいで設定が完了していないことになっていた。
大前提としてMonitorianは個人情報に触らないので、ここは最初のサブミッションからNoを選択してきた。前回のサブミッションが通過したのが10月10日、この時が10月17日だったので、この間に何らかの変更があったのか、その前の変更の影響がこのタイミングで現れたのか、その辺は不明。
いずれにせよ、Privacy policy URLの入力が必要なのはYesを選択したときだけのはずで、ダッシュボードの動作としておかしいので、インシデントとして報告した。
過去の他の経験から、まず問題をサポートに理解してもらうのが手間かなと思っていたら、サポートの反応は迅速で、かつ、一発で問題を正確に理解していたので少し驚いた。前回と変えていないのに引っ掛かったことについて調査してもらった結果、以下のことが判明。
- アプリのCapabilityとしてrunFullTrustを宣言しているので、このCapabilityの場合は、アプリの実際の動作にかかわらず、Privacy policyが必要。
- 前回までこの問題が出なかった理由は不明だが、いずれにせよ現在は必要。
ともあれ、このアプリは個人情報を取得しないという一文であっても、Microsoftストアのシステム上必要なのであれば書くが、Yesを選択すると事実と異なる虚偽の記載となって、後でペナルティ等はないのかと質問したところ（しつこく聞こえるかもしれないが、虚偽の記載は何であれ後で不利に利用されかねない）、以下の回答。
- ここでYesを選択することによって、ペナルティを課されることはない。
以上、デスクトップアプリをMicrosoftストアに出すにはDesktop Bridgeが必要、Desktop BridgeはrunFullTrustが必要、MicrosoftストアはrunFullTrustだとPrivacy policyが必要、よって、導き出される結論は、デスクトップアプリをMicrosoftストアに出すにはPrivacy policyが必要ということになる。
その後、ダッシュボードは修正されて、11月25日現在、以下のようになっている（Wifinianのもの）。
CapabilitiesとPrivacy policyの関係が明示されたので、その点は分かりやすくなった。
2018/03/21
MonitorianとWifinian
しばらく前にMonitarianとWifinianをWindowsストアでリリースしました。どちらもWindows用で、OSの機能で行けてないところ（モニターの明るさ調整、Wi-Fi設定）を補完するものです。中身的にはC#によるWPFアプリ（ただし、Win32を多用）で、Desktop Bridgeを利用してストアに出しています。これらの使い方自体は、そんなに難しくないと思うので、開発について簡単に説明しておきます。
以前の環境光センサーに関するエントリで、Windows 10のアップデートでアクションセンターにモニターの明るさ調整のスライダーが入るらしいと書きましたが、これまでのところは入っていません。
Monitorianの設定中の「調整後の明るさを表示する」は、このエントリで触れた問題に対応するもので、（環境光センサーがある場合に）設定値に加えて実際の調整後の値も表示することで、設定を多少やりやすくします。
内部的には、モニターの明るさに関して利用可能なWin32、WMIの機能をほぼ全て動員し、Device Instance IDをキーに使って統合して利用しています。少々面倒なことに、それぞれに含まれる機能が断片的なので、統合しないと必要な機能が揃わないのですよね。
外部モニターについては、DDC/CIが有効であることが条件ですが、これはモニターとその設定によるので、開発側としてはどうしようもありません。この問題に引っ掛かったらしきレビューが付いてますが、必要条件には初めから書いてあるので。一応、それと直接表示する機能を追加しました。
名前については、昔アプリには機能が分かりやすい名前を付けるべしという話を読んだことがあって、それを考慮していたこともありますが、そんなお行儀に囚われる必要などないと悟ったので、造語しています。
Native Wifiのマネージド実装であるManaged Native Wifiを利用するアプリから機能を強化・リファインの上、改名したものです。
機能としては、前のアプリと比べて、Wi-Fiの状態変化に応じて自動的に更新するようにした、Auto ConnectとAuto Switchの設定に合わせて自動的に介入して接続先を切り変える機能（Engage）を付けた、というのが主な違いです。後者はWindows 7まではOS標準であった機能が、Windows 8以降で簡略化されたものを、再び使えるようにしたことになります。
この辺はMicrosoftのデザイン上の判断で、「Wi-Fiセンサー」の顛末も見るに、ユーザーはWi-Fiに繋がりさえすれば何だって気にしないだろうという判断があったものと想像しますが、まあ実際そうかもとは思いつつ、ユーザーの意図で決めたい場合もあるので。
内部的には、このためにManaged Native Wifiを強化し、WlanClientを保持してWi-Fiの状態変化を監視できるようにしています。引き続きReactivePropertyを使わせていただいてます。その点で再確認した注意事項は、ReactiveCommandに繋げる前にはUIスレッドに戻しておけということです。
名前については、同上。Wifiの後は語感です。
タスクバーの通知領域にアイコンを出しつつ、タスクバーに引っ付いたウィンドウと通知領域アイコンに重なるウィンドウを（NotifyIconのContextMenuと同じ位置に）出すためのライブラリです。Wifinianの前のアプリで開発したものをベースに、Monitorian用に開発し、後にWifinian用に拡充しています。Wifinianではウィンドウのタスクバーからの脱着ができるようになっています。
このコードの肝は、
そういえば、先日、LGの42.5インチのモニターの実物を見てきましたが、広すぎてスクリーンの端に付いたタスクバーを起点とするUIにはもう無理があると感じました。既にこのサイズのモニターが普及価格帯に入っていますが、Microsoftはどうする気ですかね。
[追記]
後から気づきましたが、NotifyIcon中のNativeWindowはプライマリーモニターに存在する扱いになるようで、これではプライマリータスクバーのあるモニターのDPI変化を必ずしも検知できません。また、プライマリータスクバーはどのモニターにも移動できるので、これを完全に追いかけるのはほぼ無理です。
常駐アプリとして必要な自動起動のためのライブラリがStartupAgencyです。自動起動の方法は幾つかありますが、コード的に一番簡単なのはレジストリに登録することで、インストーラによるアンインストールで掃除できることを前提にすれば、それで十分なのでその方法を取っています。
ただし、Desktop Bridgeの場合はその方法ではダメで、UWPのStartupTaskを使う必要があるので、そのための別ライブラリがStartupBridgeという構成になっています。
問題は、これによる自動起動とユーザーによる手動起動をどう判別するかで（自動起動のときはウィンドウを出さないようにしたい）、自動起動のときにArgumentsを付けることができれば簡単ですが、StartupTaskでこれをやる方法が見つかりませんでした。
代替策として、完全な方法ではないですが、アプリの起動時間を記録するようにし、自動起動が有効な場合に、起動時に前回の起動時間とOSの起動時間（セッション開始時間）を比較して前者の方が前であれば自動起動と判断する方法を考えましたが、どこに記録するかという選択が残ります。
この記録には、ライブラリのモジュール性を高めたかったので、UWPのLocalSettingsを使うようにしました。Desktop Bridgeの場合は実はこの手が使えます。といっても、TaskIdはAppxManifest.xmlのものと一致する必要があるので、そこのアプリ本体への依存は避けられませんが。
[追記]
過去のStack OverflowでのMSFTの人の回答を見ても、Argumentsを付ける方法はないようです。
Desktop Bridgeのパッケージ作成は今ではVisual Studioでも直接できますが、Desktop App Converterのやり方に慣れたので、そちらを使っています。面倒な画像作成を自動でやってくれます（ただし、サイズが妙に奇数なので、輪郭がぼける）。コマンドはメモしておいてPowerShellに張ればいいので、さほどには。
このパッケージ作成を14393より新しいバージョンでやりつつ（BaseImageのバージョンは実際のOSのバージョンと一致している必要がある）最低動作バージョンを14393としておくことは可能で、パッケージ作成のためだけに14393の環境を維持する必要はありません。一応、14393のときのISOで環境を作って動作確認はしましたが。
ちなみに、Desktop Bridgeでインストールしたアプリには、UWP同様に以下のパスに専用フォルダーが作成されるので、この中を探せばAppDataに作成したファイルを直接見ることは可能です。
[system drive]\Users\[user name]\AppData\Local\Packages
Windowsストアに出すことのメリットは、正直それだけで認知度が上がる感じではないですが、クラッシュ報告が自動的に集計されてくるのは参考になります。
なお、2018年2月現在で、Desktop Bridgeはまだ専用窓口から申し込んでMicrosoftの担当者とのやり取りを経てから通常のストア申請に移る方式でした。その担当者は現在は既に日本Microsoftの方になっています。
1. Monitorian
以前の環境光センサーに関するエントリで、Windows 10のアップデートでアクションセンターにモニターの明るさ調整のスライダーが入るらしいと書きましたが、これまでのところは入っていません。
Monitorianの設定中の「調整後の明るさを表示する」は、このエントリで触れた問題に対応するもので、（環境光センサーがある場合に）設定値に加えて実際の調整後の値も表示することで、設定を多少やりやすくします。
内部的には、モニターの明るさに関して利用可能なWin32、WMIの機能をほぼ全て動員し、Device Instance IDをキーに使って統合して利用しています。少々面倒なことに、それぞれに含まれる機能が断片的なので、統合しないと必要な機能が揃わないのですよね。
外部モニターについては、DDC/CIが有効であることが条件ですが、これはモニターとその設定によるので、開発側としてはどうしようもありません。この問題に引っ掛かったらしきレビューが付いてますが、必要条件には初めから書いてあるので。一応、それと直接表示する機能を追加しました。
名前については、昔アプリには機能が分かりやすい名前を付けるべしという話を読んだことがあって、それを考慮していたこともありますが、そんなお行儀に囚われる必要などないと悟ったので、造語しています。
2. Wifinian
Native Wifiのマネージド実装であるManaged Native Wifiを利用するアプリから機能を強化・リファインの上、改名したものです。
機能としては、前のアプリと比べて、Wi-Fiの状態変化に応じて自動的に更新するようにした、Auto ConnectとAuto Switchの設定に合わせて自動的に介入して接続先を切り変える機能（Engage）を付けた、というのが主な違いです。後者はWindows 7まではOS標準であった機能が、Windows 8以降で簡略化されたものを、再び使えるようにしたことになります。
この辺はMicrosoftのデザイン上の判断で、「Wi-Fiセンサー」の顛末も見るに、ユーザーはWi-Fiに繋がりさえすれば何だって気にしないだろうという判断があったものと想像しますが、まあ実際そうかもとは思いつつ、ユーザーの意図で決めたい場合もあるので。
内部的には、このためにManaged Native Wifiを強化し、WlanClientを保持してWi-Fiの状態変化を監視できるようにしています。引き続きReactivePropertyを使わせていただいてます。その点で再確認した注意事項は、ReactiveCommandに繋げる前にはUIスレッドに戻しておけということです。
名前については、同上。Wifiの後は語感です。
3. ScreenFrame
タスクバーの通知領域にアイコンを出しつつ、タスクバーに引っ付いたウィンドウと通知領域アイコンに重なるウィンドウを（NotifyIconのContextMenuと同じ位置に）出すためのライブラリです。Wifinianの前のアプリで開発したものをベースに、Monitorian用に開発し、後にWifinian用に拡充しています。Wifinianではウィンドウのタスクバーからの脱着ができるようになっています。
このコードの肝は、
- WM_WINDOWPOSCHANGINGメッセージに引っ掛けてウィンドウのサイズ・位置調整をすること。これにより、ウィンドウのサイズ・位置変更を全て捕捉し、状態に応じてそのWINDOWPOSを改変することでサイズ・位置変更に自然に介入できる。
- NotifyIcon中のNativeWindowへのWM_DPICHANGEDメッセージを監視することで、通知領域のあるスクリーンのDPI変化を捕捉すること。
マルチモニター環境で通知領域アイコンのあるスクリーンのDPI変化をどう検知するかが課題になっていたが、これによりそのスクリーンにウィンドウがない場合でも検知できる。なお、NativeWindowへのウィンドウメッセージ監視は、そもそもNotifyIconがそうしていることに倣ったもの。
そういえば、先日、LGの42.5インチのモニターの実物を見てきましたが、広すぎてスクリーンの端に付いたタスクバーを起点とするUIにはもう無理があると感じました。既にこのサイズのモニターが普及価格帯に入っていますが、Microsoftはどうする気ですかね。
[追記]
後から気づきましたが、NotifyIcon中のNativeWindowはプライマリーモニターに存在する扱いになるようで、これではプライマリータスクバーのあるモニターのDPI変化を必ずしも検知できません。また、プライマリータスクバーはどのモニターにも移動できるので、これを完全に追いかけるのはほぼ無理です。
4. StartupAgency/StartupBridge
常駐アプリとして必要な自動起動のためのライブラリがStartupAgencyです。自動起動の方法は幾つかありますが、コード的に一番簡単なのはレジストリに登録することで、インストーラによるアンインストールで掃除できることを前提にすれば、それで十分なのでその方法を取っています。
ただし、Desktop Bridgeの場合はその方法ではダメで、UWPのStartupTaskを使う必要があるので、そのための別ライブラリがStartupBridgeという構成になっています。
問題は、これによる自動起動とユーザーによる手動起動をどう判別するかで（自動起動のときはウィンドウを出さないようにしたい）、自動起動のときにArgumentsを付けることができれば簡単ですが、StartupTaskでこれをやる方法が見つかりませんでした。
代替策として、完全な方法ではないですが、アプリの起動時間を記録するようにし、自動起動が有効な場合に、起動時に前回の起動時間とOSの起動時間（セッション開始時間）を比較して前者の方が前であれば自動起動と判断する方法を考えましたが、どこに記録するかという選択が残ります。
この記録には、ライブラリのモジュール性を高めたかったので、UWPのLocalSettingsを使うようにしました。Desktop Bridgeの場合は実はこの手が使えます。といっても、TaskIdはAppxManifest.xmlのものと一致する必要があるので、そこのアプリ本体への依存は避けられませんが。
[追記]
過去のStack OverflowでのMSFTの人の回答を見ても、Argumentsを付ける方法はないようです。
5. Desktop Bridge
Desktop Bridgeのパッケージ作成は今ではVisual Studioでも直接できますが、Desktop App Converterのやり方に慣れたので、そちらを使っています。面倒な画像作成を自動でやってくれます（ただし、サイズが妙に奇数なので、輪郭がぼける）。コマンドはメモしておいてPowerShellに張ればいいので、さほどには。
このパッケージ作成を14393より新しいバージョンでやりつつ（BaseImageのバージョンは実際のOSのバージョンと一致している必要がある）最低動作バージョンを14393としておくことは可能で、パッケージ作成のためだけに14393の環境を維持する必要はありません。一応、14393のときのISOで環境を作って動作確認はしましたが。
ちなみに、Desktop Bridgeでインストールしたアプリには、UWP同様に以下のパスに専用フォルダーが作成されるので、この中を探せばAppDataに作成したファイルを直接見ることは可能です。
[system drive]\Users\[user name]\AppData\Local\Packages
Windowsストアに出すことのメリットは、正直それだけで認知度が上がる感じではないですが、クラッシュ報告が自動的に集計されてくるのは参考になります。
なお、2018年2月現在で、Desktop Bridgeはまだ専用窓口から申し込んでMicrosoftの担当者とのやり取りを経てから通常のストア申請に移る方式でした。その担当者は現在は既に日本Microsoftの方になっています。
登録:
投稿
(
Atom
)
