ASP.NET Coreで"500.0 In-Process Handler Load Failure"のエラーが出た際

Windows Server上のIISでホストしたASP.NET Coreアプリが 500.0 In-Process Handler Load Failure のエラーで停止した際の対処法です。

以下の条件下でPublishした際に発生しました。

項目
dotnet version 2.2.402
配置モード 自己完結
ターゲットランタイム win-x64

サーバーのイベントログを見たら以下内容のエラーが記録されていました。

ソース 内容
IIS AspNetCore Module V2 Could not find inprocess request handler. Captured output from invoking hostfxr:
IIS AspNetCore Module V2 Failed to start application '/LM/W3SVC/16/ROOT', ErrorCode '0x800700c1'.

対応方法

IISマネージャのアプリケーションプールを開き、該当ASP.NET Coreアプリのアプリケーションプールを選択します。

右クリックから、詳細設定を開き、32ビットアプリケーションの有効化Falseにします。

参考

git 入門 〜Tips編〜

git 入門の4章、Tips編に入りたいと思います。

基本的な使い方意外で困ったときにざっと見る用のTips集です。 少し上級な内容等もあるかもですが、おそらくコピペで実行出来るかと思います。

前章は以下になります。

neko3cs.hatenablog.com

Tips

ぱっと思い浮かんだシチュエーションが以下なので今回は以下のみ紹介します。 他にもあるかと思いますが、最初のうちは使わないコマンドだと思います。(多分...)

  • 現在の変更箇所を確認したい!
  • リモートブランチに変更があるか見たい!
  • リモートブランチの変更を取得したい!
  • ブランチの一覧がみたい!
  • ブランチを削除したい!
  • ファイルの変更を取り消したい!
  • 間違えてステージングしてしまった!
  • 直前のコミットをやっぱやめたい!
  • 削除されたリモートブランチの情報を消したい!
  • 変更履歴を引き継いだままファイル名変更やフォルダ移動したい!
  • 変更内容を一時保存したい!

現在の変更箇所を確認したい!

今どこを変更したのか確認したくなる時があるかもしれません。

そんな時は以下のコマンドで確認出来ます。

$ git diff

リモートブランチに変更があるか見たい!

チーム開発したり、普段と違うPCを使ったりする場合、リモートリポジトリには変更が生じているかもしれません。

その変更状態があるかどうかは以下のコマンドで確認出来ます。

$ git fetch

リモートブランチの変更を取得したい!

チーム開発したり、別のPCで変更した内容があることをgit fetch でわかった際、 その変更をローカルリポジトリのブランチにも反映させたいでしょう。

その際は以下のコマンドで反映できます。

$ git pull

事前に git switch で反映させたいブランチに移動しておく必要があります。

ブランチの一覧がみたい!

いろいろブランチを作りすぎて今どんなブランチがあるか分からなくなるかもしれません。

そんな時は以下のコマンドでブランチの一覧がみれます。

$ git branch

ちなみに、 -a オプションをつけるとリモートリポジトリにあるブランチも確認出来ます。 最新のリモートリポジトリのブランチを確認したい場合は事前に git fetch をしておきましょう。

ブランチを削除したい!

ブランチをマージした後、もう不要になるブランチもあるかもです。

そんな時は以下のコマンドで削除出来ます。

$ git branch -D <削除したいブランチ名>

ちなみに、リモートリポジトリのブランチを削除するには GitHub のサイト上からおこないます。 リポジトリのページにブランチの確認ページを見るボタンがあり、そのページで削除可能ですが、詳細はググってください。

ファイルの変更を取り消したい!

いろいろ変更を加えたが、 よく分からなくなって変更する前の状態に戻したくなることがあるかもしれません。

そんな時は以下のコマンドで変更する前のコミットの状態に戻すことが出来ます。

$ git restore <元に戻したいファイルのパス>

ファイルパスは相対パスを用います。 ファイルパスの代わりに .を指定すると全部取り消せます。

間違えてステージングしてしまった!

脳死git add * してしまったなど、コミット対象にしたくないファイルまでステージングしてしまうこともあるかもしれません。

そんな時は以下のコマンドで git addする前の状態に戻すことが出来ます。

git restore --staged <ステージングしたくないファイルのパス>

直前のコミットをやっぱやめたい!

間違えてステージングしてしまったけどもうコミットしてしまったときや、 そもそも後からこの変更要らなかった思うこともあるかもしれません。

そんな時は以下のコマンドでgit addした直後まで戻すことが出来ます。

git reset --soft HEAD^

