kkamegawa's weblog

Visual Studio,TFS,ALM,VSTS,DevOps関係のことについていろいろと書いていきます。Google Analyticsで解析を行っています

.NET Conf関西 2018開催しました

台風25号の襲来が危ぶまれる中、.NET Conf関西2018無事終了しました。ご来場の皆様、お手伝いしてくれた皆様、スピーカーの皆様、場所の提供および、セッション実施してくれた日本マイクロソフト様ありがとうございました。

前日のお昼くらいまで開催するか悩んでて、だいぶそれそう&遅そうということで開催決定しましたが、ほんと気が気じゃなかった。懇親会はお店の都合もあるので、早々にキャンセルを確定したのですが、会場はね…うーんという感じでしたが、できてよかったです。.NET Confといいつつ、.NET色がほとんどないのはいいんだか悪いんだか(汗)。

connpass.com

私はLTということで、VSTSあらため、Azure DevOpsの違いについてちょっとお話させてもらいました。たぶん12月から1月か2月でAzure DevOpsのイベントやろうかなぁと思っていますので、決まったらぜひ参加してください。

来週は東京で.NET Confがあります。こちらもぜひどうぞ。

csugjp.connpass.com

Azure App Service障害発生時のダンプ解析とシンボル管理

blog.shibayan.jp

App Serviceだけではないけど、障害が発生してダンプの解析をしなければならない場合がたまにあります。

ダンプ解析するにはそのモジュールのシンボル(pdb)ファイルを取っておかないといけないのですが、障害解析ができない場合に限って、シンボルをちゃんと管理しているという話をとんと聞きません。特にCやC++のネイティブモジュールであればシンボルがあると、ないとではかなり大変さが違います。

VSTS(Visual Studio Team Services)のPackage管理機能のライセンス(Enterprise Subscriptionを持っている人には入っています)があれば、VSTSのシンボルサーバー機能が使えます。どうやって使うのか紹介します。

シンボル設定初期値
シンボル設定初期値

オプションからシンボルを選択して、右上の赤枠アイコンをクリックします。

VSTS選択
VSTS選択

シンボルサーバーとしてライセンスがあるVSTSを選択します。

VSTSシンボルサーバー追加
VSTSシンボルサーバー追加

このように追加されます。

ビルド定義にシンボル発行を追加
ビルド定義にシンボル発行を追加

Publish Symbol PathタスクのPublish Symbolsにチェックすると、pdbファイルを自動的にVSTS内に保存します。保存先はVSTS内か、ファイル共有が選べます。

前書いたように、ビルド結果はRetain Policyに従って自動削除されます。シンボルも同じ制御を受けるので、ビルド結果が削除されると自動的にシンボルも削除されます。うっかりプロダクションにリリースしたファイルを削除しないように気を付けてください。

Azure App Serviceのプランによってはダンプが採取できます。

ダンプ収集
ダンプ収集

ダウンロードしたミニダンプをダウンロードして、Visual StudioやWinDbgで開くと、VSTSもシンボルサーバーとして扱われるので、自動的にシンボルが検索されます。

ダンプを開く
ダンプを開く

今までファイル共有などでシンボル管理はタイへだったと思いますが、VSTSのシンボルサーバー機能はダンプ解析する時大変便利なので、ぜひ使ってください。

書籍レビュー:PowerShell実践ガイドブック

ちょうど読みたかったPowerShell実践ガイドブックのレビュワーをマイナビ出版さんが募集されていたので、応募したところ、見事当選しました。シェルに引っ掛けて貝殻が表紙になっているので、貝殻本だそうです。

貝殻本(と呼んで欲しいと書かれてた)とインサイドWindowsが同時に来た!

私のバックグラウンド

Windows PowerShellは1.0のころから注目していて、公私ともにぼちぼち使っていました。バッチファイルがどうも嫌だったんですね。単純に並べるだけならまだしも、制御文を考え出すとちょっとつかいたくないな、と。

