モルタルコのプログラマ日記

引き続きMacOS版のUIを見ているが、MacOSのUIの自由度が低すぎてどうにもならず。Xamarinはネイティブのコントロールを使うので、他のフレームワークに引っ越しするのは容易だと思うんだけど、Macみたいにネイティブコントロールの表現能力が低いとちょっと扱いづらくなるという特徴がある。UnityだとUIは独自描画なのでどのプラットフォームでも同じ動きになるけど、Unityがなくなったら引っ越しが難しい（使ったことないので分からないけど）。一長一短。

ボタンのボーダーを、マウスを重ねたときだけ白い四角にしたいのだが、調査の結果不可能。ボタン自体のボーダーは今となっては古くさい立体表現になっていて、Bezelをいろいろ変えても縁に合わない。Layerの色を変えるとボーダーっぽくなるのだが、マウスカーソルを重ねたときの動作を変えることができない。

テキストボックスの背景色を半透明の黒にしたかったのだが、Bezelの背景が真っ白で、半透明にならない。Bezelを消すと何故かテキストが上そろえになるし。半透明は諦めて背景を灰色にしてみたが、カレットの色が黒で固定されているので変えられない。変えるにはNSTextFieldのWindowのメソッドを呼ぶ必要があるが、Windowが設定された後に呼ばれるイベントがない。XamarinはNSFormsTextFieldという派生クラスをセットするが、Privateなので触れない。

WT4.0完了したけど何かやってないと暇なので、リリース当日からWindowsストア版やらMacOS版やらを考えている。どっちも結構直さないといけない。

MacOS版のXamarin Formsを4.2から4.4に変えてみたが、何故か「テキストボックスがあると画面遷移で落ちる問題」が4.3SR1で直っていた。バージョンアップで問題が増えるんじゃなくて減ることなんてあるのか。

クローズドベータで出た問題点も修正できたので、Weather Typing 4.0をリリース。WT3では、WT2にあった機能の実装と各プラットフォーム対応を優先させていてずっとUIに手を付けられなかった。そっちはようやく終わったので、UIを一新できた。多少は配信に堪えられる感じになったかな。

今回背景をちょっと変えてみた。天気の背景もいいんだけど、背景が暗い方がやっぱり見やすい。唯一の天気さが消えてタイトルと乖離してしまうが、もはや気にしても仕方がない。タイピングは天気のようなものだ、とかなんとかかんとかってことで。

あとは音だけど、カウントダウン音をいろいろ試してみたが、どれもしっくりこないのでとりあえず保留。

この後はどうしようかな。とりあえずWinストア版作って、MacOS版作ったら、ワード自動生成の研究に戻るか。その前にVectorも登録しないと。

追記。Windows 7はサポート範囲外にしたがたぶん動くはず。手元に環境がないので、何か問題があっても対応できない可能性が高い。実はWindows 8.1とかWindows 10 32bitとかもテストしきれないので試してはいない。こちらは環境はあるので問題への対応は可能。

Twitterで書いたとおり、WT4.0はテスト完了。あとはクローズドで試してもらったりWebサイト更新したりで来週中にリリース予定。

で、いい機会なのでウェザタイの指標を測ってみた。この辺の値を記録しておくと次のバージョンで便利なので。

全体規模

結局分かりやすいステップ数で考えると、もろもろ含めてウェザタイのソースは約10万行。

CLOCの結果。

クライアントがほぼC#/Xamarin Forms、入力やI/O周りでC/C++を少し利用。XMLはresxのことなので、若干自動生成分がある。ランキングやロビーのサーバがJava。Perl/PHPはランキング、ワードサーバに使ってたけど、今はほとんどJavaになっている。

こう見ると、20年とはいえなかなか1人で作る量ではない気がする。大手で作ろうとすると軽く1億円くらいかかるのかなあ。1億円売り上げるにはタイピング界の人口が・・・とか考えていくといつかのジェイブログさんの書き込みで「タイピング企画が通らない」と言っていたのもなんとなく分かりますね。

まあ、WTの場合、商用に比べてOSSとかフレームワーク使わずに一から作ってる部分が多いので、その分多くなってるかも。結局製品寿命が長いことを考えるとそうせざるをえなくて、20年前と変わってないのは結局Raw SocketとかDirect Inputとかそのくらいしかないような気はする。Xamarin Formsもいつまでメンテされるか分からないけど。

WT4.0の開発

