Bootstrapper().Run() 実行時にFileNotFoundException
WPFでPrsimを習得しようと日々格闘中です。
ふとしたタイミングで、Bootstrapper().Run()実行時に
"ファイルまたはアセンブリ 'System.Runtime, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'、 またはその依存関係の 1 つが読み込めませんでした。指定されたファイルが見つかりません。 ":"System.Runtime, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
なるエラーが表示されて進まなくなってしまいました。 シンプルなShellのみ起動するように修正してもダメ。NuGetですべてのライブラリを一旦アンインストールし、最小限のみとして前に正常に起動した状態に戻してもダメ。
どうやら、app.configとターゲットバージョンにより発生(自分のプロジェクトでは4.7.2)するらしい。
.NET Standard issues on .NET Framework 4.7.1 · Issue #567 · dotnet/standard · GitHub
Workaroundsにあるようにapp.configのdependentAssemblyタグをすべて削除し、ターゲットバージョンを一旦4.0にして再度4.7.2に戻したところエラーが消えて動作するようになった...
Visual Studio CodeでMarkdownのPreviewカスタマイズ
はまった。
Windows上のVisual Studio CodeでMarkdown Previewをcssでカスタマイズすることがどうしてもできない。指定した cssファイルがないと言われる。
cssを絶対パスでは指定できないことは認識しており、Markdownファイルと同じパスにcssを置き、setting.jsonでファイル名のみ指定してもダメ。各種記事を見てそのままやってみたつもりでもうまく行かない。 markdown-pdf.styles で指定してPDF出力する分には問題ないのだが。
結論としては、ファイルサーバにおいてあるファイルの場合はダメなよう。ネットワークドライブを設定してもダメ。 ローカルに持ってきたら普通に動作した... 半日無駄にした... なお、ファイルサーバに置いていると画像も表示されない。Visual Studio CodeのMarkdown編集はファイルサーバ上のファイルとは相性が悪いと認識した。
WPFのMVVMについて考える
最近、Windows FormをやめてWPFのプログラムを書き始めている。
WPFは正直必要となる知識レベルが高く難しいというイメージで手が付けにくかった。今もそうだが。 何が難しいかといえば、MVVMの考え方をどこまで徹底するかに尽きるのではないかと思う。
MVVMについてまだまだ分からないことも多いが、今の認識をまとめる。
- MVVMは、ModelとViewの間にViewModelという層を挟み、ModelとViewの依存関係を疎にするモデル
- WPFの場合、ViewとViewModelの間でデータを複雑なコード不要でやりとりするBindingという機構があるので、うまく記述すればViewとViewModelの間も疎にできる
- そうすると、Model, ViewModelは変えずにViewだけ差し替えることも可能となる。
- Windows Formの場合は、Viewの一部であるコードビハインドに処理もがっつり書いてしまうため、Viewだけ差し替えるということはできず結構な書き換えが必要となる。
- Windows Formもそうだが、何も考えずに書くとどうしてもViewに処理を書いて肥大化しがち。そこで、ViewはViewModelの処理の呼び出しのみにする方が良いとされ、コードビハインドには極力コードを書かない方が良いとされる。
- 逆にViewModel側もViewに依存してしまうと別のViewに差し替えることができなくなるので、Viewに関するコードは書かない方が良いとされる。
- MessageBoxのようなダイアログや、別のWindowを直接起動する処理すら良くないとされる。
- じゃあどうするんだというと、Blendと言う部品や直接呼び出さずにInterface経由とすることで直接依存を避ける手段を取るべきとされる。これが初心者には超絶難解だと思う。
- MessageBoxのようなダイアログや、別のWindowを直接起動する処理すら良くないとされる。
- 逆に、上記のようなViewを差し替える事態がそもそも考えなくて良いのであれば、今まで通りコードビハインドにコードを書いても問題はない。それでもWindows Formより洗練された部品が使えるのでメリットはある。
さしあたって、すぐに直面するのはViewModelからMessageBoxのような利用者への通知処理をどう行うか。行いたいのはMessageBoxを出すことではなく利用者にメッセージを伝えることと抽象化し、ShowMessageのようなメソッドをもつInterfaceを定義してこれを利用する形とする方法をとっている。以下のページが参考になった。
このパターンは、コンストラクタに引き渡す処理に気をつければViewModelからのViewの呼び出しが簡単にできるため、よく使っています。
ClosedXMLによるExcel編集がVirusBusterに強制終了させられる
ClosedXMLで、ファイルサーバの雛形ファイルをもとに編集して出力するということをよく行います。 この際、ClosedXMLの保存先がファイルサーバだと、当社のVirus Buster Business SecurityにUnauthorized Encryptionと言われて 強制終了させられることがあります。Excelファイルは作成できず、exeも消されてしまうので再インストールとなります。
テストした結果、ClosedXMLでの保存先がローカルであれば問題ないことが確認できたので、ClosedXMLではローカルに一時フォルダを作成してそこに保存し、System.IO.File.Copyでコピーすることで解消しました。
うっかりmasterリポジトリでcommit
git管理していて、ローカルリポジトリでブランチ切り忘れてmasterブランチで作業、ローカルcommitまでして気付いた。 このままpushしても、当然リモートのmasterブランチにダイレクトにpushはできず、弾かれる。 PRも出せない、と思っていたが。
pushでは、ローカルとリモートの両方のブランチを指定できる。
git push origin <local_branch>:<remote_branch>
local_branchにmaster, remote_branchに本来切ろうと思っていたブランチ名を指定し、そのブランチでPRを出す。
ClosedXMLでWindows7だけレイアウトが崩れる
アホな話です。
ClosedXMLで、一部コードでうっかり以下のようなコード書いてました。
using (IXLWorkbook targetBook = new XLWorkbook(filePath)) { using (IXLWorksheet targetSheet = targetBook.Worksheet(1)) { } targetBook.Save(); }
usingの入れ子です。 普通、入れ子になるような階層があれば一番上位のクラスが下位のDispose呼んでくれるっと思いますよね〜。 でも、このときはusing句覚えたてで、とにかく使いたかったんです、using入れ子かっけ〜って思ってたんです...
症状としては、Windows 7の場合のみシートのフォーマットが崩れます。なぜかWindows 10は大丈夫。OSによって症状が違う理由は不明。 sourceを見ると、XLWorksheetのDisposeでrange情報をクリアしてるっぽいから、そこで情報が消えて、そのまま保存すればそりゃレイアウトは崩れるな〜と。
追記) どうも、最新の0.93.1で発生し、0.92.0では発生しなかったようだ。ライブラリのバージョンアップした途端に大量に問い合わせが...