Visual Studio Community 2017

（作成：2017/09）

C# で個人的にコード開発を始めたくなって、自宅環境に色々導入してみた。
まず何は無くとも開発環境だろうという事で。
（以下 VS17 と略す）

ダウンロードURL

Visual Studio Community - Visual Studio

下の方にあるVisual Studio Community ダウンロードを開き、Visual Studio Community 2017-無償ダウンロードでインストーラを取得。（ vs_Community.exe ）

Install on Windows 10

悩む点はパッケージ選択くらいかしらん。随分簡単、だけどインストーラ起動や処理進捗にかなり時間かかるので、まあお茶でも一杯。

ライセンス条項への同意

インストール項目を選択する。
このインストール項目はパッケージ更新・管理機能も備えているようで、後から幾らでも変更できる。まずはあまり欲張らず、Windows プログラミングを色々やるために以下2項目を選択してみた。

ユニバーサルWindowsプラットフォーム開発
.NETデスクトップ開発

インストール項目の選択

以下のように表示されたら完了。それまでが長い。まあ御茶請けでも。

インストール完了

インストーラを終了し、VS17 を起動してみる。
初めて使用するための準備に続いて IDE が起動する。

VisualStudio 2017 環境

基本設定

VS17 は国際化対応されており、 PC の言語設定に沿った言語パックが入るので迷う事は無いと思う。
参考として、あまり大した設定はないけれど、自分なりに便利な設定を紹介。

ツール
- オプション

設定

以下、オプション内の項目名で説明。

参考:
- VisualStudioを自分好みの設定にする - ilovex

ビルドエラー時にデバグ実行しない

プロジェクトおよびソリューション
- ビルド/実行
- 実行時に、ビルドまたは配置のエラーが発生したとき: 起動しない

プロジェクト置き場を変更する

プロジェクトおよびソリューション
- 場所
- プロジェクトの場所: E:\Source\Repos
- ユーザープロジェクトテンプレートの場所: E:\Templates\ProjectTemplate

配色テーマを変更する

環境
- 全般
- 配色テーマ: 濃色
- タイトルの文字スタイルをメニューバーに適用する: チェック
- クライアントのパフォーマンスに基づいて視覚的効果を自動的に調整する: チェック

中二病こじらせているので暗いテーマが好き。

カーソル移動をEmacsチックに変更する

ここでの個人的な目的は、 HHK 使ってて十字キー使おうとすると右小指攣りそうになるの回避。とにかくコーディング中のカーソル移動を改善したい。で、下記参考ページに沿って拡張機能入れても良いんだけれど、全力 Emacs なのがやや不安なのと、コピペ操作に問題があるみたいであまり使いたくない。
そこで一部カーソル移動関係のみ手動で修正。これだけでも作業効率が結構上がる。

環境
- キーボード

ここの設定手順はややこしいので簡単に説明。

以下の文字列を含むコマンドを表示でショートカットを設定したいコマンドを選択
編集. で検索すると見付け易い。
使用する場所でショートカット使用場所を選択
コード編集領域なら テキストエディタ を選択。
ショートカットキーで割り当てたいショートカットを叩く
入力ミスしたら、もう一度使用する場所を選択し治せば空欄になる。
現在使用されているショートカットを確認、問題なければ割り当てを押す
全体に割り当てられたショートカットや同じ使用する場所での別機能がある場合はダメ。

特に4.、 Emacs のページ移動は C-v だけど Windows ではペーストなので使えない。
で、苦肉の策として以下のように設定した。（使用する場所は全てテキストエディタ）

コマンド	ショートカットキー	本来のEmacsキーバインド
編集.1ページ下へ移動	`Ctrl + Shift + v`	`C-v`
編集.1ページ上へ移動	`Shift + Alt + v`	`M-v`
編集.1行下へ	`Ctrl + n`	`C-n`
編集.1行上へ	`Ctrl + p`	`C-p`
編集.右に1文字移動	`Ctrl + f`	`C-f`
編集.行頭に移動	`Ctrl + Alt + a`	`C-a`
編集.行末に移動	`Ctrl + Alt + e`	`C-e`
編集.左に1文字移動	`Ctrl + b`	`C-b`

このうち Ctrl + Shift + v は 編集.クリップボードリングの切り替え(全体) に割り当てられているが、クリップボードリング自体使わない（Cliborとかフリーソフトのが余程良いものがある）ので敢えて無視。

参考:
- Visual Studio Community 2017でEmacs Keybind - Qiita
- Emacs emulation - Visual Studio Marketplace

少しでも起動を軽くする

環境
- スタートアップ
- スタートアップ時: 空の環境の表示
- コンテンツをダウンロードする間隔: 未チェック