WT4.0の開発はRTC 2019の後に始めたから、企画、設計、実装、テストで約2ヶ月。RTC 2019版からWT4.0の改造が約1万行だったから10％直したことになる。

レグレッションテストの全件数が576件で、うち自動テストが455件（約80%）。前回作ったAppiumによる自動UIテスト、やっぱりテスト効率がいい。今回かなり本体を修正したのでテストコードも結構直したけど、これがなかったらテストにあと1ヶ月くらいかかる気がする。テストコードは直し終えたので、Android版とか作るときは（理想的には）テスト実行するだけでいいし。

で、WT4.0開発でレグレッションテストした結果は不良32件。これが多いのか少ないのかは分からないけど、次回の参考にはなる。

WT4用に通信の改善を実装。せっかくなのでWTの通信処理を詳しく書いてみるか。ラグとか同着とかの理由を知りたい人もいるかもしれないし。

WT3までは、プレイヤ全員のメッセージが届いたら全員の入力を確定して、次のフレームのメッセージを送るという実装をしていた。以下の図は「ABCDEF」をAとBが打ち込んでいる例。自分のプレイヤが打った文字は遅延なく画面に反映し、他のプレイヤが打った文字はメッセージが届いてから画面に反映するので、AとBでは見ている画面が違う。ただし、内部的には自分と他のプレイヤのメッセージがそろったときに時間を進めるようにしているため、AとBの同期がとれている。ここで、いくつか問題がある。

1. Bの2フレーム目がAに届いたとき、一度に画面に描画するので3文字一度に消えてしまう。
2. フレーム間隔が一定にならず表示速度が安定しない
3. 同様に、1フレームで複数の文字を処理するので、遅延が大きいと同着が発生してしまう。
4. いろいろな状況によるが、遅延が少ない方が少しだけ有利になる。

WT初期は電話回線だったので通信対戦ができるだけでもよかったが、さすがに配信とかを考えるともう少しなんとかしたいよね、ってことで、WT4ではもう少し通信量を上げて対策をしてみる。下の図で、点線の矢印が新たに追加したもの。入力があったらとにかく相手に送りつけて画面に反映するようにした。ただし、あくまでも画面表示だけの変更で、内部処理は変えない。速度やワード取得の判定は今まで通り全員のメッセージを待つので、今までと変わらない。

上記の問題点では、1と2だけの対応になる。内部処理でローカルPC上の絶対時間を見て判定するようにすれば3と4も改善できるし、工夫次第で観戦モードではラグが発生しないようにもできそうなのだが、試した感じ、割とここまででも十分効果がありそうだったので、WT4ではひとまずここまで。

ちなみにこの辺り、約20年前に独力で実装した部分なので、今のネットゲームから見ると全然なってないんだろうな、と思って「オンラインゲームを支える技術（WEB+DB PRESS plus）」なんかを読んだりしてみたけど、割と合ってて安心した。

Weather Typing 4.0の開発。長いことプラットフォーム対応やテストプログラムとかやってたけど、一段落したので、ようやく見た目とか機能面に着手できるようになった。公開はもう少し先だけど開発は順調。次バージョンがどうなるか軽くメモ。

• UI。3.3以降、プラットフォーム共通化で変な見た目になっていたが、Windowsへのローカライズで少しはまともになる。ちなみにユーザの表示は、結局RTCの左右UIではなく今まで通りの上下UI。多少表示を整理して文字を大きくしたり。
• 機能追加。観戦機能、正確性ルールの追加、勝利数の表示、ワードスピードの表示、入力不能時間のルール化、ワードの追加と削除、はだいたい完成。
• 仕様変更。ルール周りはだいぶ変わる。考え方としては、ルール設定者が自分の得意なルールを決めて相手に押しつけるというもの。ワードもルール設定者が決めるようにし、交替で相手のワードを打つのは廃止。ルールを誰が決めるのかはとりあえずホストにしてるけど、まだ検討中。
• 不良修正は、RTCで出ていたものを中心に対策。

RTCで出ていた不良のメモ。