ほんとうはC#がよかったけど、当時はC#スクリプティングもなかったし、似たような構文でかけるかも、ということでPowerShellという名前になったころからぼちぼち使い始めました。

第一章でPowerShellとどう付き合っていくか、という分類でいえば、「.NETのクラスライブラリを簡単に呼び出したい(&クラスライブラリの挙動確認をしたい)」あたりが近いでしょうか。

Linuxでbashでそこそこのシェルスクリプト書いてプロダクションとして使ったことがありますが、どうしてもなじめなかった。まさに書かれているように、=とかifの後などに空白入れちゃいけないなどの、ルール(?)になじめなかった。とはいえ、これはほかの人がWindows(PowerShell)に移ってきても同じだと思いますので、どっこいどっこいでしょう。

よかったところ

特に1,2章が圧巻でした。PowerShell Coreとは何なのか、また何故Windows PowerShellをメンテナンスフェーズにして、新しいPowerShell Coreを作ることにしたのかという事情やBash、コマンドプロンプトとの違い、検索TIPSやデバッグを丁寧に書かれていて、ここだけで本書の実に半分近くを占めています。

PowerShellなんて昔やったよ!という方が今のPowerShellを勉強しなおすために読み直すのもいいと思います。実際、私も忘れていたところや、あいまいな知識のままだったところ、PowerShell 4.0以降で追加された機能をもう一度参照できてとても勉強になりました。やっぱり本をまとめて読むのはいいですね。

わかっているけど、構文忘れたときはWebでの検索もいいのですが、全くゼロベースの知識から始めるときはこうやってちゃんと挙動や仕様を逐一まとめてくれた本はとても助かります。

また、検索のノウハウやデバッグの基本なども書かれているのは非常にいいと思いました。こういうの教えてもらわないといつまでも無駄な時間を使いますしね。特に「メッセージを英語で」検索するの重要です。本書でも書かれていますが、英語圏には圧倒的なリソースがあるので、解決に至るまでの時間も短くなります。

読み方

順序だてて書かれているので、読みやすくはあるのですが、それでもボリュームがある本なので、すでにWindows PowerShellを使いこなしている方であれば、1章を軽く見るだけで、2章,4章を読めばいいかなと思います。

これからPowerShellを始めるんだけど、という方はまず1章,2章でいいでしょう。少しずつ練習して、少し疑問が出てきたり、エラーをもっとちゃんと処理したい、よい書き方を学びたいという方は3章飛ばして、4章読んでから自分のスクリプトを改造するのもいいんではないでしょうか。

もっと書いてほしいところ

PowerShellといえばやはりMSによるスクリプティングのシステム管理を想定しているので、今はPowerShell CoreベースのDSC実装がないことによる運用がなかったのは(著者も書かれていましたが)もっと読みたいところでした。今後DSCの実装が出てきたときに改めて第二版や分冊といった形で出してもらえるといいかなと思います。

とはいえ、ないものをねだっても仕方ないので、今ならAnsibleなんかもあっても面白いかもしれないですね(ベータはあるのかな…)。

個人的にPowerShellに期待しているところといえば、REST使った外部WebAPIをたたくことによる自動化と、WinRM(これはWindows PowerShellですが)による複数マシンの制御なので、そういった本が別にあってもいいかなと思います。

MSが作っているのに、PowerShell Coreの活用はAWSのほうが先行しているという何とも皮肉な図ですが、AzureはWindows PowerShellようにリリースしているモジュールをそのうち合わせてくるのでしょうか。

ちょっと気になったところ

長いスクリプトは動かしてないので、その部分の正誤はわからないですが、少し気づいたところなど。次の版で直してもらえたらいいかなという程度で、本書の良さを損なっているわけではありません。

82ページ

