はじめに

Visual Studio 2022を使っていると、ある日突然「起動しない」「スタート画面が表示されない」といったトラブルに遭遇することがあります。

本ブログでは、Visual Studio 2022が起動しなくなった場合の対処法を、分かり易く紹介します。

Visual Studio 2022が起動する仕組み

まずトラブルの原因を特定するため、Visual Studio 2022 の起動プロセスを説明します。

1. devenv.exe の起動
   Visual Studio の実行ファイル（devenv.exe ）が起動され、Visual Studio 2022の初期化が始まる。
   
   
2. ライセンスの検証
   「%LOCALAPPDATA%\Microsoft\VSCommon\OnlineLicensing」 にあるキャッシュを参照し、ライセンスの有効性を確認する。
   • %LOCALAPPDATA%
     C:\Users\ユーザ名\AppData\Local　を示す。
     
     
3. 拡張機能の読み込み
   ReSharperなどの拡張機能が順次読み込まれる。SafeModeでは読み込みをスキップ可能。
   
   
4. ユーザー設定の復元
   %APPDATA%\Microsoft\VisualStudio に保存された設定ファイルを読み込み、前回の状態を復元する。
   • C:\Users\ユーザ名\AppData\Roaming　を示す。
     
     
5. ワークロードの初期化
   C#や.NETなど、インストール済みのワークロードに応じて必要なコンポーネントを初期化する。
   
   
6. スタートウィンドウの表示
   最近開いたプロジェクトやテンプレートが表示され、ユーザー操作が可能になる。

amzn.to

改訂新版　Visual Studio パーフェクトガイド

本書は、初めて開発を行う人に向けに最新の「Visual Studio 2022」の活用方法を解説した入門書です。本書を読めば、.NET MAUI／Blazorによるマルチプラットフォーム開発、単体テストフレームワークを用いたソフトウェアテスト、Run To Clickによるデバッグ技法、行ステージングによるソースコード管理など開発に必要なVisual Studioの活用法がわかります。

Visual Studio 2022 が起動しないときにまず行うべき診断

ライセンスキャッシュの確認

%LOCALAPPDATA%\Microsoft\VSCommon\OnlineLicensing　フォルダ内の「default.metadata」 が NULL 埋めされていたら破損。

SafeMode で起動できるか確認する

ファイ名を指定して実行（「ウィンドウズキー＋W」）で、「devenv.exe /SafeMode」コマンドが実行できるか確認する。

拡張機能を読み込まないで起動するので、起動できた場合は拡張機能が原因の可能性が大きい。

起動ログを確認する

「devenv.exe /log」で起動後、ログファイル「%APPDATA%\Microsoft\VisualStudio\Version\ActivityLog.xml」内のエラー内容（例：ライセンス検証失敗、拡張機能クラッシュ）を確認する。

TEMP環境変数の確認

セミコロン付きや無効なパスがあると起動に失敗します。

amzn.to

Visual Studioパーフェクトガイド 単行本

本書はIDEに焦点を当てた書籍です。IDEは豊富な機能が揃っているため、C#を用いてUnityでゲーム開発を行う場合やクロスプラットフォーム開発を行う際,IDE(Visual Studio)を使うのはデファクトスタンダードになっています。本書は新人エンジニアに向けて,豊富な機能が揃ったIDEが裏で何をやっているかをわかりやすく解説した書籍を目指します。

Visual Studio 2022 が起動しない原因と対処方法

ライセンスキャッシュ破損

Visual Studio は、起動時のライセンスを、毎回オンラインで確認するのではなく、以下のフォルダにあるキャッシュファイル default.metadata 等を参照します。

%LOCALAPPDATA%\Microsoft\VSCommon\OnlineLicensing

ライセンスキャッシュが破損した場合の症状

• Visual Studio が起動直後にクラッシュ
• スタート画面が表示されず、プロセスが即終了
• ログに「License validation task failed unexpectedly」などのエラーが記録される

対処方法

以下のようにして、キャッシュのリセットを実行します。

「%LOCALAPPDATA%\Microsoft\VSCommon\OnlineLicensing」のフォルダ名称を　「OnlineLicensing_bkup」等の名称に変更し、Visual Studio を再起動。こうする事で、新しいキャッシュが自動生成される。
※この操作はライセンス情報の再取得を促すもので、ライセンス自体が無効になるわけではありません。

拡張機能の不具合

拡張機能が不具合時の症状

• スプラッシュ画面が表示された直後に強制終了
• スタートウィンドウが表示されず、プロセスが消える

拡張機能の不具合かどうかの確認方法

• SafeModeで起動してみる

devenv.exe /SafeMode

SafeModeでは拡張機能が読み込まれない為、このモードで起動できる場合は拡張機能が原因の可能性が高いと言えます。

• 起動ログを確認する
  「%APPDATA%\Microsoft\VisualStudio\17.0\ActivityLog.xml」に以下のような記述がある場合、拡張機能がクラッシュの原因です

Extension 'ReSharper' failed to load.
Exception: System.NullReferenceException...

対処方法

• SafeModeで起動して、拡張機能を無効化 又は、削除
  • SafeModeで起動（「ファイル名を指定して実行」で、devenv.exe /SafeMode）
  • メニュー → [拡張機能] → [拡張機能の管理]
  • 問題のある拡張機能（例：ReSharper）を「無効化」または「アンインストール」
    
    
• Visual Studio Installer で修復（拡張機能の不整合も含めて再構成される）
  • スタートメニュー → Visual Studio Installer → 対象バージョン → 修復

amzn.to

Kindle Paperwhite (16GB) 7インチディスプレイ

レビュー：読書が楽しくなるガジェット。スマホで読むのとは違います。カラー版もありますが、カラーの書籍って雑誌を除くとそんなにないのでPaperwhiteで十分だと個人的には思います。

アップデート失敗

アップデート失敗は、構成ファイルの破損やネットワーク不具合、インストーラーの不整合などが原因で発生します。

アップデート失敗時の症状

以下の様に、症状は多岐に渡る。

• Visual Studioが起動しない
  • スプラッシュ画面が表示された直後にクラッシュ
  • プロセス（devenv.exe）が一瞬で終了する
    
    
• Visual Studio Installer自体が起動しない
  
  
• SafeModeでも起動しない
  
  
• 特定のワークロードが消えている
  
  
• IntelliSenseが動作しない
  
  
• ツールウィンドウが表示されない
  
  
• 起動ログ（ActivityLog.xml）に下記のような構成エラーが記録される

Package 'Microsoft.VisualStudio.Shell.Connected' failed to load

• Visual Studio Installerでの症状
  • 「修復」ボタンがグレーアウトしている
  • インストール済みの構成が表示されない
  • 「アップデートに失敗しました」などのポップアップが出る

対処方法

• Visual Studio Installer で修復を試す
  • スタートメニューから「Visual Studio Installer」を起動
  • 対象のバージョン（例：Visual Studio 2022）を選択
  • 「修復」ボタンをクリック
  • 修復完了後、再起動して確認
    
    
• Installer自体が起動しない、修復できない場合は、Microsoft公式の「InstallCleanup.exe」ツールを使ってインストール情報を完全に削除します。
  • 管理者権限でコマンドプロンプトを起動
  • 以下のコマンドを実行

"C:\Program Files (x86)\Microsoft Visual Studio\Installer\InstallCleanup.exe" -i 17

※ -i 17 は Visual Studio 2022 のバージョン指定
　クリーンアップ完了後、Visual Studio 2022 を再インストール

• アップデートが「ダウンロードできない」「接続できない」といったネットワーク系のエラーで失敗する場合
  • C:\Windows\System32\drivers\etc\hosts を管理者権限で開く
  • 「93.184.215.201 download.visualstudio.microsoft.com」　を追記
    • 93.184.215.201 は、米国の CDN（コンテンツ配信ネットワーク）やホスティングサービスが使用する IP アドレスのひとつで、特に example.com というテスト用ドメインのホスト先。本来の Microsoft の更新サーバーではなく、接続テストや一時的な回避策として使われることがあるだけで、恒久的な解決策ではありません。
  • コマンドプロンプトで、「ipconfig /flushdns」を実行

TEMP環境変数の誤設定

よくある誤設定

• TEMP=C:\Temp;（末尾にセミコロン）
  • パスが無効と認識され、起動失敗
    
    
• TEMP=（空欄）
  • 一時ファイルが保存できず、クラッシュ
    
    
• TEMP=D:\フォルダ名（存在しないパス）
  • ファイル書き込みエラーで起動不能
    
    
• TEMP がネットワークドライブ
  • アクセス遅延や失敗で起動不能になることも
    

amzn.to

New Amazon Kindle Colorsoft | 16GBストレージ、防水、7インチカラーディスプレイ

booxなどのandroid搭載の電子ペーパー端末と迷いましたが、お風呂で使いたかったので結局はこの商品にしました。電子ペーパーはページ送り時の読み込みが遅いと言う印象がありましたが個人的には全然問題ありませんでした。カラーの発色は淡いですが、こんなもので良いだろうと言う感想です。

まとめ

Visual Studio が突然起動しなくても慌てる必要はありません。C#等のソースはIDEとは別フォルダとして保存されているので、最悪 他のIDE（VSCode）でも使用が可能です。

