次の方法で共有

.NET Core 1.0から3.0におけるコア .NET ライブラリの破壊的変更

コア .NET ライブラリには、.NET Core で使用されるプリミティブとその他の一般的な型が用意されています。

このページでは、次の破壊的変更について説明します。

重大な変更 導入されたバージョン
IEnumerable<T> を受け取る拡張メソッドに GroupCollection を渡すにはあいまいさが必要 .NET Core 3.0
バージョンをレポートする API が、ファイル バージョンではなく製品をレポートするようになった .NET Core 3.0
カスタム EncoderFallbackBuffer インスタンスが再帰的にフォールバックしない .NET Core 3.0
浮動小数点の書式設定と解析の動作の変更 .NET Core 3.0
浮動小数点の解析操作が失敗したり OverflowException がスローされたりすることがなくなった .NET Core 3.0
InvalidAsynchronousStateException を別のアセンブリに移動 .NET Core 3.0
Unicode のガイドラインに従って不適切な形式の UTF-8 バイト シーケンスを置き換える .NET Core 3.0
TypeDescriptionProviderAttribute を別のアセンブリに移動 .NET Core 3.0
ZipArchiveEntry による、エントリ サイズに一貫性のないアーカイブ処理の中止 .NET Core 3.0
FieldInfo.SetValue で、静的な初期化専用フィールドに対する例外がスローされる .NET Core 3.0
Path APIは無効な文字に対して例外をスローしません .NET Core 2.1
組み込みの構造体型に追加されたプライベート フィールド .NET Core 2.1
UseShellExecute の既定値の変更 .NET Core 2.1
macOS の OpenSSL バージョン .NET Core 2.1
FileSystemInfo.Attributes によってスローされる UnauthorizedAccessException .NET Core 1.0
破損プロセス状態例外の処理はサポートされていません .NET Core 1.0
UriBuilder のプロパティでは今後、先頭に文字が付加されない .NET Core 1.0
Process.StartInfo は、開始しなかったプロセスに対して InvalidOperationException をスローします .NET Core 1.0

.NET Core 3.0

IEnumerable<T> を受け取る拡張メソッドに GroupCollection を渡すにはあいまいさが必要

IEnumerable<T> で GroupCollection を受け取る拡張メソッドを呼び出す場合は、キャストを使用して型を明確にする必要があります。

変更の説明

.NET Core 3.0 以降では、System.Text.RegularExpressions.GroupCollection によって IEnumerable<KeyValuePair<String,Group>> が実装され、それによって他の型 (IEnumerable<Group> など) も加えて実装されます。 これは、IEnumerable<T> を受け取る拡張メソッドを呼び出す場合には、あいまいな結果となります。 たとえば、GroupCollection などの Enumerable.Count インスタンスでこのような拡張メソッドを呼び出すと、次のコンパイラ エラーが表示されます。

CS1061: 'GroupCollection' に 'Count' の定義が含まれておらず、型 'GroupCollection' の最初の引数を受け付ける拡張メソッド 'Count' が見つかりませんでした (using ディレクティブまたはアセンブリ参照が不足しています。)

以前のバージョンの .NET では、あいまいさはなく、コンパイラ エラーもありませんでした。

導入されたバージョン

3.0

変更の理由

これは意図しない破壊的変更でした。 しばらくの間このようになっているため、元に戻す予定はありません。 また、このような変更自体が中断されます。

GroupCollection インスタンスの場合は、キャストで IEnumerable<T> を受け入れる拡張メソッドの呼び出しを明確にします。

// Without a cast - causes CS1061.
match.Groups.Count(_ => true)

// With a disambiguating cast.
((IEnumerable<Group>)m.Groups).Count(_ => true);

カテゴリ

コア .NET ライブラリ

影響を受ける API

IEnumerable<T> を受け入れるすべての拡張メソッドが影響を受けます。 例えば次が挙げられます。

バージョンをレポートする API が、ファイル バージョンではなく製品をレポートするようになりました

.NET Core のバージョンを返す API の多くは、ファイル バージョンではなく製品バージョンを返すようになりました。

変更の説明

.NET Core 2.2 およびそれ以前のバージョンでは、Environment.Version、RuntimeInformation.FrameworkDescription などのメソッドと、.NET Core アセンブリの [ファイルのプロパティ] ダイアログにファイルのバージョンが反映されています。 .NET Core 3.0 以降では、製品のバージョンが反映されています。

