trapemiyaの日記

hatenablogが新しくなったんで新規一転また2019年1月からちょこちょこ書いてます。C#中心のプログラミングに関するお話です。

MvvmCrossでバインドできない

さて、いい加減やばいわけで、何が? というと、Androidアプリ開発なわけで。
ちゃんとやるにはやっぱりMVVMだよねってことで、流行に逆らわずMvvmCrossを導入。
ネットを漁ると、今は簡単に導入できる模様。ありがとう、NuGet!

というわけで、楽勝で動作するはず。と、思いきや、なぜかデモの"Hello MvvmCross"が表示されない。
エラーも何もでないんだよね。雰囲気としてはバインド機構が働いていない感じ。エミュレーターのXamarin Android Playerがおかしいかと思い、Windowsストアアプリでも試してみたけど、全く同じ状況。
何度見なおしても手順にミスはない。
さすがに、何で? 困りました。そう、今日一日潰しました・・・

で、結局のところ、Androidのプロジェクトにある、MainActivity.csの、Activityアトリビュートに指定してある、MainLauncher = trueに原因があった。
こいつをfalseにしたら、あっさり動いた。
これも確信があったわけじゃなく、手順に間違いがなければ、なんかMvvmCrossの邪魔をしてるものがないか?っていう発想で想像して試したら、たまたま当たったっていう感じでした。
で、このActivityのリファレンスは、

Android.App.ActivityAttribute Members
http://androidapi.xamarin.com/?link=T%3aAndroid.App.ActivityAttribute%2f*

