2016年5月15日日曜日

UWP と フォルダを介したデータ共有

UWP / StoreApp では、アプリが「直で」アクセスできるのはアプリそれぞれが持つフォルダのみである!という原理原則があります。

File access permissions
https://msdn.microsoft.com/en-us/windows/uwp/files/file-access-permissions
Open files and folders with a picker
https://msdn.microsoft.com/en-us/windows/uwp/files/quickstart-using-file-and-folder-pickers

この縛りがあるために、UWP / Store Appは他のUWP / Store Appや、ユーザーのファイルを直接触る事が不可能であり、窮屈だけど安全な環境になっております、という事になっています。

…が、原理原則だけでは人は生きては行けないので…Win10 UWP では多少その辺り柔軟な対応になってきています。ここでは、フォルダを介したデータ共有として有名なものと、そうでもないものを紹介します。


GetPublisherCacheFolder

https://msdn.microsoft.com/en-us/library/windows/apps/windows.storage.applicationdata.getpublishercachefolder.aspx

有名なほう。

  • 同じマシン
  • 同じユーザー
  • 同じアプリベンダー
の、複数のアプリ間で共通に使えるフォルダです。

このフォルダにアクセスしたいアプリは、各々のアプリのPackage.appxmanifest でアクセスするフォルダ名を<Extensions>内で宣言する必要があります。


Package.appxmanifest
デザイナでは変更できないので、右クリック→「コードの表示」で編集します。

上のように宣言したアプリは、コード中で以下のようにフォルダにアクセスできます。
ポイントとしては、このフォルダはアプリから直でアクセスが可能です。Windows.Storage ... OSのBroker Process を介さずに、.NETならば System.IOで直で触ることができます。


CacheFolderに触っている様子 直アクセスOK

なお、このフォルダの物理パスは

C:\Users\<UserName>\AppData\Local\Publishers\<publisherId>\<CacheFolderName>

になります。<CacheFolderName> は、上のManifestで指定した名前です。


SharedLocalFolder

https://msdn.microsoft.com/en-us/library/windows/apps/windows.storage.applicationdata.sharedlocalfolder.aspx

無名なほう。

  • 同じマシン
  • 同じアプリ

の、複数のユーザー間で共通に使えるフォルダです。

このフォルダにアプリからアクセスしたい場合、まず管理者がHKLMのレジストリを変更する必要があります。以下のKeyを作成し、DWORD Value "AllowSharedLocalAppData" を 1 にセットします。


HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\AppModel\StateManager

上のRegistry Flagがセットされている場合、UWP Appから「SharedLocalFolder」にアクセスできます。ちなみに、Flagが0又は存在しない場合はfolderにnullが返ります(システムの既定ではKey "AppModel" 自体が無い)。また、このフォルダもアプリから直でアクセスが可能です。


SharedLocalFolder に触っている様子 こちらも直アクセスOK

なお、このフォルダの物理パスは

C:\ProgramData\Microsoft\Windows\AppRepository\Families\<PackageFamilyName>\SharedLocal

になります。フォルダ内で作成されたファイルはアクセス権が「Everyone-FullControl」になります。
また、このフォルダは上記Registry Value が設定されている場合、アプリ側で当該フォルダを使用しなくても勝手に作成されるようです。アプリ起動時のタイミングで作成されているように見えます(つまり、フラグをセットすると全UWP アプリでこのフォルダアクセスが有効になります。要注意)。


背景


UWP がお披露目となったBuild 2015では、UWP App 間でデータ共有を行う手段が幾つか追加されました、という文脈の中で前者 PublisherCacheFolder が紹介されていました。以降のWindows Blog等でも紹介されていたように記憶しています。

一方、後者のSharedLocalFolder はBuildでは完全にスルーでした(そのはず)。 VisualStudioでいそいそとコードを書いていると、ApplicationData.Current のIntelliSenseでチラチラ表示はされるので存在は知っていたのですが…いざMSDN Docを見ると木で鼻を括ったような全くなにも説明していない表記で、何ぞこれ???という。

状況が変わったのは以下のBlogで…MSのフィールドエンジニア氏がこんなんだよーと説明していました。まじか。
https://blogs.msdn.microsoft.com/notime/2016/03/04/sharing-data-between-users-of-a-universal-app/

ただ、実際こう見てみると…半ば隠しAPI扱いなのもやむを得ない感じですね。
HKLMの変更が必要であるため、UWPだけで使用可能になる類の物ではありません。管理者権限が必要です。

(Registry Editorの無いMobileや他のDeviceFamilyではどうすんだろう?という疑問もあります)

実際に使用されるケースは…LOB Appでの使用、All UserなWin32 Appとの協調動作を企図した使用等、かなり限定的なのではと思われます。



2016年5月5日木曜日

Desktop App Installer を使ったUWP / Centennial AppXの配布

4月末、MSがDesktop App Installer なるUWP Appをストアに載せてこっそりテストしているよ、という記事がMSPowerUserに載りました。