先ずは起動のプロセスを理解し、起動しなくなった原因を突きとめるために診断を行う事です。そして、その診断に基づいた適切な処置を実行する事で再起動する事が可能となります。

Visual Studio 2022 開発環境の条件

C#による多様なアプリケーション開発に対応できる万能な環境を整えます。

プロジェクトの種類に応じて必要最小限を選ぶのもOKですが、最初は広めに入れておくと将来的にスムーズに対応できます。

Visual Studio 2022 インストールの見直し

Visual Studioインストール時のワークロード

以下のワークロードをインストールする事で、デスクトップアプリとWebアプリの開発に対応できます。

• .NETデスクトップ開発
  Windows FormsやWPFなどのデスクトップアプリケーションを開発するために必要なツール群が含まれます。
  WinForms Designer や XAML Designer、ローカルデバッグ環境 がセットアップされるため、GUIアプリ開発を行う場合は必須です。

• ASP.NETとWeb開発
  Webアプリ（ASP.NET Core, MVC, Razor Pagesなど）を開発する際に必要です。
  Visual Studio 2022にはBlazor（WebAssembly）開発機能も含まれており、サーバー／クライアント両方をC#で書ける最新開発スタイルをサポートしています。

ユニットテストツール（MSTest V2/xUnit）

テストツールを使うことで、バグの少ない・変更に強い・保守しやすいコードを実現できます。

• MSTest V2の使用
  必要なパッケージのインストール方法や具体的な使用方法は「MSTest V2によるユニットテスト」を参照下さい。

• xUnitの使用
  MSTest V2と同様、必要なパッケージのインストール方法や具体的な使用方法は「MSTest V2によるユニットテスト」を参照下さい。

Gitによるソース管理

バージョン毎のソース管理や複数人によるプロジェクト作成時には、ソースの管理ツールは欠かせません。一般的に使用されている「Git」及び「GitHub」は必須と言えます。

使用にあたっては、下記リンク先のブログを参考にしてください。

• C#ソース管理　Gitローカル編

• C#ソース管理　GitHubリモート編

Azure開発

近年、クラウドネイティブな開発がますます重要視されています。その中心にあるのが、Microsoft Azure。Visual Studio 2022を使えば、ローカルのC#プロジェクトからシームレスにクラウドへ展開することが可能です。

Azure開発 を行うのであれば、Visual Studio インストーラーを起動し、ワークロードから 「Azure 開発」をインストールしておきましょう。

モバイル開発（.NET MAUI）

「スマホアプリ開発って難しそう…？」と思っている人が多いかもしれませんが、Visual Studio と .NET MAUI を使えば、C#の知識だけで iOS・Android・Windows に対応したモバイルアプリを一つのコードで開発できます。

以前は、Xamarin（ザマリン）を使用して作成していましたが、Microsoftは 2024年5月1日をもって サポートを終了 しました。

.NET MAUI（Multi-platform App UI）はXamarinの後継で、iOS・Android・Windowsのクロスプラットフォーム開発が可能です。

モバイル開発を行うのであれば、「.NET マルチプラットフォーム アプリの UI 開発」ワークロードのインストールしておきましょう。

エディタの設定調整

複数人で共同作業を行う場合、エディタや開発環境の設定を工夫することで作業効率や品質の統一がぐっと向上します。以下は Visual Studio（または他のエディタでも応用可能）でのおすすめ設定です。

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

• .editorconfig ファイルを導入
  • インデント（スペース/タブ）、最大行長、命名規則などをプロジェクト単位で統一できます。
  • Visual Studio は .editorconfig を自動で読み込むので、個人の設定に関係なく統一が保たれます。

Live Share（リアルタイム共同編集）

• Visual Studio には「Live Share」機能があり、他のメンバーとリアルタイムでコードを共有・共同編集できます。

• 画面共有やチャット、コメントも可能。
• デバッグセッションも共有できるので、ペアプロにも最適！

コード分析と警告

• StyleCop / Roslyn Analyzer / ReSharper を導入すると、
  • コーディングルールの違反を自動で警告・修正提案
  • チームでの品質維持につながる

拡張機能で機能強化

Visual Studio Marketplaceから拡張機能をインストールすることで、機能を大幅に拡張できます。

• Roslynator：C#コードの解析・リファクタ支援
• CodeMaid：コードの整形とクリーンアップ
• Visual Studio IntelliCode：AIによるコード補完の精度向上
• GitHub Extension for Visual Studio：GitHub連携を強化

パフォーマンスの最適化

Visual Studioは非常に高機能なため、設定次第で起動やビルド時間が変わります。

• ツール > オプション > プロジェクトとソリューション > ビルドと実行
  • 「詳細なビルド出力を抑制」してログ負荷を軽減
• 不要な拡張機能やワークロードはアンインストール
• SSDにプロジェクトファイルを配置

デバッグ機能の強化

デバッグはC#開発において重要な工程です。

• ウィンドウ > 自動, ローカル, ウォッチ, 即時ウィンドウ を活用
• 条件付きブレークポイント、ログポイントの使用
• デバッグ > オプション > 全般 で「ソース サーバー サポート」を有効化すると、シンボル読み込みが高速化

まとめ

Visual Studio 2022は、正しく最適化することでC#開発において非常に高い生産性を実現できます。

開発効率を高めるためには、初期インストールから日々のデバッグ、チーム開発に至るまで、細かい設定を積み重ねていくことが重要です。

C#の非同期プログラミング（async/await）は、UIの応答性を保ったり、バックグラウンド処理を効率化する際に非常に役立ちます。

しかし、非同期コードのデバッグは慣れるまではやや難解に感じるかもしれません。

今回はコンソールアプリを例にして、非同期処理（async/await）のデバッグ方法「例外処理・ブレークポイント」について具体的に紹介します。

• 対象者
  • コンソールアプリで async/await を使い始めた初〜中級者
  • 非同期処理の例外やブレークポイント操作を学びたい方

Visual Studio 2022 同期/非同期メソッドのデバッグの違い

同期メソッドと非同期メソッドの主な違いを下表にまとまめしたが、非同期メソッドの最大の注意点は「await の前後で処理の流れが途切れるように見える」ことです。

非同期プログラム（コンソールアプリ）のデバッグ方法

下記のサンプルプログラムは非同期に HTTP リクエストを送信し、外部の Web API（https://jsonplaceholder.typicode.com/posts/1）からデータを取得。そのレスポンスをコンソールに表示するサンプルです。

このURLは「投稿（posts）」の中の IDが1の投稿データ を取得します。アクセスすると、以下のようなJSON形式のデータが返ってきます。

{
“userId”: 1,
“id”: 1,
“title”: “sunt aut facere repellat provident occaecati excepturi optio reprehenderit”,
“body”: “quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto”
}

※ここではスレッドの切り替わりを確認する為に、await の前後にスレッドIDを表示する命令を挿入しています。

using System;
using System.Net.Http;
using System.Threading.Tasks;

class Program
{
    static async Task Main(string[] args)
    {
        Console.WriteLine("処理開始");
        try
        {
Console.WriteLine($"Main開始スレッドID: {Thread.CurrentThread.ManagedThreadId}");
            var result = await FetchDataAsync("https://jsonplaceholder.typicode.com/posts/1");
Console.WriteLine($"Main終了スレッドID: {Thread.CurrentThread.ManagedThreadId}");
            Console.WriteLine("取得結果:");
            Console.WriteLine(result);
        }
        catch (Exception ex)
        {
            Console.WriteLine($"エラー発生: {ex.Message}");
        }
        Console.WriteLine("処理終了");
    }

    static async Task<string> FetchDataAsync(string url)
    {
        using var httpClient = new HttpClient();
Console.WriteLine($"GetAsync実行前ID: {Thread.CurrentThread.ManagedThreadId}");
        var response = await httpClient.GetAsync(url);
Console.WriteLine($"GetAsync実行ID: {Thread.CurrentThread.ManagedThreadId}");
        response.EnsureSuccessStatusCode(); // ステータスコードがエラーなら例外を発生
        return await response.Content.ReadAsStringAsync();
    }
}

ブレークポイントの使い方

• await の前後両方にブレークポイントを置くのが基本。
  • 処理（スレッド）の切り替わりを追いやすいくなります。

上記サンプルプログラムを実行すると以下のようになります。

「httpClient.GetAsync(url);」　命令実行後にスレッドが切り替わっているのが分かります。

非同期処理での例外の捕捉

非同期メソッド内で発生した例外は、通常の try-catch で捕捉できますが、例外が発生する場所までステップインしないと、内部の詳細が見えにくいことがあります。

今回は「ネットワークエラー」を発生させて、例外が発生した瞬間にブレークできるよう以下の設定を行います。

• 設定方法
  • メニューの「デバッグ」→「ウィンドウ」→「例外設定」で、System.Net.Http.HttpRequestException をチェック

他の例外でも、対象となる例外設定にチェックを入れると例外が発生した瞬間にブレークできるようになります。

サンプルプログラムで使用しているURLを存在しないURLに変更して実行してみると、「response.EnsureSuccessStatusCode(); // ステータスコードがエラーなら例外を発生」の箇所でブレークします。

• デバッグのポイント
  • ブレークポイントの設定箇所
    • 「await httpClient.GetAsync(url);」の前後
    • catch (Exception ex) の中
  • ウォッチする変数
    • url： 正しく設定されているか？
    • response：null になる可能性があるか？
    • ex.Message：実際のエラーメッセージを確認

