unload threads, and thread pool timer threads.|
|**ThreadState \<** *State value field* **>**|Displays the state of the thread. The `value` parameter is the value of the `State` field in the **Threads** report output.
Example:
0:003> !Threads
ThreadCount: 2
UnstartedThread: 0
BackgroundThread: 1
PendingThread: 0
DeadThread: 0
Hosted Runtime: no
PreEmptive GC Alloc Lock
ID OSID ThreadOBJ State GC Context Domain Count APT Exception
0 1 250 0019b068 a020 Disabled 02349668:02349fe8 0015def0 0 MTA
2 2 944 001a6020 b220 Enabled 00000000:00000000 0015def0 0 MTA (Finalizer)
0:003> !ThreadState b220
Legal to Join
Background
CLR Owns
CoInitialized
In Multi Threaded Apartment
|
|**TraverseHeap** [**-xml**] \<*filename*>|Writes heap information to the specified file in a format understood by the CLR profiler. The **-xml** option causes the **TraverseHeap** command to format the file as XML.|
-|**U** [**-gcinfo**] [**-ehinfo**] [**-n**] \<*MethodDesc address*> | \<*Code address*>|Displays an annotated disassembly of a managed method specified either by a `MethodDesc` structure pointer for the method or by a code address within the method body. The **U** command displays the entire method from start to finish, with annotations that convert metadata tokens to names.
The **-gcinfo** option causes the **U** command to display the `GCInfo` structure for the method.
The **-ehinfo** option displays exception information for the method. You can also obtain this information with the **EHInfo** command.
The **-n** option disables the display of source file names and line numbers. If the debugger has the option SYMOPT_LOAD_LINES specified, SOS looks up the symbols for every managed frame and, if successful, displays the corresponding source file name and line number. You can specify the **-n** option to disable this behavior.|
+| **U** [**-gcinfo**] [**-ehinfo**] [**-n**] [**-o**] [**-il**] [**-map**] \<*MethodDesc address*> | \<*Code address*> | Displays an annotated disassembly of a managed method specified either by a `MethodDesc` structure pointer for the method or by a code address within the method body. The **U** command displays the entire method from start to finish, with annotations that convert metadata tokens to names.
The **-gcinfo** option causes the **U** command to display the `GCInfo` structure for the method.
The **-ehinfo** option displays exception information for the method. You can also obtain this information with the **EHInfo** command.
The **-n** option disables the display of source file names and line numbers. If the debugger has the option SYMOPT_LOAD_LINES specified, SOS looks up the symbols for every managed frame and, if successful, displays the corresponding source file name and line number. You can specify the **-n** option to disable this behavior.
The **-o** option displays the native offsets of code in addition to raw code addresses.
The **-il** option displays IL interspersed with the native code at the appropriate offset.
The **-map** option displays the compiler-generated map of IL to native offsets. Note that **-map** requires **-il**. |
|**VerifyHeap**|Checks the garbage collector heap for signs of corruption and displays any errors found.
Heap corruptions can be caused by platform invoke calls that are constructed incorrectly.|
|**VerifyObj** \<*object address*>|Checks the object that is passed as an argument for signs of corruption.|
|**VMMap**|Traverses the virtual address space and displays the type of protection applied to each region.|
diff --git a/docs/fundamentals/code-analysis/configuration-options.md b/docs/fundamentals/code-analysis/configuration-options.md
index 60b022afd877f..93064898ecd20 100644
--- a/docs/fundamentals/code-analysis/configuration-options.md
+++ b/docs/fundamentals/code-analysis/configuration-options.md
@@ -1,7 +1,7 @@
---
title: Configure code analysis rules
description: Learn how to configure code analysis rules in an analyzer configuration file.
-ms.date: 12/06/2021
+ms.date: 02/13/2026
no-loc: ["EditorConfig"]
---
# Configuration options for code analysis
@@ -30,7 +30,7 @@ For additional options, see [Code analysis properties](../../core/project-sdk/ms
### Analysis mode
-While the .NET SDK includes all code analysis rules, only some of them are [enabled by default](https://github.com/dotnet/roslyn-analyzers/blob/main/src/NetAnalyzers/Core/AnalyzerReleases.Shipped.md). The *analysis mode* determines which, if any, set of rules to enable. You can choose a more aggressive analysis mode where most or all rules are enabled. Or you can choose a more conservative analysis mode where most or all rules are disabled, and you can then opt-in to specific rules as needed. Set your analysis mode by adding the [``](../../core/project-sdk/msbuild-props.md#analysismode) MSBuild property to your project file.
+While the .NET SDK includes all code analysis rules, only some of them are [enabled by default](https://github.com/dotnet/sdk/blob/main/src/Microsoft.CodeAnalysis.NetAnalyzers/src/Microsoft.CodeAnalysis.NetAnalyzers/AnalyzerReleases.Shipped.md). The *analysis mode* determines which, if any, set of rules to enable. You can choose a more aggressive analysis mode where most or all rules are enabled. Or you can choose a more conservative analysis mode where most or all rules are disabled, and you can then opt-in to specific rules as needed. Set your analysis mode by adding the [``](../../core/project-sdk/msbuild-props.md#analysismode) MSBuild property to your project file.
```xml
@@ -85,7 +85,7 @@ The following table shows the different rule severities that you can configure f
| `suggestion` | Violations appear as build *messages* and as suggestions in the Visual Studio IDE. (In Visual Studio, suggestions appear as three gray dots under the first two characters.) |
| `silent` | Violations aren't visible to the user.
However, for code-style rules, Visual Studio code-generation features still generate code in this style. These rules also participate in cleanup and appear in the **Quick Actions and Refactorings** menu in Visual Studio. |
| `none` | Rule is suppressed completely.
However, for code-style rules, Visual Studio code-generation features still generate code in this style. |
-| `default` | The default severity of the rule is used. The default severities for each .NET release are listed in the [roslyn-analyzers repo](https://github.com/dotnet/roslyn-analyzers/blob/main/src/NetAnalyzers/Core/AnalyzerReleases.Shipped.md). In that table, "Disabled" corresponds to `none`, "Hidden" corresponds to `silent`, and "Info" corresponds to `suggestion`. |
+| `default` | The default severity of the rule is used. The default severities for each .NET release are listed in the [dotnet/sdk repo](https://github.com/dotnet/sdk/blob/main/src/Microsoft.CodeAnalysis.NetAnalyzers/src/Microsoft.CodeAnalysis.NetAnalyzers/AnalyzerReleases.Shipped.md). In that table, "Disabled" corresponds to `none`, "Hidden" corresponds to `silent`, and "Info" corresponds to `suggestion`. |
#### Scope
@@ -116,7 +116,7 @@ The following table shows the different rule severities that you can configure f
```
> [!IMPORTANT]
-> When you configure the severity level for multiple rules with a single entry, either for a *category* of rules or for *all* rules, the severity only applies to rules that are [enabled by default](https://github.com/dotnet/roslyn-analyzers/blob/main/src/NetAnalyzers/Core/AnalyzerReleases.Shipped.md). And if you enable all rules by using the MSBuild properties [``](../../core/project-sdk/msbuild-props.md#analysismode) or [``](../../core/project-sdk/msbuild-props.md#analysislevel), any bulk `dotnet_analyzer_diagnostic` options are ignored. For this reason, it's better to enable a category of rules by setting [\>](../../core/project-sdk/msbuild-props.md#analysismodecategory) to `All`.
+> When you configure the severity level for multiple rules with a single entry, either for a *category* of rules or for *all* rules, the severity only applies to rules that are [enabled by default](https://github.com/dotnet/sdk/blob/main/src/Microsoft.CodeAnalysis.NetAnalyzers/src/Microsoft.CodeAnalysis.NetAnalyzers/AnalyzerReleases.Shipped.md). And if you enable all rules by using the MSBuild properties [``](../../core/project-sdk/msbuild-props.md#analysismode) or [``](../../core/project-sdk/msbuild-props.md#analysislevel), any bulk `dotnet_analyzer_diagnostic` options are ignored. For this reason, it's better to enable a category of rules by setting [\>](../../core/project-sdk/msbuild-props.md#analysismodecategory) to `All`.
> [!NOTE]
> The prefix for setting severity for a single rule, `dotnet_diagnostic`, is different than the prefix for configuring severity via category or for all rules, `dotnet_analyzer_diagnostic`.
diff --git a/docs/orleans/dashboard/index.md b/docs/orleans/dashboard/index.md
index 9ed5319bd3877..53ac8609351ac 100644
--- a/docs/orleans/dashboard/index.md
+++ b/docs/orleans/dashboard/index.md
@@ -12,6 +12,8 @@ zone_pivot_groups: orleans-version
The Orleans Dashboard is a built-in web-based monitoring tool that provides real-time visibility into your Orleans cluster. It allows you to monitor silo health, grain activations, method calls, reminders, and system metrics without requiring external monitoring infrastructure.
+For Orleans 10.0, use the official dashboard packages: `Microsoft.Orleans.Dashboard` and `Microsoft.Orleans.Dashboard.Abstractions`.
+
[!INCLUDE [orleans-10-preview](../includes/orleans-10-preview.md)]
## Features
@@ -275,11 +277,19 @@ If the `/Trace` endpoint returns 403 Forbidden:
:::zone-end
-:::zone target="docs" pivot="orleans-9-0,orleans-8-0,orleans-7-0,orleans-3-x"
+:::zone target="docs" pivot="orleans-9-0,orleans-8-0,orleans-7-0"
+
+The Orleans Dashboard is a built-in monitoring tool introduced in Orleans 10.0. For Orleans 9.0, 8.0, and 7.0, use the unofficial community dashboard package:
+
+- **[OrleansDashboard (community)](https://github.com/OrleansContrib/OrleansDashboard)**: A community-maintained dashboard package for Orleans versions earlier than 10.0.
+- **OpenTelemetry integration**: Built-in observability features are available in Orleans 7.0 and later. See [Observability in Orleans](../host/monitoring/index.md).
+
+:::zone-end
+
+:::zone target="docs" pivot="orleans-3-x"
-The Orleans Dashboard is a built-in monitoring tool introduced in Orleans 10.0. For earlier versions, consider using:
+The Orleans Dashboard is a built-in monitoring tool introduced in Orleans 10.0. For Orleans 3.x, use the unofficial community dashboard package:
-- **[OrleansDashboard (community)](https://github.com/OrleansContrib/OrleansDashboard)**: A community-maintained dashboard for Orleans 3.x through 8.x.
-- **OpenTelemetry integration**: Built-in observability features available in Orleans 7.0 and later. See [Observability in Orleans](../host/monitoring/index.md).
+- **[OrleansDashboard (community)](https://github.com/OrleansContrib/OrleansDashboard)**: A community-maintained dashboard package for Orleans versions earlier than 10.0.
:::zone-end
diff --git a/docs/orleans/deployment/deploy-to-azure-container-apps.md b/docs/orleans/deployment/deploy-to-azure-container-apps.md
index c3159608a4278..d6541a5cd77bc 100644
--- a/docs/orleans/deployment/deploy-to-azure-container-apps.md
+++ b/docs/orleans/deployment/deploy-to-azure-container-apps.md
@@ -55,7 +55,7 @@ curl -sSL https://aspire.dev/install.sh | bash
The `aspire deploy` command is currently in preview and must be explicitly enabled:
-### [Windows (PowerShell)](#tab/windows)
+### [Windows](#tab/windows)
```powershell
$env:DOTNET_ASPIRE_ENABLE_DEPLOY_COMMAND="true"
@@ -117,12 +117,12 @@ aspire deploy --deployment-params-file deployment-params.json
When you deploy an Orleans Aspire application to Azure Container Apps, `aspire deploy` automatically provisions:
-- **Azure Container Apps environment** - The hosting environment for your containers
-- **Azure Container Registry (ACR)** - For storing your container images
-- **Redis Cache** - If your Orleans cluster uses Redis for clustering, grain storage, or reminders
-- **Azure Storage** - If your Orleans cluster uses Azure Storage for clustering, grain storage, reminders, or streaming
-- **Azure Monitor / Application Insights** - For observability and distributed tracing
-- **Managed identities** - For secure, passwordless authentication between services
+- **Azure Container Apps environment** - The hosting environment for your containers.
+- **Azure Container Registry (ACR)** - For storing your container images.
+- **Redis Cache** - If your Orleans cluster uses Redis for clustering, grain storage, or reminders.
+- **Azure Storage** - If your Orleans cluster uses Azure Storage for clustering, grain storage, reminders, or streaming.
+- **Azure Monitor / Application Insights** - For observability and distributed tracing.
+- **Managed identities** - For secure, passwordless authentication between services.
> [!TIP]
> To update your app after code changes, simply run `aspire deploy` again. The CLI handles incremental updates efficiently.
diff --git a/docs/orleans/deployment/handling-failures.md b/docs/orleans/deployment/handling-failures.md
index 045ac0de8cfa9..f08ad4460fd11 100644
--- a/docs/orleans/deployment/handling-failures.md
+++ b/docs/orleans/deployment/handling-failures.md
@@ -18,7 +18,7 @@ When coding grains, all calls are asynchronous and potentially go over the netwo
- The grain was activated on a silo currently unavailable due to a network partition, crash, or other reason. If the silo hasn't been declared dead yet, the request might time out.
- The grain method call can throw an exception, signaling failure and inability to continue its job.
-- An activation of the grain doesn't exist and cannot be created because the method throws an exception or deadlocks.
+- An activation of the grain doesn't exist and can't be created because the method throws an exception or deadlocks.
- Network failures prevent communication with the grain before the timeout occurs.
- Other potential reasons.
diff --git a/docs/orleans/deployment/kubernetes.md b/docs/orleans/deployment/kubernetes.md
index 59d083c6af609..0defea5dd842a 100644
--- a/docs/orleans/deployment/kubernetes.md
+++ b/docs/orleans/deployment/kubernetes.md
@@ -90,10 +90,10 @@ helm install my-orleans-app ./k8s-manifests/charts/my-orleans-app
### Benefits of Aspire-generated manifests
-- **Consistent configuration**: Environment variables, ports, and resource references are automatically synchronized
-- **Dependency management**: Services are configured with correct connection strings and service references
-- **Orleans-aware**: The Orleans hosting integration ensures proper silo configuration is included
-- **Helm support**: Generated Helm charts allow parameterized deployments across environments
+- **Consistent configuration**: Environment variables, ports, and resource references are automatically synchronized.
+- **Dependency management**: Services are configured with correct connection strings and service references.
+- **Orleans-aware**: The Orleans hosting integration ensures proper silo configuration is included.
+- **Helm support**: Generated Helm charts allow parameterized deployments across environments.
> [!TIP]
> For production deployments, review and customize the generated manifests as needed. Use [external parameters](https://aspire.dev/get-started/resources/) to configure environment-specific values.
diff --git a/docs/orleans/deployment/snippets/service-fabric/stateless/Orleans.ServiceFabric.Stateless.csproj b/docs/orleans/deployment/snippets/service-fabric/stateless/Orleans.ServiceFabric.Stateless.csproj
index 7f45de7cc575f..fdd8ad1e8238f 100644
--- a/docs/orleans/deployment/snippets/service-fabric/stateless/Orleans.ServiceFabric.Stateless.csproj
+++ b/docs/orleans/deployment/snippets/service-fabric/stateless/Orleans.ServiceFabric.Stateless.csproj
@@ -12,7 +12,7 @@
-
+
diff --git a/docs/orleans/deployment/troubleshooting-azure-cloud-services-deployments.md b/docs/orleans/deployment/troubleshooting-azure-cloud-services-deployments.md
index c7f1324eb4bc8..f76ea41ce1cfa 100644
--- a/docs/orleans/deployment/troubleshooting-azure-cloud-services-deployments.md
+++ b/docs/orleans/deployment/troubleshooting-azure-cloud-services-deployments.md
@@ -20,9 +20,9 @@ ms.custom: devops
This page provides general guidelines for troubleshooting issues occurring when deploying to Azure Cloud Services. These are common issues to watch out for. Check the logs for more detailed information.
-## The
+## SiloUnavailableException
-First, ensure silos start before attempting to initialize the client. Sometimes silos take a long time to start, so trying to initialize the client multiple times can be beneficial. If it still throws an exception, another issue might exist with the silos.
+If your client throws a , first ensure silos start before attempting to initialize the client. Sometimes silos take a long time to start, so trying to initialize the client multiple times can be beneficial. If it still throws an exception, another issue might exist with the silos.
Check the silo configuration and ensure the silos start properly.
diff --git a/docs/orleans/deployment/troubleshooting-deployments.md b/docs/orleans/deployment/troubleshooting-deployments.md
index 4377daa7b4969..510369eef368c 100644
--- a/docs/orleans/deployment/troubleshooting-deployments.md
+++ b/docs/orleans/deployment/troubleshooting-deployments.md
@@ -13,9 +13,9 @@ zone_pivot_groups: orleans-version
This page provides general guidelines for troubleshooting common Orleans deployment issues.
-## The
+## SiloUnavailableException
-This exception indicates that the target silo for a grain call is unavailable. This commonly occurs when:
+A indicates that the target silo for a grain call is unavailable. This commonly occurs when:
- **Silo terminated abruptly**: A silo crashed or was forcefully terminated and has been evicted from the cluster. This is expected behavior during cluster membership changes.
- **Network partition**: The target silo is temporarily unreachable due to network issues.
diff --git a/docs/orleans/grains/event-sourcing/journaledgrain-basics.md b/docs/orleans/grains/event-sourcing/journaledgrain-basics.md
index 587d6efd12a60..d27a96ce71a82 100644
--- a/docs/orleans/grains/event-sourcing/journaledgrain-basics.md
+++ b/docs/orleans/grains/event-sourcing/journaledgrain-basics.md
@@ -27,7 +27,8 @@ int Version { get; }
The version number always equals the total number of confirmed events, and the state is the result of applying all confirmed events to the initial state. The default constructor of the `GrainState` class determines the initial state, which has version 0 (because no events have been applied to it).
-_Important:_ Your application should never directly modify the object returned by . It's meant for reading only. When your application needs to modify the state, it must do so indirectly by raising events.
+> [!IMPORTANT]
+> Never directly modify the object returned by . It's meant for reading only. When your application needs to modify the state, do so indirectly by raising events.
## Raise events
diff --git a/docs/orleans/host/configuration-guide/typical-configurations.md b/docs/orleans/host/configuration-guide/typical-configurations.md
index e86d26d790656..ec5b3ca31b877 100644
--- a/docs/orleans/host/configuration-guide/typical-configurations.md
+++ b/docs/orleans/host/configuration-guide/typical-configurations.md
@@ -332,7 +332,7 @@ For a reliable production deployment using SQL Server, supply a SQL Server conne
> [!NOTE]
> Starting with Orleans 10.0, ADO.NET providers require the `Microsoft.Data.SqlClient` package instead of `System.Data.SqlClient`. Use the invariant `Microsoft.Data.SqlClient` in Orleans 10.0 and later.
-### [Orleans 10.0+](#tab/orleans-10)
+### Orleans 10.0+
```csharp
const string connectionString = "YOUR_CONNECTION_STRING_HERE";
@@ -358,7 +358,7 @@ builder.Logging.SetMinimumLevel(LogLevel.Information).AddConsole();
using var host = builder.Build();
```
-### [Orleans 7.0-9.x](#tab/orleans-7)
+### Orleans 7.0-9.x
```csharp
const string connectionString = "YOUR_CONNECTION_STRING_HERE";
@@ -384,8 +384,6 @@ builder.Logging.SetMinimumLevel(LogLevel.Information).AddConsole();
using var host = builder.Build();
```
----
-
Client configuration:
```csharp
diff --git a/docs/orleans/host/monitoring/index.md b/docs/orleans/host/monitoring/index.md
index 247e6cc7320ad..ee8e805c6e693 100644
--- a/docs/orleans/host/monitoring/index.md
+++ b/docs/orleans/host/monitoring/index.md
@@ -315,36 +315,42 @@ The following table shows a collection of transaction meters used to monitor the
| `orleans-transactions-failed` | | An observable counter representing the number of failed transactions. |
| `orleans-transactions-throttled` | | An observable counter representing the number of throttled transactions. |
-### Prometheus
+### Export metrics
-Various third-party metrics providers are available for use with Orleans. One popular example is [Prometheus](https://prometheus.io), which you can use to collect metrics from your app with OpenTelemetry.
+Various third-party metrics providers are available for use with Orleans. Export metrics from your app using the [OpenTelemetry Protocol (OTLP)](https://opentelemetry.io/docs/specs/otlp/). Many observability platforms consume OTLP data directly or through an OpenTelemetry Collector, including [Prometheus](https://prometheus.io), Grafana, and Azure Monitor.
-To use OpenTelemetry and Prometheus with Orleans, call the following extension method:
+To export metrics using OTLP with Orleans, install the [OpenTelemetry.Exporter.OpenTelemetryProtocol](https://www.nuget.org/packages/OpenTelemetry.Exporter.OpenTelemetryProtocol/) NuGet package and call the following extension method:
```csharp
builder.Services.AddOpenTelemetry()
.WithMetrics(metrics =>
{
metrics
- .AddPrometheusExporter()
+ .AddOtlpExporter()
.AddMeter("Microsoft.Orleans");
});
```
-> [!IMPORTANT]
-> Both the [OpenTelemetry.Exporter.Prometheus](https://www.nuget.org/packages/OpenTelemetry.Exporter.Prometheus) and [OpenTelemetry.Exporter.Prometheus.AspNetCore](https://www.nuget.org/packages/OpenTelemetry.Exporter.Prometheus.AspNetCore) NuGet packages are currently in preview as release candidates. They're not recommended for production use.
+The `AddOtlpExporter` method ensures the OTLP exporter is added to the `builder`. Orleans uses a named `"Microsoft.Orleans"` to create instances for many Orleans-specific metrics. Use the `AddMeter` method to specify the name of the meter to subscribe to, in this case, `"Microsoft.Orleans"`.
-The `AddPrometheusExporter` method ensures the `PrometheusExporter` is added to the `builder`. Orleans uses a named `"Microsoft.Orleans"` to create instances for many Orleans-specific metrics. Use the `AddMeter` method to specify the name of the meter to subscribe to, in this case, `"Microsoft.Orleans"`.
-
-After configuring the exporter and building your app, call `MapPrometheusScrapingEndpoint` on the `IEndpointRouteBuilder` (the `app` instance) to expose the metrics to Prometheus. For example:
+You can configure the OTLP exporter endpoint and other options as needed. For example:
```csharp
-WebApplication app = builder.Build();
-
-app.MapPrometheusScrapingEndpoint();
-app.Run();
+builder.Services.AddOpenTelemetry()
+ .WithMetrics(metrics =>
+ {
+ metrics
+ .AddOtlpExporter(options =>
+ {
+ options.Endpoint = new Uri("http://localhost:4317");
+ })
+ .AddMeter("Microsoft.Orleans");
+ });
```
+> [!NOTE]
+> The default OTLP exporter configuration uses gRPC (typically port `4317`). To export metrics to Prometheus, send telemetry through an OpenTelemetry Collector or configure OTLP/HTTP settings instead.
+
## Distributed tracing
Distributed tracing is a set of tools and practices for monitoring and troubleshooting distributed applications. It's a key component of observability and a critical tool for understanding your app's behavior. Orleans supports distributed tracing with [OpenTelemetry](https://opentelemetry.io).
@@ -356,7 +362,7 @@ Regardless of the distributed tracing exporter you choose, call:
Or set the `EnableDistributedTracing` config option to `true`.
-Referring back to the [Orleans GPS Tracker sample app](/samples/dotnet/samples/orleans-gps-device-tracker-sample), you can use the [Zipkin](https://zipkin.io) distributed tracing system to monitor the app by updating _Program.cs_. To use OpenTelemetry and Zipkin with Orleans, call the following extension method:
+Referring back to the [Orleans GPS Tracker sample app](/samples/dotnet/samples/orleans-gps-device-tracker-sample), you can export distributed traces using the [OpenTelemetry Protocol (OTLP)](https://opentelemetry.io/docs/specs/otlp/). To use OpenTelemetry with OTLP and Orleans, install the [OpenTelemetry.Exporter.OpenTelemetryProtocol](https://www.nuget.org/packages/OpenTelemetry.Exporter.OpenTelemetryProtocol/) NuGet package and call the following extension method in _Program.cs_:
```csharp
builder.Services.AddOpenTelemetry()
@@ -370,17 +376,14 @@ builder.Services.AddOpenTelemetry()
tracing.AddSource("Microsoft.Orleans.Runtime");
tracing.AddSource("Microsoft.Orleans.Application");
- tracing.AddZipkinExporter(zipkin =>
+ tracing.AddOtlpExporter(otlp =>
{
- zipkin.Endpoint = new Uri("http://localhost:9411/api/v2/spans");
+ otlp.Endpoint = new Uri("http://localhost:4317");
});
});
```
-> [!IMPORTANT]
-> The [OpenTelemetry.Exporter.Zipkin](https://www.nuget.org/packages/OpenTelemetry.Exporter.Zipkin) NuGet package is currently in preview as a release candidate. It is not recommended for production use.
-
-The Zipkin trace is shown in the Jaeger UI (an alternative to Zipkin that uses the same data format):
+The OTLP exporter works with many observability backends including Jaeger, Zipkin, Grafana Tempo, and Azure Monitor. The traces can be visualized in tools like Jaeger UI:
:::image type="content" source="../media/jaeger-ui.png" lightbox="../media/jaeger-ui.png" alt-text="Orleans GPS Tracker sample app: Jaeger UI trace.":::
diff --git a/docs/orleans/host/silo-lifecycle.md b/docs/orleans/host/silo-lifecycle.md
index e6395d63cd201..4e727639d4bbb 100644
--- a/docs/orleans/host/silo-lifecycle.md
+++ b/docs/orleans/host/silo-lifecycle.md
@@ -3,7 +3,6 @@ title: Orleans silo lifecycles
description: Learn about .NET Orleans silo lifecycles.
ms.date: 01/22/2026
ms.topic: overview
-zone_pivot_groups: orleans-version
---
# Orleans silo lifecycle overview
diff --git a/docs/orleans/tutorials-and-samples/tutorial-1.md b/docs/orleans/tutorials-and-samples/tutorial-1.md
index 735a6571ee2ee..cc962bf77f685 100644
--- a/docs/orleans/tutorials-and-samples/tutorial-1.md
+++ b/docs/orleans/tutorials-and-samples/tutorial-1.md
@@ -27,8 +27,19 @@ This tutorial lacks appropriate error handling and other essential code useful f
## Prerequisites
+:::zone target="docs" pivot="orleans-8-0,orleans-9-0,orleans-10-0"
+
+- [Visual Studio 2026 or later](https://visualstudio.microsoft.com/downloads)
+- [The latest .NET SDK](https://dotnet.microsoft.com/download/dotnet)
+
+:::zone-end
+
+:::zone target="docs" pivot="orleans-7-0,orleans-3-x"
+
- [Visual Studio 2022 or later](https://visualstudio.microsoft.com/downloads)
-- [.NET 8.0 SDK or later](https://dotnet.microsoft.com/download/dotnet)
+- [.NET SDK compatible with your target Orleans version](https://dotnet.microsoft.com/download/dotnet)
+
+:::zone-end
## Project setup
diff --git a/docs/standard/base-types/regular-expression-source-generators.md b/docs/standard/base-types/regular-expression-source-generators.md
index 6f3c9382548b3..2d9bf2847ff91 100644
--- a/docs/standard/base-types/regular-expression-source-generators.md
+++ b/docs/standard/base-types/regular-expression-source-generators.md
@@ -22,7 +22,7 @@ There are several downsides to `RegexOptions.Compiled`. The most impactful is th
## Source generation
-.NET 7 introduced a new `RegexGenerator` source generator. A *source generator* is a component that plugs into the compiler and augments the compilation unit with additional source code. The .NET SDK (version 7 and later) includes a source generator that recognizes the attribute on a partial method that returns `Regex`. The source generator provides an implementation of that method that contains all the logic for the `Regex`. For example, you previously might have written code like this:
+.NET 7 introduced a new `RegexGenerator` source generator. A *source generator* is a component that plugs into the compiler and augments the compilation unit with additional source code. The .NET SDK includes a source generator that recognizes the attribute on a partial method that returns `Regex`. Starting in .NET 9, the attribute can also be applied to partial properties. The source generator provides an implementation of that method or property that contains all the logic for the `Regex`. For example, you previously might have written code like this:
```csharp
private static readonly Regex s_abcOrDefGeneratedRegex =
@@ -53,6 +53,21 @@ private static void EvaluateText(string text)
}
```
+Starting in .NET 9, you can also apply the `GeneratedRegexAttribute` to a partial property instead of a partial method. This is enabled by C# 13's support for partial properties. The following example shows the property equivalent:
+
+```csharp
+[GeneratedRegex("abc|def", RegexOptions.IgnoreCase, "en-US")]
+private static partial Regex AbcOrDefGeneratedRegexProperty { get; }
+
+private static void EvaluateText(string text)
+{
+ if (AbcOrDefGeneratedRegexProperty.IsMatch(text))
+ {
+ // Take action with matching text
+ }
+}
+```
+
> [!TIP]
> The `RegexOptions.Compiled` flag is ignored by the source generator, thus it's not needed in the source-generated version.
@@ -67,7 +82,7 @@ But as can be seen, it's not just doing `new Regex(...)`. Rather, the source gen
:::image type="content" source="media/regular-expression-source-generators/debuggable-source.png" lightbox="media/regular-expression-source-generators/debuggable-source.png" alt-text="Debugging through source-generated Regex code":::
> [!TIP]
-> In Visual Studio, right-click on your partial method declaration and select **Go To Definition**. Or, alternatively, select the project node in **Solution Explorer**, then expand **Dependencies** > **Analyzers** > **System.Text.RegularExpressions.Generator** > **System.Text.RegularExpressions.Generator.RegexGenerator** > _RegexGenerator.g.cs_ to see the generated C# code from this regex generator.
+> In Visual Studio, right-click on your partial method or property declaration and select **Go To Definition**. Or, alternatively, select the project node in **Solution Explorer**, then expand **Dependencies** > **Analyzers** > **System.Text.RegularExpressions.Generator** > **System.Text.RegularExpressions.Generator.RegexGenerator** > _RegexGenerator.g.cs_ to see the generated C# code from this regex generator.
You can set breakpoints in it, you can step through it, and you can use it as a learning tool to understand exactly how the regex engine is processing your pattern with your input. The generator even generates [triple-slash (XML) comments](../../csharp/language-reference/xmldoc/index.md) to help make the expression understandable at a glance and where it's used.