はじめに：.NETバージョン取得は「どんなエンジンで走っているか」を知るためのもの
同じ C# コードでも、 どの .NET ランタイムバージョン で動いているかによって、 使える API や挙動、パフォーマンスが変わります。
「開発環境では .NET 7、本番はまだ .NET 6」 「古い .NET Framework 上で動いていて、新しい構文が使えない」
こういうズレがあると、 「開発では動くのに本番で落ちる」「ドキュメント通りに動かない」 ということが起きがちです。
だからこそ、コードから .NET のバージョンを取得してログに残せるようにしておくことが、 業務・実務ではかなり重要になります。
ここでは、初心者向けに
Environment.Versionで取れる「ランタイムバージョン」- 実務で使える「.NETバージョンダンプユーティリティ」
- どんな場面で .NET バージョン情報が効いてくるか
を、例題付きでかみ砕いて説明します。
基本の .NETバージョン取得：Environment.Version
「今このプロセスが乗っている .NET ランタイム」を知る
一番シンプルな方法は、System.Environment.Version を見ることです。
public static void ShowDotNetVersion()
{
Console.WriteLine($".NET Runtime Version: {Environment.Version}");
}
これで出てくるのは、 「このプロセスが実際に動いているランタイムのバージョン」です。
例えば、.NET 7 で動いていれば、 7.0.xxxx.x のようなバージョンが表示されます。
ここでの重要ポイントは、 「これは“ランタイムのバージョン”であり、“ターゲットフレームワーク”とは別物」 だということです。
プロジェクトの TargetFramework が net7.0 でも、 実際に動いているランタイムが違えば、挙動も変わります。
「このコードは .NET 7 前提で書いているのに、 本番サーバーでは古いランタイムで動いていた」 という事故を防ぐために、 Environment.Version をログに残しておくのはとても有効です。
実務で使える「.NETバージョンダンプユーティリティ」
起動時や重大エラー時に、まとめてログに残す
毎回 Environment.Version を単発で見るのではなく、 「環境情報の一部として .NET バージョンをまとめてログに残す」 形にしておくと、実務で使いやすくなります。
ILogger と組み合わせたユーティリティの例です。
using System;
using Microsoft.Extensions.Logging;
public static class DotNetVersionLogger
{
public static void LogDotNetVersion(ILogger logger, string context)
{
var runtimeVersion = Environment.Version;
logger.LogInformation(
"DotNetInfo Context={Context} RuntimeVersion={RuntimeVersion}",
context,
runtimeVersion);
}
}
使い方の例です。
// アプリ起動時に一度だけ
DotNetVersionLogger.LogDotNetVersion(_logger, "AppStart");
// 重大なエラー発生時にも
DotNetVersionLogger.LogDotNetVersion(_logger, "FatalError");
ログには、例えばこんな行が残ります。
「DotNetInfo Context=AppStart RuntimeVersion=7.0.10」
ここでの重要ポイントは、 「いつ・どの文脈でそのバージョンだったか」を残すことです。
起動時のバージョンが分かれば、 「このバージョンのランタイムで本番を動かしていた」 と後から確認できますし、 重大エラー時のバージョンが分かれば、 「このエラーは .NET 6 のときだけ起きていた」 といった切り分けができます。
.NETバージョン情報が効いてくる具体的な場面
「ドキュメント通りに動かない」「開発と本番で挙動が違う」とき
.NETバージン取得が特に役立つのは、次のような状況です。
新しい API を使ったのに、本番で MissingMethodException が出る → 本番ランタイムが古くて、その API が存在しない。
日付やタイムゾーンの扱いが、開発と本番で微妙に違う → ランタイムのバージョン差で、バグ修正や仕様変更が入っている。
パフォーマンスが、開発環境（新しい .NET）と本番（古い .NET）で大きく違う → JIT や GC の改善が入っているかどうかの差。
こういうとき、 「本番は .NET 6.0.5、開発は .NET 7.0.10」 といった情報がログに残っていれば、 「まずランタイム差を疑う」という判断ができます。
ここでの重要ポイントは、 「コードだけでなく、“どの .NET で動いていたか”もバグの再現条件の一部」 だということです。
まとめ：.NETバージョン取得は“エンジンのバージョンを見える化する”ためのユーティリティ
.NETバージョン取得の本質を一言で言うと、
「このアプリが、 どのバージョンの .NET ランタイムの上で動いていたかを、 コードから機械的に取得し、ログとして残すことで、 バージョン差による挙動の違いや不具合を正しく理解できるようにする」
ことです。
押さえておきたいポイントは次の通りです。
Environment.Version で「今動いている .NET ランタイムのバージョン」を取得できる。 DotNetVersionLogger のようなユーティリティを作り、「起動時・重大エラー時などに文脈付きでログに残す」と、実務で非常に使いやすい。 ランタイムバージョンは、開発環境と本番環境の差、古い .NET と新しい .NET の差を切り分けるための重要な手がかりになる。
ここまでイメージできていれば、 「なんか本番だけ挙動が違う」というときに、 “.NET のバージョン差”という視点を持って診断できるようになります。