非同期例外のデバッグTips

• wait での例外はメソッド外に伝播するので、try-catch を呼び出し元にも必ず書く
• テータスコードが 404 や 500 のような「正常なHTTPレスポンス」は GetAsync() で例外を投げませんが、EnsureSuccessStatusCode() で例外になる
• 存在しないホスト名などは DNS で即座に例外となるため、確実に例外デバッグが行えます

ログ出力による追跡

• デバッグログを挟むことで、await 前後の流れや問題の特定がしやすくなります。
• 本格的には Serilog や NLog を使ってログをファイル出力するのもおすすめです。

■Serilog や NLog の使用方法は下記ブログを参照下さい

• Serilog：【C# デバッグ入門】Serilogの使用方法を徹底解説

• NLog ：【C#デバッグ入門】NLog の使用方法を徹底開発

ステップ実行と動作の巻き戻し

• ステップ実行
  • F10：ステップオーバー
  • F11：ステップイン（async関数内に入れる）
  • Shift + F11：ステップアウト

注意点：await をステップインすると、生成されたステートマシン（裏側のコード）に入ることがあり、慣れないうちは混乱します。

• 動作の巻き戻し
  • ブレーク時のブレークポイントをクリックしたまま、実行を戻したい場所までドラッグして放す
  • 黄色い⇒が表示され、そこからステップ実行が可能となる。但し、状態を完全に巻き戻すわけではないので注意が必要。

下記は、①でブレークした状態を②まで実行を巻き戻した例。②からステップ実行実行が可能となる。

呼び出し履歴（コールスタック）の活用

非同期コードではスタックの流れが分かりづらくなるため、コールスタックを活用する事も重要です。

• どのawaitから来たか（呼び出し元）を追える
  • Main → FetchDataAsync → ParseJsonAsync のように非同期でも呼び出し経路を視覚化できる

• 非同期メソッド間の流れが分断されない
  • 途中のawaitで中断されても、再開された処理の文脈が残っている
  • 「このawaitの後に、なぜここに来たのか？」を確認できる

• 例外が発生した場所と、呼び出し元を一度に確認できる
  • 非同期処理中に例外が発生したとき、どの関数から呼ばれ、最終的にどこで例外がスローされたかがすぐに分かる

呼び出し履歴（コールスタック）の使い方

1. 非同期メソッド内でブレークポイント停止
2. メニュー → [デバッグ] → [ウィンドウ] → コールスタック（または Ctrl + Alt + C）
3. 一番下が起点、一番上が現在の位置
4. 各メソッドをダブルクリックすると、ソースにジャンプ可能

まとめ

非同期処理でも以下の点を押さえておけば効率的なデバッグが可能です。

• await の前後にブレークポイント
• ウォッチやクイックウォッチで変数確認
• ステップ実行（F10/F11）で処理を追う
• 例外ウィンドウでエラーの瞬間を補足
• 呼び出し履歴（コールスタック）を活用

例外がキャッチされてるのに原因が分からない…？
そんな悩みを解決するのが、Visual Studio の「例外設定」機能です。C# プログラマ向けに、Visual Studio の「例外設定」機能の基本から活用テクまでわかりやすく紹介します。

Visual Studio 2022 C#「 例外設定」とは？

例外設定ウィンドウでは、以下のようなことができます。

• 特定の例外が発生した瞬間（スローされた瞬間）に中断（try-catch で捕捉されていても）
• 例外の種類ごとに中断の有無を設定
• 独自に定義したカスタム例外も追加可能

Visual Studio C#「 例外設定」の使い方

1. [デバッグ] > [ウィンドウ] > [例外設定] を選択
2. 表示されたウィンドウで例えば
   • Common Language Exception のSystem.DivideByZeroException（0割り) にチェックを入れる
3. これで、その例外がスローされた瞬間に Visual Studio が中断してくれます

■簡単な具体例

通常は catch に入って処理が続きますが、例外設定で DivideByZeroException にチェックを入れておくと、例外発生の行で中断してくれます。これにより、例外の発生箇所を正確に特定できます。

Visual Studio C# でチェックを推奨する主なCLR例外

• System.NullReferenceException（ヌル参照例外）
• System.AccessViolationException（メモリアクセス違反）
• System.DivideByZeroException（ゼロ除算例外）
• System.InvalidOperationException（無効な操作）
• System.IndexOutOfRangeException（配列の範囲外アクセス）
• System.StackOverflowException（スタックオーバーフロー）
• System.OutOfMemoryException（メモリ不足）
• System.ArgumentException（無効な引数）
• System.ArgumentNullException（ヌル引数）
• System.ArgumentOutOfRangeException（範囲外の引数）
• System.IO.IOException（入出力エラー）
• System.FormatException（フォーマットエラー）
• System.TypeInitializationException（型の初期化エラー）

• CLR例外
  • .NET の Common Language Runtime (CLR) によって管理される例外。これは、C# や VB.NET などの .NET 言語で発生する例外を統一的に処理するための仕組です。
• 上記の推奨するCLR例外の中には標準でチェックが入っている場合もあります。

「Visual Studio C#」カスタム例外

C# では特定のエラー状況を、標準の Exception クラスを継承する事で自作の例外として定義する事も可能です。

自作の例外（例：MyCustomException）は、例外設定ウィンドウの「＋」ボタンから追加すれば、CLRと同様に中断対象にできます。

※名前空間を定義している場合は、名前空間名を付けて追加する

カスタム例外を活用するメリット

• 広範囲に try-catch を使っているコードでも、例外の発生箇所を特定しやすくなる
• 非同期処理や外部ライブラリの例外も追いやすくなる
• 「マイコードのみ」設定と組み合わせると、ユーザーコードに限定して中断可能となる

カスタム例外を使用すべき状況

• ドメイン固有のエラーを表現したい
  • 例：銀行システムで「残高不足」を表す InsufficientFundsException
  • 例：ECサイトで「在庫切れ」を表す OutOfStockException

• 特定のエラーに対して専用の処理をしたい
  • 例：FileProcessingException を作成し、ファイル関連のエラーを一括管理
  • 例：InvalidUserInputException を作成し、ユーザー入力エラーを適切に処理

• 標準の例外では意味が曖昧な場合
  • ArgumentException ではなく InvalidPasswordException など、より明確なエラー名を付けることで可読性向上

• エラー情報を追加したい
  • 例：DatabaseConnectionException に ConnectionString を保持し、ログ出力時に詳細情報を提供

Visual Studio C#「カスタム例外」の作成手順

カスタム例外のサンプルとしてファイルが存在しない場合に、catch で補足するのではなく、例外をスローした行で実行を中断する設定を紹介します。

• ソースコード
  • Exceptionクラスを継承したカスタム例外「FileMissingException」を作成
    • FilePath プロパティ を追加し、例外発生時に 問題のあるファイルのパスを保持
    • コンストラクタで message と filePath を受け取り、base(message) で親クラスの Exception にメッセージを渡す
  • 処理部分
    • ファイルが存在するかを確認し、ファイルがなかったら「FileMissingException」例外をスローする
    • 「FileMissingException」例外はcatchでも補足

• 例外設定にカスタム例外「FileMissingException」を追加
  • [デバッグ] > [ウィンドウ] > [例外設定] で例外設定画面を表示
  • 今回は、①の「Common Language Runtime Exceptions」を選択
  • ②の追加「＋」がクリックできるようになるのでクリック

• 入力欄にカスタム例外の名称を入力（namespaceを定義している場合はnamespace名を付加）

• Debugモードで実行すると、例外のスローで実行が中断する

• Debugモードなしで実行すると、catchで補足される

Serilogも広く使用されており、NLog と同様にログレベル（Verbose, Debug, Information など）の切り分け・ログファイルの出力先・出力形式のカスタマイズなどが簡単に設定できるログライブラリです。

• 使用環境
  • Windows 10 Pro 2009 ビルド19045.5854
  • Visual Studio 2020 Version 17.14.2
  • Serilog 4.3.0

Visual Studio 2022 C# Serilogを使用した本格的なデバッグログ管理

Visual Studio C# Serilogの主な用途

1. デバッグ
   • Log.Debug()を使って変数の値や処理の流れを記録し、問題の特定を容易にする
2. エラートラッキング
   • Log.Error()やLog.Fatal()を使ってエラーメッセージやスタックトレースを記録し、原因を分析する
3. ユーザーアクションの記録
   • ログインやデータ更新の履歴をLog.Information()で記録し、監査やトラブルシューティングに役立てる
4. パフォーマンス監視
   • アプリケーションの処理時間を測定し、ボトルネックを特定する

Visual Studio C# Serilogのログ出力形式

Visual Studio C# Serilogのログレベル一覧（レベルの低い順）

Visual Studio C# Serilogの使用手順

NuGet Serilogパッケージのインストール

• ソリューションエクスプローラー画面の「プロジェクト」を右クリック→「ＮuＧetパッケージの管理」画面から下記のパッケージをインストールします。
  • Serilog　4.3.0
  • Serilog.Sinks.Console　6.0.0
  • Serilog.Sinks.Debug　3.0.0
  • Serilog.Sinks.File　7.0.0

■パッケージのインストール結果

Visual Studio C# Serilogの初期設定

アプリケーションの開始時、通常は「Main」やアプリケーションの初期化時にSerilogを設定します。

■設定例

 public Form1()
{
    InitializeComponent();
    // フォームを画面の中央に表示
    this.StartPosition = FormStartPosition.CenterScreen;

    //---------------------------------------------------------------------------------
    // Serilogの初期設定
    //---------------------------------------------------------------------------------

    // LoggerConfiguration インスタンスの作成
    Log.Logger = new LoggerConfiguration()

    // 出力先の設定　コンソール/デバッグウィンドウ/ログファイル
    .WriteTo.Console()
    .WriteTo.Debug()

    //rollingInterval: RollingInterval.Day ログファイルを日ごとに作成
　　//ログファイルにはWarningレベル以上のログが記録される
    .WriteTo.File(@"C:\temp\Serilog\serilog_code.txt", 
                restrictedToMinimumLevel: LogEventLevel.Warning, 
                rollingInterval: RollingInterval.Day)

    //コンソール・デバッグウィンドウには、Debugレベル以上のログが記録される
    .MinimumLevel.Debug()
    .CreateLogger();

}

• 出力先の設定
  • 本設定では、コンソールとデバッグウィンドウ及びログファイル
• 出力レベルの設定
  • 両方のウィンドウにはDebugレベル以上のメッセージを出力（.MinimumLevel.Debug()）
  • ログファイルにはWarningレベル以上のメッセージを出力（restrictedToMinimumLevel: LogEventLevel.Warning,）
• ログファイルの作成周期
  • 一日ごとに別ファイルとして作成（rollingInterval: RollingInterval.Day）

ログ出力先の設定例

• コンソール
  • .WriteTo.Console()
• デバッグウィンドウ
  • .WriteTo.Debug()　
• ファイル出力
  • .WriteTo.File(@”C:\temp\Serilog.txt”, restrictedToMinimumLevel: LogEventLevel.Warning,
    rollingInterval: RollingInterval.Day)
• SQL Server
  • .WriteTo.MSSqlServer(“Server=myServer;Database=myDB;User Id=myUser;Password=myPassword;”, “Logs”)
