-
Notifications
You must be signed in to change notification settings - Fork 5.9k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #42090 from dotnet/main
Merge main into live
- Loading branch information
Showing
14 changed files
with
328 additions
and
10 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
38 changes: 38 additions & 0 deletions
38
docs/core/compatibility/core-libraries/8.0/complex-format.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,38 @@ | ||
--- | ||
title: ".NET 8 breaking change: Complex.ToString format changed to `<a; b>`" | ||
description: Learn about the .NET 8 breaking change in core .NET libraries where the Complex.ToString() format changed from `(a, b)` to `<a; b>`. | ||
ms.date: 08/06/2024 | ||
--- | ||
# Complex.ToString format changed to `<a; b>` | ||
|
||
To better support formatting values with culture-specific information, the default string representation of complex numbers was changed to avoid using characters that can be used in formatted numeric values. This change affects <xref:System.Numerics.Complex.ToString%2A?displayProperty=nameWithType>, where the value is now formatted as `<a; b>` instead of `(a, b)`. Both *a* and *b* are formatted using the general format specifier ("G") and the conventions of the culture defined by provider—this hasn't changed. | ||
|
||
## Previous behavior | ||
|
||
Previously, the string representation of the complex number returned by <xref:System.Numerics.Complex.ToString%2A?displayProperty=nameWithType> displayed the number using its Cartesian coordinates in the form `(a, b)`, where *a* was the real part of the complex number, and *b* was its imaginary part. | ||
|
||
## New behavior | ||
|
||
Starting in .NET 8, the string representation of the complex number returned by <xref:System.Numerics.Complex.ToString%2A?displayProperty=nameWithType> displays the number using its Cartesian coordinates in the form `<a; b>`, where *a* is the real part of the complex number, and *b* is its imaginary part. | ||
|
||
## Version introduced | ||
|
||
.NET 8 | ||
|
||
## Type of breaking change | ||
|
||
This change is a [behavioral change](../../categories.md#behavioral-change). | ||
|
||
## Reason for change | ||
|
||
The change to use a semicolon enables support of formatting with culture-specific information. It also enables the corresponding need to be able to parse results back out given that it implements <xref:System.Numerics.INumberBase%601>. | ||
|
||
The change from parentheses (`( )`) to angle brackets avoids potential collision with numeric formats where negative numbers are formatted as `(x)`. The new behavior is also consistent with the behavior of the `Vector*` types. | ||
|
||
## Recommended action | ||
|
||
If you need the previous format, you can use a custom string formatting mechanism such as `$"({complex.Real}, {complex.Imaginary})"` to produce a string in that format. | ||
|
||
## Affected APIs | ||
|
||
- <xref:System.Numerics.Complex.ToString%2A?displayProperty=fullName> |
43 changes: 43 additions & 0 deletions
43
docs/core/compatibility/core-libraries/9.0/biginteger-limit.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,43 @@ | ||
--- | ||
title: "Breaking change: BigInteger maximum length" | ||
description: Learn about the .NET 9 breaking change in core .NET libraries where a maximum length for BigInteger is enforced. | ||
ms.date: 08/06/2024 | ||
--- | ||
# BigInteger maximum length | ||
|
||
.NET 9 enforces a maximum length of <xref:System.Numerics.BigInteger>, which is that it can contain no more than `(2^31) - 1` (approximately 2.14 billion) bits. Such a number represents an almost 256 MB allocation and contains approximately 646.5 million digits. This new limit ensures that all APIs exposed are well behaved and consistent while still allowing numbers that are far beyond most usage scenarios. | ||
|
||
## Previous behavior | ||
|
||
Previously, you could assign a value with a length up to `Array.MaxLength * 32` bits to a <xref:System.Numerics.BigInteger> variable. | ||
|
||
> [!NOTE] | ||
> Typical machines would hit an <xref:System.OutOfMemoryException> far before this limit could ever be reached. | ||
## New behavior | ||
|
||
Starting in .NET 9, <xref:System.Numerics.BigInteger> has a maximum length of `(2^31) - 1` (approximately 2.14 billion) bits. If you attempt to assign a larger value, an <xref:System.OverflowException> is thrown at run time. For example, the following code throws an exception: | ||
|
||
```csharp | ||
BigInteger bigInt = new BigInteger(-1) << int.MaxValue; | ||
``` | ||
|
||
## Version introduced | ||
|
||
.NET 9 Preview 6 | ||
|
||
## Type of breaking change | ||
|
||
This change is a [behavioral change](../../categories.md#behavioral-change). | ||
|
||
## Reason for change | ||
|
||
<xref:System.Numerics.BigInteger> supports representing integer values of essentially arbitrary length. However, in practice, the length is constrained by limits of the underlying computer, such as available memory or how long it would take to compute a given expression. Additionally, there exist some APIs that fail given inputs that result in a value that's too large. For these reasons, a maximum length is now enforced. | ||
|
||
## Recommended action | ||
|
||
If your code is affected, decrease the length of value you're assigning to <xref:System.Numerics.BigInteger> or add a length check. | ||
|
||
## Affected APIs | ||
|
||
- <xref:System.Numerics.BigInteger> |
48 changes: 48 additions & 0 deletions
48
docs/core/compatibility/serialization/9.0/binaryformatter-removal.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,48 @@ | ||
--- | ||
title: "Breaking change: In-box BinaryFormatter implementation removed and always throws" | ||
description: Learn about the .NET 9 breaking change in serialization where the in-box BinaryFormatter implementation was removed and always throws exceptions. | ||
ms.date: 08/06/2024 | ||
--- | ||
# In-box BinaryFormatter implementation removed and always throws | ||
|
||
The "in box" <xref:System.Runtime.Serialization.Formatters.Binary.BinaryFormatter> implementation now throws exceptions at run time in all cases. This is the final stage of the [BinaryFormatter obsoletion plan](https://github.com/dotnet/designs/blob/main/accepted/2020/better-obsoletion/binaryformatter-obsoletion.md). | ||
|
||
## Previous behavior | ||
|
||
You could construct a <xref:System.Runtime.Serialization.Formatters.Binary.BinaryFormatter> instance and use it to serialize and deserialize payloads. | ||
|
||
## New behavior | ||
|
||
Starting in .NET 9, the in-box <xref:System.Runtime.Serialization.Formatters.Binary.BinaryFormatter> implementation throws exceptions on use, even with the settings that previously enabled its use. Those settings are also removed. | ||
|
||
## Version introduced | ||
|
||
.NET 9 Preview 6 | ||
|
||
## Type of breaking change | ||
|
||
This change is a [behavioral change](../../categories.md#behavioral-change). | ||
|
||
## Reason for change | ||
|
||
`BinaryFormatter` is an insecure format and the cause of many security bugs. Removing it from the framework increases the overall safety of .NET. | ||
|
||
## Recommended action | ||
|
||
If your code uses `BinaryFormatter`, you should select a new serialization format and migrate your code. | ||
|
||
If you judge the risk of `BinaryFormatter` acceptable for your use cases and you're committed to using a class that can't be made secure, you'll still be able to use `BinaryFormatter` through a separate, unsupported NuGet package. | ||
|
||
For more information, including guidance on alternative serializers, see the [BinaryFormatter migration guide](../../../../standard/serialization/binaryformatter-migration-guide/index.md). | ||
|
||
## Affected APIs | ||
|
||
- <xref:System.Runtime.Serialization.Formatters.Binary.BinaryFormatter?displayProperty=fullName> | ||
|
||
## See also | ||
|
||
- [Announcement: BinaryFormatter is being removed in .NET 9](https://github.com/dotnet/runtime/issues/98245) | ||
- [BinaryFormatter disabled across most project types (.NET 8)](../8.0/binaryformatter-disabled.md) | ||
- [BinaryFormatter serialization APIs produce compiler errors (.NET 7)](../7.0/binaryformatter-apis-produce-errors.md) | ||
- [SerializationFormat.Binary is obsolete (.NET 7)](../7.0/serializationformat-binary.md) | ||
- [BinaryFormatter serialization methods are obsolete (.NET 5)](../5.0/binaryformatter-serialization-obsolete.md) |
Oops, something went wrong.