次の図は、.NET Core 2.2 (左側) と .NET Core 3.0 (右側) の System.Runtime.dll アセンブリのバージョン情報の違いを示しています。これは、Windows Explorer [ファイルのプロパティ] ダイアログに表示されます。

製品バージョン情報の相違点

導入されたバージョン

3.0

なし。 この変更により、機能性ではなく、バージョン検出を直感的に行う必要があります。

カテゴリ

コア .NET ライブラリ

影響を受ける API

カスタム EncoderFallbackBuffer インスタンスが再帰的にフォールバックしない

カスタム EncoderFallbackBuffer インスタンスが再帰的にフォールバックしません。 EncoderFallbackBuffer.GetNextChar() を実装した場合、文字のシーケンスが変換先のエンコードに変換されるようにする必要があります。 それ以外の場合は、例外が発生します。

変更の説明

文字をバイトに変換する操作中に、ランタイムによって不適切な形式または変換不能な UTF-16 のシーケンスが検出され、それらの文字は EncoderFallbackBuffer.Fallback メソッドに渡されます。 元の変換不能なデータの代わりに置き換える文字は、Fallback メソッドによって決定されますが、これらの文字は、EncoderFallbackBuffer.GetNextChar をループで呼び出すことによってドレインされます。

それからランタイムはこれらの置換文字を、ターゲットのエンコードに変換しようとします。 この操作が成功する場合、ランタイムによって、元の入力文字列の中断した箇所からコード変換が継続されます。

以前は、EncoderFallbackBuffer.GetNextChar() をカスタム実装することにより、変換先のエンコードに変換できなかった文字シーケンスが返されました。 置換文字がターゲットのエンコードにコード変換できない場合、EncoderFallbackBuffer.Fallback メソッドによって新しい置換のシーケンスが返されることを期待し、ランタイムによって置換文字列が使用されて EncoderFallbackBuffer.GetNextChar() メソッドが再度呼び出されます。 この処理は、結果的に、ランタイムによって正しい形式の、変換可能な代替が確認されるまで、または最大再帰数に到達するまで、継続します。

.NET Core 3.0 以降では、EncoderFallbackBuffer.GetNextChar() をカスタム実装した場合、変換先のエンコードに変換できる文字シーケンスが返される必要があります。 置換文字がターゲットのエンコードにコード変換できない場合、ArgumentException がスローされます。 ランタイムは、それ以上 EncoderFallbackBuffer インスタンスに対し、再帰呼び出しを実行しなくなります。

この動作は、次の 3 つの条件がすべて満たされている場合にのみ行われます。

  • ランタイムによって、不正な形式の UTF-16 シーケンスまたはターゲットのエンコードに変換できない UTF-16 シーケンスが検出される。
  • カスタム EncoderFallback が指定された。
  • カスタム EncoderFallback によって、新しい不正な形式の、または変換不能な URT-16 シーケンスへの置換を試行される。

導入されたバージョン

3.0

ほとんどの開発者は、何も措置を講じる必要はありません。

アプリケーションでカスタム EncoderFallback および EncoderFallbackBuffer クラスを使用している場合、EncoderFallbackBuffer.Fallback メソッドがランタイムによって最初に呼び出されたときに、Fallback を実装することで、ターゲットのエンコードに直接変換できる正しい形式の UTF-16 で、データがフォールバック バッファーに入力されるようにします。

カテゴリ

コア .NET ライブラリ

影響を受ける API

浮動小数点の書式設定と解析の動作が変更されました

(Double および Single 型による) 浮動小数点の解析と書式設定の動作が IEEE に準拠するようになりました。 これにより、.NET での浮動小数点型の動作が、他の IEEE 準拠言語の動作と一致するようになります。 たとえば、double.Parse("SomeLiteral") は、double x = SomeLiteral に対して C# で生成される内容と常に一致する必要があります。

変更の説明

.NET Core 2.2 以前のバージョンでは、Double.ToString および Single.ToString を使用した書式設定と Double.Parse、Double.TryParse、Single.Parse、および Single.TryParse を使用した解析は IEEE に準拠していません。 その結果、任意のサポートされている標準またはカスタムの書式設定文字列について、値がラウンドトリップすることを保証できません。 一部の入力では、書式設定された値を解析しようとして失敗する場合や、解析された値は元の値と同じではない場合があります。

.NET Core 3.0 以降、浮動小数点の解析および書式設定操作は IEEE 754 に準拠しています。

