Merge main into live

docs/core/rid-catalog.md

@@ -56,7 +56,7 @@ The above RID specifies that `osx-x64` imports `unix-x64`. So, when NuGet restor
 The following example shows a slightly bigger RID graph also defined in the *runtime.json*  file:
 
 ```
-    linux-arm64     linux-arm32
+    linux-arm64     linux-x64
          |     \   /     |
          |     linux     |
          |       |       |

docs/csharp/whats-new/csharp-14.md

@@ -39,7 +39,7 @@ public static class Enumerable
         // Extension property:
         public bool IsEmpty => source.Any() == false;
         // Extension indexer:
-        public int this[int index] => source.Skip(index).First();
+        public TSource this[int index] => source.Skip(index).First();
 
         // Extension method:
         public IEnumerable<TSource> Where(Func<TSource, bool> predicate) { ... }

docs/fsharp/language-reference/task-expressions.md

@@ -68,6 +68,28 @@ let makeTask() =
 makeTask() |> ValueTask<int>
 ```
 
+## `and!` bindings (starting from F# 10)
+
+Within task expressions, it is possible to concurrently await for multiple asynchronous operations (`Task<'T>`, `ValueTask<'T>`, `Async<'T>` etc). Compare:
+
+```fsharp
+// We'll wait for x to resolve and then for y to resolve. Overall execution time is sum of two execution times.
+let getResultsSequentially() =
+    task {
+        let! x = getX()
+        let! y = getY()
+        return x, y
+    }
+
+// x and y will be awaited concurrently. Overall execution time is the time of the slowest operation.
+let getResultsConcurrently() =
+    task {
+        let! x = getX()
+        and! y = getY()
+        return x, y
+    }
+```
+
 ## Adding cancellation tokens and cancellation checks
 
 Unlike F# async expressions, task expressions do not implicitly pass a cancellation token and don't implicitly perform cancellation checks. If your code requires a cancellation token, you should specify the cancellation token as a parameter. For example:

docs/standard/library-guidance/strong-naming.md

@@ -43,11 +43,13 @@ You should strong name your open-source .NET libraries if their targets include
 
 ✔️ CONSIDER strong naming your library's assemblies.
 
-✔️ CONSIDER adding the strong naming key to your source control system.
+✔️ CONSIDER adding the strong naming key pair (public + private) to your source control system.
 
-> A publicly available key lets developers modify and recompile your library source code with the same key.
+> A publicly available key pair lets developers modify and recompile your library source code with the same key.
 >
-> You shouldn't make the strong naming key public if it has been used in the past to give special permissions in [partial-trust scenarios](/previous-versions/dotnet/framework/code-access-security/using-libraries-from-partially-trusted-code). Otherwise, you might compromise existing environments.
+> You shouldn't make the strong naming key pair public if it has been used in the past to give special permissions in [partial-trust scenarios](/previous-versions/dotnet/framework/code-access-security/using-libraries-from-partially-trusted-code). Otherwise, you might compromise existing environments.
+>
+> If you can't check in the public + private key pair, then check in the public key and use [public signing](../../csharp/language-reference/compiler-options/security.md#publicsign) for regular builds. Public signing still allows developers to recompile and use your library in most scenarios.
 
 > [!IMPORTANT]
 > When the identity of the publisher of the code is desired, [Authenticode](/windows-hardware/drivers/install/authenticode) and [NuGet Package Signing](/nuget/create-packages/sign-a-package) are recommended. Code Access Security (CAS) should not be used as a security mitigation.