docs: fix typos across documentation and specs - #14818
Conversation
|
@vaibhav8a please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement ( “Agreement” ) is agreed to by the party signing below ( “You” ), 1. Definitions. “Code” means the computer software code, whether in human-readable or machine-executable form, “Project” means any of the projects owned or managed by .NET Foundation and offered under a license “Submit” is the act of uploading, submitting, transmitting, or distributing code or other content to any “Submission” means the Code and any other copyrightable material Submitted by You, including any 2. Your Submission. You must agree to the terms of this Agreement before making a Submission to any 3. Originality of Work. You represent that each of Your Submissions is entirely Your 4. Your Employer. References to “employer” in this Agreement include Your employer or anyone else 5. Licenses. a. Copyright License. You grant .NET Foundation, and those who receive the Submission directly b. Patent License. You grant .NET Foundation, and those who receive the Submission directly or c. Other Rights Reserved. Each party reserves all rights not expressly granted in this Agreement. 6. Representations and Warranties. You represent that You are legally entitled to grant the above 7. Notice to .NET Foundation. You agree to notify .NET Foundation in writing of any facts or 8. Information about Submissions. You agree that contributions to Projects and information about 9. Governing Law/Jurisdiction. This Agreement is governed by the laws of the State of Washington, and 10. Entire Agreement/Assignment. This Agreement is the entire agreement between the parties, and .NET Foundation dedicates this Contribution License Agreement to the public domain according to the Creative Commons CC0 1. |
There was a problem hiding this comment.
Pull request overview
This PR focuses on improving documentation quality by correcting typos across several docs and spec markdown files, without changing MSBuild behavior or APIs.
Changes:
- Corrects multiple misspellings in docs/specs (e.g., “overriden” → “overridden”, “sytem” → “system”, “recieve” → “receive”).
- Updates wording typos in proposed specs and wiki documentation to improve readability and professionalism.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| documentation/Logging-behavior.md | Fixes a typo in console logger description (“overridden”). |
| documentation/Persistent-Problems.md | Fixes a typo in evaluation section (“system”). |
| documentation/specs/project-cache.md | Fixes spelling of “receive/received” in project cache spec. |
| documentation/specs/proposed/evaluation-perf.md | Fixes spelling of “unknown” in evaluation perf spec. |
| documentation/specs/proposed/interactive-package-references.md | Fixes spelling of “appropriate” in interactive package references spec. |
| documentation/specs/proposed/security-metadata.md | Fixes spelling of “recommended” in security metadata spec. |
| documentation/specs/test-target.md | Fixes spelling of “implementation” in test target spec. |
| documentation/wiki/Controlling-Dependencies-Behavior.md | Fixes spelling of “appropriate” in dependency behavior wiki doc. |
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
| **Notes:** | ||
|
|
||
| `SetTargetFramework` is currently not honored by the NuGet client([nuget issue #12436](https://github.com/NuGet/Home/issues/12436)), so the output folder will contain binaries from nuget packages as if this metadata was not used. To workaround this the apropriate nuget needs to be directly referenced from the project enforcing reference framework via `SetTargetFramework`, or copied to output/publish folder via different means. | ||
| `SetTargetFramework` is currently not honored by the NuGet client([nuget issue #12436](https://github.com/NuGet/Home/issues/12436)), so the output folder will contain binaries from nuget packages as if this metadata was not used. To workaround this the appropriate nuget needs to be directly referenced from the project enforcing reference framework via `SetTargetFramework`, or copied to output/publish folder via different means. |
| **Notes:** | ||
|
|
||
| `SetTargetFramework` is currently not honored by the NuGet client([nuget issue #12436](https://github.com/NuGet/Home/issues/12436)), so the output folder will contain binaries from nuget packages as if this metadata was not used. To workaround this the apropriate nuget needs to be directly referenced from the project enforcing reference framework via `SetTargetFramework`, or copied to output/publish folder via different means. | ||
| `SetTargetFramework` is currently not honored by the NuGet client([nuget issue #12436](https://github.com/NuGet/Home/issues/12436)), so the output folder will contain binaries from nuget packages as if this metadata was not used. To workaround this the appropriate nuget needs to be directly referenced from the project enforcing reference framework via `SetTargetFramework`, or copied to output/publish folder via different means. |
| ## Evaluation | ||
|
|
||
| *Every* [batch build]() (absent a higher-order build system) must evaluate every project in the scope of the build. IDEs can cache evaluation and act as a higher-order builds sytem but important IDE scenarios like “first load after a repo clone” are dominated by evaluation. | ||
| *Every* [batch build]() (absent a higher-order build system) must evaluate every project in the scope of the build. IDEs can cache evaluation and act as a higher-order builds system but important IDE scenarios like “first load after a repo clone” are dominated by evaluation. |
|
|
||
| ## Description | ||
| Current performance state of evaluation is mostly unkown, we have a few measures but no easy way of accessing and assessing them. As such, we are unsure which specific areas can be improve. | ||
| Current performance state of evaluation is mostly unknown, we have a few measures but no easy way of accessing and assessing them. As such, we are unsure which specific areas can be improve. |
| For a given project, `GetCacheResultAsync` will be invoked, but will end up returning a cache miss since the cache is empty. | ||
|
|
||
| MSBuild will then build the project normally but under a detoured worker node. Because of this, the plugin will recieve `HandleFileAccess` and `HandleProcess` events. In this example implementation we will ignore `HandleProcess`. For `HandleFileAccess`, the plugin will simply store all `FileAccessData`s for a `FileAccessContext` to build up a list of all file accesses during the build. The plugin may decide to avoid storing the entire `FileAccessData` and instead just peel off the data it finds relevant (eg. paths, whether it was a read or write, etc). | ||
| MSBuild will then build the project normally but under a detoured worker node. Because of this, the plugin will receive `HandleFileAccess` and `HandleProcess` events. In this example implementation we will ignore `HandleProcess`. For `HandleFileAccess`, the plugin will simply store all `FileAccessData`s for a `FileAccessContext` to build up a list of all file accesses during the build. The plugin may decide to avoid storing the entire `FileAccessData` and instead just peel off the data it finds relevant (eg. paths, whether it was a read or write, etc). |
|
|
||
| * New data type - this is part of the [North Star vision](#north-star--longer-term-vision), but is out of scope for the initial iteration. | ||
| * [Not recomended] Denoting those via some metadata on a definition of the data to be redacted - this has two main drawbacks - a) For some data types (properties, metadata) we'd need new constructs how to attach additional info (property metadata; item meta-metadata). b) some data can be defined implicitly or dynamicaly | ||
| * [Not recommended] Denoting those via some metadata on a definition of the data to be redacted - this has two main drawbacks - a) For some data types (properties, metadata) we'd need new constructs how to attach additional info (property metadata; item meta-metadata). b) some data can be defined implicitly or dynamicaly |
Nine typo fixes in documentation:
documentation/Logging-behavior.md:37overriden→overriddendocumentation/Persistent-Problems.md:9sytem→systemdocumentation/specs/project-cache.md:168,170recieve/recieved→receive/receiveddocumentation/specs/proposed/evaluation-perf.md:5unkown→unknowndocumentation/specs/proposed/interactive-package-references.md:9apropriate→appropriatedocumentation/specs/proposed/security-metadata.md:121recomended→recommendeddocumentation/specs/test-target.md:70implemenation→implementationdocumentation/wiki/Controlling-Dependencies-Behavior.md:284apropriate→appropriateDocs prose only — no property names, targets, or code changed.