次の表は、2 つのコード スニペットと、.NET Core 2.2 と .NET Core 3.1 の間では出力がどのように変化するかを示しています。

コード スニペット .NET Core 2.2 での出力 .NET Core 3.1 での出力
Console.WriteLine((-0.0).ToString()); 0 -0
var value = -3.123456789123456789;
Console.WriteLine(value == double.Parse(value.ToString()));		 False True

詳細については、「Floating-point parsing and formatting improvements in .NET Core 3.0」(.NET Core 3.0 での浮動小数点の解析と書式設定の強化) に関するブログ記事を参照してください。

導入されたバージョン

3.0

「Floating-point parsing and formatting improvements in .NET Core 3.0」 (.NET Core 3.0 での浮動小数点の解析と書式設定の強化) に関するブログ記事の「Potential impact to existing code」 (既存のコードに対して考えられる影響) セクションでは、以前の動作を維持する必要がある場合にコードに対して加えることができる変更をいくつか提案しています。

  • 書式設定の違いの一部については、別の書式設定文字列を指定することで、以前の動作と同等の動作を得ることができます。
  • 解析の違いについては、以前の動作にフォールバックするためのメカニズムはありません。

カテゴリ

コア .NET ライブラリ

影響を受ける API

浮動小数点の解析操作が失敗したり OverflowException がスローされたりすることがなくなった

浮動小数点の解析メソッドが、OverflowException または false 浮動小数点の型の範囲外の数値を持つ文字列を解析する場合に、Single をスローしたり、Double を返したりすることがなくなりました。

変更の説明

.NET Core 2.2 以前のバージョンでは、Double.Parse および Single.Parse メソッドは、それぞれの型の範囲外の値に対して、OverflowException をスローします。 Double.TryParse および Single.TryParse メソッドは、範囲外の数値を持つ文字列表現に対して false を返します。

.NET Core 3.0 以降、範囲外の数値文字列を解析するときに、Double.Parse、Double.TryParse、Single.Parse、および Single.TryParse の各メソッドが失敗しなくなりました。 代わりに、Double の解析メソッドが、Double.PositiveInfinity を超過する値に対して Double.MaxValue を返し、また Double.NegativeInfinity 未満の値に対して Double.MinValue を返すようになりました。 同様に、Single の解析メソッドが、Single.PositiveInfinity を超過する値に対して Single.MaxValue を返し、また Single.NegativeInfinity 未満の値に対して Single.MinValue を返すようになりました。

この変更は、IEEE 754:2008 に対する準拠の改善のために行われました。

導入されたバージョン

3.0

この変更は、次の 2 つのいずれかの方法でコードに影響を与える可能性があります。

  • コードは、オーバーフローが発生したときに実行される OverflowException のハンドラーに依存します。 この場合、catch ステートメントを削除し、If または Double.IsInfinity が Single.IsInfinity であるかをテストする任意のコードを true ステートメントに含める必要があります。

  • コードは、浮動小数点値が Infinity ではないことを前提としています。 この場合は、必要な PositiveInfinity および NegativeInfinity の浮動小数点値を確認するコードを追加する必要があります。

カテゴリ

コア .NET ライブラリ

影響を受ける API

InvalidAsynchronousStateException が別のアセンブリに移動された

InvalidAsynchronousStateException クラスは移動されました。

変更の説明

.NET Core 2.2 およびそれ以前のバージョンでは、InvalidAsynchronousStateException クラスは System.ComponentModel.TypeConverter アセンブリにあります。

.NET Core 3.0 以降では、System.ComponentModel.Primitives アセンブリに含まれています。

導入されたバージョン

3.0

この変更によって影響を受けるのは、リフレクションを使用し、InvalidAsynchronousStateException などのメソッドや、型が特定のアセンブリにあることを想定している Assembly.GetType のオーバーロードを呼び出すことによって、Activator.CreateInstance を読み込んでいるアプリケーションのみです。 これに該当する場合は、メソッドの呼び出しで参照されているアセンブリを、型の新しいアセンブリの場所を反映するように更新します。

カテゴリ

コア .NET ライブラリ

影響を受ける API

なし。

Unicode のガイドラインに従って不適切な形式の UTF-8 バイト シーケンスを置き換える