併せて起動時のスプラッシュウインドウも消しちゃう。
これはショートカットの修正が必要なので、エクスプローラから。

C:\ProgramData\Microsoft\Windows\Start Menu\Programs を開く
Visual Studio 2017 を右クリック プロパティ
リンク先 最後尾 /nosplash を追記 OK （管理者権限が必要）

VisualStudio 2017 環境

参考:
- Visual Studio の動作を少しでも軽くするための4つの設定 - かわろぐ

少しでも作業領域を広くする

環境
- タブとウインドウ
- マウスポイントで自動的に隠されたウインドウを表示する: チェック

併せて作業画面に戻って以下をすれば、周囲のウインドウが隠れてくれて便利。

ウインドウ
- すべて自動的に隠す

自動更新を有効にする

環境
- 拡張機能と更新プログラム
- 更新プログラムを自動的に確認する: チェック
  - 拡張機能を自動的に更新する: チェック

エディタのテキストを折り返す

テキストエディタ
- C#
- テキストを折り返す: チェック
  - 右端の折り返しの記号を表示: チェック

コーディングスタイルの統一

前置

VS17 の標準は UTF-8-BOM + CRLF

コーディングするにも色々なツールを活用する場合は多い。けれど文字コードや改行コード、インデント方法などツールによって統一されてないと色々ツラい。
たとえば VS17 でソリューションを新規作成して Program.cs を nkf で文字コード確認すると、標準ではこうなっている。

$ nkf --guess Program.cs
UTF-8 (BOM) (CRLF)

ここで編集中のコードを一旦閉じ、他のテキストエディタで修正したとする。んで、そのエディタが Shift-JIS + CRLF で保存しちゃったとする。

右上、SJIS（CRLF）になってる

$ nkf --guess Program.cs
Shift_JIS (CRLF)

再度 VS17 でコードを開いても、特に文字化けの気配は無い。普通にコンパイルも通るし、編集して保存もできる。
でもやっぱり Shift-JIS + CRLF のまま。

右上、やっぱりSJIS（CRLF）

$ nkf --guess Program.cs
Shift_JIS (CRLF)

さてこれをキモいと思うかどうかに依るけれど、まあ多少なりITに携わった人間ならキモいと思うんじゃないかなと。
まだ文字コードを EUC-JP + LF なんかで保存されたなら、VS17のエディタ上で日本語は確実に文字化け起こすので解る。（許容は出来ないけれど）
現在の文字コード表示くらいあれば違うんだけど、勿論それも無い。

盛大に文字化け、改行もおかしい

で、 UTF-8-BOM + LF で保存し直したいとなると、標準のVS17では以下の方法しか無い模様。

ファイル-名前を付けて（ファイル名）を保存
- 右下エンコード付きで保存
  
  名前を付けてファイルを保存
- エンコード: Unicode （UTF-8 シグネチャ付き） - コードページ 65001
- 行の終わり: Unix （LF）
  
  保存オプションの詳細設定

以降は VS17 で編集する限り UTF-8-BOM + LF を保つみたいだけど、新規にファイルを作れば改行コードはやっぱり CRLF になるし。え、毎回これやるの？　文字コードの強制とか設定出来ないの？

