Visual StudioでXamarin.Androidのリソースを追加削除するときはaapt.exeを実行しないようにしておくと速い

Visual StudioでXamarin.Androidのリソース、例えば画像をプロジェクトへ追加したり削除するとき、やけに、ものすごく時間がかかる事があります。
というか、ほぼハングしているようにしか見えません。

このときタスクマネージャの詳細を見ると「aapt.exe」がCPUを食いまくっています。

これをKillすれば少し速くなるのですが、画像の数だけ順にaapt.exeが起動されるようで50個とか追加しようとしているときは発狂します。

というわけで、プロジェクトを開いた後で冒頭の画像のようにAndroidのbuild-toolsのフォルダ名を変更し、この中にあるaapt.exeが実行されないようにするといいです。

画像の追加が終わったら元に戻せばOKです。

なおaapt.exeはbuild-toolsの中のバージョンごとのフォルダに存在するですが、実行中の１バージョンのフォルダ名だけ変更しても、次にまた別のバージョンのaapt.exeが実行されるようです。
どうせ変更するなら最上位を、ということです。

気が向いたらお試しください。

Xamarinでアプリ開発して良かったこと悪かったこと

業務でXamarin.Formsを使い、iOSとAndroid向けに同じアプリを作るということをしました。

以前はiOSとAndroidの担当が数名ずつで2チームだったのですが、仕様や実装に関する知識が分断しやすく、結果的に実装の都合を互いに押しつけあうなど問題があったのでその解決をXamarinに求めたのです。（その後他にも色々対策はしましたが）

「どうだった」と聞かれがちなので、良かった点と悪かった点を書いておこうと思います。随時追記もするつもりです。

■どんな感じだったか

• Xamarin.Formsをベースに、たとえばPageの切り替えアニメをiOSとAndroidで同様にするなど、独自のUIフレームワークを作りました。
• UIが絡まなくてNative機能を使いまくるところはPCL＋BindingLibraryな共通ライブラリを作り、UIからはあまりNativeを意識せず実装できるようにしました。
• UI側でNative機能を使いたいときはDependencyServiceやRendererを使いました。
• NuGetサーバやCI環境など色々必要になりました。

■良かった点

• 仕様に関する知識が分断しづらくなりました。
  ある画面がiOSだとこういう仕様でAndroidだと違う仕様というのが激減しました。もちろんXamarin.Formsの中で実装が異なるので挙動が違うというのは良くありましたがたいていはRendererなどで回避・調整可能でした。
• UIフレームワークやライブラリを使う「だけ」のNative分からない人も開発に参加できるようになりました。人の融通がしやすくなるという意味で良かったです。
• GitやiOS、Macなど今まで「食わず嫌い」だったものが少し浸透しました。
  SubVersionで止まっている人にGitを使わせたり、AndroidやWindowsしか触ったことのない人に多少なりともiOSやMacを触らせることができました。
  GitはMergeコミットだらけになったり色々アレですが、そこは具体的な悪影響が出るまで我慢です。

■悪かった点

• 開発環境を人数分揃えるのにかなりコストがかかりました（詳しくはココ）。
  XcodeやAndroid Studioだけなら無料なのに。
• 実装に関する知識は分断したままでした。
  Nativeを分かる人が独自のUIフレームワークやライブラリを作る担当になり、画面を作る人は別となることが多かったです。結果iOS、Android、C#それぞれで担当部分しか触らないという人はそれなりに残りました。うまく分担できたという気もしますが、もう少し「誰でも触れる」状態が作れればと思います。ただMacやMSDN付きでないとやりづらくコストもより増えてしまうので敬遠されました。
• 問題の原因を探る階層が増えました。
  例えばUI部品を思うように配置できなかったとき、Nativeならそれらの範囲を調べれば良いのですが、Xamarin.Formsの場合はそちらの挙動も見る必要があったりして手間を感じました。
• なにかとiOSはズルいです。
  普通に作るとどうしてもiOSアプリの方が安定しています。処理中にホームボタンを押したりしたときもiOSはただサスペンドしている感じですが、Androidは動き続けてヌルポで死ぬとか。画像を読み込む速度もiOSの方が早いです。
  さらには独自ライブラリのほうで依存関係が増えたとしても、iOSの方は簡単に取り込めるのに、Androidはアプリ側でイチイチBinding Libraryを作成してjarを取り込まないとClassNotFoundExceptionになったり。Androidはやりづらさがありました。
• Mac Agentがアテにならない
  Windows(Visual Studio)からMacへ接続してリモートビルドをかけるための仕組みですが、Visual Studioからのデバッグ実行などは頻繁に切れて失敗します。コマンド（msbuild）からなら割と安定しているのですが。
• Xamarinの更新がドキドキ
  XcodeやAndroid Studioであれば更新しても問題にあうことはさほど頻繁ではなかったように思いますが、Xamarinは毎回心臓に悪いです。特に今回のXamarin.Android 7.3のようにGCやMonoが変わって実行時に原因不明でクラッシュするとかやめてほしいです。
• 依存関係が難しい
  例えば今のプロジェクトはFormsの2.3.3.180を使っているのですが、2.3.4に上げるのは難しいかもしれません。
  というのもこれと合わせてXamarin.Android.Support.v4の23.3を使っていて、AndroidのBinding Libraryのほうも同じバージョンで、と揃えた状態で、これまたバージョンを上げるとどうなるか分からないというのがあります。ただモバイル開発は基本的にバージョン上げていかないとシンドイので、近いうちに、せーの、でやることになるのだと思います。

■その他

• 計測していないのですが、コードを共通化できた部分はさほどないと思います。
  前述の通りBindingLibraryやRenderer、DependencyServiceなども結構書きましたし。

というわけで、Xamarinは（目的と手段とスキルと制限などとコストが折り合いつけば、わりと）いいぞ。

Visual Studio for MacのmsbuildでビルドするとDEBUG定数がなくなる

ちょっと不思議な現象です。

あるXamarin.iOS（＋PCL）プロジェクトを、Visual Studio for MacのIDEでビルドするとDEBUG定数があるのに、同じMac上のmsbuildでビルドするとDEBUG定数がなくなるのです。

ソース内で
#if DEBUG
#pragma warning DEBUG is defined.
#else
#pragma warning DEBUG is not defined.
#endifと書き、またmsbuildに/v:diagを付けてログをみたところ、やはり"is not defined"と出力されましたし、DefineConstantsにTRACEしか付いていないみたいでした。

Ad-Hoc|iPhone構成にDEBUGを付けたのが悪かったのだろうか。

もうしばらく調べてみます。

MacでもWindowsと同じようにNuGetパッケージを作成しPushできる

以前、Xamarinを使った開発でNuGetのパッケージを作るならWindows側で行う方がよさそうというエントリを書きました。

その後Macの環境もVisual Studio for Macになり、何となく思いつきで「sudo nuget update -self」してみました。

すると2.xだったnugetが4.xになり、Windows(nugetは3.x)でpackしたNuGetパッケージと同じようなものが生成できるようになりました。
（ZIP展開して、中身がIDっぽい値以外ファイル構成や中身が同じでした。2.xの時はだいぶ違いました）

pushも問題なくできたので、そのまま使っています。

もともとこのMacはJenkinsのいちスレーブで、nuget pack/pushするためにWindowsスレーブも使っていたのですが、Macだけで済むようになりました。

めでたしめでたし。