削除されたリモートブランチの情報を消したい!

git branch -aでフェッチ済みのリモートリポジトリのブランチの情報も表示できますが、 これはリモートリポジトリで削除済みのブランチが自動で表示されなくなる訳ではありません。

以下のコマンドで消します。

git remote prune origin

変更履歴を引き継いだままファイル名変更やフォルダ移動したい!

git では普通にD&Dでファイルを移動させたりOSの機能でファイル名を変えたりフォルダ移動してしまうと一度削除され、 新しく作成されたファイルとして認識してしまい、過去の履歴が消えてしまいます。

ファイル名の変更やフォルダ移動も履歴として残す場合は以下のコマンドで変更します。

git mv <今のファイルパス> <変更後のファイルパス>

変更内容を一時保存したい!

git switch は変更がない状態でないと実行出来ません。 例えば、チーム作業でよくある緊急の変更対応が必要になったなど、 ブランチをすぐに切り替えたいけど今の状態はコミットしたくないみたいなことがあるかもしれません。

そんな時は以下のコマンドで変更を一時保存出来ます。

$ git stash save

一時保存は幾つでも出来ます。

今幾つ保存したかは以下のコマンドで確認出来ます。

$ git stash list

無事一時保存できると以下のような結果になります。

f:id:neko3cs:20191020033101p:plain

一時保存した内容を取り出したい場合は以下のコマンドで保存内容を取り出せます。

$ git stash pop stash@{<スタッシュ番号>}

スタッシュ番号は git stash list した際に表示されている左側の番号です。

一時保存を pop で取り出すとその一時保存は削除されます。

最後に

本章までが git 入門のすべてになります。

最初に比べて git に対する知識が深まったでしょうか? そうであれば、この記事を書いた甲斐があります。

紹介編でも申した通り、 git は今や変更履歴管理システムのデファクトスタンダードになっています。

本エントリーを読んで git を使えるエンジニア・デザイナーが増えると嬉しいです。

git 入門 〜基本利用編〜

git 入門の3章、基本利用編に入りたいと思います。

本章では git を最低限使うための簡単な手順を説明します。

前章は以下になります。

neko3cs.hatenablog.com

git の基本的な使い方

git をつかって覚えるべき最初の操作は以下の5つだと思います。

  1. リポジトリを作成し、クローンする
  2. 作業内容をコミットする
  3. リモートブランチにコードをプッシュする
  4. ブランチを切って作業する
  5. ブランチをマージする

説明していない単語も出てきましたが、それぞれで説明していきます。

リポジトリを作成し、クローンする

GitHub にアクセスすると以下の様なボタンがあるのでクリックします。

f:id:neko3cs:20191016011930p:plain

リポジトリ名と説明を入力したらおもむろに「Create repository」をクリックしましょう!

f:id:neko3cs:20191016012231p:plain

以下の様な画面が表示されると思います。 「Clone or download」というボタンをクリック後、赤枠のボタンをクリックしてURLをコピーしておきます。

f:id:neko3cs:20191016012413p:plain

リモートリポジトリが出来たらローカル環境にクローンしましょう。

ローカルにクローンすることで自身のPC内にリモートリポジトリと同じ状態のリポジトリを複製出来ます。

以下のコマンドを実行するだけでリモートリポジトリをクローンしてローカルリポジトリを作成できます。

$ git clone <コピーしたURL>

作業内容をコミットする

クローンしたリポジトリのフォルダに移動しましょう。

$ cd ./getting-started-git/

ここでは簡単にファイルを追加してみます。 本来であればここでソースコードを追加、編集したりバックアップしたいファイルをおいたりします。

$ echo "Hello World" > greet.txt

変更がされたかどうかは以下のコマンドで確認が出来ます。

$ git status

変更があれば赤色のファイル名が表示されると思います。

f:id:neko3cs:20191018061343p:plain

変更が生じたのでコミットして作業内容を保存しましょう。

コミットするためには、まずコミットするファイルをステージングする必要があります。

ステージングは変更内容を保存したいものを選ぶ作業です。 ステージングしたものだけが作業内容の保存がされます。

ステージングは以下のコマンドで行います。

$ git add <ステージングしたいファイルのパス>

ファイルパスを指定する代わりに*で変更がされた全てのファイルを指定することも可能です。

ステージング出来たらコミットしましょう。 コミットにはコミットコメントと言うものをつけます。 コミットコメントは何の作業なのかを簡潔に書きます。

$ git commit -m "<コミットコメントの内容>"