UTF8Encoding クラスで、バイトから文字へのコード変換中に不適切な形式の UTF-8 バイト シーケンスが検出された場合、そのシーケンスは出力文字列内で "�" (U+FFFD REPLACEMENT CHARACTER) 文字に置き換えられます。 .NET Core 3.0 では、コード変換の操作中にこの置換を実行するための Unicode ベスト プラクティスに従うことで、以前のバージョンの .NET Core と .NET Framework との差別化が行われています。

これは、新しい System.Text.Unicode.Utf8 型および System.Text.Rune 型の使用を含め、.NET 全体での UTF-8 の処理を向上させようとする、より大きな取り組みの一環です。 UTF8Encoding 型では、新しく導入された型と一致する出力が生成されるよう、エラー処理のメカニズムが向上しています。

変更の説明

.NET Core 3.0 からは、バイトの文字列へのコード変換は、Unicode のベスト プラクティスに基づいて UTF8Encoding クラスによって文字列が置換されます。 使用される置換メカニズムについては、Unicode 標準のバージョン 12.0 のセクション 3.9 (PDF) の「U+FFFD Substitution of Maximal Subparts」 (最大サブパーツの U+FFFD 置換) という見出しを参照してください。

この動作は、入力バイト シーケンスに不正な形式の UTF-8 データが含まれている場合のみ該当します。 また、UTF8Encoding インスタンスが throwOnInvalidBytes: true を使用して構築されている場合、UTF8Encoding インスタンスは U+FFFD 置換を実行せずに無効な入力のスローを続けます。 UTF8Encoding コンストラクターについて詳しくは、「UTF8Encoding(Boolean, Boolean)」をご覧ください。

次の表では、不正な 3 バイトの入力でのこの変更の影響を示します。

不正形式の 3 バイトの入力 .NET Core 3.0 以前の出力 .NET Core 3.0 以降の出力
[ ED A0 90 ] [ FFFD FFFD ] (2 文字の出力) [ FFFD FFFD FFFD ] (3 文字の出力)

3 文字の出力は、前にリンクした Unicode 標準の PDF の "表 3-9" に従って、優先される出力となります。

導入されたバージョン

3.0

開発者側では、何も行う必要はありません。

カテゴリ

コア .NET ライブラリ

影響を受ける API

TypeDescriptionProviderAttribute は別のアセンブリに移動されました

TypeDescriptionProviderAttribute クラスは移動されました。

変更の説明

.NET Core 2.2 およびそれ以前のバージョンでは、TypeDescriptionProviderAttribute クラスは System.ComponentModel.TypeConverter アセンブリにあります。

.NET Core 3.0 以降では、System.ObjectModel アセンブリに含まれています。

導入されたバージョン

3.0

この変更によって影響を受けるのは、リフレクションを使用し、TypeDescriptionProviderAttribute などのメソッドや、型が特定のアセンブリにあることを想定している Assembly.GetType のオーバーロードを呼び出すことによって、Activator.CreateInstance 型を読み込んでいるアプリケーションのみです。 これに該当する場合は、メソッドの呼び出しで参照されているアセンブリを、型の新しいアセンブリの場所を反映するように更新する必要があります。

カテゴリ

Windows フォーム

影響を受ける API

なし。

ZipArchiveEntry による、エントリ サイズに一貫性のないアーカイブ処理の中止

Zip アーカイブは、圧縮されているサイズと圧縮されていないサイズの両方を、中央ディレクトリとローカル ヘッダーに一覧表示します。 また、エントリ データ自体のサイズも示されます。 .NET Core 2.2 以前のバージョンでは、これらの値の一貫性はチェックされませんでした。 .NET Core 3.0 より、これが開始します。

変更の説明

.NET Core 2.2 以前のバージョンでは、ZipArchiveEntry.Open() はローカル ヘッダーが zip ファイルの中央ヘッダーと一致しない場合でも成功します。 圧縮されたストリームの末尾に達するまで、データは圧縮解除されます。これは、その長さが、中央ディレクトリ/ローカル ヘッダーに示されている圧縮されていないファイル サイズを超えている場合も同様です。

.NET Core 3.0 以降では、ZipArchiveEntry.Open() メソッドによって、エントリの圧縮されたサイズと圧縮されていないサイズがローカル ヘッダーと中央ヘッダーで一致することが確認されます。 そうでない場合、アーカイブのローカル ヘッダーやデータ記述子に zip ファイルの中央ディレクトリと一致しないサイズが一覧表示されている場合、メソッドによって InvalidDataException がスローされます。 エントリを読み取るときに、圧縮解除されたデータは、ヘッダーに一覧表示されている圧縮されていないファイル サイズにまで切り詰められます。

この変更は、ZipArchiveEntry がそのデータのサイズを正しく表し、そのデータ量だけが読み取られるようにするために行われました。

導入されたバージョン

3.0

この問題が発生している zip アーカイブをすべて再パッケージ化します。

カテゴリ

コア .NET ライブラリ

影響を受ける API

FieldInfo.SetValue で、静的な初期化専用フィールドに対する例外がスローされる

.NET Core 3.0 以降、InitOnly を呼び出して静的な System.Reflection.FieldInfo.SetValue フィールドに値を設定しようとすると、例外がスローされます。

変更の説明

.NET Framework と、3.0 より前のバージョンの .NET Core では、定数である静的フィールドの初期化 (C# では読み取り専用に) した後、System.Reflection.FieldInfo.SetValue を呼び出すことで値を設定できました。 ただし、この方法でこのようなフィールドを設定すると、ターゲット フレームワークと最適化の設定に基づく動作を予測できなくなります。

.NET Core 3.0 以降のバージョンでは、静的な SetValue フィールドに対して InitOnly を呼び出すと、System.FieldAccessException 例外がスローされます。

ヒント

InitOnly フィールドは、その宣言時またはそれを含んでいるクラスのコンストラクター内にのみ設定可能なフィールドです。 つまり、それは初期化された後は定数になります。

導入されたバージョン

3.0

静的コンストラクター内の静的な InitOnly フィールドを初期化します。 これは、動的な型と非動的な型の両方に適用されます。

または、フィールドから FieldAttributes.InitOnly 属性を削除した後、FieldInfo.SetValue を呼び出すこともできます。

カテゴリ

コア .NET ライブラリ

影響を受ける API

.NET Core 2.1

パス API から、無効な文字に対する例外はスローされません

ファイル パスを含む API は、パス文字を検証したり、無効な文字が見つかった場合に ArgumentException をスローしたりしなくなりました。

変更の説明

.NET Framework および .NET Core 1.0 - 2.0 では、「 影響を受ける API」 セクションに記載されているメソッドは、パス引数に無効なパス文字が含まれている場合に ArgumentException をスローします。 .NET Core 2.1 以降では、これらのメソッドは 無効なパス文字 をチェックしたり、無効な文字が見つかった場合に例外をスローしたりしなくなりました。

変更の理由

パス文字を積極的に検証すると、一部のクロスプラットフォーム シナリオがブロックされます。 この変更は、.NET がオペレーティング システム API 呼び出しの結果をレプリケートまたは予測しないように導入されました。 詳細については、 .NET Core 2.1 の System.IO に関するブログ記事を参照 してください。

導入されたバージョン

.NET Core 2.1

コードが無効な文字をチェックするためにこれらの API に依存している場合は、 Path.GetInvalidPathCharsの呼び出しを追加できます。

影響を受ける API

こちらも参照ください

組み込みの構造体型に追加されたプライベート フィールド

参照アセンブリの特定の構造体型にプライベート フィールドが追加されました。 その結果、C# では、これらの構造体型は常に 新しい演算子 または 既定のリテラルを使用してインスタンス化する必要があります。

変更の説明

.NET Core 2.0 以前のバージョンでは、 ConsoleKeyInfoなど、一部の指定された構造体型は、C# で new 演算子または 既定のリテラル を使用せずにインスタンス化できます。 これは、C# コンパイラによって使用される 参照アセンブリ に構造体のプライベート フィールドが含まれていないためです。 .NET 構造体型のすべてのプライベート フィールドは、.NET Core 2.1 以降の参照アセンブリに追加されます。

たとえば、次の C# コードは .NET Core 2.0 ではコンパイルされますが、.NET Core 2.1 ではコンパイルされません。

ConsoleKeyInfo key;    // Struct type

if (key.ToString() == "y")
{
    Console.WriteLine("Yes!");
}

.NET Core 2.1 では、前のコードで次のコンパイラ エラーが発生します。 CS0165 - 割り当てられていないローカル変数 'key' の使用

導入されたバージョン

2.1

new演算子または既定のリテラルを使用して構造体型をインスタンス化します。

例えば次が挙げられます。

ConsoleKeyInfo key = new ConsoleKeyInfo();    // Struct type.

if (key.ToString() == "y")
    Console.WriteLine("Yes!");

ConsoleKeyInfo key = default;    // Struct type.

if (key.ToString() == "y")
    Console.WriteLine("Yes!");

カテゴリ

コア .NET ライブラリ

影響を受ける API

UseShellExecute の既定値の変更

ProcessStartInfo.UseShellExecute の既定値は .NET Core の false です。 .NET Framework では、既定値は true。

変更の説明

Process.Start を使用すると、たとえば Paint を起動する Process.Start("mspaint.exe") などのコードを使用して、アプリケーションを直接起動できます。 また、 ProcessStartInfo.UseShellExecute が trueに設定されている場合は、関連するアプリケーションを間接的に起動することもできます。 .NET Framework では、 ProcessStartInfo.UseShellExecute の既定値は trueです。つまり、 Process.Start("mytextfile.txt") などのコードは、そのエディターに.txtファイルを関連付けた場合にメモ帳 を 起動します。 .NET Framework でアプリを間接的に起動しないようにするには、 ProcessStartInfo.UseShellExecute を明示的に false に設定する必要があります。 .NET Core では、 ProcessStartInfo.UseShellExecute の既定値は false。 つまり、既定では、 Process.Startを呼び出すときに、関連付けられているアプリケーションは起動されません。

System.Diagnostics.ProcessStartInfoの次のプロパティは、ProcessStartInfo.UseShellExecuteがtrueされている場合にのみ機能します。

この変更は、パフォーマンス上の理由から .NET Core で導入されました。 通常、 Process.Start はアプリケーションを直接起動するために使用されます。 アプリを直接起動する場合、Windows シェルを使用する必要はないため、関連するパフォーマンス コストが発生します。 この既定のケースを高速化するために、.NET Core では既定値の ProcessStartInfo.UseShellExecute が false に変更されます。 必要に応じて、低速パスにオプトインできます。

導入されたバージョン

2.1

注

以前のバージョンの .NET Core では、 UseShellExecute は Windows 用に実装されていませんでした。

アプリが古い動作に依存している場合は、Process.Start(ProcessStartInfo)をUseShellExecuteでtrueに設定してProcessStartInfo オブジェクトを呼び出します。

カテゴリ

コア .NET ライブラリ

影響を受ける API

macOS の OpenSSL バージョン

macOS 上の .NET Core 3.0 以降のランタイムでは、openSSL 1.1.x バージョンが、 AesCcm、 AesGcm、 DSAOpenSsl、 ECDiffieHellmanOpenSsl、 ECDsaOpenSsl、 RSAOpenSsl、および SafeEvpPKeyHandle の型に対して OpenSSL 1.0.x バージョンよりも優先されるようになりました。

.NET Core 2.1 ランタイムでは OpenSSL 1.1.x バージョンがサポートされるようになりましたが、引き続き OpenSSL 1.0.x バージョンが優先されます。

変更の説明

以前は、.NET Core ランタイムは、OpenSSL と対話する型に macOS 上の OpenSSL 1.0.x バージョンを使用しました。 最新の OpenSSL 1.0.x バージョンである OpenSSL 1.0.2 はサポート対象外になりました。 サポートされているバージョンの OpenSSL で OpenSSL を使用する型を保持するために、.NET Core 3.0 以降のランタイムでは、macOS で新しいバージョンの OpenSSL が使用されるようになりました。

この変更により、macOS 上の .NET Core ランタイムの動作は次のようになります。

  • .NET Core 3.0 以降のバージョン ランタイムは、OpenSSL 1.1.x (使用可能な場合) を使用し、使用可能な 1.1.x バージョンがない場合にのみ OpenSSL 1.0.x にフォールバックします。

    カスタム P/Invoke で OpenSSL 相互運用機能の種類を使用する呼び出し元の場合は、 SafeEvpPKeyHandle.OpenSslVersion 解説のガイダンスに従ってください。 OpenSslVersion値を確認しないと、アプリがクラッシュする可能性があります。

  • .NET Core 2.1 ランタイムは、OpenSSL 1.0.x (使用可能な場合) を使用し、使用可能な 1.0.x バージョンがない場合は OpenSSL 1.1.x にフォールバックします。

    SafeEvpPKeyHandle.OpenSslVersion プロパティが .NET Core 2.1 に存在しないため、2.1 ランタイムは以前のバージョンの OpenSSL を優先するため、実行時に OpenSSL のバージョンを確実に特定できません。

導入されたバージョン

  • .NET Core 2.1.16
  • .NET Core 3.0.3
  • .NET Core 3.1.2

カテゴリ

コア .NET ライブラリ

影響を受ける API

.NET Core 1.0

FileSystemInfo.Attributes によってスローされる UnauthorizedAccessException

.NET Core では、呼び出し元がファイル属性値を設定しようとして、書き込みアクセス許可がない場合、UnauthorizedAccessException がスローされます。

変更の説明

.NET Framework では、呼び出し元が ArgumentException でファイル属性値を設定しようとして、書き込みアクセス許可がない場合、FileSystemInfo.Attributes がスローされます。 .NET Core では、代わりに UnauthorizedAccessException がスローされます (.NET Core では、呼び出し元が無効なファイル属性を設定しようとした場合でも ArgumentException がスローされます)。

導入されたバージョン

1.0

必要に応じて、catchの代わりにUnauthorizedAccessExceptionをキャッチするように、ArgumentExceptionステートメントを変更します。

カテゴリ

コア .NET ライブラリ

影響を受ける API

破損した状態の例外の処理はサポートされていません

.NET Core での破損プロセス状態例外の処理はサポートされていません。

変更の説明

以前は、C# で try-catch ステートメントを使用するなど、マネージド コードの例外ハンドラーによって、破損したプロセス状態の例外をキャッチして処理できました。

.NET Core 1.0 以降では、破損したプロセス状態の例外はマネージド コードでは処理できません。 共通言語ランタイムは、破損したプロセス状態の例外をマネージド コードに提供しません。

導入されたバージョン

1.0

破損したプロセス状態の例外を処理する必要を避け、それらを引き起こす状況に対処することを検討してください。 破損したプロセス状態の例外を処理する必要がある場合は、C または C++ コードで例外ハンドラーを記述します。

カテゴリ

コア .NET ライブラリ

影響を受ける API

UriBuilder プロパティはもはや先頭文字を追加しません

UriBuilder.Fragment は、先頭 # 文字の先頭に付加されなくなり、 UriBuilder.Query が既に存在する場合は先頭 ? 文字の先頭に付加されなくなります。

変更の説明

.NET Framework では、 UriBuilder.Fragment プロパティと UriBuilder.Query プロパティは、常に、格納される値の先頭に # または ? 文字を付加します。 この動作により、文字列にこれらの先頭文字のいずれかが既に含まれている場合、格納された値に複数の # または ? 文字が含まれる可能性があります。 たとえば、 UriBuilder.Fragment の値が ##mainになる場合があります。

.NET Core 1.0以降、これらのプロパティは、文字列の先頭に#または?文字が既に存在している場合、それらを追加しなくなりました。

導入されたバージョン

1.0

プロパティ値を設定するときに、これらの先頭文字を明示的に削除する必要がなくなりました。 これは、値を追加するときに特に便利です。追加するたびに先頭の # や ? を削除する必要がなくなったためです。

たとえば、次のコード スニペットは、.NET Framework と .NET Core の動作の違いを示しています。

var builder = new UriBuilder();
builder.Query = "one=1";
builder.Query += "&two=2";
builder.Query += "&three=3";
builder.Query += "&four=4";

Console.WriteLine(builder.Query);
  • .NET Framework では、出力は ????one=1&two=2&three=3&four=4。
  • .NET Core では、出力は ?one=1&two=2&three=3&four=4。

カテゴリ

コア .NET ライブラリ

影響を受ける API

Process.StartInfo は、開始しなかったプロセスに対して InvalidOperationException をスローします

コードで開始されなかったプロセスの Process.StartInfo プロパティの読み取りによって、InvalidOperationException がスローされます。

変更の説明

.NET Framework で、コードが開始しなかったプロセスの Process.StartInfo プロパティにアクセスすると、ダミーの ProcessStartInfo オブジェクトが返されます。 ダミー オブジェクトには、 EnvironmentVariablesを除くすべてのプロパティの既定値が含まれています。

.NET Core 1.0 以降では、開始されなかった (Process.StartInfo が呼びされなかった) プロセスの Process.Start プロパティを読み取ると、InvalidOperationException がスローされます。

導入されたバージョン

1.0

コードが開始されなかったプロセスの Process.StartInfo プロパティにアクセスしないでください。 たとえば、 Process.GetProcessesによって返されるプロセスについては、このプロパティを読み取らないでください。

カテゴリ

コア .NET ライブラリ

影響を受ける API