Microsoft Desktop App Installer now available in the Windows Store
http://mspoweruser.com/microsoft-desktop-app-installer-now-available-in-the-windows-store/

このアプリ、まだストアに載っており、誰でもDownload・Installできる状態です。
この記事はDesktop App Installer を試し、これからのUWP AppのDeploy方法について考えてみたよという話です。

Microsoft Desktop App Installer
https://www.microsoft.com/store/apps/app/9nblggh4nns1

※インストールできるのはWin10 RS1 以降です。Win10 TH2には入りません。
※5月6日追記…今上がっているPackageは「Win10 Desktop / Mobile, x86/x64」が対象であるため、殆どのWin10 Mobileには入りません。
※5月9日追記… 名前が「App Installer」に変わり、Win10 TH2 にも入るようになりました。しかし、試した所App Installerを使ったUWP App のDeployには失敗してしまいます。
※5月30日追記… MSDN Blogに記事が載ったようです(今まではストアにあったアプリを勝手に見つけて撫でまわしてるだけだったので…)

App Installer!!
https://blogs.msdn.microsoft.com/appinstaller/2016/05/27/app-installer/

記事によると、Win10 Anniversary Updateには最初からApp Installerが入っているようです。


背景


この「AppXをDoubleClickしてインストールできる仕組み」、最初にお披露目となったのはBuild 2016, UWP AppModel Sessionの中でした。"Modern Desktop App Installer"としてAppXをストア外で配布する手段が確立されましたよ、という文脈です。

Universal App Model Overview: What's New in the UWP App Model
https://channel9.msdn.com/Events/Build/2016/B809
(当該箇所は5:19あたりからです。説明・デモでいろいろ大事な事を言っているので、スライドだけでなくセッションの視聴をお勧めします。また最後のQ&Aも)






説明ではCentennialでConvertしたPaint.netをDeployしていますが、別にCentennial用という訳では無く…AppXならばGenericに使うことができます。以下の例では UWP AppのAppx Packageを使っています。


AppX をDoubleClick するとどうなるか


Desktop App Installer をインストールすると、.appx / .appxbundle が Desktop App Installerでの実行に関連付けられ、小包アイコンで表示されるようになります。


拡張子 .appxbundle に Desktop App Installer が関連付けられている様子

ダブルクリックすると、Desktop App Installerが起動します。

仮のUWP App "Shumen" のAppxbundleを起動した様子


この画面以降、インストールできるかどうかは以下の条件により変ってきます。


AppX 未署名の場合・又は証明書がインストールされていない場合


以下のエラーメッセージが表示され、インストールは出来ません。
Either you need a new certificate installed for this app package, or you need a new app package with trusted certificates. Your system administrator or the app developer can help. A certificate chain processed, but terminated in a root certificate which isn't trusted (0x800B0109)

つまり、あなたのAppXがTrusted Rootな証明書で署名されているか、又は、あなたのAppXの署名に使った証明書が「この」システムの証明書ツリーにインストールされている必要があるよ、という事です。

前者…Trusted Rootな証明書での署名は、これまでもApplicationの配布時にはほぼ必須となっているもので、自分が自分であることをVerisign等の発行業者から年数百ドルで証明書を購入することで発行業者に裏書きしてもらいましょう、その証明書でバイナリに署名しましょう、という話です。

後者は所謂「オレオレ証明書」と言われているもので、Appx作成に使った.cer をシステムにインストールすれば前者と同じことにはなります。違うのは、自分が自分であることを証明するのは自分しかいない所です(なのでオレオレ)。
限定的な配布のテスト用途等には使えますが、一般配布にはもちろん使えません(エンドユーザーに.cerを渡してTrusted Rootにインストールさせるのがどう考えても間違いである、.cerが他者に使われてしまう恐れがある、不正なTrusted Rootとして使用を停止される恐れがある、等々ダメな理由はいくらでもあります)


以降は、上の条件を(オレオレ証明書で)クリアした環境下での検証結果になります。また、以下で参照している「開発者モード」とは、設定→更新とセキュリティ→開発者向け、で設定できる以下の項目の事です。

「開発者モード」

開発者モードが「Windows ストア アプリ」(既定)の場合


実行すると以下のErrorMessageが表示される。
To install this app, turn on sideloading mode in Settings > Update & security > For developers. If you can't turn it on, ask your system administrator to unlock the machine for sideloading (0x80073CFF)

開発者モードが「サイドロード」「開発者モード」の場合


実行すると特にエラーなくインストール可能

これらから、Desktop App Installer は「サイドロード」以上の設定を必要とすることが分かります。
また、この設定→アップデートとセキュリティ→開発者モード、の設定は一般ユーザーには変更ができず、管理者権限が必要になります。
(おそらくPolicyのDeployは可能と思われますが、基本的に管理者マターであるという事になります)


参考...バージョンアップ・ダウンについて


バージョンアップ又は同一バージョンの場合…特にメッセージは無く、置き換えが行われます。未確認ですが、通常のストアでの更新同様にApp構成ファイルは入れ替え、AppLocal Settings/Folderは維持と思われます。