上手くコミットが出来たら以下の様な表示がされると思います。

f:id:neko3cs:20191018062133p:plain

リモートブランチにコードをプッシュする

上記でのコミットはまだローカルリポジトリにしか保存されていません。

リモートリポジトリへその変更を反映させないと万が一PCが壊れた場合に変更が消えてしまったり、 そもそもチームでその変更を確認したりマージしたりすることが出来ません。

ですが、プッシュはとても簡単です。

以下のコマンドで現在のコミット数を確認します。

$ git status

コミットが1件あると思います。

f:id:neko3cs:20191018063009p:plain

コミットがあることを確認したら、以下のコマンドでプッシュします。

$ git push origin <pushする先のリモートブランチ名>

ここまで紹介した手順通りに作業していれば、現在のブランチは master だと思います。 なのでローカルの master ブランチのコミットをリモートの master ブランチにも反映します。

以下の結果が表示されたらプッシュ成功です。

f:id:neko3cs:20191018063238p:plain

GitHubのサイトにアクセスし、きちんと変更が反映されているか確認してみましょう!

f:id:neko3cs:20191018063523p:plain

ブランチを切って作業する

さてここで技術検証もかねて greet.txt に変更を加えたくなったとします。

でも、試験的な変更なので現在の master ブランチに変更履歴を残したくないとします。

この様な場合は別のブランチを切って作業しましょう!

早速ですが、以下のコマンドでブランチを切ります。

$ git switch -c <新しいブランチ名>

git switchコマンドはブランチを切り替えるコマンドです。 -cオプションを付け加えることで新しいブランチを作ることが出来ます。

以下の結果が表示されていればブランチの作成は成功です。

f:id:neko3cs:20191020020006p:plain

何かしらの変更を加えてみます。 ここは説明済みなのでさらっと進めます。

f:id:neko3cs:20191020020413p:plain

無事コミット出来ましたね。

ではこの変更をリモートリポジトリに反映します。 ですが、 new-branch ブランチはローカルリポジトリで勝手に作成したものです。 なので、まだリモートリポジトリにはブランチはありません。

このような場合は git pushコマンドに -u オプションをつけましょう。 リモートリポジトリにも同じブランチを作成して変更を保存してくれます。

以下の様な結果が表示されていればプッシュ成功です。

f:id:neko3cs:20191020020727p:plain

GitHub もみてみましょう。 ブランチドロップダウンをクリックすると新しく作った new-branch ブランチがあります。

f:id:neko3cs:20191020021139p:plain

コミットもきちんとリモート側に保存されていることが確認できます。

f:id:neko3cs:20191020020935p:plain

ブランチをマージする

変更した内容がやっぱり master ブランチにも反映したくなることがあるかもしれません。

その場合は new-branch ブランチを master ブランチにマージします。

以下のコマンドを実行するとブランチをマージ出来ます。

$ git merge <マージしたいブランチ名>

マージは現在のブランチに対して行われます。 そのため、 master ブランチに new-branch をマージしたい場合は先に master ブランチに移動してからおこないます。

f:id:neko3cs:20191020022241p:plain

上記の結果の通り、マージしたあとに変更が master ブランチにも反映されていることがわかりますね。

あとはマージした結果を git push コマンドでリモートブランチにも反映させておきましょう。

まとめ

本章では基本的な git の使い方について説明しました。

git 初心者が覚えておくべき基本の操作は以下のコマンドになります。

  • git clone
  • git status
  • git add
  • git commit
  • git push
  • git switch [-c]
  • git merge

以下が次の章になります。

neko3cs.hatenablog.com

git 入門 〜導入編〜

git 入門の2章、導入編に入りたいと思います。

本章では git を使うにあたっての事前準備の仕方を説明します。

前章はこちらになります。

neko3cs.hatenablog.com

導入手順

基本的に以下の手順で git がすぐに使える様になると思います。

  1. GitHubにアカウントを作成する
  2. git をインストールする
  3. git と GitHub の通信設定をする

GitHub にアカウントを作成する

git を最大限に利用するためにはリモートリポジトリが必要です。

リモートリポジトリとはチームで同じソースコードへアクセス出来る様に集中管理しているリポジトリです。 ソースコードリポジトリという単位で変更履歴が管理されます。

git のリモートリポジトリを作るには git サーバと呼ばれる専用のサーバを立てる必要がありますが、 通常は GitHub という git サーバやその他変更履歴管理・チーム開発に関するサービスを提供する Web サービスを利用します。

