.NET Core 1.0-3.0 の Core .NET ライブラリの破壊的変更

  • [アーティクル]

Core .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
パス 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 を渡すにはあいまいさが必要

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

変更内容

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

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);

カテゴリ

Core .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 [ファイルのプロパティ] ダイアログに表示されます。

Difference in product version information

導入されたバージョン

3.0

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

カテゴリ

Core .NET ライブラリ

影響を受ける API

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

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

変更の説明

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

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

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

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

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

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

導入されたバージョン

3.0

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

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

カテゴリ

Core .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」 (既存のコードに対して考えられる影響) セクションでは、以前の動作を維持する必要がある場合にコードに対して加えることができる変更をいくつか提案しています。

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

カテゴリ

Core .NET ライブラリ

影響を受ける API

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

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

変更の説明

.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.MaxValue を超過する値に対して Double.PositiveInfinity を返し、また Double.MinValue 未満の値に対して Double.NegativeInfinity を返すようになりました。 同様に、Single の解析メソッドが、Single.MaxValue を超過する値に対して Single.PositiveInfinity を返し、また Single.MinValue 未満の値に対して Single.NegativeInfinity を返すようになりました。

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

導入されたバージョン

3.0

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

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

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

カテゴリ

Core .NET ライブラリ

影響を受ける API

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

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

変更の説明

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

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

導入されたバージョン

3.0

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

カテゴリ

Core .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

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

カテゴリ

Core .NET ライブラリ

影響を受ける API

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

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

変更の説明

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

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

導入されたバージョン

3.0

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

カテゴリ

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 アーカイブをすべて再パッケージ化します。

カテゴリ

Core .NET ライブラリ

影響を受ける API

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

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

変更の説明

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

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

ヒント

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

導入されたバージョン

3.0

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

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

カテゴリ

Core .NET ライブラリ

影響を受ける API

.NET Core 2.1

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

ファイル パスを必要とする API では、パス文字の検証も、無効な文字が見つかった場合の ArgumentException のスローも行わなくなりました。

変更の説明

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

変更理由

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

導入されたバージョン

.NET Core 2.1

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

影響を受ける API

関連項目

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

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

変更の説明

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

たとえば、次の 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 演算子または default リテラルを使用して構造体型をインスタンス化します。

次に例を示します。

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!");

カテゴリ

Core .NET ライブラリ

影響を受ける API

UseShellExecute の既定値の変更

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

変更の説明

Process.Start では、たとえば、ペイントを起動する Process.Start("mspaint.exe") などのコードを使用して、アプリケーションを直接起動することができます。 また、ProcessStartInfo.UseShellExecute が true に設定されている場合、関連付けられているアプリケーションを間接的に起動することもできます。 .NET Framework では、ProcessStartInfo.UseShellExecute の既定値は true です。つまり、 .txt ファイルをメモ帳に関連付けていれば、Process.Start("mytextfile.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 の以前のバージョンでは、Windows に対して UseShellExecute は実装されていませんでした。

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

カテゴリ

Core .NET ライブラリ

影響を受ける API

macOS 上の OpenSSL バージョン

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

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

変更の説明

以前、.NET Core ランタイムでは、macOS 上の OpenSSL 1.0.x バージョンは OpenSSL とやりとりする型に対して使用されていました。 最新の 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 にフォールバックします。

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

導入されたバージョン

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

カテゴリ

Core .NET ライブラリ

影響を受ける API

.NET Core 1.0

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

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

変更の説明

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

導入されたバージョン

1.0

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

カテゴリ

Core .NET ライブラリ

影響を受ける API

破損状態例外の処理がサポートされない

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

変更の説明

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

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

導入されたバージョン

1.0

代わりに、そのような例外をもたらした状況に対処することで、プロセス破損状態例外を処理する必要がないようにします。 プロセス破損状態例外をどうしても処理する必要がある場合は、C または C++ のコードで例外ハンドラーを記述します。

カテゴリ

Core .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 です。

カテゴリ

Core .NET ライブラリ

影響を受ける API

開始されなかったプロセスについて Process.StartInfo が InvalidOperationException をスローする

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

変更の説明

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

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

導入されたバージョン

1.0

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

カテゴリ

Core .NET ライブラリ

影響を受ける API