バージョンダウンの場合…以下のエラーメッセージが表示され、インストールはできません。
There's a newer version of this package already installed. To install this older package instead, uninstall the one currently on your system (0x80073D06)



参考…「PowerShellを使った配布」について


これまでは.ps1 を使うDeployが開発用に使われていました。
この.ps1で行っているのは、
  • 開発者モードを「開発者モード」に変更 (PowerShellはSettings Panelを表示するまで 変更自体はユーザーが自分でToggleButtonを押す)
  • .cer をシステムにインストール

という動作です。
  • 開発者モードに入れる事
  • 実際にはユーザーにボタンを押してもらう事
  • .ps1を右クリックして「PowerShellで実行」を選択してもらう事

等、基本的には…エンドユーザーにさわってもらう形にはなっていませんでした。

この項まとめ


今回のDesktop App Installer によって、(証明書を用意できるのならば)「エンドユーザーにストアを介さずAppXを直接ダウンロード・インストールしてもらう」という形がかなり現実的になったと言えるでしょう。

※ 現在は「Desktop App Installer」という独立したUWP App Packageになっていますが…これOS組み込みにしない理由が僕にはどうもわかりません。単に今回は試験中だからかもしれませんが。後から別にインストールするのは手間ですので、RS1 GMには最初から入っている形が望ましいと考えます。


ストア外配布の現実味と将来



Win10 RS1では、上で挙げたセッションで云うように「ストア外」での配布が可能となっています。

ただ、これまで見てきて分かるように、あくまでも署名付きパッケージのみの話と考えるのが正しいように思われます。
「署名の無い」パッケージについては、事実上、一般配布は極めて難しいように思われます。

※未署名パッケージ配布の是非を論じるのは僕の手に余るのですが…個人的な印象としては、(可能であったとしても)未署名のパッケージ・バイナリを配布するのが許される世の中ではもう無いのかなという気がしています。

未署名パッケージ配布は脇に置くとして、これからのUWP Appの配布方法としては

  • Microsoft Corporationと契約し、Windows Storeを使った配布を行う
  • 自前で証明書を調達し、自前でAppXを配布する環境を持つ

この二択になると思われます。

ただ実際のところ…殆どのソフトハウス・個人開発者等は前者…Windows Store を選ぶだろうという気がします。
以下に簡単な長所・短所比較を挙げてみます。ほぼ裏表になりますが、


Windows Store

長所
  • ダウンロード・更新システムをMicrosoftに丸投げ
  • アプリ販売・IAPシステムをMicrosoftに丸投げ
  • Ad Mediationを使用可能
  • OS持ちの既定のマーケットである


短所

  • 販売に30%のMS税がある
  • アプリを載せるのにCompliance Testを通す必要がある(極端なエロス等は無理)
  • Testに数日かかる
  • バカな伸びしろのあるTesterと付き合う必要がある
  • ストアがバグると大変なことになる(2015年は本当に大変でした)

自前配布

長所

  • 売上総取り(料金システムが自分持ちなら)
  • Compliance Testを通さなくていい
  • そもそもTestが無い

短所

  • ダウンロード・更新・認証システムを自分で持つ
  • アプリ販売・IAP システムを自分で持つ
  • 証明書を自分で買う必用がある
  • Ad Mediation を使えない
  • 既定のマーケットではない…見つけてもらえるにはどうすれば

※認証システム…AppX をそのまま配布する場合、そのままではいくらでもCopy可能です。
CopyFreeにするのでなければ、何らかの「認証」の仕組みを自分で持つ必要があります。
キーを販売し、App起動時に認証サーバに見に行って認証する、というような。何かのアカウントに紐づけてもいいかもしれません。


…どうでしょうか。
個人的には、自前配布で短所の要件を克服するよりは…Testの面倒さと30% のAdmission Feeを受け入れたほうが楽かなぁという気がします。
特に、今はゲーム・非ゲーム共IAPでおぜぜを頂く道がとても大事です。そこを全部自前でやるのはなかなかつらいのではと思います。

MSさんもそこはわかっているようで、Win10 RS1ではWindows Storeが大幅に拡張されることになっています。以下のセッション見て頂ければわかるのですが、ざっくりいうとSteamのStore的なものをそのままWindows Storeに持ってくるつもりのようです。

Windows Store: Publishing Apps and Games to Desktop, Mobile, and Xbox
https://channel9.msdn.com/Events/Build/2016/B839


逆に、自前配布の短所で列挙しているような用件を全部自分でクリアするのではなく、ある程度割り切ることで現実的な自前配布も在り得るのかもしれません。
普通のソフトハウスならば証明書は既に持っているでしょうし、認証の仕組みさえクリアできれば何とかなってしまう場合も多いように思われます。Windows StoreのマネをしてMSAなら10個まで、でも良いかもしれません。


また、上の比較は主にConsumer…一般向けアプリで考えてみたのですが、これがLOB…社内配布向けになると全然別の話になりそうです。しかし長くなってしまったので…このあたりにしておきます。