で、原因はよくわかりません(^^; 詳しい方、コメントしていただけるとありがたいです。

ちなみに環境は、

Microsoft Visual Studio Ultimate 2013 Version 12.0.31101.00 Update 4
・Xamarin.Android 4.20.0.28 Visual Studio plugin to enable development for Xamarin.Android.

です。

#さぁ、ようやくスタートラインに立てました。

XamarinInstaller.exeを実行しても数秒後に勝手に終了し、インストールできない

今年度の目標としてXamarinに取り組もうと思っています。というわけで、約2ヵ月前にXamarinInstaller.exeをダウンロードしたのですが、それから急に忙しくなり、そのまま放置しておりました。ようやく落ち着いてXamarinをインストールしようと思ってXamarinInstaller.exeを実行したのですが、なぜか数秒後に勝手に終了し、インストールできません。
ネットで調べると.NET Framework 4.5が必要という情報があったのですが、インストールしようとしているPCはWindows 8.1 Pro、かつVisual Studio 2013が入っているので、ここは問題なくクリアしていました。
その後、インストールログがあることを知り、そのログを見ると重要なヒントがありました。ちなみにログは以下にあります。

%userprofile%\AppData\Local\Temp

以下、ログから抜粋

[0640:09F8][2014-11-28T09:24:27]e000: Error 0x800b0101: Failed authenticode verification of payload: C:\ProgramData\Package Cache\.unverified\WindowsInstaller
[0640:09F8][2014-11-28T09:24:27]e000: Error 0x800b0101: Failed to verify signature of payload: WindowsInstaller

これはWindowsInstaller.exeのデジタル署名が怪しいと睨み、早速見てみると・・・

切れてました・・・。しかも先週の金曜日に・・・

というわけで、パソコンの日時を一時的に11月21日にタイムスリップさせ、無事にインストールできましたとさ。

コードレシピにアップしました。「2つのListView間で項目をDrag & Dropによって移動(ビヘイビアのサンプルとしても)」

2つのListView間で項目をDrag & Dropによって移動(ビヘイビアのサンプルとしても)
http://code.msdn.microsoft.com/ListViewDrag-Drop-f1ef1456

SQL ServerのNプレフィックス

今から約10年ほど前に、SQL ServerのNプレフィックスについて旧MSDNフォーラムに投稿しましたが、今はアクセスできなくなっていますので、以下に載せておきます。当時の原文のままです。なお、当時の私のハンドル名はMIYAでした。
ーーーーーーーーーーーーーーーーーーーーー
MIYA

参加日: 2003-5-6
投稿数: 1641

Re: SqlServerでの日本語定数の使用
投稿日時: 2004-11-14 午後 6:07
こんにちは。MIYAです。

(以下の文について、私も100%の自信があるわけではありません。いろいろな記事、および経験から総合的に私は以下のように理解しています。誤りがあればご指摘ください。(^^;)

日本で普通にSQLserverをインストールした場合、SQLserverにおける既定のコードページはjapanese(コードページ932、以下CP932)です。これは基本的にS-JISです。
SQLserverはこのコードページを切り替えることにより、多言語に対応しています。しかし、複数の言語を扱う場合はどうでしょうか?これははっきり言って不可能です。
そこで、複数言語を統一的に扱えるunicodeの対応が、SQLserver7.0で初めて実現されました。これでSQLserverは、既定のコードページとunicodeの両方を扱えるようになりました。

そこで、じゃぁ、どっちを使うのという問題が発生します。charは非unicode、ncharはunicodeで保存するのはご存知だと思います。
SQLserverへ文字がやってきた時、それは単にビットストリームですから、それをエンコードして文字として認識しなければなりません(binary型への保存だとそのまま入ります)。
これは、ブラウザでビットストリームを文字にエンコードして表示するのに似ています。
さて、SQLserverエンコードする時に、SQLserverは規定のCP932でエンコードしようとします。大抵のやってくる文字はS-JISなので問題なくエンコードされます。charの列だとこのまま保存されますし、ncharの列だとここからunicodeに変換されて保存されます。

やってきた文字がS-JISでは無い場合はどうでしょうか?例えば「まるいん(丸付きの印)」はunicodeです。この文字をSQLserverは既定のCP932としてエンコードしようとします。しかし、もともとS-JISに無かった文字なのでunicodeを使ってSQL文を作ったぐらいですから、エンコードに失敗します。失敗すると「?」になります。charだとこの「?」が保存され、ncharだとunicodeに変換され、unicodeの「?」が保存されます。

では、「まるいん(丸付きの印)」を保存する方法は無いのでしょうか?あります。Nプレフィックスを使えば良いのです。
この場合、SQLserverは既定のコードページではなく、unicodeエンコードします。
しかし、unicodeですから当然ncharにしか保存されず、charには「?」と保存されてしまいます。
Nプレフィックスを「まるいん(丸付きの印)」のようなunicodeではない普通のS-JISに使ったらどうなるでしょうか?この場合もSQLserverはNプレフィックスが付いているので、unicodeとしてエンコードしようとします。しかしS-JISのため、既定のコードページを利用してunicodeとしてエンコードすることになります。

以上は保存時でしたが、select時も同様です。「まるいん(丸付きの印)」のようなunicodeの文字をNプレフィックス無しでSQLserverに送った場合、charだろうがncharだろうが「?」で保存されます。これをselectでNプレフィックス無しで「まるいん(丸付きの印)」で検索した場合、「?」に変換されて検索されることになり、先に保存した「?」にヒットして、検索結果として「?」が返されます。

以上よりncharなどのunicode型の列を使用する場合、どのみちビットストリームを最終的にunicodeに変換しなければならないため、unicodeの文字だけではなく、Nプレフィックスを常に付けても良いと思います。逆に付けないと一度CP932にエンコードされてからふたたびunicodeに変換されるため、非効率だと思います。
しかし、charなどの非unicode型を列に使用する場合は、ビットストリームを一度既定のコードページ経由でunicodeに変換し、それをふたたびCP932に基づいて変換する必要があり無駄が発生します。といいますか、charなどの非unicode型にはunicodeで保存できませんので、Nプレフィックスを使うこと自体が無意味です。

全く「まるいん(丸付きの印)」のようなunicode文字を使わず、CP932のみで良い場合はncharとかではなく、charなどの非unicode型を使う方が効率的です。S-JISからunicodeへの変換も発生しませんし、記憶容量も小さくなります。

unicodeというと多言語対応ということが前面に出ますが、日本語に限った場合でもunicodeの文字まで必要なのかどうかということで、charかncharの選択がわかれます。

簡単にまとめると、ncharなどのunicode型に保存する場合はNプレフィックスを常に付ける、charなどの非unicode型に保存する場合には付けない(むしろ付けると効率が悪い)。というように私は理解しておりますが、何分詳細まできっちりとわかっているわけではないので、ncharなどのunicode型に保存する場合でも、S-JISの場合にはNプレフィックスを付けないほうが効率が良いという事実があるのかもしれません。

>データアダプター構成ウィザードでデータアダプターを自動生成した場合、Nプレフィックスを使用していないようですが。

これは既定のコードページが基本になっているからだと思います。先に述べたように、charなどだと全く無意味になるどころか、かえって非効率になるからではないでしょうか?textBoxに「まるいん(丸付きの印)」などの文字を打ち込んでSQLserverに保存する可能性がある場合は、Nプレフィックスを付けて下さい。でないと「?」で保存されてしまいます。
コードページという概念をやめて全てunicodeで統一すればNプレフィックスなど気にする必要は無くなるのですが、世の中にはまだまだunicodeを扱えないものが多く存在するので、そうもいかないのでしょうね。

新年になりました。とりあえず今年はストアアプリの開発に力を入れる予定

今年もよろしくお願いいたします。
さて、私の中で何となく中途半端で消化しきれていないストアアプリの開発ですが、今年はもうちょっと真面目にやろうと思っています。
仕事でストアアプリの開発をやっていないとどうもしっかり身に付かない人なので、何とか無理やり仕事に絡めたいと考えているところです。

昨年、芝浦でストアアプリの開発の研修を受けましたが、これがなかなか良くてすっかり油断しておりました。(泣)
Windows 8.1になって、テンプレートの内容が変わってしまい、この研修の内容がそのまま当てはまらなくなってしまいました。
ストアアプリの開発は正に発展段階なので仕方ないことだと思いますが、これも私が少し逃げていた原因の一つです。

ストアアプリの開発を始めるには、以下のページが役に立ちそうです。しかも、ちゃんとWindows 8.1に対応しています。

パート 1: "Hello, world" アプリを作成する (C#/VBXAML を使った Windows ストア アプリ)
http://msdn.microsoft.com/ja-JP/library/windows/apps/hh986965.aspx

もう一つ、MVAMicrosoft Virtual Academy )があります。こちらはビデオもあってわかりやくなっており、お勧めだと思います。
これらのビデオの背景にWindows 8.1の文字があるので、こちらもWindows 8.1対応の内容になっていそうですね。

いまさら聞けない Windows アプリ開発入門 XAML/C#
http://www.microsoftvirtualacademy.com/training-courses/windows-app-xamlcs#?mtag=MVP32149

ClickOnceの配置で「厳密な名前の署名はこのアセンブリ stdole.dll に対して無効です。」のエラーでアプリ起動せず。

Visual Studio 2010で開発し、ClickOnceで配置しているWPFアプリケーションがあり、いつものようにこのアプリケーションを修正し、ClickOnceで発行を行った。
発行はうまく行ったのだが、クライアントで起動しようとすると、「厳密な名前の署名はこのアセンブリ stdole.dll に対して無効です。」というエラーが出て起動しなくなった。
前回から今回のClickOnceの間に何が変わったのだろう?と思い出してみると、そう、Visual Studio 2013をインストールしたことだった。ひょっとして、これが原因?
とりあえず、Visual Studio 2013のインストール先にある、stdole.dllを確認してみる。そのプロパティを表示すると、製品バージョンが7.00.9466。サイズが16kb。ちなみにVisual Studioの参照設定でAssembliesのExtensionsの一覧にあるstdoleを確認すると、このdllのバージョンは7.0.3300.0のようである。

Visual Studio 2013のstdole.dllがあるフォルダ)
C:\Program Files (x86)\Microsoft Visual Studio 12.0\Visual Studio Tools for Office\PIA\Common

次にVisual Studio 2010のインストール先にある、stdole.dllを確認しみる。この製品バージョンは、Visual Studio 2013と同じく7.00.9466、および7.0.3300.0。しかし、サイズが22kbと大きい。

Visual Studio 2010のstdole.dllがあるフォルダ)
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Visual Studio Tools for Office\PIA\Common

ひょっとして、Visual Studio 2013のインストールによって、署名なしのstdole.dllがGACに登録されてしまった? そう考えて以下のコマンドを発行したところ、無事にClickOnceでの配置に成功した。
以下、Visual Studioコマンドプロンプトを管理者権限で起動し、実行した記録である。

C:\Windows\system32>gacutil -if "C:\Program Files (x86)\Microsoft Visual Studio
10.0\Visual Studio Tools for Office\PIA\Common\stdole.dll"

実際に実行している画面は以下の通り。

#本当は、GACの登録にかかわらず、Visual Studio 2010で発行する際に、どのstdole.dllを含むか指定できれば良いと思うんですが、もし誰か知ってたら教えて下さい。しかも、この対応で良かったんだろうか?と思うのだが・・・。いずれにしてもVisual Studio 2013のインストールは注意が必要かもしれない。(犯人がVisual Studio 2013と決まったわけではないのだが・・・。しかも、Visual Studio 2012のstdole.dllを確認すると16kbしかないんだよね。このdllはVisual Studio 2012のインストール時にGACに登録されなかったってことかな?)