Fix a couple bad links and verify script to catch them (Azure#851)

_config.yml

@@ -31,6 +31,7 @@ exclude:
   - .gitignore
   - eng
   - vendor
+  - docs/policies/README*
 
 feedback_subject_line: Azure SDK Design Guidelines Feedback
 feedback_email: adparch@microsoft.com

_data/sidebars/home_sidebar.yml

@@ -38,17 +38,13 @@ entries:
       - title: Implementation
         url: /clang_implementation.html
       - title: Documentation
-        url: /clang_documentation.html       
+        url: /clang_documentation.html
   - title: C#.NET Guidelines
     folderitems:
       - title: Introduction
         url: /dotnet_introduction.html
-      - title: API Design
-        url: /dotnet_design.html
       - title: Implementation
         url: /dotnet_implementation.html
-      - title: Documentation
-        url: /dotnet_documentation.html
   - title: Go Guidelines (Draft)
     folderitems:
       - title: Introduction

docs/dotnet/introduction.md

@@ -584,7 +584,7 @@ Consider 5+ models to be "large".  The types that the user needs should be easy
 
 ### Error Reporting {#dotnet-errors}
 
-{% include requirement/MUST id="dotnet-errors-response-failed" %} throw `RequestFailedException` or its subtype when a service method fails with non-success status code. 
+{% include requirement/MUST id="dotnet-errors-response-failed" %} throw `RequestFailedException` or its subtype when a service method fails with non-success status code.
 
 The exception is available in ```Azure.Core``` package:
 ```csharp
@@ -613,9 +613,9 @@ Don't introduce new exception types unless there's a programmatic scenario for h
 
 ### Logging
 
-Request logging will be done automatically by the `HttpPipeline`.  If a client library needs to add custom logging, follow the [same guidelines](../implementation.md#general-logging) and mechanisms as the pipeline logging mechanism.  If a client library wants to do custom logging, the designer of the library must ensure that the logging mechanism is pluggable in the same way as the `HttpPipeline` logging policy.
+Request logging will be done automatically by the `HttpPipeline`.  If a client library needs to add custom logging, follow the [same guidelines](implementation.md#general-logging) and mechanisms as the pipeline logging mechanism.  If a client library wants to do custom logging, the designer of the library must ensure that the logging mechanism is pluggable in the same way as the `HttpPipeline` logging policy.
 
-{% include requirement/MUST id="dotnet-logging-follow-guidelines" %} follow [the logging section of the Azure SDK General Guidelines](../implementation.md#general-logging) if logging directly (as opposed to through the `HttpPipeline`).
+{% include requirement/MUST id="dotnet-logging-follow-guidelines" %} follow [the logging section of the Azure SDK General Guidelines](implementation.md#general-logging) if logging directly (as opposed to through the `HttpPipeline`).
 
 #### Distributed Tracing {#dotnet-distributedtracing}
 

eng/scripts/Verify-Links.ps1

@@ -46,7 +46,7 @@ foreach ($link in $links)
     $linkUri = [System.Uri]$link;
     if (!$linkUri.IsAbsoluteUri)
     {
-      $linkUri = new-object System.Uri($Url, $link);
+      $linkUri = new-object System.Uri($uri, $link);
       Write-Verbose "Resolved relative link to $linkUri"
     }
     # If the link is not a web request, like mailto, skip it.

releases/2019-08-06/index.md

@@ -11,37 +11,37 @@ The second previews of Azure SDKs which follow the latest Azure API Guidelines a
 
 ## What’s new
 
-The SDKs have many new features, bug fixes, and improvements. Some of the new features are below but please read the release notes linked above and changelogs they point at for details. 
+The SDKs have many new features, bug fixes, and improvements. Some of the new features are below but please read the release notes linked above and changelogs they point at for details.
 
-* Storage Libraries for Java now include Files and Queues support 
-* Storage Libraries for Python have added Async versions of the APIs for Files, Queues, and Blobs 
-* Event Hubs libraries across languages have expanded support for sending multiple messages in a single call by adding the ability to create a batch avoiding the error scenario where a call exceeds size limits and giving batch size control to developers with bandwidth concerns 
-* Event Hubs libraries across languages have introduced a new model for consuming events via the EventProcessor class which simplifies the process of checkpointing today and will handle load balancing across partitions in upcoming previews 
+* Storage Libraries for Java now include Files and Queues support
+* Storage Libraries for Python have added Async versions of the APIs for Files, Queues, and Blobs
+* Event Hubs libraries across languages have expanded support for sending multiple messages in a single call by adding the ability to create a batch avoiding the error scenario where a call exceeds size limits and giving batch size control to developers with bandwidth concerns
+* Event Hubs libraries across languages have introduced a new model for consuming events via the EventProcessor class which simplifies the process of checkpointing today and will handle load balancing across partitions in upcoming previews
 
-## Diving deeper into the Guidelines: Consistency 
+## Diving deeper into the Guidelines: Consistency
 
-These Azure SDKs represent a cross-organizational effort to provide an ergonomic experience to every developer using every platform and as mentioned in the [previous blog post](../2019-07-10/index.html) developers feedback helped define the following set of principles: 
+These Azure SDKs represent a cross-organizational effort to provide an ergonomic experience to every developer using every platform and as mentioned in the [previous blog post](../2019-07-10/index.html) developers feedback helped define the following set of principles:
 
-* Idiomatic 
-* Consistent 
-* Approachable 
-* Diagnosable 
-* Compatible 
+* Idiomatic
+* Consistent
+* Approachable
+* Diagnosable
+* Compatible
 
-Today we will deep dive into consistency. 
+Today we will deep dive into consistency.
 
-## Consistent 
+## Consistent
 
-Feedback from developers and user studies has shown that APIs which are consistent are generally easier to learn and remember. To guide SDKs from Azure to be consistent the guidelines contain [the consistency principle]({{ site.baseurl }}/general_introduction.html#consistent): 
+Feedback from developers and user studies has shown that APIs which are consistent are generally easier to learn and remember. To guide SDKs from Azure to be consistent the guidelines contain [the consistency principle]({{ site.baseurl }}/general_introduction.html#consistent):
 
-* Client libraries should be consistent within the language, consistent with the service and consistent between all target languages. In cases of conflict, consistency within the language is the highest priority and consistency between all target languages is the lowest priority. 
-* Service-agnostic concepts such as logging, HTTP communication, and error handling should be consistent. The developer should not have to relearn service-agnostic concepts as they move between client libraries. 
-* Consistency of terminology between the client library and the service is a good thing that aids in diagnosability. 
-* All differences between the service and client library must have a good (articulated) reason for existing, rooted in idiomatic usage rather than whim. 
-* The Azure SDK for each target language feels like a single product developed by a single team. 
+* Client libraries should be consistent within the language, consistent with the service and consistent between all target languages. In cases of conflict, consistency within the language is the highest priority and consistency between all target languages is the lowest priority.
+* Service-agnostic concepts such as logging, HTTP communication, and error handling should be consistent. The developer should not have to relearn service-agnostic concepts as they move between client libraries.
+* Consistency of terminology between the client library and the service is a good thing that aids in diagnosability.
+* All differences between the service and client library must have a good (articulated) reason for existing, rooted in idiomatic usage rather than whim.
+* The Azure SDK for each target language feels like a single product developed by a single team.
 * There should be feature parity across target languages. This is more important than feature parity with the service.
 
-Looking at the second bullet point – “Service-agnostic concepts such as logging, HTTP communication, and error handling should be consistent.” Developers pointed out APIs that worked nicely on their own but which weren’t always perfectly consistent with each other. For examples: 
+Looking at the second bullet point – “Service-agnostic concepts such as logging, HTTP communication, and error handling should be consistent.” Developers pointed out APIs that worked nicely on their own but which weren’t always perfectly consistent with each other. For examples:
 
 **Blob storage used a skip/take style of paging, while returning a sync iterator as the result set**:
 
@@ -81,7 +81,7 @@ The [JavaScript guidelines]({{ site.baseurl }}/typescript_introduction.html) spe
 
 {% include requirement/SHOULD id="ts-use-async-functions" %} _use `async` functions for implementing asynchronous library APIs._
 
-_If you need to support ES5 and are concerned with library size, use `async` when combining asynchronous code with control flow constructs.  Use promises for simpler code flows.  `async` adds code bloat (especially when targeting ES5) when transpiled._ 
+_If you need to support ES5 and are concerned with library size, use `async` when combining asynchronous code with control flow constructs.  Use promises for simpler code flows.  `async` adds code bloat (especially when targeting ES5) when transpiled._
 
 {% include requirement/MUST id="ts-use-iterators" %} _use [Iterators](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Iterators_and_Generators) and [Async Iterators](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for-await...of) for sequences and streams of all sorts._
 
@@ -117,4 +117,4 @@ As you can see, a service-agnostic concept - in this case, paging - has been sta
 
 ## Feedback
 
-If you have feedback on consistency or think you've found a bug after trying the August 2019 Preview ([.NET](dotnet.html), [Java](java.html), [JavaScript](js.html), [Python](python.html)), then file an issue or pull request on GitHub ([.NET](https://github.com/azure/azure-sdk-for-net/), [Java](https://github.com/azure/azure-sdk-for-java), [JavaScript](https://github.com/azure/azure-sdk-for-js), [Python](https://github.com/azure/azure-sdk-for-python)) or reach out to [@AzureSDK](https//twitter.com/AzureSDK) on Twitter.  We welcome contributions to these guidelines and libraries!
+If you have feedback on consistency or think you've found a bug after trying the August 2019 Preview ([.NET](dotnet.html), [Java](java.html), [JavaScript](js.html), [Python](python.html)), then file an issue or pull request on GitHub ([.NET](https://github.com/azure/azure-sdk-for-net/), [Java](https://github.com/azure/azure-sdk-for-java), [JavaScript](https://github.com/azure/azure-sdk-for-js), [Python](https://github.com/azure/azure-sdk-for-python)) or reach out to [@AzureSDK](https://twitter.com/AzureSDK) on Twitter.  We welcome contributions to these guidelines and libraries!

releases/2019-12/2019-12-dotnet.md

@@ -56,9 +56,9 @@ Detailed changelogs are linked from the [Quick Links](#quick-links) below. Here
 
 ### Event Hubs
 
-- A large portion of the public API surface, including members and parameters, have had adjustments to their naming and organization in order to improve discoverability, provide better context to developers, and better conform to the [Azure SDK Design Guidelines for .NET](https://azure.github.io/azure-sdk/dotnet_introduction.html). For more details, please see the [Event Hubs](https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/eventhub/Azure.Messaging.EventHubs/CHANGELOG.md#500-preview6) and [Event Processor](https://github.com/Azure/azure-sdk-for-net/blob/master/sdk/eventhub/Azure.Messaging.EventHubs.Processor/CHANGELOG.md#500-preview6) changelogs.
+- A large portion of the public API surface, including members and parameters, have had adjustments to their naming and organization in order to improve discoverability, provide better context to developers, and better conform to the [Azure SDK Design Guidelines for .NET](https://azure.github.io/azure-sdk/dotnet_introduction.html). For more details, please see the [Event Hubs](https://github.com/Azure/azure-sdk-for-net/blob/Azure.Messaging.EventHubs_5.0.0-preview.6/sdk/eventhub/Azure.Messaging.EventHubs/CHANGELOG.md#500-preview6) and [Event Processor](https://github.com/Azure/azure-sdk-for-net/tree/Azure.Messaging.EventHubs.Processor_5.0.0-preview.6/sdk/eventhub/Azure.Messaging.EventHubs.Processor/CHANGELOG.md#500-preview6) changelogs.
 
-- The `EventProcessorClient` has been moved into its own [package](./../Azure.Messaging.EventHubs.Processor) and evolved into an opinionated implementation on top of Azure Storage Blobs. This is intended to offer a more streamlined developer experience for the majority of scenarios and allow developers to more easily take advantage of the processor.
+- The `EventProcessorClient` has been moved into its own [package](https://github.com/Azure/azure-sdk-for-net/tree/Azure.Messaging.EventHubs.Processor_5.0.0-preview.6/sdk/eventhub/Azure.Messaging.EventHubs.Processor) and evolved into an opinionated implementation on top of Azure Storage Blobs. This is intended to offer a more streamlined developer experience for the majority of scenarios and allow developers to more easily take advantage of the processor.
 
 - A bug with the use of Azure.Identity credential scopes has been fixed; Azure identities should now allow for proper authorization with Event Hubs resources.
 _(A community contribution, courtesy of [albertodenatale](https://github.com/albertodenatale))_