style: add language to code snippets (#36701)

Author: timdeschryver

aspnetcore/fundamentals/servers/yarp/ab-testing.md

@@ -18,7 +18,7 @@ A/B testing and rolling upgrades require procedures for dynamically assigning in
 
 ## Example
 
-```
+```csharp
 app.MapReverseProxy(proxyPipeline =>
 {
     // Custom cluster selection

aspnetcore/fundamentals/servers/yarp/authn-authz.md

@@ -51,7 +51,8 @@ Example:
 [Authorization policies](/aspnet/core/security/authorization/policies) are an ASP.NET Core concept that the proxy utilizes. The proxy provides the above configuration to specify a policy per route and the rest is handled by existing ASP.NET Core authentication and authorization components.
 
 Authorization policies can be configured in the application as follows:
-```
+
+```csharp
 services.AddAuthorization(options =>
 {
     options.AddPolicy("customPolicy", policy =>
@@ -61,7 +62,7 @@ services.AddAuthorization(options =>
 
 In Program.cs add the Authorization and Authentication middleware.
 
-```
+```csharp
 app.UseAuthentication();
 app.UseAuthorization();
 

aspnetcore/fundamentals/servers/yarp/config-providers.md

@@ -42,13 +42,13 @@ For additional fields see [ClusterConfig](xref:Yarp.ReverseProxy.Configuration.C
 
 The `InMemoryConfigProvider` implements `IProxyConfigProvider` and enables specifying routes and clusters directly in code by calling `LoadFromMemory`.
 
-```
+```csharp
 services.AddReverseProxy().LoadFromMemory(routes, clusters);
 ```
 
 To update the config later, resolve the `InMemoryConfigProvider` from the services container and call `Update` with the new lists of routes and clusters.
 
-```
+```csharp
 httpContext.RequestServices.GetRequiredService<InMemoryConfigProvider>().Update(routes, clusters);
 ```
 
@@ -87,13 +87,15 @@ Once the new configuration has been validated and applied, the proxy will regist
 ## Multiple Configuration Sources
 As of 1.1, YARP supports loading the proxy configuration from multiple sources. Multiple `IProxyConfigProvider`'s can be registered as singleton services and all will be resolved and combined. The sources may be the same or different types such as IConfiguration or InMemory. Routes can reference clusters from other sources. Note merging partial config from different sources for a given route or cluster is not supported.
 
-```
+```csharp
     services.AddReverseProxy()
         .LoadFromConfig(Configuration.GetSection("ReverseProxy1"))
         .LoadFromConfig(Configuration.GetSection("ReverseProxy2"));
 ```
+
 or
-```
+
+```csharp
     services.AddReverseProxy()
         .LoadFromMemory(routes, clusters)
         .LoadFromConfig(Configuration.GetSection("ReverseProxy"));

aspnetcore/fundamentals/servers/yarp/cors.md

@@ -51,7 +51,7 @@ Example:
 [CORS policies](/aspnet/core/security/cors#cors-with-named-policy-and-middleware) are an ASP.NET Core concept that the proxy utilizes. The proxy provides the above configuration to specify a policy per route and the rest is handled by existing ASP.NET Core CORS Middleware.
 
 CORS policies can be configured in the application as follows:
-```
+```csharp
 services.AddCors(options =>
 {
     options.AddPolicy("customPolicy", builder =>
@@ -63,7 +63,7 @@ services.AddCors(options =>
 
 Then add the CORS middleware.
 
-```
+```csharp
 app.UseCors();
 
 app.MapReverseProxy();

aspnetcore/fundamentals/servers/yarp/dests-health-checks.md

@@ -280,6 +280,7 @@ Global parameters are set via the options mechanism using `TransportFailureRateH
 * `DefaultFailureRateLimit` - default failure rate limit for a destination to be marked as unhealthy that is applied if it's not set on a cluster's metadata. The value is in range `(0,1)`. Default is `0.3` (30%).
 
 Global policy options can be set in code as follows:
+
 ```csharp
 services.Configure<TransportFailureRateHealthPolicyOptions>(o =>
 {

aspnetcore/fundamentals/servers/yarp/kubernetes-ingress.md

@@ -41,7 +41,7 @@ Before we continue with this tutorial, make sure you have the following ready...
 
 In the meantime, the YARP ingress controller must be built locally and deploy it. In the root of the repository, run:
 
-```
+```bash
 docker build . -t {REGISTRY_NAME}/yarp-controller:{TAG} -f .\src\Kubernetes.Controller\Dockerfile
 docker push {REGISTRY_NAME}/yarp-controller:{TAG}
 ```
@@ -51,27 +51,27 @@ In the preceding commands, the `{REGISTRY_NAME}` placeholder is the name of the
 The first step is to deploy the YARP ingress controller to the Kubernetes cluster. This can be done by navigating to [Kubernetes Ingress sample](https://github.com/dotnet/yarp/tree/release/latest/samples/KubernetesIngress.Sample) `\samples\KubernetesIngress.Sample\Ingress`
 and running (after modifying `ingress-controller.yaml` with the same `REGISTRY_NAME` and `TAG`):
 
-```
+```bash
 kubectl apply -f ingress-controller.yaml
 ```
 
 To verify that the ingress controller has been deployed, run:
 
-```
+```bash
 kubectl get pods -n yarp
 ```
 
 You can then check logs from the ingress controller by running:
 
-```
+```bash
 kubectl logs {POD NAME} -n yarp
 ```
 
 All services, deployments, and pods for YARP are in the namespace `yarp`. Make sure to include `-n yarp` if you want to check on the status of yarp.
 
 Next, build and deploy the ingress. In the root of the repository, run:
 
-```
+```bash
 docker build . -t {REGISTRY_NAME}/yarp:<TAG> -f .\samples\KuberenetesIngress.Sample\Ingress\Dockerfile
 docker push {REGISTRY_NAME}/yarp:{TAG}
 ```
@@ -80,7 +80,7 @@ In the preceding commands, the `{REGISTRY_NAME}` placeholder is the name of the
 
 Finally, we need to deploy the ingress itself to Kubernetes. Navigate to the `Ingress` directory and modify the `ingress.yaml` file for your registry and tag specified earlier and run:
 
-```
+```bash
 kubectl apply -f .\ingress.yaml
 ```
 
@@ -90,28 +90,28 @@ At this point, your ingress and controller should be running.
 
 To use the ingress, we now need to deploy an application to Kubernetes. Navigate to `samples\KuberenetesIngress.Sample\backend` and run:
 
-```
+```bash
 docker build . -t {REGISTRY_NAME}/backend:{TAG}
 docker push {REGISTRY_NAME}/backend:{TAG}
 ```
 
 And deploying it to Kubernetes by running, after modifying `backend.yaml` with the same registry name (`{REGISTRY_NAME}`) and tag (`{TAG}`):
 
-```
+```bash
 kubectl apply -f .\backend.yaml
 ```
 
 ## Creating the ingress definition
 
 Finally, once we have deployed the backend application, we need to route traffic to the backend. To do this, run in the `backend` directory:
 
-```
+```bash
 kubectl apply -f .\ingress-sample.yaml
 ```
 
 And then execute the following command to get the external IP of the ingress, the name of the related service being `yarp-proxy`:
 
-```
+```bash
 kubectl get service -n yarp
 ```
 

aspnetcore/fundamentals/servers/yarp/lets-encrypt.md

@@ -23,7 +23,7 @@ YARP can support the certificate authority [Lets Encrypt](https://letsencrypt.or
 
 Add the `LettuceEncrypt` package dependency:
 
-```csproj
+```xml
 <PackageReference Include="LettuceEncrypt" Version="1.1.2" />
 ```
 

aspnetcore/fundamentals/servers/yarp/middleware.md

@@ -36,7 +36,7 @@ Middleware added to your application pipeline will see the request in different
 
 [ReverseProxyIEndpointRouteBuilderExtensions](xref:Microsoft.AspNetCore.Builder.ReverseProxyIEndpointRouteBuilderExtensions) provides an overload of `MapReverseProxy` that lets you build a middleware pipeline that will run only for requests matched to proxy configured routes.
 
-```
+```csharp
 app.MapReverseProxy(proxyPipeline =>
 {
     proxyPipeline.Use((context, next) =>

aspnetcore/fundamentals/servers/yarp/rate-limiting.md

@@ -22,6 +22,7 @@ The reverse proxy can be used to rate-limit requests before they are proxied to
 No rate limiting is performed on requests unless enabled in the route or application configuration. However, the Rate Limiting middleware (`app.UseRateLimiter()`) can apply a default limiter applied to all routes, and this doesn't require any opt-in from the config.
 
 Example:
+
 ```csharp
 services.AddRateLimiter(options => options.GlobalLimiter = globalLimiter);
 ```
@@ -58,6 +59,7 @@ Example:
 [RateLimiter policies](/aspnet/core/performance/rate-limit) are an ASP.NET Core concept that the proxy utilizes. The proxy provides the above configuration to specify a policy per route and the rest is handled by existing ASP.NET Core rate limiting middleware.
 
 RateLimiter policies can be configured in services as follows:
+
 ```csharp
 services.AddRateLimiter(options =>
 {

aspnetcore/fundamentals/servers/yarp/session-affinity.md

@@ -20,6 +20,7 @@ Session affinity is a mechanism to bind (affinitize) a causally related request
 Session affinity services are registered in the DI container automatically by `AddReverseProxy()`. The middleware `UseSessionAffinity()` is included by default in the parameterless MapReverseProxy method. If you are customizing the proxy pipeline, place the first middleware **before** adding `UseLoadBalancing()`.
 
 Example:
+
 ```csharp
 app.MapReverseProxy(proxyPipeline =>
 {