• 対戦開始時に打ち込めなくなる問題。前の対戦でシフトOnで終わると、次の対戦開始時にシフトOffになるのだが、次の対戦前にキーを8打鍵（on+offで16打鍵）以上してしまうと、キーバッファが溢れてシフトOffが消えてしまう。RTCの動画を見ると分かるけど、結構な選手がカウントダウン中などにエアプレイをしているのでバッファが溢れる。さらに、コンピュータワードでは後半にシフトを押すワードが出ることが多く、起きやすくなっていた。
• 対戦開始時にラグが出る問題。3、2、1、0のカウントを、1000ミリ秒Timerで実現しているが、タイマー起動のタイミングが微妙にずれるのが原因。タイマーのタイミングが 1001 2002 3003 4003 とかだと1000未満を切り捨ててちゃんと1234になるのだが、999 1998 2998 3998 4998 みたいに1秒未満になってしまうと、1000未満を切り捨ててて01234になって1秒増える。たまに1秒未満になるとカウントが3、1、0みたいにスキップすることもある。WT2は60FPSで処理していて、WT3でTimerに変えたことでバグっていた。
• 打鍵時にマウスカーソルがちらつく問題。よく分からないけど、ローマ字表示の上にレイヤーを付けたら起きなくなった。レイヤーはワードスピード表示のためでたまたまだけど、起きなくなったからまあいいか。

この辺りは今日RTCの動画見ながら原因調査したけど、推理力と観察力と地道な捜査が必要で、プログラマの能力はプログラムだけじゃなくてこういった能力が大事だというのを感じる。

で、あとは大会用にホスト兼観戦モードみたいなのを追加するのと、通信のラグ改善を入れたらテストして完成かな。さすがに2/16のWarriors of Typingには間に合わないか。

あ、あとカウントダウンの音か。一応書いておかないと怒られる。

WT RTC2019版の正確性の仕様についてメモ。

WT RTC2019 v06版では、正確性の仕様がWT本家およびRTC2018版と変わっている。WT本家では、画面表示時の正確性はC#のdouble-文字列変換で少数点1位まで表示したものに従う。四捨五入っぽいけど正確なところは不明。で、変換の詳細が分からないと95%未満で黄色い背景にすることは難しいので、RTC2019 v06では少数第1位で切り捨てることにした。結果、最大0.05%ほど正確性が下がる。例えば、最後のワード、最後の文字で、今1999打鍵105ミスだから、あと1文字はミス可能、全速力で打とう、といったギリギリの計算をしていると、106ミスで95%を割ってしまい、負けてしまうので注意が必要。

ちなみにWT本家への反映予定はない。入れるにしても過去との互換性等、いろいろ検討しないと。

既に各所で告知されている通り、12/1の「REALFORCE TYPING CHAMPIONSHIP 2019」のオフライントーナメントでWeather Typingが使われる。で、今日告知があったが、11/24に行われる「N高等学校 第2回 ネット運動会～esports Festival～」の競技の一つにWeather Typingが入った。RTC2019は現地参加予定、ネット運動会の方もネット配信あるので楽しみ。

両方とも事前に話を聞いていたが、日程かぶってなくてよかった。ていうか、日程かぶりを心配するほどWeather Typingが使われることにビックリだ。ゲームに詳しい人に聞く感じ、RTC2019会場の大型ビジョン（タイトーステーションのところ）はゲーマー界隈では知られているらしく、そこに映るのは結構スゴイらしいし、ネット運動会もFortniteと並んでいるのはスゴイことらしい。まあ、タイピングでe-sportsというのが（TODを除いて）商業ソフトにないだけではあるけど。

ちなみにRTC2019の方はOEM的に配信特化した版を提供している。運営の方にはWeather Typing本体にも配信用のデザインを反映させて欲しいとは伝えている。「Warriors of Typing」も続けて頂けているし、配信用画面とか観戦機能を付けて4.0にできるといいなあ。

Weather Typing 3.7を公開。

Windowsデスクトップ版は、いつかのWindows 10のアップデートでUIがおかしくなった問題の修正。これだけでバージョン番号をあげるとWT4.0に近づいてしまうのでなんとなく保留していたのだが、いろいろ大会に使われてきてもいるので、そろそろ公開しないと。

MacOS版は、本当は対戦サーバに接続する機能だけ追加しようとしていたのだが、結局ほぼWT3.6までの機能は入れた上で公開した。当時のソースコードを再度ビルドすると、新しいMacOSライブラリでは全然ちゃんと動かなくて、Xamarin Formsを4にしたり、いろんなバグを回避をしたり大変。結局最新ソースを使うしかなかった。

• 今まで問題なかったところで「UIスレッドで呼べ」エラーで落ちるようになった
• スクロールビューなどの中にエディットボックスを入れて、エディットボックスに一度でもフォーカスしてから画面遷移するとフリーズする