• Elasticsearch
  • .WriteTo.Elasticsearch(new Serilog.Sinks.Elasticsearch.ElasticsearchSinkOptions(new Uri(“http://localhost:9200”)))
• Syslog（Linux向け）
  • .WriteTo.Syslog()
• メール通知
  • .WriteTo.Email(new EmailConnectionInfo{FromEmail = “noreply@example.com”,ToEmail = “admin@example.com”,MailServer = “smtp.example.com”})
• Slack通知
  • .WriteTo.Slack(“https://hooks.slack.com/services/your/webhook/url”)

ファイル出力設定の主な設定項目一覧

ファイル出力設定では、さまざまなオプションを指定できます。以下に、主な設定項目を一覧にまとめました。

■設定例

• 下記設定では、1日ごとにログファイルを作成し、最大7日分保持、10MBを超えたら新しいファイルを作成するようになっています。
• また、Warning以上のログのみ記録され、バッファリングを有効化してパフォーマンスを向上させています。

Log.Logger = new LoggerConfiguration()
    .WriteTo.File("logs/log.txt",
        rollingInterval: RollingInterval.Day,　　// 日毎にログファイルを作成
        retainedFileCountLimit: 7,　　　　　　　 // ７日文のログを保持
        fileSizeLimitBytes: 10485760,　　　　　　// 10MBを超えたら新しいファイルを作成
        buffered: true,　　　　　　　　　　　　　// バッファリングを有効化
        flushToDiskInterval: TimeSpan.FromSeconds(5),　// ディスクへの書き込み間隔 5秒
        outputTemplate: "{Timestamp:yyyy-MM-dd HH:mm:ss} [{Level}] {Message}{NewLine}{Exception}",　 
　　　　　　　　// ログの表示例　2025-06-08 12:33:20 [Error] データベース接続エラー
　　　　　　　　// {NewLine}{Exception}：例外が発生した場合、詳細なスタックトレースを表示
        restrictedToMinimumLevel: LogEventLevel.Warning)　// Warning以上のログのみ記録
    .CreateLogger();

Visual Studio C# JSONファイルによるSerilogの設定

• 設定をJSONファイルで管理する利点
  • ソースコードを変更せずにログの設定が可能となる
  • 環境ごとに異なる設定を利用する事ができる（例：serilog.dev.json、serilog.prod.json等）

上記だけでも利便性は相当に高いと言えます。

■serilog.jsonの例

この設定では、コンソールにはＤebugレベル以上、ファイルにはWarningレベル以上のログを出力するようにしています。

{
  "Serilog": {
    "Using": [ "Serilog.Sinks.Console", "Serilog.Sinks.File" ],
    "MinimumLevel": "Debug",
    "WriteTo": [
      {
        "Name": "Console",
        "Args": { "restrictedToMinimumLevel": "Debug" }
      },
      {
        "Name": "File",
        "Args": {
          "path": "C:/temp/Serilog/serilog_json.txt",
          "rollingInterval": "Day",
          "restrictedToMinimumLevel": "Warning"
        }
      }
    ],
    "Enrich": [ "WithMachineName", "WithThreadId" ]
  }
}

設定手順

• serilog.jsonの作成
  • プロジェクトのルートディレクトリ（binフォルダの外）に作成します
    内容は上記通り。

• JSON設定の読み込み
  • C#のコードでJSONファイルを読み込むには下記のパッケージが必要となるので、NuGetパッケージからインストールします。
    • Microsoft.Extensions.Configuration.Json
    • Serilog.Settings.Configuration

• serilog.jsonファイルのプロパティ設定
  • ファイルを「右クリック」→「プロパティ」でプロパティを表示し、下記項目を設定
    • ビルドアクション：コンテンツ
    • 出力ディレクトリコピー：新しい場合はコピーする

• プロパティの設定の意味
  • ビルド時に設定ファイルを bin フォルダへコピー
  • 実行時に serilog.json を参照できる（アプリが正しくログ出力できる）
  • ファイルが変更された場合のみコピーされるため、不要な更新を防ぐ

Visual Studio C#　Serilog 動作確認

Serilogの「コード内」設定と「JSONファイル」設定も、下記の簡単なプログラムコードを実行して検証します。

• 設定した条件
  • コンソール画面には、Debugレベル以上のエラーを出力する
  • ログファイルには、Warningレベル以上のエラーを出力する

using Serilog;
using Serilog.Events;

//---------------------------------------------------------------------------------
// Serilogの初期設定
//---------------------------------------------------------------------------------
try
{ 
    // LoggerConfiguration インスタンスの作成
    Log.Logger = new LoggerConfiguration()

    // 出力先の設定　コンソール/デバッグウィンドウ/ログファイル
    .WriteTo.Console()
    .WriteTo.Debug()

    //rollingInterval: RollingInterval.Day ログファイルを日ごとに作成
    .WriteTo.File(@"C:\temp\Serilog\serilog_code.txt",
            restrictedToMinimumLevel: LogEventLevel.Warning,
            rollingInterval: RollingInterval.Day)

    //Debug 以上のログレベルのログが記録される
    .MinimumLevel.Debug()
    .CreateLogger();

    Log.Information("Information：コード内の、Serilog設定が適用されました。Fileには表示されない。");
    Log.Verbose("Verbose：ログに表示されないメッセージ。Fileには表示されない。");
    Log.Debug("Debug：プログラムが開始しました。");
    Log.Warning("Warning：警告エラーメッセージ");

    for (int i = 0; i < 10; i++)
    {
        int doubled = i * 2;
        //logger.Info($"NLog ループ {i}：2 倍の値 = {doubled}");
        Log.Debug($"ループ {i}：2倍の値 = {doubled}" + " Fileには表示されない。");
    }

    // 故意に例外を発生させるためのコード
    int val_1 = 10;
    int val_2 = 0;
    int result = val_1 / val_2;
}
catch (Exception ex)
{
    // 例外が発生した場合
    Log.Error(ex, "Error：アプリケーションでエラーが発生しました");
    Log.Fatal(ex, "Fatal：アプリケーションで致命的なエラーが発生しました");
}
finally
{
    // アプリケーション終了時のログ
    Log.Information("プログラムが終了しました");
}

Visual Studio C# コード内でSerilogを設定した場合

下記の出力結果を見ると、想定通りに動作した事が確認できました。

■コンソール画面への出力結果

■ログファイルへの出力結果

Visual Studio C# JsonファイルでSerilogを設定した場合

■コンソール画面への出力結果

■ログファイルへの出力結果

Visual Studio C# Serilog まとめ（NLogと比較して）

NLogとSerilogはどちらもC#のログ記録ライブラリとして広く使われていますが、それぞれに優れた点とデメリットがあります。

一般的に、NLogはレガシーシステムや高パフォーマンスを求めるアプリケーションで使われることが多く、Serilogはクラウド環境や構造化ログを活用するプロジェクトで人気があります。

最近では、Serilogの採用が増えている傾向があるようですが、用途によって適したライブラリを選択する事が重要です。

NLog は柔軟で高機能な .NET 用のログライブラリです。ログレベル（Info, Debug, Error など）の切り分け、ログファイルの出力先や形式のカスタマイズなどが簡単に設定できる便利なツールです。

• 使用環境
  • Windows 10 Pro 2009 ビルド19045.5854
  • Visual Studio 2020 Version 17.14.2
  • NLog 5.5

Visual Studio 2022 C#　NLogを使用した本格的なログ管理

• NLogの主な用途
  • デバッグ：開発時の挙動を把握し、エラーを素早く特定
  • エラートラッキング：アプリの異常動作を記録し、問題分析に役立つ
  • パフォーマンス監視：処理時間の記録やシステム負荷の検出
  • 運用ログ管理：ファイル、データベース、クラウドなど様々な場所へログ保存

• ログ出力形式

NLogの使用方法

NuGet パッケージからインストール

• ソリューションエクスプローラー画面の「プロジェクト」を右クリック→「ＮuＧetパッケージの管理」画面から下記のパッケージをインストールする。
  • NLog　5.5.0
  • NLog.Schema　5.5.0

• NLog.Schema
  • XML スキーマを提供し、設定ミスを防ぐ
  • 設定ファイルの構造をチェックし、誤ったタグや属性の使用を防止

■パッケージのインストール結果

NLog.config ファイルの作成

• NLog.configファイル とは
  • ログの出力方法（出力先・レベル・書式など）を XML 形式で定義し、アプリケーションのログ動作の制御を記述する

• 「NLog.config」ファイル をプロジェクトのルートフォルダに作成

• ファイルに下記内容（サンプル）をコピー

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<!-- 変数の設定 -->
  <variable name="logdir" value="c:\temp\nlog"/>

<!-- ターゲットの設定 -->
  <targets>
   <target xsi:type="File" name="filelog" fileName="${logdir}/logs/${shortdate}.log"
        layout="${longdate} ${uppercase:${level}} ${message}" />
   <target xsi:type="Console" name="consolelog"
	layout="${longdate} ${uppercase:${level}} ${message}" />
  </targets>

<!-- ルールの設定 -->
  <rules>
    <logger name="*" minlevel="Info" writeTo="filelog,consolelog" />
  </rules>
</nlog>

• NLog.configファイルを「右クリック」→「プロパティ」でプロパティ画面を表示し、下記項目を設定
  • ビルドアクション：コンテンツ
  • 出力ディレクトリコピー：新しい場合はコピーする

• プロパティの設定の意味
  • ビルド時に設定ファイルを bin フォルダへコピー
  • 実行時に NLog.config を参照できる（アプリが正しくログ出力できる）
  • ファイルが変更された場合のみコピーされるため、不要な更新を防ぐ

NLog.config ファイルの構成

「NLog.config」ファイルは、以下の３つの主要なセクションから構成されています。

• 変数 <variable>
• ターゲット <targets> → ログの出力先
• ルール <rules> → どのログレベルをどこに記録するか

変数 <variable>の設定方法

設定ファイル（NLog.config）内でよく使う値を変数として定義し、再使用するための機能。
ログの出力先フォルダ名やファイル名などを変数化することで、メンテナンス性・可読性が向上する。

■基本構文

<variable name="変数名" value="値"/>

■具体例

• 下記の様に定義した変数は、NLog.configファイル内で ${logDir} のように参照できます。

<variable name="logDir" value="logs" />

■よく使用する変数パターン

ターゲット <targets>の設定方法

ターゲットは、「ログの出力先（どこにログを書き出すか）」を定義するセクションです。

ログの出力先はファイル、コンソール、データベース、メール、デバッグウィンドウなど多岐にわたり、それらを「ターゲット」と呼びます。

■基本構文

下記は、「xsi:type=”File”」で出力先をファイルとし、「fileTarget」という識別名で、log.txt ファイルに　ログを出力するターゲットを定義しています。

• type：出力先
• name：定義した本<targets>の識別名
• fileName：出力先が、”File” の場合のログファイル名称

  <targets>
    <target xsi:type="File" name="fileTarget" fileName="log.txt" />
  </targets>

■よく使われるターゲット（出力先）の種類

■具体例（File）

• 変数<variable>との関係も併せて説明

<variable name="logDir" value="logs" />

<targets>
  <target xsi:type="File"
          name="fileTarget"
          fileName="${logDir}/app.log"
          layout="${longdate}|${level}|${logger}|${message}" />
</targets>

• fileName：出力ファイル名（変数値を使用したので出力先は、”logs/app.log” となる）
  ${logDir}を使用する事で、ログの出力先を一括で変更できる。
• layout： ログの出力フォーマット（テンプレート文字列）

• Fileの出力例

2025-06-05 20:00:00.0000|INFO|MyApp.Main|アプリ起動

■具体例（Debug）

Visual Studio の「出力ウィンドウ」にログが表示されるので、開発中の動作確認に便利です。

<targets>
  <target xsi:type="Debug"
          name="debugTarget"
          layout="${longdate}|${message}" />
</targets>

■layout のカスタマイズ

layout 属性では、以下のような変数を使ってログ出力内容を柔軟に構成できます。

ルール<rules>の設定方法

<rules>はどのログレベルをどこに記録するか を定義します。

■基本構文

下記のサンプルは、後で「writeTo」を説明する為に<targets>も含めています。

<targets>
    <target xsi:type="File" name="filelog" fileName="${logdir}/logs/${shortdate}.log"
        layout="${longdate} ${uppercase:${level}} ${message}" />
	
	<target xsi:type="Console" name="consolelog"
		layout="${longdate} ${uppercase:${level}} ${message}" />      
</targets>

<rules>
    <logger name="*" minlevel="Info" writeTo="filelog,consolelog" />
</rules>

• name
  • <targets>で指定するnameの名称を指定する。name=”*” は、全ての<targets>に適用

• minlevel
  • どのレベル以上のログを記録するかを指定
    • minlevel=”Info”は、”Info”,”Warn”,”Error”,”Fatal”レベルを出力する。

• writeTo
  • ログの出力先を指定 する為、<target>で定義されている name の名称を指定します。サンプルでは、”filelog,consolelog” と指定している為、ログファイルとコンソールの両方に出力します。

Visual Studio C#　NLog　動作確認

本ブログで使用した「NLog.config」を使用して、実際に以下の簡単なコンソールアプリをReleaseモードで動かしてみました。

// See https://aka.ms/new-console-template for more information

using NLog;

namespace Console_Test
{
    class Program
    {
        // ロガーを定義（クラススコープで静的に）
        private static readonly Logger logger = LogManager.GetCurrentClassLogger();

        static void Main(string[] args)
        {
            try
            {
                logger.Trace("Trace：トレースログ　ログに表示されない。");
                logger.Debug("Debug：デバッグログ　ログに表示されない。");
                logger.Info("Info：テストプログラムが開始しました。");
                logger.Warn("Warn：警告エラーメッセージ");

                for (int i = 0; i < 10; i++)
                {
                    int doubled = i * 2;
                    logger.Info($"NLog ループ {i}：2 倍の値 = {doubled}");
                }

                // 故意に例外を発生させるためのコード
                int val_1 = 10;
                int val_2 = 0;
                int result = val_1 / val_2; 
            }
            catch (Exception ex)
            {
                // 例外が発生した場合はエラーログを記録
                logger.Error(ex, "Error：アプリケーションでエラーが発生しました");
                logger.Fatal(ex, "Fatal：アプリケーションで致命的なエラーが発生しました");
            }
            finally
            {
                // アプリケーション終了時のログ
                logger.Info("アプリケーション終了が終了しました");
            }  
        }
    }
}

下記の出力結果を見ると、想定通りに動作した事が確認できました。

• TraceとDebugレベルのメッセージは表示されない
• コンソールとログファイルの両方に出力された

■コンソール画面への出力結果

■ログファイルへの出力結果

「Visual Studio C#」 NLog まとめ

NLogはXML設定ファイルを使った構成が得意でリリース後にログ設定を変更し易い為、長期運用されるシステムでの使用が今後も続くでしょう。

NLogと同様にC#のログ記録ライブラリとして広く使われているライブラリに、Serilogがあります。こちらはSerilogはクラウド環境や構造化ログを活用するプロジェクトで人気があります。

最近では、Serilogの採用が増えている傾向があるようですが、用途によって適したライブラリを選択する事が重要です。

Serilogについては「Serilogの使用方法を徹底解説」を御覧ください。

変数値の確認方法は使用場面や目的に合わせて様々な方法があります。適切な方法を使用する事で効率的なデバッグが可能となります。

※デバッグ時はDebugモードで実行して下さい。
※Visual Studio 2020 Version 17.14.2 を使用

Visual Studio 2022 C# ブレーク時に値を確認する方法

マウスホバーで確認

変数にマウスを合わせると現在の値をポップアップで表示してくれます。下記の例では、変数「Txt_a」の値は”10″。コレクションやオブジェクトの場合、展開して内容も確認できます。

• 用途例
  • 変数や式の現在値をすばやく確認したい
  • プロパティやフィールドの中身をドリルダウンで展開して確認したい

• 変数値確認手順
  • 変数にマウスを合わせる

• ポップアップのピン止め
  • ポップアップ左側の▷をクリックすると、ポップアップをピン止めする事が可能です。ピン止めしておけば、次回実行時の値もそのままで確認できます。

QuickWatch（クイックウォッチ）

デバッグ中に変数や式の評価結果を一時的に詳しく確認できるウィンドウです。特に複雑な式やオブジェクトの内容をじっくり調べたいときに便利なウィンドウです。

• 用途例
  • 構造体・クラスなど複雑なオブジェクトの中身を展開表示で確認
  • 条件式やプロパティチェーンなどの式を即時評価

• QuickWatch を開く手順
  • ①変数や式を選択して右クリック →「クイックウォッチ」
  • ②メニュー [デバッグ] → [ウィンドウ] → [クイックウォッチ…]　等

①の関数呼び出しを選択　→　「右クリック」→「クイックウォッチ」で結果が表示

ローカルウィンドウ（スコープ内変数値の確認）

現在のスコープ内で定義されているすべてのローカル変数を一覧で確認できるウィンドウです。

• 用途例
  • 現在スコープ内の変数を一括で確認したい
  • ループ中・条件分岐中の変数の動きを追跡

• ウィンドウ表示手順
  • ブレーク中　→　メニュー「デバッグ」→「ウィンドウ」→「ローカル」

Watchウィンドウ（任意の式・変数を登録）

監視したい変数や式を追加し、値の変化を継続して監視できるウィンドウです。

• 用途例
  • 重要な変数やオブジェクトの集中監視
  • 値の変化を逐次確認
  • スコープをまたいでの監視

• ウィンドウ表示手順
  • ブレーク中　→　メニュー「デバッグ」→「ウィンドウ」→「ウォッチ」→「ウォッチ1～4」
  • ①ウォッチしたい変数を入力
  • ②ウォッチウィンドウの切り替え

自動変数ウィンドウ（最近使われた変数）

現在および直前の行で使われている変数を自動で表示するウィンドウです。

• 用途例
  • カーソルのある行付近で「使用」「代入」「参照」された変数の確認
  • 「関係のない変数」の表示にデバッグ作業を妨げられたくない 等 etc.

• ウィンドウ表示手順
  • ブレーク中 　→　メニュー「デバッグ」→「ウィンドウ」→「自動変数」

■現在ブレーク中の変数「b」と直前の変数「a」が表示されています。

イミディエイトウィンドウ（その場で式を評価）

対話的にコマンドや式を入力できるウィンドウです。C# の式やメソッド呼び出し、変数参照などをリアルタイムで実行して結果を確認したり、値の変更やオブジェクト操作も可能です。

• 用途例
  • デバッグ中に任意の変数やプロパティの現在の値を確認
  • 変数の値をその場で変更して動作確認が可能
  • 計算式（例：a + b、list.Count > 0など）の評価　等 etc.

• ウィンドウ表示手順
  • ブレーク中　→　メニュー[デバッグ] → [ウィンドウ] → [イミディエイト]

イミディエイトウィンドウでは ? をつけなくても構いませんが、

• 結果を見たい → ? をつける
• 単に処理・代入だけしたい → つけない

というルールで使い分けると良いでしょう。

コマンドウィンドウ

デバッグ中や開発中に Visual Studio のコマンドやデバッグ機能を実行するための特別なインターフェースです。

デバッグ中の変数値の確認やコード操作をコマンド形式で実行できます。コマンドを使わず変数値の確認用として使用するならば、イミディエイトウィンドウで十分でしょう。

• 用途例
  • 現在の変数値の表示やメソッド呼び出しを実行（イミディエイトウィンドウと似た使い方）
  • コードの検索・移動、マクロ実行
  • Build.Solution や Debug.Start などの IDE コマンドを直接実行

• ウィンドウ表示手順
  • メニュー「表示」→「その他のウィンドウ」→「コマンドウィンドウ」

■コマンド「Debug.Start」でデバッグを開始し、変数の値を確認

プログラム動作中に値を確認する方法

Console.WriteLine() で出力

Console.WriteLine() は、C# において標準出力（通常はコンソール画面）に文字列や数値などを出力するためのメソッドです。

開発中のデバッグやログ出力、ユーザーへの情報表示など幅広く使われます。

• 用途例
  • デバッグ出力
  • 開発初期段階での簡易ログ記録　等 etc.

• 表示の仕方
  • Console.WriteLine(値または文字列);

■下記はループを100回繰り返し、ループカウンタの２倍の値をConsole.WriteLine()で出力しています

■Console.WriteLine()の出力結果

System.Diagnostics.Debug.WriteLine()

デバッグ中に出力ウィンドウへメッセージを表示するために使用します。

Console.WriteLine() と異なり、GUIアプリケーションや WinForms、WPF のような環境でもコンソールを開かずに出力確認が可能です。

• 用途例
  • デバッグログとして変数値や処理の流れを等を出力
  • 条件分岐や例外の追跡　等

• 表示の仕方（Debug.WriteLine() の出力は「出力ウィンドウ」に表示）
  • アプリを「デバッグモード」で実行（F5）
  • メニュー → 表示 → 出力（または Ctrl + Alt + O）　等

■System.Diagnostics.Debug.WriteLine()のコード

■「デバッグ実行」で、出力ウィンドウへメッセージを出力

Trace.WriteLine()

デバッグモード/リリースモードの両方で、出力ウィンドウにメッセージを表示します。

• 用途例
  • システム全体の挙動をトレース（追跡）
  • リリースビルドでもトレースしたい

• 出力ウィンドウ（デフォルト）
  • アプリを「デバッグモード」で実行（F5）
  • メニュー → 表示 → 出力（または Ctrl + Alt + O）　等

■Releaceモードでビルド

■デバッグ実行

まとめ

デバッグ時の変数値を画面上で確認する方法を色々と紹介してきましたが、これらの方法は、「いつ」「どこで」「何のために」変数の値を確認したいかという目的に応じて、選び分けることが大切です。

• 特定の変数や式を継続的に追跡したい → ウォッチ／自動／ローカルウィンドウ
• 画面で直接見たい → Console.WriteLine(), Debug.WriteLine(), Trace.WriteLine()
• 実行中にその場で調べたい → イミディエイトウィンドウやウォッチウィンドウ

Visual Studioは可視化・監視だけでなく、実行中にその値を変更することまで可能です。これを活用できるようになると、バグの発見・解決スピードが格段に向上し、より安定したアプリケーション開発が行えるようになるでしょう。

ブレークポイントの設定には様々な方法が有り、使用場面に合わせて適切な方法を使用する事で効率的なデバッグが可能となります。

※デバッグ時はDebugモードで実行して下さい。
※Visual Studio 2020 Version 17.14.2 を使用

Visual Studio 2022 C# ブレークポイントの基本設定

特定の行で必ず停止したい場合

この行が実行される都度 必ず停止する設定。（●が表示される）

• 用途例
  • プログラムがどのように実行されるか、1行ずつ確認したい
  • その時点での変数やオブジェクトの内容を確認したい
  • 決まった場所で発生する例外直前の状態を観察したい　等 ext.　

• 設定手順
  • 行の左側をクリックするかF9を押下

条件付きブレークポイント

特定の条件に合致した場合にのみ停止

「特定の条件のときだけ止めたい」という場合は、条件付きブレークポイントが便利。

• 用途例
  • ループ中、○○回目でブレークしたい
  • エラーが起きそうな特定の入力のときだけ確認したい　等 etc.

• 設定手順
  • ブレーポイントを設定後、「設定」をクリック
    ※ブレークポイントの赤丸にカーソルを合わせると、「設定」「無効にする」が表示される
  • 「条件」をチェックし「例:x==5」の欄に「i==50」を入力して条件を確定させる

• 条件の設定

• ブレークポイントの形が「条件付き」の形になる

ヒットカウント付きブレークポイント

ループ処理等で停止条件を複数指定できる

通常のブレークポイントは「毎回」停止しますがヒットカウント付きにすると、

• 10回目だけ止める
• 50回目以降は毎回止める
• 3回目ごとに止める

といった制御が可能になる。

• 用途例
  • 大量ループの内、○○○○番目だけを停止したい
  • 「3回目に必ず失敗する」など特定パターンを再現するために使う
  • 同じ関数が複数回呼ばれるケースで、５回目だけ調査したい　　等 etc.

• 設定手順
  • 「条件」をチェックし「ヒットカウント」を選択
  • ①の条件を選択
  • ② ①の条件に対応する数値を入力

アクション付きブレークポイント

プログラムを停止しないで出力ウィンドウにメッセージを表示

「アクション付きブレークポイント」は「ログ代わり」として活用できます。Console.WriteLine を入れずに確認したいときや、デバッグ中に処理を止めたくない場合に有効。

• 用途例
  • 毎回止めずに変数の状態ログを取りたい
  • ソースコードを書き換えずに、一時的にログを仕込んで調査したい場合
  • 再現の難しいバグに対して、処理フローや変数値の流れを記録したい　等 etc.

• 設定手順
  • ブレークポイント設定後 　→　「設定」でアクションをチェック
  • メッセージ表示欄に表示したいメッセージを入力
  • コード実行のチェックは外さない（外すと実行が停止する）
  • 「閉じる」をクリックして確定

一度ヒットしたブレークポイントの無効化

ブレークポイントが一度だけ発動したら自動で無効化

最初の一度だけブレークし２回目以降はブレークしない機能。

• 主な用途
  • 初回だけ変数や状態を確認したい
  • テストデータの初回通過時だけ追いたい
  • 再現性のあるバグに対して初回のみの挙動に注目して調査したい　等 etc.

• 設定手順
  • ブレークポイント設定後 　→　「設定」で「一度ヒットしたブレークポイントを無効にする」をチェック
  • 「閉じる」をクリックして確定

他のブレークポイントにヒットした場合のみ停止

他の指定したブレークポイントで停止したら有効となる

これは、指定した「別のブレークポイント(A)」が先にヒットした場合に限って、現在のブレークポイント(B)を有効にするという設定。

• 用途例
  • ある関数を経由して別の処理が呼ばれたときだけ調べたい
  • 複数の経路から呼ばれる共通処理で、特定経路のみ追いたい
  • 特定の分岐を通ったあとの挙動だけ調査したい　等 etc.

• 設定手順
  • 別のブレークポイント(A)を設定
  • Aで停止した後で停止したいコードにブレークポイントを設定
  • 「設定」で「次のブレークポイントにヒットした場合のみ有効にします」をチェック
  • 次のブレークポイントにAを選択
  • 「閉じる」をクリックして確定

関数ブレークポイント

指定した関数名の関数が呼び出されたら停止

関数名を指定してその関数に入ったときにブレークする機能。コード上で場所を探す必要がなく、対象関数の呼び出しを瞬時に捕まえることができる。

• 用途例
  • 呼び出し元が不明な関数を調べたい
  • オーバーロード関数の特定引数を追いたい
  • コードのリファクタリング時の影響調査　等 etc.

• 設定手順
  • メニュー「デバック」→「ウィンドウ」→「ブレークポイント」でブレークポイントウィンドウを表示
  • メニュー「デバック」→「ブレークポイントの作成」→「関数のブレークポイント」
  • 表示された入力ボックスに「関数名」やブレーク条件を入力して「OK」
    →　「ブレークポイントウィンド」に関数名が表示される

• 関数のブレークポイント指定画面を表示

• ブレークする関数名とブレークの条件を指定

• ブレークポイントウィンドウに「ブレーク関数名称」とブレーク条件が表示される

ブレークポイントの無効化/有効化

ブレークポイントを一時無効にして再度有効にする

一時的にブレークポイントの動作をオン／オフできる便利なデバッグ機能。

• 用途例
  • 複数のブレークポイントを切り替えて検証したい
  • デバッグの条件ごとに無効化したり有効にしたい　等 etc.

• 設定手順
  • マウスをブレークポイントの赤丸に合わせ「無効にする」を選択
    →　ブレークポイントが「無効」の形になり、条件が合致しても停止しなくなる
  • 再度有効にしたい場合は、ブレークポイントにポインタを合わせ「有効にする」を選択

• ブレークポイントが「無効」の形になる

• 有効にする

前回同様、Udemyで人気の「ピーコックアンダーソン氏」が作成した「VisualStudioでGit＆GitHubを使ってソースコードを管理する方法【C#】」を参考にし、私見を交えながらの説明です。

Visual Studio 2022 GitHubの役割

GitHubはチーム開発におけるソースコード管理に適したサービスで、クラウド上でソースコードを管理・共有できるシステムです。

各個人のソースコードをGitHubで管理する事により以下の事が可能となります。

1. チーム内各個人のソースコード履歴管理ができる（誰が・いつ・何を変更したか）
2. チームによる開発がスムーズに行える
3. クラウド上でソースコードを安全に保存できる
4. Web上でコードを閲覧・レビュー・コメントできる

GitHubを利用した開発の手順

GitHubに自分のアカウント登録する

• GitHub登録画面を表示
  開発者のためのプラットフォーム

• 「GitHubに登録する」ボタンをクリックして以下を入力
  • メールアドレス
  • パスワード
  • ユーザー名
  • あなたの国/地域
• 質問に回答してロボットでない事を証明
• 「Create account」ボタンをクリック
• Codeの入力
  • 登録したメールアドレスに届いているメールを見てCodeを入力する
• 「GitHubへのサインイン」
  下記の「サインイン」画面が自動表示されるので必要事項を入力して「Sign in」をクリック

• GitHubのダッシュボードが表示されればアカウントの作成は完了

GitHubへのソースコード登録

• 下記の「加算」「減算」を行うC#プログラムを登録する

GitHub リモートリポジトリの作成

• メニュー「Git」→「Gitリポジトリの作成」

• 「GitHub」を選択
• アカウントで「GitHub」のアカウントを指定する
  • 「GitHub」へのサインイン画面が表示されるのでサインインする
  • リポジトリ名は変更しても良いがこのままとする
  • 表示範囲を「Private」にする
    • 作成者と指定したメンバーのみが使用可能となる
    • 「public」はインターネット上のユーザーがアクセス可能
    • 「Internal」は同じEnterprise内の全メンバーがアクセス可能
      無料版のでは利用できない
• 「作成とプッシュ」をクリック

• メッセージも表示されますが、画面左下の「準備完了」をクリックしても「作成とプッシュ」が成功した事を確認できます

Visual Studioのアカウントを複数持っている場合

私の場合「作成とプッシュ」をクリックすると、下記のメッセージボックスが表示されました。使用したい「アカウント」を選択して「Continue」をクリックすると処理は続行できましたが、原因として考えられるのは、

• Visual Studioに複数アカウントが登録されている
• Visual StudioとGitHubアカウントのリンクが不一致又は不完全

Visual Studioのアカウントを調べてみると、「Kemmy-Git」とは別のアカウントで使用していました。Visual Studioを複数のアカウントで使用していたのが原因だったようです。

GitHubでのリポジトリとソースの確認

GitHubにサインインしてみると、「GitHub_Test_A」というリポジトリが「Private」で作成されており、「Form1.cs」のコードもプッシュされている事が確認できます。

• リポジトリ「GitHub_Test_A」

• 公開範囲は「Private」

• ソースの内容も確認できる

GitHub リモートリポジトリへのメンバー招待

本PCでC#プロジェクトを作成しGitHubのリモートリポジトリを作成しましたが、他のメンバーがGitHubからリポジトリ「GitHub_Test_A」を取り込む手順を紹介します。

招待者側の作業

• 自分のアカウントでGitHubに入り、Settings タブの「Collaborators」クリック

• Manage access の項目で、「Add people」をクリック

• 検索欄に招待したいメンバーのアカウントを入力すると候補者が表示される

• メンバーを選択して「Add Kemmy-it」をクリックすると、「Kemmy-it」通知が届く

• 「 Kemmy-it」からの回答待ち状態

招待される（Kemmy-it）側の作業

• 通知を開く

• ケミー-Gitからの招待通知を確認

• 通知を開いて「招待を承諾する」をクリック

• 招待された「Kemmy-it」のGitHub上で、リポジトリ「GitHub-Test_A」が参照できるようになる

GitHub リモートリポジトリからのソースコード取得

招待された「Kemmy-it」のローカルPCには、「GitHub_Test_A」のソースがないので、GitHubからソースを取得します。

• Visual Sutudio 2022 を起動し「リポジトリのクローン」をクリック

GitHubのどこから、ローカルPCのどこへクローンするかの設定を行います

• ①「GiuHub」を選択
• ②自身のアカウント（招待された側）である事を確認
• ③クローンするリポジトリのURLを指定
• ④ローカルPCのクローンするフォルダを指定
• ⑤「クローン」ボタンをクリック

• コンテンツに鍵マークの付いたリポジトリをローカルPCにクローンできました

GitHub リモートリポジトリへのソースコード変更の反映

Gitローカル環境ではソースを変更した後「コミット」すれば変更は反映されましたが、GitHubのリモートリポジトリに変更を適用させるには更に「プッシュ」という作業が必要です。

• ローカルリポジトリのソース変更（messageBox を追加）
• メニュー「表示」→「Git変更」→「すべてをコミット」でコミット

• メニュー「Git」→「ブランチの管理」を表示し「プッシュ」　

• GitHubリモートリポジトリのソース内容に
  • 「MessageBoxの追加」で変更したソースが反映されている

• 同期
  • 「プッシュ」の右側にある「同期」は、「プル」と「プッシュ」を連続して実行する機能

他メンバーの変更内容を取得する

上記の変更内容を「Kemmy-it」が、自分のローカル環境に取り込む手順を紹介します。他のメンバーがソースを変更しているか確認「フェッチ」してから取り込み「プル」します。

• 「Kemmy-it」側でVisual studio 2022を起動し「GitHub_Test_A」リポジトリを開く
• メニュー「Git」→「ブランチの管理」でブランチの管理画面を表示
• 「フェッチ」をクリックしてソースに変更があるか確認
  変更があると下記のように、受信(1)となり「MessageBoxの追加」の変更がある事が分かります

• 自分「Kemmy-it」のソースに変更内容を反映させる為、「プル」をクリックします
  リポジトリが更新されたというメッセージと、「MessageBoxの追加」のコミットが「master」に反映された事が分かります

• 「Kemmy-it」のソースを確認すると「MessageBox」のソースが追加されています。

競合の解決方法

他のメンバーが修正して「プッシュ」したソースコードの同一箇所を、自分が修正して「プッシュ」するとどうなるでしょうか？

実際に試してみましょう。

• Kemmy-itのソースコードを下記の様に変更して、プッシュしておきます。

• Kemmy-Git側のソースコードを下記の様に変更し、コミットします

• 「メッセージボックスのテキスト変更」がコミットされました。

• そのままプッシュすると下記のエラーがでます。
  「ローカルブランチ」が「リモートブランチ」の背後にあるため、リモートリポジトリにプッシュできません。プッシュする前にプルすることによりブランチを更新して下さい。

つまり、自分がプルした後に「リモートブランチ」に変更がされている為、プルしてからプッシュして下さいという意味です。「キャンセル」でエラーを閉じます。

それでは、プルしてみます。

プルすると、「GitHub_Test_A」リポジトリで競合が発生しました。競合を解決してから結果をコミットして下さい。というエラーが表示されます。

競合が解決していない箇所を調べます。「競合を解決」のリンクをクリックすると、Git変更画面に[両方変更]というクラスが表示されるので、そのクラスをクリックします。

GitHub側と、自分の変更内容が表示されるので、

• ①正しい変更をチェックする（両方でも良いがチェックの早いコードが上になる）
• ②選択の結果を確認して
• ③マージする

マージされた結果を確認したら、「すべてをコミット」

「コミット」しただけなので、GitHub上のソースは変更されていません。

その後、「競合をマージした結果」を「プッシュ」すると、変更内容がGitHubに反映されます。

【参考文献】

ソフトウェア開発の現場で広く使われており、コードやファイルの変更履歴を管理し、複数人での共同開発を効率化します。

本ブログは、Udemyで人気の「ピーコックアンダーソン氏」が作成した、「VisualStudioでGit＆GitHubを使ってソースコードを管理する方法【C#】」を参考にし、自分なりにGitを操作した手順と少しの考察を紹介します。

Visual Studio 2022 Gitによるバージョン管理の基本手順

1. ローカルリポジトリの作成
   各自のパソコン内に、ソースとソースの変更履歴を保存する領域（ローカルリポジトリ）を作成する
   
   
2. 変更履歴のコミット
   変更履歴をローカルリポジトリ内のに記録（コミット）する
   
   
3. ブランチの作成（必要な場合）
   新機能を追加する場合等、変更履歴の流れを分岐させ、上手くいけばブランチを統合（マージ）し、うまくいかない場合はブランチを切り捨てる
   
   
4. 各自のリポジトリを同期する
   • GitHub上に各自がアクセスできる「リモートリポジトリ」を作成
   • 各自が「リモートリポジトリ」へ変更をプッシュし、且つ「リモートリポジトリ」からプルしてローカルリポジトリを同期させる
     
     
5. リベースやリバートで履歴を整理する
   • リベース
     • 変更履歴を直線的に保つためコミット履歴を再整理します。
   • リバート
     • 新しいコミットを追加することで履歴を「逆転」させ、特定の変更を無効にします。リセットとは異なり「逆転」前の履歴も保持されます。
       
       

Gitのインストールと初期設定

Gitのインストール

• Visual Studio を「コードなしで続行」

• メニューの「ツール」→「ツールと機能を取得」
• 「個別コンポーネント」タブで Git を検索し「Git for Windows」にチェック
• 「変更ボタン」をクリックしてインストール

• Gitのインストール確認
  コマンドプロンプトで、「git –version」と入力しバージョン番号が表示されればOK

ローカルリポジトリ　Git使用手順

• 使用環境
  • Windows 10 Pro　2009
  • Visual Studio Community 2022　17.14.0

• 簡単なC# Windows Formアプリ「Git_Test_A」(.NET Windows)を作成して手順を説明します
  • サンプルプログラム
    入力欄A、Bに数値を入力し「加算」又は「減算」ボタンをクリックしたら結果を「回答欄」に表示

ローカル Gitリポジトリの作成

• メニュー「Git」→「Gitリポジトリの作成」

• 「ローカルのみ」を選択し「作成」ボタンをクリック

• 画面左下の「NuGetパッケージをクリック」して「正常に作成されました」のメッセージが表示されれは作成は成功

• Gitに管理されている項目には、キーマークが付く

変更内容の確認

• ソースを変更したコンテンツには✔マークが付いて変更の差分を確認できる
  • 掛け算のコードを追加

• 差分の表示
  変更されたコンテンツを右クリック⇀「Git」→「未変更のものと比較」

• 左側が変更前、右側が変更後

コミット前の変更内容取り消し

• サンプルプログラムに「Aの二乗」を追加したが、不要なので変更を取り消す
  • 取り消し前

• ①「Form1.cs」を右クリック ⇀ ②「Git」→「変更を元に戻す」

• 取り消し後
  変更コンテンツの✔マークも消えている

変更内容の確定　コミット

• メニュー①「表示」→②「Git変更」
• ③に変更されたコンテンツが表示されるので確認
• ④に変更内容を入力
• ⑤「全てをコミット」ボタンでコミット

コミットの確認

• メニュー①「表示」→②「Gitリポジトリ」をクリック
  ③のコミットの履歴が表示される。プロジェクトを作成してから「掛け算の追加」と「割り算の追加」がコミットされているのが確認できる。

コミットの内容確認

コミットの履歴で、「割り算の追加」の青い〇をクリックすると、変更内容が確認できる。

コミット後の取り消し

サンプルプログラムに「Aの二乗」と「Bの二乗」をコミットした後、「Aの二乗」までに戻りたい場合

• メニュー「表示」→「Gitリポジトリ」で現在のコミット状態を表示

「Bの二乗」のコードを残したままコミット取り消す

• 「Aの二乗」を右クリック⇀「リセット」→「変更を保持」

• 「Bの二乗」のコミットは消えたがソース変更の✔は付いており、「Forms.cs」を確認すると「Bの二乗」のコードは残っている。

「Bの二乗」のコードも削除してコミット取り消し

• 再度「Bの二乗」をコミット
• 「Aの二乗」リポジトリを右クリック⇀「リセット」→「変更を削除」

「Bの二乗」のコミット・ソース変更の✔・「Bの二乗」のコードが全て削除された。

ブランチの利用

ブランチの目的

ブランチは「master（本流）」に影響を与えずに、枝分かれして作業する為に作成します。主な目的は、

1. 機能追加や修正を独立して行う
2. バグ修正やホットフィックス
3. 同時に異なる機能や修正を開発する
4. 長期的なプロジェクト管理
5. 実験的な機能をテスト　etc.

ブランチの作成

最初は「master」しかないので、「master」からの分岐になります。

• 作成手順
  • ①「master」のどのコミットからブランチするのか指定
  • ②メニュー「Git」→「新しいブランチ」→「新しいブランチの作成」→ ダイアログ表示
  • ③「ブランチ名」を入力
  • ④「ブランチのチェックアウト」のチェックを確認
    • 「ブランチのチェックアウト」のチェックが入っていないとブランチ作成後、新しいブランチに分岐できない
  • ⑤「作成」をクリック

コミット「割り算の追加」からブランチ「Git_Test_A_2」が作成されました。現在どのブランチを操作しているかは、画面右下からも確認できます。

ブランチのコード変更とmasterの状態

ブランチ「Git_Test_A_2」のコードを変更し、「master」に影響がない事を確認します。

• 各計算ボタンをクリックした時に「ブランチ名」を表示する変更を加え、コミット

■ブランチ「Git_Test_A_2」のコード

• 「master」にはブランチ「Git_Test_A_2」のコード内容が反映されていない。

ブランチの統合

ブランチの統合例として、以下の要件で統合してみます。

1. ブランチ「Git_Test_A_2」の「割り算の追加」からブランチ「Git_Test_A_３」を作成
2. ブランチ「Git_Test_A_３」の各演算に「ブランチ「Git_Test_A_３」実行」のメッセージボックスを追加
3. ブランチ「Git_Test_A_2」にブランチ「Git_Test_A_３」を統合する

■ブランチ「Git_Test_A_３」

• 「ブランチ「Git_Test_A_３」加算実行」のメッセージボックスを追加

ブランチの統合手順

• ①統合先のブランチ「Git_Test_A_2」を表示
• ②統合するブランチ「Git_Test_A_3」をリポジトリ画面で右クリック
• ③「’Git_Test_A_3’を’Git_Test_A_2’にマージする」をクリック

ブランチ「Git_Test_A_3」でコミットした変更が、「Git_Test_A_２」に表示され、統合された。

ブランチ「Git_Test_A_2」ソースコード。「Git_Test_A_3」で追加したコードが統合されている。

フォームの統合

フォームの統合は可能ですが、マージの競合が発生し解決する事が難しい場合もあります。その理由としては、

• フォームの構造が異なる
  • マージ時に.Designer.csファイルの自動生成コードが破損しているケースが多い
• 手動編集が混在
  • WinFormsのデザイナからではなく、手動でコードを変更した場合に競合が発生しやすい
• Visual Studioのキャッシュ問題
• .Designer.csファイルは自動生成コードのため、手動での解決が難しい

※私の場合、他のプログラムで「GitHub Copilot」の力を借りて何とか統合する事ができました。

ローカルブランチの削除

• ブランチ削除の前提
  • 現在使用していないブランチであること（チェックアウトしていない）。
  • マージが完了していること（削除後に復元が困難なため）。
  • ローカルとリモートでは異なる操作が必要です

ブランチ「Git_Test_A_3」の削除

• 手順
  • ブランチ管理ウィンドウを表示します。
  • 削除したいブランチを右クリック
  • [削除] を選択
  • 確認ダイアログが表示されるので、「OK」をクリックします。

【参考文献】

次回、GitHubリモート編をお届けします。