Fix github URLs microsoft/msbuild -> dotnet/msbuild (#7083)

### Context

As @Forgind and @drewnoakes pointed out, we still have links to [github.com/microsoft/msbuild](https://github.com/microsoft/msbuild) in the tree.

### Changes Made

Replaced [github.com/microsoft/msbuild](https://github.com/microsoft/msbuild) with [github.com/dotnet/msbuild](https://github.com/dotnet/msbuild).

Except for the two occurrences fixed in #7055.

### Testing

Build, CI

documentation/specs/static-graph-implementation-details.md

@@ -12,7 +12,7 @@ The presence of either input or output caches turns on [isolated build constrain
 
 ## Input / Output cache implementation
 <!-- cache structure -->
-The cache files contain the serialized state of MSBuild's [ConfigCache](https://github.com/dotnet/msbuild/blob/main/src/Build/BackEnd/Components/Caching/ConfigCache.cs) and [ResultsCache](https://github.com/dotnet/msbuild/blob/master/src/Build/BackEnd/Components/Caching/ResultsCache.cs). These two caches have been traditionally used by the engine to cache build results. For example, it is these caches which ensure that a target is only built once per build submission. The `ConfigCache` entries are instances of [BuildRequestConfiguration](https://github.com/microsoft/msbuild/blob/37c5a9fec416b403212a63f95f15b03dbd5e8b5d/src/Build/BackEnd/Shared/BuildRequestConfiguration.cs#L25). The `ResultsCache` entries are instances of [BuildResult](https://github.com/microsoft/msbuild/blob/37c5a9fec416b403212a63f95f15b03dbd5e8b5d/src/Build/BackEnd/Shared/BuildResult.cs#L34), which contain or more instances of [TargetResult](https://github.com/microsoft/msbuild/blob/37c5a9fec416b403212a63f95f15b03dbd5e8b5d/src/Build/BackEnd/Shared/TargetResult.cs#L22).
+The cache files contain the serialized state of MSBuild's [ConfigCache](https://github.com/dotnet/msbuild/blob/main/src/Build/BackEnd/Components/Caching/ConfigCache.cs) and [ResultsCache](https://github.com/dotnet/msbuild/blob/master/src/Build/BackEnd/Components/Caching/ResultsCache.cs). These two caches have been traditionally used by the engine to cache build results. For example, it is these caches which ensure that a target is only built once per build submission. The `ConfigCache` entries are instances of [BuildRequestConfiguration](https://github.com/dotnet/msbuild/blob/37c5a9fec416b403212a63f95f15b03dbd5e8b5d/src/Build/BackEnd/Shared/BuildRequestConfiguration.cs#L25). The `ResultsCache` entries are instances of [BuildResult](https://github.com/dotnet/msbuild/blob/37c5a9fec416b403212a63f95f15b03dbd5e8b5d/src/Build/BackEnd/Shared/BuildResult.cs#L34), which contain or more instances of [TargetResult](https://github.com/dotnet/msbuild/blob/37c5a9fec416b403212a63f95f15b03dbd5e8b5d/src/Build/BackEnd/Shared/TargetResult.cs#L22).
 
 One can view the two caches as the following mapping: `(project path, global properties) -> results`. `(project path, global properties)` is represented by a `BuildRequestConfiguration`, and the results are represented by `BuildResult` and `TargetResult`.
 
@@ -30,11 +30,11 @@ The following constraints are enforced during cache aggregation:
 The output cache file **only contains results for additional work performed in the current BeginBuild / EndBuild session**. Entries from input caches are not transferred to the output cache.
 
 <!-- How input / output cache entries are separated with the override caches -->
-Entries that make it into the output cache file are separated from entries serialized from input cache files via the use of [ConfigCacheWithOverride](https://github.com/dotnet/msbuild/blob/main/src/Build/BackEnd/Components/Caching/ConfigCacheWithOverride.cs) and [ResultsCacheWithOverride](https://github.com/microsoft/msbuild/blob/master/src/Build/BackEnd/Components/Caching/ResultsCacheWithOverride.cs). These are composite caches. Each contains two underlying caches: a cache where input caches files are loaded into (called the override cache), and a cache where new results are written into (called the current cache). Cache reads are satisified from both underlying caches (override cache is queried first, current cache is queried second). Writes are only written to the current cache, never into the override cache. The output cache file only contains the serialized current cache, and not the override cache, thus ensuring that only newly built results are serialized in the output cache file. It is illegal for both the current cache and override cache to contain entries for the same project configuration, a constraint that is checked by the two override caches on each cache read.
+Entries that make it into the output cache file are separated from entries serialized from input cache files via the use of [ConfigCacheWithOverride](https://github.com/dotnet/msbuild/blob/main/src/Build/BackEnd/Components/Caching/ConfigCacheWithOverride.cs) and [ResultsCacheWithOverride](https://github.com/dotnet/msbuild/blob/master/src/Build/BackEnd/Components/Caching/ResultsCacheWithOverride.cs). These are composite caches. Each contains two underlying caches: a cache where input caches files are loaded into (called the override cache), and a cache where new results are written into (called the current cache). Cache reads are satisified from both underlying caches (override cache is queried first, current cache is queried second). Writes are only written to the current cache, never into the override cache. The output cache file only contains the serialized current cache, and not the override cache, thus ensuring that only newly built results are serialized in the output cache file. It is illegal for both the current cache and override cache to contain entries for the same project configuration, a constraint that is checked by the two override caches on each cache read.
 
 ## Isolation implementation
 
-[Isolation constraints](static-graph.md##single-project-isolated-builds) are implemented in the Scheduler and the TaskBuilder. [TaskBuilder.ExecuteInstantiatedTask](https://github.com/dotnet/msbuild/blob/37c5a9fec416b403212a63f95f15b03dbd5e8b5d/src/Build/BackEnd/Components/RequestBuilder/TaskBuilder.cs#L743) ensures that the `MSBuild` task is only called on projects declared in `ProjectReference`. [Scheduler.CheckIfCacheMissOnReferencedProjectIsAllowedAndErrorIfNot](https://github.com/microsoft/msbuild/blob/37c5a9fec416b403212a63f95f15b03dbd5e8b5d/src/Build/BackEnd/Components/Scheduler/Scheduler.cs#L1818) ensures that all `MSBuild` tasks are cache hits.
+[Isolation constraints](static-graph.md##single-project-isolated-builds) are implemented in the Scheduler and the TaskBuilder. [TaskBuilder.ExecuteInstantiatedTask](https://github.com/dotnet/msbuild/blob/37c5a9fec416b403212a63f95f15b03dbd5e8b5d/src/Build/BackEnd/Components/RequestBuilder/TaskBuilder.cs#L743) ensures that the `MSBuild` task is only called on projects declared in `ProjectReference`. [Scheduler.CheckIfCacheMissOnReferencedProjectIsAllowedAndErrorIfNot](https://github.com/dotnet/msbuild/blob/37c5a9fec416b403212a63f95f15b03dbd5e8b5d/src/Build/BackEnd/Components/Scheduler/Scheduler.cs#L1818) ensures that all `MSBuild` tasks are cache hits.
 
 ### How isolation exemption complicates everything
 <!-- Potential cache scenarios caused by exemption -->

documentation/specs/static-graph.md

@@ -173,7 +173,7 @@ Note that graph cycles are disallowed, even if they're using disconnected target
 
 #### APIs
 
-[BuildManager.PendBuildRequest(GraphBuildRequestData requestData)](https://github.com/microsoft/msbuild/blob/37c5a9fec416b403212a63f95f15b03dbd5e8b5d/src/Build/BackEnd/BuildManager/BuildManager.cs#L676)
+[BuildManager.PendBuildRequest(GraphBuildRequestData requestData)](https://github.com/dotnet/msbuild/blob/37c5a9fec416b403212a63f95f15b03dbd5e8b5d/src/Build/BackEnd/BuildManager/BuildManager.cs#L676)
 
 ### Inferring which targets to run for a project within the graph
 In the classic MSBuild build (i.e. execution of targets), the referencing project chooses which targets to call on the referenced projects and may call into a project multiple times with different target lists and global properties (examples in [project reference protocol](../ProjectReference-Protocol.md)). This is a top-down traversal of dependencies. These calls are made via the [MSBuild task](https://docs.microsoft.com/en-us/visualstudio/msbuild/msbuild-task?view=vs-2019). When building a graph, projects are built before the projects that reference them. This is a bottom-up traversal. Therefore the graph needs to determine the list of targets to execute on a specific project `B` **before** building the referencing projects that reference `B`.
@@ -387,9 +387,9 @@ These incremental builds could be extended to the entire graph by keeping a proj
 Details on how isolation and cache files are implemented in MSBuild can be found [here](./static-graph-implementation-details.md).
 
 #### APIs
-Cache file information is provided via [BuildParameters](https://github.com/Microsoft/msbuild/blob/2d4dc592a638b809944af10ad1e48e7169e40808/src/Build/BackEnd/BuildManager/BuildParameters.cs#L746-L764). Input caches are applied in `BuildManager.BeginBuild`. Output cache files are written in `BuildManager.EndBuild`. Thus, the scope of the caches are one BuildManager BeginBuild/EndBuild session.
+Cache file information is provided via [BuildParameters](https://github.com/dotnet/msbuild/blob/2d4dc592a638b809944af10ad1e48e7169e40808/src/Build/BackEnd/BuildManager/BuildParameters.cs#L746-L764). Input caches are applied in `BuildManager.BeginBuild`. Output cache files are written in `BuildManager.EndBuild`. Thus, the scope of the caches are one BuildManager BeginBuild/EndBuild session.
 
-Isolation constraints are turned on via [BuildParameters.IsolateProjects](https://github.com/microsoft/msbuild/blob/b111470ae61eba02c6102374c2b7d62aebe45f5b/src/Build/BackEnd/BuildManager/BuildParameters.cs#L742). Isolation constraints are also automatically turned on if either input or output cache files are used.
+Isolation constraints are turned on via [BuildParameters.IsolateProjects](https://github.com/dotnet/msbuild/blob/b111470ae61eba02c6102374c2b7d62aebe45f5b/src/Build/BackEnd/BuildManager/BuildParameters.cs#L742). Isolation constraints are also automatically turned on if either input or output cache files are used.
 
 #### Command line
 Caches are provided to MSBuild.exe via the multi value `/inputResultsCaches` and the single value `/outputResultsCache`.

documentation/wiki/Building-Testing-and-Debugging-on-Full-Framework-MSBuild.md

@@ -31,7 +31,7 @@ The CI does two builds. In the second build, it uses the binaries from the first
 
 ## Contributing
 
-Please see [Contributing Code](https://github.com/Microsoft/msbuild/blob/master/documentation/wiki/Contributing-Code.md) for details on contributing changes back to the code. Please read this carefully and engage with us early to ensure work is not wasted.
+Please see [Contributing Code](https://github.com/dotnet/msbuild/blob/master/documentation/wiki/Contributing-Code.md) for details on contributing changes back to the code. Please read this carefully and engage with us early to ensure work is not wasted.
 
 ## Walkthroughs
 

documentation/wiki/Contributing-Tasks.md

@@ -3,7 +3,7 @@
 MSBuild tasks are units of executable code used to perform atomic build operations.  There are many tasks already in MSBuild but there is always a need for more.  We encourage you to contribute useful tasks directory to MSBuild.
 
 ## Getting Started
-Please [open an issue](https://github.com/Microsoft/msbuild/issues/new) to propose a new task.  This gives the community a chance to provide feedback and make suggestions.  Once there is consensus that the task is needed and the below requirements are met, fork the repository and begin development.
+Please [open an issue](https://github.com/dotnet/msbuild/issues/new) to propose a new task.  This gives the community a chance to provide feedback and make suggestions.  Once there is consensus that the task is needed and the below requirements are met, fork the repository and begin development.
 
 ## Requirements
 The following requirements are in place for contributed tasks:
@@ -13,12 +13,12 @@ The following requirements are in place for contributed tasks:
 3. The task must have unit tests in place to prevent regressions.
 
 ## Developing a new Task
-Review the existing documentation on [Task Writing](https://docs.microsoft.com/en-us/visualstudio/msbuild/task-writing) to learn about the fundamentals.  You can also looking at existing tasks in the [Microsoft.Build.Tasks.Core assembly](https://github.com/Microsoft/msbuild/tree/master/src/Tasks) for a great starting point.
+Review the existing documentation on [Task Writing](https://docs.microsoft.com/en-us/visualstudio/msbuild/task-writing) to learn about the fundamentals.  You can also looking at existing tasks in the [Microsoft.Build.Tasks.Core assembly](https://github.com/dotnet/msbuild/tree/master/src/Tasks) for a great starting point.
 
 Tasks are generally simple and should not require much effort to develop.  If you find a task becoming very complicated, consider breaking it up into smaller tasks which can be run together in a target.
 
 ## Developing unit tests
-Contributed tasks must have unit tests in place to prove they work and to prevent regressions caused by other code changes.  There are a lot of examples in the [Microsoft.Build.Tasks.UnitTests](https://github.com/Microsoft/msbuild/tree/master/src/Tasks.UnitTests) project.  Please provide a reasonable amount of test coverage so ensure the quality of the product.
+Contributed tasks must have unit tests in place to prove they work and to prevent regressions caused by other code changes.  There are a lot of examples in the [Microsoft.Build.Tasks.UnitTests](https://github.com/dotnet/msbuild/tree/master/src/Tasks.UnitTests) project.  Please provide a reasonable amount of test coverage so ensure the quality of the product.
 
 ## Documentation
 You can document the new task in the [visualstudio-docs](https://github.com/MicrosoftDocs/visualstudio-docs/tree/master/docs/msbuild) repository.  This helps users discover the new functionality.  The easiest way is to copy the documentation page for an existing task as a template.

documentation/wiki/Localization.md

@@ -6,7 +6,7 @@
 - `Strings.shared.resx` is a shared resource and gets embedded into all msbuild dlls
 - each neutral resource has a directory named `xlf` besides it which contains its localized strings in .xlf format
 - there is one language per xlf
-- the logical name for a resource is: `<Assembly Name>.<Neutral Resx File Name>.resources`. In the ResourceManager this appears as `<Assembly Name>.<Neutral Resx File Name>` (without the trailing `.resources`). For example, the `Microsoft.Build` assembly uses the `Microsoft.Build.Strings.resources` [logical resource name](https://github.com/Microsoft/msbuild/blob/master/src/XMakeBuildEngine/Microsoft.Build.csproj#L659) (the resource file is `Strings.resx`), and its corresponding [ResourceManager](https://github.com/Microsoft/msbuild/blob/master/src/XMakeBuildEngine/Resources/AssemblyResources.cs#L116) uses `Microsoft.Build.Strings`.
+- the logical name for a resource is: `<Assembly Name>.<Neutral Resx File Name>.resources`. In the ResourceManager this appears as `<Assembly Name>.<Neutral Resx File Name>` (without the trailing `.resources`). For example, the `Microsoft.Build` assembly uses the `Microsoft.Build.Strings.resources` [logical resource name](https://github.com/dotnet/msbuild/blob/master/src/XMakeBuildEngine/Microsoft.Build.csproj#L659) (the resource file is `Strings.resx`), and its corresponding [ResourceManager](https://github.com/dotnet/msbuild/blob/master/src/XMakeBuildEngine/Resources/AssemblyResources.cs#L116) uses `Microsoft.Build.Strings`.
 
 ## How to edit a resource
 
@@ -31,7 +31,7 @@
 
 ## Localizing XSD "IntelliSense"
 
-Code completion ("IntelliSense") for MSBuild project files is provided minimally in Visual Studio by XML Schema files like [`Microsoft.Build.CommonTypes.xsd`](https://github.com/microsoft/msbuild/blob/ba9a1d64a7abf15a8505827c00413156a3eb7f62/src/MSBuild/MSBuild/Microsoft.Build.CommonTypes.xsd). These files are English-only in the GitHub repo; their localization is managed in the Microsoft-internal `VS` repo.
+Code completion ("IntelliSense") for MSBuild project files is provided minimally in Visual Studio by XML Schema files like [`Microsoft.Build.CommonTypes.xsd`](https://github.com/dotnet/msbuild/blob/ba9a1d64a7abf15a8505827c00413156a3eb7f62/src/MSBuild/MSBuild/Microsoft.Build.CommonTypes.xsd). These files are English-only in the GitHub repo; their localization is managed in the Microsoft-internal `VS` repo.
 
 ### If there is a bug in XSD localization
 

documentation/wiki/MSBuild-Resources.md

@@ -5,7 +5,7 @@
  * [Target Maps](Target-Maps.md)
 
 # MSBuild Source Code
- * [https://github.com/Microsoft/MSBuild](https://github.com/Microsoft/MSBuild)
+ * [https://github.com/dotnet/msbuild](https://github.com/dotnet/msbuild)
  * [https://source.dot.net](https://source.dot.net)
  * Use [http://referencesource.microsoft.com](http://referencesource.microsoft.com) or [http://source.roslyn.io](http://source.roslyn.io) to browse Microsoft MSBuild targets. Examples:
    * search for "[_FindDependencies MSBuildProperty](http://referencesource.microsoft.com/#q=_FindDependencies%20MSBuildProperty)"

documentation/wiki/ResolveAssemblyReference.md

@@ -9,17 +9,17 @@ If you notice the ordering, ResolveAssemblyReferences is happening before Compil
 
 ## Source Code
 You can browse Microsoft's MSBuild targets online at:
-https://github.com/microsoft/msbuild/blob/a936b97e30679dcea4d99c362efa6f732c9d3587/src/Tasks/Microsoft.Common.CurrentVersion.targets#L1991-L2140
+https://github.com/dotnet/msbuild/blob/a936b97e30679dcea4d99c362efa6f732c9d3587/src/Tasks/Microsoft.Common.CurrentVersion.targets#L1991-L2140
 This is where the RAR task is invoked in the targets file.
 
 The source code for RAR is at:
-https://github.com/Microsoft/msbuild/blob/master/src/Tasks/AssemblyDependency/ResolveAssemblyReference.cs
+https://github.com/dotnet/msbuild/blob/master/src/Tasks/AssemblyDependency/ResolveAssemblyReference.cs
 
 ## Inputs
 RAR is very detailed about logging its inputs:
 ![image](https://cloud.githubusercontent.com/assets/679326/21276697/76ea6830-c387-11e6-94f7-cd523c19064e.png)
 The Parameters node is standard for all tasks, but additionally RAR logs its own set of information under Inputs (which is basically the same as under Parameters but structured differently). RAR logs this information in a method called LogInputs():
-https://github.com/Microsoft/msbuild/blob/xplat/src/XMakeTasks/AssemblyDependency/ResolveAssemblyReference.cs#L1249
+https://github.com/dotnet/msbuild/blob/xplat/src/XMakeTasks/AssemblyDependency/ResolveAssemblyReference.cs#L1249
 
 The most important inputs are Assemblies and AssemblyFiles:
 
@@ -47,7 +47,7 @@ You can set this property to false in your build to turn off analyzing transitiv
 ## Execution
 
 The source code of the main `Execute()` method can be found in MSBuild source code on GitHub:
-https://github.com/Microsoft/msbuild/blob/xplat/src/XMakeTasks/AssemblyDependency/ResolveAssemblyReference.cs#L1877
+https://github.com/dotnet/msbuild/blob/xplat/src/XMakeTasks/AssemblyDependency/ResolveAssemblyReference.cs#L1877
 
 The algorithm simplified is:
 ```
@@ -84,7 +84,7 @@ Line 2284: LogResults();
 Very simplified, the way it works is it takes the input list of assemblies (both from metadata and project references), retrieves the list of references for each assembly it processes (by reading metadata) and builds a transitive closure of all referenced assemblies, and resolves them from various locations (including the GAC, AssemblyFoldersEx, etc.).
 
 It builds a ReferenceTable:
-https://github.com/Microsoft/msbuild/blob/xplat/src/XMakeTasks/AssemblyDependency/ReferenceTable.cs
+https://github.com/dotnet/msbuild/blob/xplat/src/XMakeTasks/AssemblyDependency/ReferenceTable.cs
 
 Referenced assemblies are added to the closure iteratively until no more new references are added. Then the algorithm stops.
 
@@ -125,7 +125,7 @@ https://github.com/dotnet/msbuild/blob/main/src/Tasks/AssemblyDependency/Referen
 The last point is an often used reason for CopyLocal being set to false:
 `This reference is not "CopyLocal" because at least one source item had "Private" set to "false" and no source items had "Private" set to "true".`
 
-Unfortunately MSBuild doesn't tell us _which_ reference has set Private to false. I've filed an issue on MSBuild to improve logging: https://github.com/Microsoft/msbuild/issues/1485
+Unfortunately MSBuild doesn't tell us _which_ reference has set Private to false. I've filed an issue on MSBuild to improve logging: https://github.com/dotnet/msbuild/issues/1485
 
 For now, MSBuildStructuredLog offers an enhancement. It adds Private metadata to the items that had it specified above:
 ![image](https://cloud.githubusercontent.com/assets/679326/21278154/733b5f80-c38e-11e6-9eda-ef213b0e233c.png)