UIスレッドの問題は面倒だけど回避は簡単。いろんなところにUIスレッドコールを追加して解決。エディットボックスの問題は、その時点でもうMacOS版を捨てようとしたくらい致命的。バグは増えても減ることはないので今後も修正されることはないし。でもあがいた結果、画面遷移の直前にエディットボックスを含むちょうどいい領域を非表示にすることでたまたまうまく動いたので、それで回避することにした。

そしてリリース版を作ろうとしたらVisual Studioの署名オプションがDisableになっていて付けられない。MacOS Developerのサイトから証明書をダウンロードしたりいろいろしたけど、結局サイトからダウンロードする必要はなくて、XCodeのオーガナイザで追加することでVisual Studioの署名オプションが有効になった。

で、WT3.6で入れた背景画像選択機能がサンドボックス化で動かなくてトークン化したり、初回起動時に権限を聞かれるようになったりしつつようやくpkg化完了。したんだけど、pkgをインストールしたらもう二度とpkgからもMacOS Appストアからウェザタイをインストールできなくなった。トラップ。3.7をリリースしたらストアから入れられるようになったけど、これだとバージョンアップのテストが不可能。やっぱりMacOSは一般の開発者に厳しい。

Android版Weather Typing。Android版というか全プラットフォームでネイティブライブラリを使っているのだが、Visual Studio Xamarinを使ってアーカイブを作るとx86/x64のどちらかにしかネイティブライブラリが入らない。仕方ないので今までは64bit版だけを入れていたのだが、おそらくx86のAndroidでは起動エラーになっていたはず。なので今回はもう64bit専用にして32bitはインストール不可にしたのだが、掲示板で32bit版のOSに関する報告があった。

いくつか調べてみたが、Xamarinの公式でも困っている人がいて、Xamarinとしての解決策はなさそう。Androidとしての解決策として、32bit用と64bit用のapkを両方登録することができるらしい。なので今回、32bit用のネイティブライブラリを入れたapkを登録した。ただ、Xamarinの制約？バグ？として32bit版専用のapkを作っても64bit用のmonoライブラリも入ってしまう。なので、GooglePlayに、1つVersion Codeを下げた32bit版を登録してみた。これでどうなるか。

Weather Typing 3.6 Android版を更新。ロビー参加とネット対戦に正式対応。今までホストを作るのが困難だったので隠し機能扱いにしていたのだが、サーバクライアント式にしたことでようやく正式対応と言えるようになった。

今回、Android 64bit版のみ対応にしてみたけど大丈夫なのかな。前のバージョンでも32bit版ネイティブDLLを入れていなかったのでエラーになっていたはずで、64bitのみにした方がややこしくないかなってことで。

Xamarin+Appiumによる自動テストは、入力関係はうまくいかなかったりしたが、70%くらいは自動化できた。あとはMacOSとiOSの自動テストができるとテスト効率が上がる。

ちょっと更新が遅れたけど、高知県のPCショップエレパさんの2019エレパ夏祭り内でタイピング大会が開かれ、Weather Typingを使って頂いた。

メールで連絡を頂いたものの高知県ということでどうかな、と思いつつツイートしてみたところ、タイピングAGOGOのおはようさんが高知県在住ということで参加された模様。しかも優勝してるし。Twitterすごい。

大会の詳細もブログにまとめられていて参考になる。RTCはかなりガチな競技会になっているが、こういう場の場合、対戦だと時間拘束もされるし、単純にスコアを競う感じの方がよいってことかな。もっと派手な見た目のソフトの方が一般受けはしそうだけど、その中でウェザタイを使ってもらってありがたい。

Windows 10のMay 2019 Updateを入れたら、ウェザタイのタイトルや結果画面のListViewが崩れるようになった。

調べてみたところ、ListViewの表示がちょっと遅れて、最初の行を追加するときはListViewの幅が分からず最小の幅になって、その後の行はListViewの幅が確定してちゃんと表示される、っぽい。なので、最初の表示だけListView.SizeChangedが来たときにListViewItemを追加するようにした。もうWPFは廃れていくだろうし、適当でいいや。

しばらくWeather Typing 3.5を開発版としていたが、開発版のままにしておくデメリットが大きいので、正式版として公開した。Xamarin Formsがバージョン同じままバイナリが変わる問題もあって、リビジョンアップができないのでマイナーバージョンアップにしている。

本当はストア版やMac/モバイル版をアップデートしてから正式版にしたかったのだが、もうこっちは少し時間がかかりそう。