コマンドプロンプト(MSDOS)
コマンドプロンプトはMSDOSではないですね。その後ではちゃんと「DOSではない」と書かれているので、あえてそう書かれているのかもしれませんが。あと、Windows PowerShellはメンテナンスフェーズと書かれているのに、エクスプローラにあるというのはちょっと説得力が弱いかなぁと思いました。

コマンドプロンプトのおそらく内蔵コマンドに関しては強化されることはないかもしれませんが、CUIを動かすシェルとしての強化はWSLと連携して続いていますしね。

132と136ページ

132ではSYNTAX(たぶんPowerShellの表示結果から)だが、136ページではシンタックスとカタカナ読みになっているのはわざと?

190ページ

void型を使うと、処理結果を戻り値のないことを表現できます
→少しへんな日本語

191ページ

「配列の節で説明しているので」
→ここに限らないのですが、後半では章レベルになるものの、参照が書かれているのですが、前に戻ってみるときに探さないといけないので、ちゃんと節番号で書いてもらえると助かります。

218ページ

リスト2-244に変数だけあって結果がない

222ページ、232ページ

「あえて一節を設けて」
→2.7なので、書くなら「一項」?

245ページのリスト2-292

PowerShellの実行結果ではなく、dotnet coreになってる。たぶんリスト2-291が間違い(実行できないソースのまま掲載)して、ずれてる。

268ページ

モジュールを任意の方法で読み込んだり、自動的な〜
→だりが一つしかない

322ページ

リスト3-69の前のところと文のつなぎがよくわからない

3.4の認証のところ

Windows PowerShellには証明書を使った認証もあるので、その言及があってもよかったかなぁ。

495ページ

初期値の説明がですます調(ほかはである調)

495ページその2

メソッドの説明の「記述できます、」の句点誤り

547ページ

5.1.6の内容は例外の再スローを避ける話なのに、タイトルがちょっと違う気がします。最初タイトルだけ見て内容とあわなくて?となったけど、ソース見て理解できました。

567ページ

Get-process のtypo

PowerShell実践ガイドブック クロスプラットフォーム対応の次世代シェルを徹底解説

PowerShell実践ガイドブック クロスプラットフォーム対応の次世代シェルを徹底解説

PowerShell実践ガイドブック ~クロスプラットフォーム対応の次世代シェルを徹底解説~

PowerShell実践ガイドブック ~クロスプラットフォーム対応の次世代シェルを徹底解説~

Visual Studio 2017でMStestが実行できない場合の対処(System.Runtime, Version=4.1.1.0または依存関係の1つが読み込めないエラー)

二日ほどドはまりしました。Visual Studio 2017(15.7.1)でフル .NETでプログラムを作っていたのですが、ある日からMSTestを使ったUnit testの実行時こんなエラーが出るようになりました。

実行プログラム 'executor://mstestadapter/v2' の呼び出し中に例外が発生しました: 
ファイルまたはアセンブリ 'System.Runtime, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'、
またはその依存関係の 1 つが読み込めませんでした。指定されたファイルが見つかりません。

ターゲットフレームワークを 4.5から4.7.2までいろいろ変えても駄目。どうもNuGetからライブラリーを追加してからのようで、プロジェクトテンプレートから作ったような足し算するような素のプロジェクトでは起きません。

csprojの 方法: 自動バインディング リダイレクトを有効/無効にする | Microsoft Docsを無効にするという方法も駄目。探しまくったら対処方法がありました。

github.com

  • MSTestのプロジェクトテンプレートに追加されているMicrosoft.VisualStudio.TestPlatform.TestFrameworkと同Extensionsを削除する
  • 代わりに参照からC:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll" を追加する

「単体テストを作る」から作ったMSTestの参照状態。

f:id:kkamegawa:20180516142712p:plain

この状態だと実行できないですが、Microsoft.VisualStudio.TestPlatform.TestFrameworkで始まるアセンブリを二つ消して、前述のC:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dllを追加します。

こんな感じになっていれば実行できるはずです。少なくとも私は大丈夫でした。

f:id:kkamegawa:20180516142521p:plain