（標準設定では）できなかったよ。。。(´･ω･`)

コーディングで使う文字コード/改行コードとその理由

VS17 の標準が UTF-8-BOM + CRLF なんだからそれで良いんじゃん？　とは思うものの、あまり理由を追求した参考サイトも無く、肝心の理由も自分の中で曖昧なので調べたり考えたりしてみた。
まず文字コード。日本語使うにしても Shift-JIS 、 EUC-JP 、 ISO-2022-JP は流石に今更感あるし、そもそもこの中では Shift-JIS くらいしか VS17 で使えない。
となると UTF-8 だけれど、 BOM の有無で違いがある。 BOM の何たるかは解説サイトが沢山あるのでそちらに譲って、調べたところでのメリデメを書いてみる。

なおあくまでウチ個人の感想であり万人向けではない事を逃げ口上として述べておく。

文字コード

UTF-8
- ○ Unicode 規格上 BOM は必要とも推奨ともしていない
- × VC++2010 など旧環境でコード判別できずコンパイルが通らない、事があった
- × VS15 あたりでも文字化けやエラーが起きる、事があった
UTF-8-BOM
- ○ ヘッダ部だけ見れば Shift-JIS か UTF-8 か判断が付く
- ○ Windows の標準だし、 CSV ファイルも MS Office で文字化けしない
- × Git が BOM を見て「変更有り」と誤判してしまう、事があった
- × ヘッダ部の除外を考慮しないとテキストファイル読取にミスる
- × 同、 HTML や PHP では無効なヘッダとして扱われる

Windows での開発が前提なら、 HTML や PHP など特殊な場合を除き UTF-8-BOM のが利がありそう。でも文字コードを意識したコーディングが必要だったり、 Git の誤判の事など注意も必要で、今後の状況によっては UTF-8 に傾倒するかも。

改行コード

CRLF
- ○ Windows 標準
- × Unity や Git 、 Linux で非標準、変換が必要な事が多い
LF
- ○ Unity や Git で標準、 Linux 環境とも互換性ある
- × WIndows 標準でない
CR
- えっ、漢字 talk 時代の旧 Macintosh しか標準環境知らんし……

Windows での開発が前提だけれど、こちらは特に WIndows 標準である事が強みには思えない。むしろ Unity や Git で気を付けないと問題になるなら、 LF の方が良いかも。

というわけで、今のところ文字コードのコーディングスタイルは UTF-8-BOM + LF が良いんじゃないかな、と思った次第。

参考:
- バイトオーダーマーク - Wikipedia
- BOMの地雷を踏み抜かない正しい文字コードとの接し方
- C言語ソースの文字コードをUTF-8（BOM付）に統一してみる | 積水成淵日記
- Visual Studio の UTF-8 BOM と Git の設定で悩まされた話 - しばやん雑記
- visual c++ 2010 では BOM 無しの UTF-8 がコンパイルできない | Moonmile Solutions Blog
- Git - Gitの設定
- Unityと改行コード - エフアンダーバー

。。。前置はこのくらいで、以下コーディングスタイルを統一するための設定など。

EditorConfig

VS17 は標準で EditorConfig 機能を搭載している。これは管理フォルダ内に .editorconfig なるファイルを置いておくことで、そのプロジェクト内で以降追加されるアイテムのインデント処理や使用する文字コードなどを揃えてくれる、というもの。

ソリューションエクスプローラ
- （プロジェクト名）右クリック追加-新しい項目
- テキストファイル: .editorconfig
  
  新しい項目の追加
  
  ※この方法で追加しないとソリューション管理下にならないので注意。

設定はこんな感じ。

root = true

[*]
end_of_line = lf
charset = utf-8-bom
indent_style = tab
indent_size = 4
trim_trailing_whitespace = false
insert_final_newline = false

[*.{c,h,cpp,cs}]
trim_trailing_whitespace = true
insert_final_newline = true
indent_style = space
indent_size = 4

[*.{md,txt}]
trim_trailing_whitespace = true
insert_final_newline = true

新規コードの追加時など、上記ルールに沿ったものが追加される。
既存ファイルをルールに当て嵌めたい場合は、ファイルを開いて編集-詳細-ドキュメントのフォーマットを実施してから変更/保存する。ただ、試したところ改行コードの変更はうまくいかないみたい。参考サイトでも指摘しているけれど、いつか直るのかしらん。

参考:
- EditorConfig
- Unityと改行コード - エフアンダーバー
- 行末の空白は EditorConfig で始末しましょう - Qiita

開いたファイルを悉く UTF-8-BOM + LF コードに統一する拡張機能

EditorConfig の方法は新規作成時のスタイル統一に利点があるのだと思う、何となく。既存ファイルに関しては結局手動対応だし。
で、文字コードに関してもう少し強制的に統一する方法。使う拡張機能は以下。

サクッとインストール。ここでは BOM ありを選んでるけれど、 BOM なしが良い場合は「ForceUTF8 （No BOM）」を選べば良いと思う。

ツール-拡張機能と更新プログラム
- オンライン
  
  拡張機能と更新プログラム
- 検索utf8
  - ForceUTF8 （with BOM）-ダウンロード
- 検索line end
  - Line Endings Unifier-ダウンロード

VS17 を終了するとインストーラが起動する。

VSIXインストーラ

変更

VSIXインストーラ

VS17 再起動。 ForceUTF8 は何もしなくても適用されるけど、 Line Endings Unifier は設定が必要。

ツール-オプション
- Line Endings Unifier-General Settings
  
  オプション - Line Endings Unifier
- Default Line Ending: Linux
- Force Default Line Ending On Document Save: True

さて前述で別のエディタにて Shift-JIS + CRLF 保存されたコードを VS17 で普通に修正、保存してみる。

右上、UTF8#（LF）になってる

$ nkf --guess Program.cs
UTF-8 (BOM) (LF)

UTF-8-BOM + LF で自動的に上書きできた。

参考:
- C言語ソースの文字コードをUTF-8（BOM付）に統一してみる | 積水成淵日記
- Visual Studio で改行コードを Unix （LF）に統一する - kyoto-u-koheiのブログ