diff --git a/docs/core/additional-tools/uninstall-tool-cli-remove.md b/docs/core/additional-tools/uninstall-tool-cli-remove.md index 742efd4462562..4ab3acc470c19 100644 --- a/docs/core/additional-tools/uninstall-tool-cli-remove.md +++ b/docs/core/additional-tools/uninstall-tool-cli-remove.md @@ -19,13 +19,13 @@ zone_pivot_groups: operating-systems-set-three ::: zone pivot="os-windows" ```dotnetcli -dotnet-core-uninstall dry-run [--x64|--x86] ... +dotnet-core-uninstall remove [--x64|--x86] ... [-v|--verbosity ] [--force] [-y|--yes] -dotnet-core-uninstall dry-run [--x64|--x86] +dotnet-core-uninstall remove [--x64|--x86] [-v|--verbosity ] [--force] [-y|--yes] -dotnet-core-uninstall dry-run -h|--help|-? +dotnet-core-uninstall remove -h|--help|-? ``` ::: zone-end @@ -33,13 +33,13 @@ dotnet-core-uninstall dry-run -h|--help|-? ::: zone pivot="os-macos" ```dotnetcli -dotnet-core-uninstall dry-run ... +dotnet-core-uninstall remove ... [-v|--verbosity ] [--force] [-y|--yes] -dotnet-core-uninstall dry-run +dotnet-core-uninstall remove [-v|--verbosity ] [--force] [-y|--yes] -dotnet-core-uninstall dry-run -h|--help|-? +dotnet-core-uninstall remove -h|--help|-? ``` ::: zone-end @@ -70,11 +70,11 @@ The `dotnet-core-uninstall remove` command removes .NET SDKs and runtimes from t ::: zone pivot="os-windows" - **`--aspnet-runtime`** - + Discovers all the ASP.NET Core runtimes that can be uninstalled with this tool. - **`--hosting-bundle`** - + Lists all the .NET hosting bundles that can be uninstalled with this tool. ::: zone-end @@ -207,7 +207,7 @@ These options are exclusive. ``` The content of the *versions.rsp* file is as follows: - + ```text 2.2.300 6.0.301 diff --git a/docs/core/compatibility/9.0.md b/docs/core/compatibility/9.0.md index 89f9b011d451a..73558aa1fafea 100644 --- a/docs/core/compatibility/9.0.md +++ b/docs/core/compatibility/9.0.md @@ -29,7 +29,7 @@ If you're migrating an app to .NET 9, the breaking changes listed here might aff | [Adding a ZipArchiveEntry with CompressionLevel sets ZIP central directory header general-purpose bit flags](core-libraries/9.0/compressionlevel-bits.md) | Behavioral change | Preview 5 | | [Altered UnsafeAccessor support for non-open generics](core-libraries/9.0/unsafeaccessor-generics.md) | Behavioral change | Preview 6 | | [API obsoletions with custom diagnostic IDs](core-libraries/9.0/obsolete-apis-with-custom-diagnostics.md) | Source incompatible | Preview 16 | -| [BigInteger maximum length](core-libraries/9.0/biginteger-limit.md) | Source incompatible | Preview 1 | +| [BigInteger maximum length](core-libraries/9.0/biginteger-limit.md) | Behavioral change | Preview 6 | | [Creating type of array of System.Void not allowed](core-libraries/9.0/type-instance.md) | Behavioral change | Preview 1 | | [Default `Equals()` and `GetHashCode()` throw for types marked with `InlineArrayAttribute`](core-libraries/9.0/inlinearrayattribute.md) | Behavioral change | Preview 6 | | [Inline array struct size limit is enforced](core-libraries/9.0/inlinearray-size.md) | Behavioral change | Preview 1 | diff --git a/docs/framework/migration-guide/how-to-determine-which-versions-are-installed.md b/docs/framework/migration-guide/how-to-determine-which-versions-are-installed.md index 8cae0231fa648..71c3e9cb577e1 100644 --- a/docs/framework/migration-guide/how-to-determine-which-versions-are-installed.md +++ b/docs/framework/migration-guide/how-to-determine-which-versions-are-installed.md @@ -133,7 +133,7 @@ The following examples check the value of the **Release** entry to determine whe 1. Use the and methods to access the **HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\NET Framework Setup\\NDP\\v4\\Full** subkey in the Windows registry. > [!IMPORTANT] - > If the app you're running is 32-bit and running in 64-bit Windows, the registry paths will be different than previously listed. The 64-bit registry is available in the **HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\** subkey. For example, the registry subkey for .NET Framework 4.5 is **HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\NET Framework Setup\\NDP\\v4\\Full**. + > If the app you're running is 32-bit and running in 64-bit Windows, the registry paths will be different than previously listed. The 32-bit registry is available in the **HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\** subkey. For example, the registry subkey for .NET Framework 4.5 is **HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\NET Framework Setup\\NDP\\v4\\Full**. 1. Check the **Release** REG_DWORD value to determine the installed version. To be forward-compatible, check for a value greater than or equal to the value listed in the [.NET Framework version table](#version_table). @@ -202,7 +202,7 @@ Each version of .NET Framework from 1.1 to 4.0 is listed as a subkey at **HKEY_L | 4.0 Full Profile | **HKLM\\Software\\Microsoft\\NET Framework Setup\\NDP\\v4\\Full** | **Install** REG_DWORD equals `1` | > [!IMPORTANT] -> If the app you're running is 32-bit and running in 64-bit Windows, the registry paths will be different than previously listed. The 64-bit registry is available in the **HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\** subkey. For example, the registry subkey for .NET Framework 3.5 is **HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\NET Framework Setup\\NDP\\v3.5**. +> If the app you're running is 32-bit and running in 64-bit Windows, the registry paths will be different than previously listed. The 32-bit registry is available in the **HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\** subkey. For example, the registry subkey for .NET Framework 3.5 is **HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\NET Framework Setup\\NDP\\v3.5**. Notice that the registry path to the .NET Framework 1.0 subkey is different from the others. @@ -223,7 +223,7 @@ Notice that the registry path to the .NET Framework 1.0 subkey is different from Use the class to access the **HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\NET Framework Setup\\NDP** subkey in the Windows registry. > [!IMPORTANT] -> If the app you're running is 32-bit and running in 64-bit Windows, the registry paths will be different than previously listed. The 64-bit registry is available in the **HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\** subkey. For example, the registry subkey for .NET Framework 3.5 is **HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\NET Framework Setup\\NDP\\v3.5**. +> If the app you're running is 32-bit and running in 64-bit Windows, the registry paths will be different than previously listed. The 32-bit registry is available in the **HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\** subkey. For example, the registry subkey for .NET Framework 3.5 is **HKEY_LOCAL_MACHINE\\SOFTWARE\\Wow6432Node\\Microsoft\\NET Framework Setup\\NDP\\v3.5**. The following example finds the versions of .NET Framework 1-4 that are installed: diff --git a/docs/standard/serialization/system-text-json/deserialization.md b/docs/standard/serialization/system-text-json/deserialization.md index f7fbabdd30b07..925c39829663a 100644 --- a/docs/standard/serialization/system-text-json/deserialization.md +++ b/docs/standard/serialization/system-text-json/deserialization.md @@ -10,17 +10,20 @@ helpviewer_keywords: - "JSON deserialization" - "deserializing objects" - "deserialization" -ms.topic: how-to +ms.topic: concept-article +#customer intent: As a developer, I want to learn how to use System.Text.Json to deserialize JSON data. --- # How to read JSON as .NET objects (deserialize) -This article shows how to use the namespace to serialize to and deserialize from JavaScript Object Notation (JSON). If you're porting existing code from `Newtonsoft.Json`, see [How to migrate to `System.Text.Json`](migrate-from-newtonsoft.md). +This article shows how to use the namespace to deserialize from JavaScript Object Notation (JSON). If you're porting existing code from `Newtonsoft.Json`, see [How to migrate to `System.Text.Json`](migrate-from-newtonsoft.md). A common way to deserialize JSON is to have (or create) a .NET class with properties and fields that represent one or more of the JSON properties. Then, to deserialize from a string or a file, call the method. For the generic overloads, the generic type parameter is the .NET class. For the non-generic overloads, you pass the type of the class as a method parameter. You can deserialize either synchronously or asynchronously. Any JSON properties that aren't represented in your class are ignored [by default](missing-members.md). Also, if any properties on the type are [required](required-properties.md) but not present in the JSON payload, deserialization will fail. +## Examples + The following example shows how to deserialize a JSON string: :::code language="csharp" source="snippets/how-to/csharp/DeserializeExtra.cs" highlight="54-55"::: diff --git a/docs/standard/serialization/system-text-json/missing-members.md b/docs/standard/serialization/system-text-json/missing-members.md index 83f7081a162e7..3b69e33fdc134 100644 --- a/docs/standard/serialization/system-text-json/missing-members.md +++ b/docs/standard/serialization/system-text-json/missing-members.md @@ -11,7 +11,7 @@ dev_langs: By default, if the JSON payload you're deserializing contains properties that don't exist in the deserialized plain old CLR object (POCO) type, they're simply ignored. Starting in .NET 8, you can specify that all members must be present in the payload. If they're not, a exception is thrown. You can configure this behavior in one of three ways: -- Annotate your POCO type with the `[]` attribute, specifying either to or missing members. +- Annotate your POCO type with the attribute, specifying either to or missing members. ```csharp [JsonUnmappedMemberHandling(JsonUnmappedMemberHandling.Disallow)] @@ -20,7 +20,7 @@ By default, if the JSON payload you're deserializing contains properties that do public int Id { get; set; } } - JsonSerializer.Deserialize("""{"Id" : 42, "AnotherId" : -1 }"""); + JsonSerializer.Deserialize("""{"Id" : 42, "AnotherId" : -1 }"""); // JsonException : The JSON property 'AnotherId' could not be mapped to any .NET member contained in type 'MyPoco'. ```