GitHub アカウント作成の詳細な手順は省略しますが、 以下のリンクからGitHubサイトへアクセスし、 Sign up のボタンからアカウントが作成できます。

github.com

git をインストールする

git は通常 CLI によるコマンド操作で使用します。 git コマンドを使用するには git がインストールされている必要があります。

Windows であれば Git for WindowsmacOS であれば Homebrew から brew install git でインストールします。

正常にインストールされているかどうかはmacOS であればターミナルを、 Windows であれば Windows PowerShell を開いて以下のコマンドを実行してみてください。

$ git --version

以下の様な結果が表示されていればインストール成功です。 (バージョンの値はインストールした時期によって変わります)

f:id:neko3cs:20191016013907p:plain

git のインストールが済んだら git にユーザ名とメールアドレスを設定しておきます。 ここでのユーザ名、メールアドレスはコミット時に誰のコミットかを識別するために使われます。

普通は GitHub アカウントと同じユーザ名、メールアドレスにしておくかと思われます。

ユーザ名、メールアドレスの設定は以下のコマンドでおこないます。

$ git config --global user.name "<ユーザ名>"
$ git config --global user.email "<メールアドレス>"

git と GitHub の通信設定をする

git を使って GitHub のリモートリポジトリにソースコードを上げるには ssh プロトコルによる暗号化通信が一般的です。

でも、 git を使う上で必ずしも ssh を理解する必要性はないので以下の手順だけおこなってください。

ターミナル (macOS) / Windows PowerShell (Windows) を開いて以下のコマンドを実行します。

$ cd ~/.ssh
$ ssh-keygen -t rsa -b 4096 -C "<gitに登録したメールアドレス>"

何か聞かれると思いますが、ひとまずは無視して Enter キーを3回押しましょう。*1 以下の様なアスキーアートが表示されたら成功です。

f:id:neko3cs:20191018050022p:plain

上記が成功したら以下のコマンドを使用して暗号化のキー情報をコピーします。

# macOS の場合
$ pbcopy < id_rsa.pub

# Windowsの場合
PS > cat id_rsa.pub | clip

次にコピーした暗号化キーを GitHub に登録します。

以下の図の番号順に進んでください。

  1. 右上のアイコンをクリック
  2. Settings をクリック
  3. SSH and GPG keys
  4. New SSH key をクリック

f:id:neko3cs:20191018051825p:plain

表示された画面のKey入力欄に ⌘ + V (macOS) / Ctrl + V (Windows) でペーストしましょう。 Titleはわかる名前をつけておけば良いです。

f:id:neko3cs:20191018052120p:plain

最後に通信確認をします。

もう一度、ターミナル (macOS) / Windows PowerShell (Windows) を開いて以下のコマンドを実行します。 何か聞かれますが、一言で言うと接続してよいかを問われているので yes と入力して Enter します。

$ ssh -T git@github.com

以下の様に Hi と挨拶されたら OK です!

f:id:neko3cs:20191018052757p:plain

まとめ

本章では git を使える様にするための導入手順について説明しました。

以下が手順のまとめです。

  1. GitHub のアカウントを作成する
  2. git をインストールし、アカウント設定をおこなう
  3. git と GitHub 間の暗号化通信の鍵を GitHub に登録する

次の章は以下になります。

neko3cs.hatenablog.com

*1:聞かれている内容はパスフレーズの設定です。セキュリティを向上させたいのであれば、パスフレーズを考えて入力してください。

git 入門 〜紹介編〜

git は今やバージョン管理システムデファクトスタンダードになっています。

しかしながら、若手エンジニアである、レガシーな環境にいるために git を知らない、 そもそも難しそうなどの理由で git を使えない人もいるかと思います。

今回はそんな迷える子羊に git の便利さと覚える意義、簡単な使い方について説明したいと思います。

ちょっと長いので4章立てにしたいと思います。

目次

git とは

gitとはソースコード等のファイルのバックアップを取ったり変更履歴を管理したり出来るシステムです。

ソースコードに限らず、ただのテキストファイルや ExcelPhotoshop 、画像ファイルといったバイナリデータも管理出来ます。

git を使用すると便利な点は以下の3点です。

  • 過去の状態に簡単に戻せる
  • ちょっとお試しの感覚で簡単にコード改変しやすい
  • 複数人での作業が簡単になる

過去の状態に簡単に戻せる

編集したソースコードに不具合があり、過去の動いていた状態に戻したくなった場合、どうしますか?

一番手っ取り早い方法はコピーしてバックアップフォルダ等に別途保存する方法だと思います。