あんまり下手なことはかけないのでTwitterかブログか迷ったけど、折角なのでこっちに。TwitterでGANGASさんの、タイプウェルランキングが6/1で更新終了という話が。TODとタイプウェルがなければウェザタイはここまでになってないので、感謝。思わずタイピング本のインタビューを読み返したりした。ウェザタイの適当なランキングと比べて、あの厳格なランキングを20年くらいメンテし続けているのはすごい。

ウェザタイはどうなるかな。メンテだけなら負担はほとんどないので、ランキングやロビーは続けようと思えばいつまでも続けられる。ただ、プラットフォームについていくには、定期的に作り直しが必要になるので、WT2のときみたく他のソフトウェアを作り始めてしばらく放置はありうる。あとは、何かあったとき用に、ボタン一つでソースコードを公開する仕組みか、ランキングと対戦で不正ができないようにした上でオープンソース化できる仕組みを編み出さないと。

冬休みの研究としてウェザタイをクライアントサーバ方式にしてみた。これをそのまま使えばポート開放しなくてよくなる。ただ，全部をサーバクライアント方式にすると，サーバの通信量的にどうなんだろう，というのがあるので，直接つながらなかったときだけウェザタイサーバを使うようにすることを検討中。ちなみに通信量を測ってみたら，4人対戦で30ワード打つとだいたい送受信2.5MB。1日100回対戦があっても250MBで，全部クライアントサーバにしたところで，まあたいしたことはないのかな，とは思う。

ちなみに，以前のネットワーク構成。ホストとゲストをP2Pで接続するので，全員にポート開放が必要。元々はホストもゲストも同条件にしたかったのでこういう構成にした。

今のネットワーク構成。ホスト側にサーバを分離して，ゲストからはサーバにつなぎにいくので，ホスト側だけポート開放が必要。遅延が大きい環境だと，多少ホスト有利になる可能性がある。

で，検討中のネットワーク構成。分離していたホストをdenasuサーバへ持って行くことで完全なサーバクライアントに。

一応もう一つ選択肢があって，サーバを公開して誰でもサーバをたてられるようにする，というのもある。Linuxに.NET Core runtimeを入れて，1.5MBくらいのサーバを実行するだけで，サーバを立てるのは割とお手軽。

RTC2018の本番前、TwitterでWeather Typingの指摘をもらった。内容は、左右のシフトを両方押して片方離すとシフトが押されていないことになるというもの。ウェザタイ2では問題ないようなので、ウェザタイ3くらいからのバグっぽい。

ひとまず左右のシフトを区別しないまま、シフトを押した回数をReference Counter的に解決してみたが、左右のシフトの押し離しイベントの数が合わないことがあるようでダメ。RTC2018では修正しないことにした。

で、落ち着いて直してみたが、WPFはいいけど、UWPだとそもそもKeyDown-KeyDown-KeyUpしかイベントが来ない。こんなところでハマるとは。とりあえずKeyStateをとってシフトが押されてなければKeyUpイベントを無理矢理送ることでとりあえず解決。

ウェザタイ、RTC2018バージョンで改造した部分を本体のカスタマイズでできるようにする計画。まずは背景画像を設定できるように。

やっているうちにいろいろ増えてしまったけど、これだけあればだいたいのニーズに対応できるかな。タイル表示は難しいので入れてないけど。

前の日記で書いていたREALFORCEの画像を背景に設定したのがこれ。公式背景にはできないので、ここに貼り付けるだけ。

D.E.放送局さんの「視聴者参加型 タイピング対決～負けたら台詞読み～」を見てみた。ちょっと前に配信に使って良いか問い合わせて頂いたのだが，twitterで情報が流れてきたので。

タイピングサミットでオフラインの大会は何度か見ていたのだが，配信だとこうなるのか，というのでタイピングの動画としても面白かったし，開発視点でも参考になった。いくつかメモ。

• 対戦できる人数。仕様としては8人まで。誰かがOKを押して「待機中」になると，その後の人が参加できなくなる。そのため，4人で締切になったりしていた。キャンセルすれば「待機中」を消せるとかあるけど，やっぱりここは分かりづらい。
• 5人以上だと画面表示や通信の問題があるので，対戦人数を制限するオプションはいるかも。オフラインの大会だと人数を制限できるのでよいが，配信だと必要になってくる。
• 4桁のゲーム番号はアプリを終了させるまでは変わらない。これは何度か連続で同じ人とやる場合を考えた仕様だけど，配信の場合，ゲーム番号をみんなに伝えて早い者勝ちにする，って感じになってて，毎回変わった方が便利そう
• 配信者も，見てる側も，配信動画を流しながらウェザタイの対戦もしてるわけだが，4人対戦くらいなら十分な速度が出るというのが分かった。8人はさすがに重そうだったけど。

