-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge remote-tracking branch 'upstream/main' into fix-21708
- Loading branch information
Showing
3,844 changed files
with
13,182 additions
and
203,661 deletions.
The diff you're trying to view is too large. We only load the first 3000 changed files.
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,41 @@ | ||
| <!-- BEGIN MICROSOFT SECURITY.MD V0.0.9 BLOCK --> | ||
|
|
||
| ## Security | ||
|
|
||
| Microsoft takes the security of our software products and services seriously, which includes all source code repositories managed through our GitHub organizations, which include [Microsoft](https://github.com/Microsoft), [Azure](https://github.com/Azure), [DotNet](https://github.com/dotnet), [AspNet](https://github.com/aspnet) and [Xamarin](https://github.com/xamarin). | ||
|
|
||
| If you believe you have found a security vulnerability in any Microsoft-owned repository that meets [Microsoft's definition of a security vulnerability](https://aka.ms/security.md/definition), please report it to us as described below. | ||
|
|
||
| ## Reporting Security Issues | ||
|
|
||
| **Please do not report security vulnerabilities through public GitHub issues.** | ||
|
|
||
| Instead, please report them to the Microsoft Security Response Center (MSRC) at [https://msrc.microsoft.com/create-report](https://aka.ms/security.md/msrc/create-report). | ||
|
|
||
| If you prefer to submit without logging in, send email to [[email protected]](mailto:[email protected]). If possible, encrypt your message with our PGP key; please download it from the [Microsoft Security Response Center PGP Key page](https://aka.ms/security.md/msrc/pgp). | ||
|
|
||
| You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Additional information can be found at [microsoft.com/msrc](https://www.microsoft.com/msrc). | ||
|
|
||
| Please include the requested information listed below (as much as you can provide) to help us better understand the nature and scope of the possible issue: | ||
|
|
||
| * Type of issue (e.g. buffer overflow, SQL injection, cross-site scripting, etc.) | ||
| * Full paths of source file(s) related to the manifestation of the issue | ||
| * The location of the affected source code (tag/branch/commit or direct URL) | ||
| * Any special configuration required to reproduce the issue | ||
| * Step-by-step instructions to reproduce the issue | ||
| * Proof-of-concept or exploit code (if possible) | ||
| * Impact of the issue, including how an attacker might exploit the issue | ||
|
|
||
| This information will help us triage your report more quickly. | ||
|
|
||
| If you are reporting for a bug bounty, more complete reports can contribute to a higher bounty award. Please visit our [Microsoft Bug Bounty Program](https://aka.ms/security.md/msrc/bounty) page for more details about our active programs. | ||
|
|
||
| ## Preferred Languages | ||
|
|
||
| We prefer all communications to be in English. | ||
|
|
||
| ## Policy | ||
|
|
||
| Microsoft follows the principle of [Coordinated Vulnerability Disclosure](https://aka.ms/security.md/cvd). | ||
|
|
||
| <!-- END MICROSOFT SECURITY.MD BLOCK --> |
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,73 @@ | ||
| # When all check suites are completed successfully, the workflow adds a label to the pull request. | ||
| # When a new check suite is requested (or rerequested), the workflow removes the label from the pull request. | ||
| name: Manage Label on Check Suites | ||
|
|
||
| on: | ||
| check_suite: | ||
| types: [completed, requested, rerequested] | ||
|
|
||
| jobs: | ||
| add-label: | ||
| if: github.event.action == 'completed' | ||
| runs-on: ubuntu-latest | ||
|
|
||
| steps: | ||
| - name: Checkout repository | ||
| uses: actions/checkout@v3 | ||
|
|
||
| - name: Check if all check suites are successful | ||
| id: check_suites | ||
| uses: actions/github-script@v6 | ||
| with: | ||
| script: | | ||
| const { data: checkSuites } = await github.checks.listSuitesForRef({ | ||
| owner: context.repo.owner, | ||
| repo: context.repo.repo, | ||
| ref: context.payload.check_suite.head_sha, | ||
| }); | ||
| const allSuccessful = checkSuites.check_suites.every( | ||
| suite => suite.conclusion === 'success' || suite.conclusion === 'skipped'); | ||
| if (allSuccessful) { | ||
| return { success: true }; | ||
| } else { | ||
| return { success: false }; | ||
| } | ||
| - name: Add label if all check suites are successful | ||
| if: steps.check_suites.outputs.success == 'true' | ||
| uses: actions/github-script@v6 | ||
| with: | ||
| script: | | ||
| const pullRequest = context.payload.check_suite.pull_requests[0]; | ||
| if (pullRequest) { | ||
| github.issues.addLabels({ | ||
| owner: context.repo.owner, | ||
| repo: context.repo.repo, | ||
| issue_number: pullRequest.number, | ||
| labels: 'all-checks-passed', | ||
| }); | ||
| } | ||
| remove-label: | ||
| if: github.event.action == 'requested' || github.event.action == 'rerequested' | ||
| runs-on: ubuntu-latest | ||
|
|
||
| steps: | ||
| - name: Checkout repository | ||
| uses: actions/checkout@v3 | ||
|
|
||
| - name: Remove label when check suite is triggered or re-requested | ||
| uses: actions/github-script@v6 | ||
| with: | ||
| script: | | ||
| const pullRequest = context.payload.check_suite.pull_requests[0]; | ||
| if (pullRequest) { | ||
| github.issues.removeLabel({ | ||
| owner: context.repo.owner, | ||
| repo: context.repo.repo, | ||
| issue_number: pullRequest.number, | ||
| name: 'all-checks-passed', | ||
| }); | ||
| } |
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 was deleted.
Oops, something went wrong.
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 |
|---|---|---|
| @@ -1,36 +1,36 @@ | ||
| # Code Documentation Guidelines | ||
|
|
||
| In this document you will find the guidelines for adding XML comments to our codebase. By adding consistent and well-formatted comments to our code we benefit on all fronts: the online API docs are a useful reference for people looking up our APIs, the IntelliSense inside of Visual Studio will help developers understand our product better, and contributors and maintainers of this repository will have all the documentation at hand. | ||
| In this document you will find the guidelines for adding XML comments to our codebase. By adding consistent and well-formatted comments to our code, we benefit on all fronts: the online API docs are a useful reference for people looking up our APIs, the IntelliSense inside of Visual Studio will help developers understand our product better, and contributors and maintainers of this repository will have all the documentation at hand. | ||
|
|
||
| ## Guidelines | ||
|
|
||
| For what kind of comments to our code we mainly follow the [recommended XML tags documentation](https://learn.microsoft.com/dotnet/csharp/language-reference/xmldoc/recommended-tags) by Microsoft. This is also what is best supported by Visual Studio. As a rule of thumb: complete your code first and just start typing a triple slash (`///`) above your code. That will suggest all the attributes that we want to see. Which attributes will show up is inferred from your code. | ||
| For comments on our code, we primarily follow the [recommended XML tags documentation](https://learn.microsoft.com/dotnet/csharp/language-reference/xmldoc/recommended-tags) by Microsoft. These tags are also best supported by Visual Studio. As a rule of thumb, complete your code first and just start typing a triple slash (`///`) above your code. This will suggest all the attributes we expect to see. The attributes that appear are inferred from your code. | ||
|
|
||
| If you're unsure about how to document a certain element, have a look the [.NET API docs wiki](https://github.com/dotnet/dotnet-api-docs/wiki) which has a very extensive description on what kind of comment to add on which element in the code. We would highly recommend going through that and applying the same style of comments everywhere. | ||
| If you're unsure about how to document a certain element, have a look at the [.NET API docs wiki](https://github.com/dotnet/dotnet-api-docs/wiki) which has a very extensive description of what kind of comment to add on which element in the code. We would highly recommend going through that and applying the same style of comments everywhere. | ||
|
|
||
| These are the tags that we would like to see when applicable: `<summary>`, `<remarks>`, `<returns>`, `<param>`, `<exception>`, `<inheritdoc>`, `<see>`, `<c>`. | ||
|
|
||
| * All public members should have at the very least a `<summary>` | ||
| * Add "This is a bindable property." to the end of the summary of the regular C# properties that are bindable properties. | ||
| * Keep the descriptions short and concise | ||
| * 1-2 lines typically, no screenshots or long code-blocks (those belong in the conceptual docs) | ||
| * 1-2 lines typically, no screenshots or long code blocks (those belong in the conceptual docs) | ||
| * Make sure the spelling is correct | ||
| * Add the descriptions at the highest base class/interface level. On an implementing type add `<inheritdoc/>` on each member | ||
| * If the implemented member differs too much you can choose to override the comments; typically this shouldn't be necessary | ||
| * Add the descriptions at the highest base class/interface level. On an implementing type, add `<inheritdoc/>` on each member | ||
| * If the implemented member differs too much, you can choose to override the comments; typically this shouldn't be necessary | ||
| * When adding `<inheritdoc/>` on a class where you want to inherit the comments from an interface, you will have to be explicit about which interface to inherit from. Even if the class only implements one interface. For example: `<inheritdoc cref="IEntry"/>` will inherit the comments from the `IEntry` interface. | ||
| * Do **not** add `<inheritdoc/>` to overridden members, this will potentially cause issues in the online API docs system and doesn't add any value. The documentation is inherited implicitly. | ||
| * Where applicable make references to other types and parameters with the appropriate tags (`<see cref="YourType"/>` and `<paramref name="parameterName"/>` respectively). This will create links in IntelliSense and online API docs | ||
| * Reference all C# keywords with a `<see langword="keyword"/>` tag. For example for `true`: `<see langword="true"/>` | ||
| * If you do want to add a minimal amount of code in your comment, use the `<c></c>` tags which formats it as code | ||
| * Do **not** add `<inheritdoc/>` to overridden members; this will potentially cause issues in the online API docs system and doesn't add any value. The documentation is inherited implicitly. | ||
| * Where applicable, make references to other types and parameters with the appropriate tags (`<see cref="YourType"/>` and `<paramref name="parameterName"/>` respectively). This will create links in IntelliSense and online API docs | ||
| * Reference all C# keywords with a `<see langword="keyword"/>` tag. For example, for `true`: `<see langword="true"/>` | ||
| * If you do want to add a minimal amount of code in your comment, use the `<c></c>` tags, which format it as code | ||
| * Think of things you'd like to know as a developer/future-you maintainer: | ||
| * default values that are not obvious | ||
| * in which scale a value should be (seconds or milliseconds, 0.0 is nothing 1.0 is everything) | ||
| * what exceptions can you expect and what triggers them | ||
| * what exceptions can you expect, and what triggers them? | ||
|
|
||
| If you are looking for examples, browse through the codebase, searching for the `<summary>` tag or `///` should give you all kinds of examples. | ||
| If you are looking for examples, browsing through the codebase, searching for the `<summary>` tag or `///` should give you all kinds of examples. | ||
|
|
||
| ## "Testing" the documentation | ||
|
|
||
| You can "test" the docs by simply hovering over the type in Visual Studio. The IntelliSense updates should be instantaneous when you have edited something. See image below for an example. | ||
| You can "test" the docs by simply hovering over the type in Visual Studio. The IntelliSense updates should be instantaneous when you have edited something. See the image below for an example. | ||
|
|
||
|  |
Oops, something went wrong.