ですが、バックアップファイルが増えすぎるとどこにどんな変更を保存したかわかりづらくなります。

git を使用することでコミットという作業単位でバックアップを取ることが出来るため、 作業に不都合が生じた際に簡単に過去のピンポイントな状態へ戻すことが出来ます。

ちょっとお試しの感覚で簡単にコード改変しやすい

git では作業の時系列をブランチという機能で並列化することが出来ます。

ブランチのイメージは以下の図を参考にしてください。

f:id:neko3cs:20191015235940p:plain

図では master ブランチから feature-branch が分岐しています。 分岐する直前まではソースコードの内容はまったく同じ状態です。

分岐した先からは master ブランチには変更の影響を一切与えません。 好き放題ソースコードを変更し、コミットしてしまっても、そのバックアップされた情報は feature-branch に閉じています。

ブランチは不要になれば削除することも出来ます。

複数人での作業が簡単になる

チーム等の複数人で同じファイルを作業する場合、どのように変更内容を適用しますか? おそらく、作業者それぞれの変更した部分を手作業で話し合って継ぎ合わせていくと思います。

このファイルの差分を継ぎ合わす作業は想像するだけで大変ですね。 影響するファイルが20、30とあると想像もしたくないです。

ですが、 git のマージという機能を用いることで、 それぞれのブランチでコミットした作業内容がもれなく上手く自動で継ぎ合わせてくれます。 これにより、チームでの同時作業も容易になります。

まとめ

本章では簡単に git の紹介をおこないました。

簡単にまとめると git には以下のメリットがありました。

  • コミットを遡って過去の状態に簡単に戻せる
  • ブランチを切っておくことで元のソースコードに影響を与えずに作業が出来る
  • 切ったブランチは他のブランチにマージ出来るため、共同作業が可能になる

この章を読んで git を使ってみようと思って頂けたら幸いです。

以下が次の章になります。

neko3cs.hatenablog.com

bashでコマンドの存在確認をする

最近環境構築の自動化にハマりつつあります。

Linux等のUNIX OSではほとんどが標準でパッケージマネージャが存在し、 アプリケーションの管理はパッケージマネージャで行われることが多いです。

macOSの場合、Homebrewを使うことによって アプリケーションのパッケージ管理の幅がグッと広がります。

brewで管理しているアプリを初期インストール時だけでなく、 brewが入っていない状態や追加でアプリをインストールしたい時など、 そもそもそのコマンドが生きているのかを確認したい場合があったので今回はその方法を紹介します。

結論

以下のコマンドでコマンドの生死がわかります。

$ type {command} >/dev/null 2>&1 && echo "{command} exists."

>/dev/null 2>&1とは???

それぞれ次のような意味です。

Shell 意味
>/dev/null 出力を破棄する
2>&1 標準エラー出力を標準出力として出力する

ちなみに、>/dev/nullスペシャルファイルの1つであらゆる入力をも破棄する特殊なインターフェースです。 別名ビットバケツ

つまり、出力は全てゴミ箱へ(まったく表示しない)と言う意味。

なぜこれで存在チェックが出来るかと言うと、 コマンドの終了コードを見ているからです。シェルでのtruefalseの終了コードは以下の通り。

$ true
$ echo $?
0
$ false
$ echo $?
1

そのため、コマンドが存在する場合は正常終了し、 終了コード0 = trueとして見なされ存在チェックが可能と言うわけですね。

いや、難しい...💦

おまけ

ちなみにpwshでは以下のようにやると同じようなことが出来るそうです。

PS> if (Get-Command {command} -ea SilentlyContinue) { echo "{command} exists." }

(pwshだとand演算子、or演算子で分岐処理出来ないかも?)

ASP.NET Core Moduleをサーバにインストールする際の注意点

おしごとで勘違いしたので備忘録。

ASP.NET CoreをIISでホストする時、ASP.NET Core Moduleをサーバにインストールする必要があります。

いろいろ調べていてIISにインストールしたModuleをIISの [機能ビュー] > [ハンドラーマッピング] からモジュールマップを追加する必要があるのかと勘違いしました。

ASP.NET Coreのハンドラーモジュールはサイトをデプロイした際にweb.configを読込み、自動的に設定してくれるため、手作業でIIS上でハンドラーマッピングの追加をする必要はないです。

Visual StudioにてASP.NET Coreアプリを発行した際に生成されるweb.configに以下の設定があれば自動設定されます。

<system.webServer>
    <handlers>
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="dotnet" arguments=".\WebApplication1.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="InProcess" />
</system.webServer>