ついでに，ちょくちょくウェザタイを○○に使いたい，っていうメールを頂いているので，「よくある質問」にOKって書いておいた。

Weather Typing 3.3がMacOSストアで公開された。これで予定していた全プラットフォームで公開されたことになる。GitHub更新がまだ残ってるけど。

各ストアの入り口はWeather Typingのページを参照。

明日から関西に別荘を作って仮住まいするので，なんとか間に合ってよかった。これから荷物を準備しないと。

Weather Typing 3.3をMicrosoft/Google/Appleのストアに申請した。Windows/Androidは既に公開済みでiOS/MacOSは申請中。

久しぶりに申請した感想としては，Windowsストアが一番楽。Appleストアはきつい。Windowsストアはアプリが少ないのでできるだけ登録しやすくしていて，Appleはアプリが多すぎて質が落ちるのを嫌って障壁を作っているんじゃないかと邪推してしまう。

Microsoftストアは特に何もつまづくことなく申請と登録が完了した。前回の申請からそんなに期間が空いてないのもあるのかもだけど，一番申請しやすい気がする。

Googleプレイは特に前と変わらずだが，元々見づらいというか・・・。申請しようとしたら，もうすぐ古いOS（API）のアプリは申請できなくなるという警告が出た。でAPIレベルを上げたら，パーミッションの設定の方法が変わっていて動かなくなった。とりあえずアプリ起動時に，パーミッション許可をユーザに聞くようにして，許可されなかったら終了するようにした。本当は許可しなくてもある程度使えるようにするのがいいんだろうけど。

Appleストア。どのストアも必要なスクリーンショットやアイコンがかなりあるんだけど，Appleはビルド，アップロード，サブミットと色んな段階で少しずつエラーにしてくるのがつらい。スクリーンショットも，厳密にピクセル数が決まっているのに，シミュレータではどうやってもその解像度の画像を作れないとか。最終的に「アップロードして完了したけどiPadのアイコンはなかったよ」とか言われて，修正するにはアプリのバージョンを上げないといけないとか。ちゃんとしたアプリを開発している人は途中で投げ出して，スパム業者だけはちゃんと頑張るみたいな状況になったりしないのかな。

ただ，輸出管理のことをちゃんと出してきたのはAppleストアだけかな。Mac版を申請しようとしたら，HTTPSを使っているだけでも輸出管理が必要だ，と言われて，なるほど，的な。denasu.comのHTTPS化でここに影響があるのか。結局，年次レポートを米国に出せばいいのかな。

Xamarin.FormsにWPFが追加されたので，Xamarinで実装できなかった既存機能をXamarinに入れている。あとはプラグインくらいなのだが，1つ問題が発生。

今回，プラグイン共通DLLであるWeatherTypingPlugin.dllを，PCLから.NET Standardに変更したりいくつか修正をした。でもこのDLLはStrong Nameになっているので，DLLのロード元をリビルドする必要がある。Denasu System公式プラグインはリビルドすればいいのだが，非公式のものもリビルドが必要になる。

V1共通DLLとV2共通DLLを両方読み込むと型が衝突してしまうし，V1共通DLL用のAppDomainとV2共通DLL用のAppDomainを分離して両方読み込んでみるというのも試したけど，結局，V1プラグインが作成した共通DLL内のインスタンスの型をコンパイルできず，うまくいかなかった。正攻法はGACに入れることなんだろうけど，やっぱり抵抗がある。

てことで，WeatherTypingPlugin.dllのStrong Nameを外すことに。これならファイル名が合っていて後方互換性を確保してあれば読み込める。今まで作られていた非公式プラグインは一度リビルドしてもらわないと動かなくなってしまうが，今ならまだ大丈夫だろうという判断。

ちなみに。UWP，つまりWindowsストアアプリでも.NET StandardなDLLを使ってプラグイン的なものは作れそう。AppDomainは作ることはできないのだが，DLLのLoadはできる。UWP自体サンドボックスで，ファイルアクセスなどが制限されているのでセキュリティ的にはそれほど問題はないのかな。ただ，DLLの置き場所が特殊すぎるので，プラグインのダウンロード機能は必須。