Fix .NET branding in public docs (#6925)

* Fix .NET branding in public docs

Was an attempt to try fixing issue #6924 but it seems that code may live elsewhere. Figured I might as well update public-facing first-party branding in this repo while I was in here.

* Update src/dotnet/APIView/APIViewWeb/CONTRIBUTING.md

Co-authored-by: Mariana Rios Flores <[email protected]>

* Resolve PR feedback

---------

Co-authored-by: Mariana Rios Flores <[email protected]>

packages/python-packages/doc-warden/README.md

@@ -224,7 +224,7 @@ the `package_indexing_exclusion_list` array members to enable just this sort of
 
 `package_indexing_traversal_stops` is used during parse of .NET language repos _only_. This is due to how the discovery logic for readme and changelog is implemented for .NET projects. Specifically, readmes for a .csproj are often a couple directories up from their parent .csproj location!
 
-For .net, `warden` will traverse **up** one directory at a time, looking for the readme and changelog files in each traversed directory. `warden` will continue to traverse until...
+For .NET, `warden` will traverse **up** one directory at a time, looking for the readme and changelog files in each traversed directory. `warden` will continue to traverse until...
 
 1. It discovers a folder with a `.sln` within it
 2. It encounters a folder that exactly matches one present in `package_indexing_traversal_stops`

src/dotnet/APIView/APIViewWeb/CONTRIBUTING.md

@@ -14,7 +14,7 @@ contact [[email protected]](mailto:[email protected]) with any additio
 
 ## Where to begin
 
-Core of the APIView tool is the web app developed using ASP.Net and TypeScript. This core module takes care of presenting reviews to users, storing review files and metadata in Azure Storage Account and Cosmos database and process requests from Azure Devops pipelines and respond. We also have language level parsers that converts each language specific artifact into a common json stub file that's known to core APIView web app. So, first step as a contributor is to understand the feature or bug fix you would like to submit and identify the area you would like to contribute to. Language parsers are either added as plugin modules developed in .Net or developed using corresponding language as command line tool to extract and generate stub file. If change is specific to a language in how langauge specific API details are extracted to stub tokens then change will be at parser level for that language. If change is applicable for all languages then change will most likely be in core APIView web app.
+Core of the APIView tool is the web app developed using ASP.NET and TypeScript. This core module takes care of presenting reviews to users, storing review files and metadata in Azure Storage Account and Cosmos database and process requests from Azure Devops pipelines and respond. We also have language level parsers that converts each language specific artifact into a common json stub file that's known to core APIView web app. So, first step as a contributor is to understand the feature or bug fix you would like to submit and identify the area you would like to contribute to. Language parsers are either added as plugin modules developed in .NET or developed using corresponding language as command line tool to extract and generate stub file. If change is specific to a language in how langauge specific API details are extracted to stub tokens then change will be at parser level for that language. If change is applicable for all languages then change will most likely be in core APIView web app.
 
 
 | Module                        | Source Path                                                                                                                     |
@@ -39,7 +39,7 @@ Following are tools required to develop and run test instance of APIView to veri
 
 - Git
 - Visual Studio
-- .Net
+- .NET
 - Any LTS version of Node.js [download](https://nodejs.org/en/download/)
 - Java (Optional: Only required if you want to generate Java review locally)
 - Python 3.9+ (Optional: Only required if you want to generate Python review locally)

src/dotnet/APIView/apiview.yml

@@ -172,7 +172,7 @@ stages:
           - pwsh: |
               dotnet --list-runtimes
               dotnet --version
-            displayName: 'List .Net run times'
+            displayName: 'List .NET run times'
 
           - task: GoTool@0
             inputs:

tools/assets-automation/asset-sync/README.md

@@ -151,8 +151,8 @@ TODO: Read about this option.
 - The physical drive the enlistment is on seems to matter more when using LFS -  For example: two machines, both physically in Redmond  and on corpnet, one was a single spinning drive and the other was an array, the clone time difference was negligible (30 vs 22 seconds) but the checkout times were wildly variant (18 seconds vs 2 minutes and 58 seconds)
 - Distance matters – Fetching from Redmond produced very different numbers than fetching from Australia. On average clone times were double of what we’d see on corpnet and still around a minute, but the checkout times were horrendous. Non-LFS checkout had an average of 32 seconds where the LFS checkouts were taking an average of 8 minutes. Note: This was on an SSD, not a spinning disk.
 - Git LFS files are pulled individually - There’s no way to bulk pull everything. The files are pulled over https with a default concurrency of 3 and while this is something that could be tweaked in the lfs config it would potentially help checkout times on an SSD but make the times on a spinning disk worse.
-- The size on disk size, for us, would initially get worse and then eventually taper off – Because we wouldn’t be rewriting history we’re still going to have space in .git/objects from the previous versions of these files but with the way LFS works, you’re also going to have .git/lfs/objects. Unlike .git/objects, the .git/lfs/objects will only contain the version that’s been pulled local. If you checkout a version you don’t have, it’ll update the .git/lfs/object with that and the other version will simply be a file with pointer. In the case of the .net repo, which has 6029 recording json files taking up about 671MB, this means that the size on disk would grow by that amount. The reason for this bloat is that there’s no compression on the LFS folder.
-  
+- The size on disk size, for us, would initially get worse and then eventually taper off – Because we wouldn’t be rewriting history we’re still going to have space in .git/objects from the previous versions of these files but with the way LFS works, you’re also going to have .git/lfs/objects. Unlike .git/objects, the .git/lfs/objects will only contain the version that’s been pulled local. If you checkout a version you don’t have, it’ll update the .git/lfs/object with that and the other version will simply be a file with pointer. In the case of the .NET repo, which has 6029 recording json files taking up about 671MB, this means that the size on disk would grow by that amount. The reason for this bloat is that there’s no compression on the LFS folder.
+
 ### `External Git Repo`
 
 Current prototype visible [here.](./assets.ps1).

tools/http-fault-injector/README.md

@@ -7,7 +7,7 @@
 * No response. Then either wait indefinitely, close (TCP FIN), or abort (TCP RST).
 
 ## Installation
-1. [Install .Net](https://dotnet.microsoft.com/download)
+1. [Install .NET](https://dotnet.microsoft.com/download)
 
 2. Install http-fault-injector
 ```

tools/net-changelog-gen-mgmt/Azure.SDK.Management.ChangelogGen.Tests/changelog1.md

@@ -42,7 +42,7 @@ Polishing since last public beta release:
 - Prepended `AppService` prefix to all single / simple model names.
 - Corrected the format of all `ResourceIdentifier` type properties / parameters.
 - Corrected the format of all `AzureLocation` type properties / parameters.
-- Corrected all acronyms that not follow [.Net Naming Guidelines](https://docs.microsoft.com/dotnet/standard/design-guidelines/naming-guidelines).
+- Corrected all acronyms that not follow [.NET Naming Guidelines](https://docs.microsoft.com/dotnet/standard/design-guidelines/naming-guidelines).
 - Corrected enumeration name by following [Naming Enumerations Rule](https://docs.microsoft.com/dotnet/standard/design-guidelines/names-of-classes-structs-and-interfaces#naming-enumerations).
 - Corrected the suffix of `DateTimeOffset` properties / parameters.
 - Corrected the name of interval / duration properties / parameters that end with units.

tools/net-changelog-gen-mgmt/Azure.SDK.Management.ChangelogGen.Tests/mergedChangelog1.md

@@ -68,7 +68,7 @@ Polishing since last public beta release:
 - Prepended `AppService` prefix to all single / simple model names.
 - Corrected the format of all `ResourceIdentifier` type properties / parameters.
 - Corrected the format of all `AzureLocation` type properties / parameters.
-- Corrected all acronyms that not follow [.Net Naming Guidelines](https://docs.microsoft.com/dotnet/standard/design-guidelines/naming-guidelines).
+- Corrected all acronyms that not follow [.NET Naming Guidelines](https://docs.microsoft.com/dotnet/standard/design-guidelines/naming-guidelines).
 - Corrected enumeration name by following [Naming Enumerations Rule](https://docs.microsoft.com/dotnet/standard/design-guidelines/names-of-classes-structs-and-interfaces#naming-enumerations).
 - Corrected the suffix of `DateTimeOffset` properties / parameters.
 - Corrected the name of interval / duration properties / parameters that end with units.

tools/perf-automation/README.md

@@ -4,7 +4,7 @@
 `perf-automation` is a tool to run multiple perf tests in any languages and collect the results in a single JSON file.
 
 ## Walkthrough
-1. [Install .Net](https://dotnet.microsoft.com/download)
+1. [Install .NET](https://dotnet.microsoft.com/download)
 
 2. `git clone https://github.com/Azure/azure-sdk-tools`
 

tools/sdk-generation-pipeline/documents/docker/README.md

@@ -36,7 +36,7 @@ Parameter description:
 | { local_autorest_config }   | Optional. When you generate data-plane sdk, and there is no autorest configuration in sdk repository or you want to change the autorest configuration, you can set new autorest config in a file and mount it to the docker container. About the content of file, please refer to [document](https://github.com/Azure/azure-rest-api-specs/blob/dpg-doc/documentation/onboard-dpg-in-sdkautomation/add-autorest-configuration-in-spec-comment.md)                             | /home/test/autorest.md ([Example file](./autorest-config-file-sample.md)) |
 | { relative_readme }         | Required. It's used to specify the readme.md file and docker image uses it to generate SDKs. it's the relative path from {path_to_local_spec_repo}                                                                                                                                                                                                                                                                                                                            | specification/agrifood/resource-manager/readme.md                         |
 | { relative_typespec_project }   | Required. It's used to specify the typespec project folder and docker image uses it to generate SDKs. it's the relative path from {path_to_local_spec_repo}                                                                                                                                                                                                                                                                                                                       | specification/agrifood/resource-manager/readme.md                         |
-| { sdk_to_generate }         | Required. It's used to specify which language of sdk you want to generate. Supported value for management sdk: js, java, python, .net, and go. Supported value for dataplane sdk: js, java, python, and .net. If you want to generate multi-packages, use comma to separate them. (__Not recommend to generate multi packages in one docker container because the docker will failed when encoutering error in generating one sdk, and the remaining sdk will be generated__) | js,java                                                                   |
+| { sdk_to_generate }         | Required. It's used to specify which language of sdk you want to generate. Supported value for management sdk: js, java, python, .NET, and go. Supported value for dataplane sdk: js, java, python, and .NET. If you want to generate multi-packages, use comma to separate them. (__Not recommend to generate multi packages in one docker container because the docker will failed when encoutering error in generating one sdk, and the remaining sdk will be generated__) | js,java                                                                   |
 
 Example Command:
 1. Generate codes with Autorest:

tools/sdk-generation-pipeline/documents/docker/vscode-connect-docker-container.md

@@ -11,7 +11,7 @@ Please follow the following steps to connect your vscode to docker container.
 1. Press `F1` and select `Remote-Containers: Attach to Running Container`.
 2. Select your running docker image, and attach to it.
 3. After vscode connects to docker container, open folder `/work-dir/{sdk-repository}`. 
-   1. For .Net, you can only open the generated SDK namespace folder, such as `Azure.Verticals.AgriFood.Farming`.
+   1. For .NET, you can only open the generated SDK namespace folder, such as `Azure.Verticals.AgriFood.Farming`.
    2. For Java, you can only open the generated package, such as `azure-resourcemanager-agrifood`.
 
 Then you can write your codes in vscode.

tools/test-proxy/Azure.Sdk.Tools.TestProxy/README.md

@@ -92,7 +92,7 @@ For a more detailed explanation of how the test proxy works, along with links to
 
 ### Via Local Compile or .NET
 
-1. [Install .Net 5.0 or 6.0](https://dotnet.microsoft.com/download)
+1. [Install .NET 5.0 or 6.0](https://dotnet.microsoft.com/download)
 2. Install test-proxy
 
 ```powershell

tools/test-proxy/CONTRIBUTING.md

@@ -2,7 +2,7 @@
 
 Within this folder are all the components that make up the the tool `Azure.Sdk.Tools.TestProxy`, henceforth referred to as the `test-proxy`.
 
-This product is currently developed on Visual Studio 2022, but CLI build/test also work fine. Currently, this project only supports `.net 6`, though `.net 7` support is coming.
+This product is currently developed on Visual Studio 2022, but CLI build/test also work fine. Currently, this project only supports .NET 6.0, though .NET 7.0 support is coming.
 
 To contribute a change: