Fix Broken Links

build/nuget.props

@@ -6,7 +6,7 @@
   <RepositoryType>git</RepositoryType>
   <RepositoryUrl>https://github.com/dotnet/aspnet-api-versioning</RepositoryUrl>
   <PackageIcon>icon.png</PackageIcon>
-  <PackageProjectUrl>https://github.com/dotnet/aspnet-api-versioning/wiki</PackageProjectUrl>
+  <PackageProjectUrl>https://dotnet.github.io/aspnet-api-versioning</PackageProjectUrl>
   <PackageRequireLicenseAcceptance>true</PackageRequireLicenseAcceptance>
   <PackageLicenseExpression>MIT</PackageLicenseExpression>
   <PackageOutputPath Condition=" $(PackageOutputPath) == '' ">$(MSBuildThisFileDirectory)..\bin</PackageOutputPath>

examples/AspNet/WebApi/ByNamespaceWebApiExample/README.md

@@ -6,4 +6,4 @@ decorate controllers with API versions and have them automatically versioned usi
 their type. Launch the project and try the [example requests](Examples.http) to view an API in action.
 
 
-[wiki]: https://github.com/dotnet/aspnet-api-versioning/wiki/API-Version-Conventions#version-by-namespace-convention
+[wiki]: https://dotnet.github.io/aspnet-api-versioning/aspnet/config/conventions.html#namespace

examples/AspNetCore/WebApi/ByNamespaceExample/README.md

@@ -6,4 +6,4 @@ decorate controllers with API versions and have them automatically versioned usi
 their type. Launch the project and try the [example requests](Examples.http) to view an API in action.
 
 
-[wiki]: https://github.com/dotnet/aspnet-api-versioning/wiki/API-Version-Conventions#version-by-namespace-convention
+[wiki]: https://dotnet.github.io/aspnet-api-versioning/aspnet-core/config/conventions.html#namespace

src/Analyzers/src/Asp.Versioning.Analyzers/Descriptor.cs

@@ -14,7 +14,7 @@ private static DiagnosticDescriptor Diagnostic(
         DiagnosticSeverity defaultSeverity,
         string messageFormat )
     {
-        var helpLink = $"https://github.com/dotnet/aspnet-api-versioning/wiki/analyzer-rules-{id}";
+        var helpLink = $"https://dotnet.github.io/aspnet-api-versioning/diagnostic/{id.ToLowerInvariant()}.html";
 
         return new( id, title, messageFormat, category, defaultSeverity, isEnabledByDefault: true, helpLinkUri: helpLink );
     }

src/Analyzers/src/Asp.Versioning.Api.Analyzers/Descriptor.cs

@@ -16,7 +16,7 @@ private static DiagnosticDescriptor Diagnostic(
         string messageFormat,
         params string[] customTags )
     {
-        var helpLink = $"https://github.com/dotnet/aspnet-api-versioning/wiki/analyzer-rules-{id}";
+        var helpLink = $"https://dotnet.github.io/aspnet-api-versioning/diagnostic/{id.ToLowerInvariant()}.html";
 
         return new(
             id,

wiki/book.toml

@@ -4,7 +4,7 @@ authors = ["Chris Martinez"]
 language = "en"
 
 [output.html]
-site-url = "/docs/"
+site-url = "/aspnet-api-versioning/"
 no-section-label = true
 git-repository-url = "https://github.com/dotnet/aspnet-api-versioning"
 edit-url-template = "https://github.com/dotnet/aspnet-api-versioning/edit/main/wiki/{path}"

wiki/src/aspnet-core/quick-starts/migration.md

@@ -73,7 +73,7 @@ will continue to return `400` when versioning by query string or header, but tha
 [ApiVersioningOptions.UnsupportedApiVersionStatusCode]. Versioning by URL segment will always return `404`. Versioning
 by media type will always return `406` or `415`.
 
-[ApiVersioningOptions.UnsupportedApiVersionStatusCode]: https://github.com/dotnet/aspnet-api-versioning/wiki/API-Versioning-Options#unsupported-api-version-status-code
+[ApiVersioningOptions.UnsupportedApiVersionStatusCode]: ../config/options.md#unsupported-api-version-status-code
 
 The `UseApiVersioning()` middleware in ASP.NET Core has been removed. It never did anything except setup the
 `IApiVersioningFeature` in the current request, which doesn't require middleware.
@@ -103,10 +103,4 @@ services.AddApiVersioning()     // Core services with support for Minimal APIs
 - `ApiVersioningOptions.Conventions` has been moved to `MvcApiVersioningOptions.Conventions` as API Versioning no longer requires MVC Core
   - To configure conventions, use `.AddMvc(options => options.Conventions = ?)` via the `IApiVersioningBuilder` extension method
 - `ApiVersioningOptions.ControllerNameConvention` has been removed as an explicit option, but can be changed via dependency injection
-  - To configure a different naming convention, use `builder.Services.AddSingleton<IControllerNameConvention, OriginalControllerNameConvention>()`
-
-[RFC 7807]: https://datatracker.ietf.org/doc/html/rfc7807
-[Microsoft REST Guidelines error response format]: https://github.com/Microsoft/api-guidelines/blob/master/Guidelines.md#710-response-formats
-[OData JSON Format §21.1]: https://docs.oasis-open.org/odata/odata-json-format/v4.01/odata-json-format-v4.01.html#_Toc38457793
-[Error Response backward compatibility]: https://github.com/dotnet/aspnet-api-versioning/wiki/Error-Responses#Backward-Compatibility
-[Error Responses]: https://github.com/dotnet/aspnet-api-versioning/wiki/Error-Responses
+  - To configure a different naming convention, use `builder.Services.AddSingleton<IControllerNameConvention, OriginalControllerNameConvention>()`

wiki/src/shared/config/options.md

@@ -91,4 +91,4 @@ Regardless of the configured option, when versioning by:
 
 [IApiVersionSelector]: selector.md
 [Conventions]: conventions.md
-[Policies]: ../how-to/version-policies.md
+[Policies]: ../version-policies.md

wiki/src/shared/docs/odata-options-post.md

@@ -10,7 +10,7 @@ property determines whether the constructed URLs use qualified names. The defaul
 This option allows you to configure OData query options. The configuration for query options can be expressed purely by
 convention, through the use of supported OData query attribute, or both. The default behavior will always apply
 conventions from OData query attributes without additional configuration. For more information see the
-[OData query options](odata-query-options.md) topic.
+[OData query options](odata-options.md#query-options) topic.
 
 ### Metadata Options
 
@@ -24,7 +24,7 @@ This property returns an `VersionedODataModelBuilder` that can be used for build
 that are used when defining the query options for APIs that do **not** use the full OData stack. Some OData query
 options can **only** be set via _Model Bound_ settings. This builder constructs an ad hoc EDM that will contain those
 settings solely for the purposes of API exploration and without opting into any other OData-specific features. For more
-information see the [OData query options](odata-query-options.md) topic.
+information see the [OData query options](odata-options.md#query-options) topic.
 
 ### Related Entity Id Parameter Description
 

wiki/src/shared/ext/clients.md

@@ -195,4 +195,4 @@ public class ApiInformation
 _Parsed API information_
 
 [Asp.Versioning.Http.Client]: https://www.nuget.org/packages/Asp.Versioning.Http.Client
-[IApiVersionReader]: ../../config/reader.md
+[IApiVersionReader]: ../config/reader.md

wiki/src/shared/ext/custom-attributes-post.md

@@ -1,4 +1,4 @@
 This approach can help centralize API version management and avoid developer typographical errors when implementing a
 set of services that all use the same API version.
 
-[API versioning options]: ../../config/options.md)
+[API versioning options]: ../config/options.md

wiki/src/shared/how-to/existing-services-post.md

@@ -1,5 +1,5 @@
 If these basic configuration settings are still insufficient for your needs, then you will need to use or create an
 [API version selector] and register it in the [API versioning options].
 
-[API versioning options]: ../config/api-versioning-options.md
-[API version selector]: ../config/api-version-selector.md
+[API versioning options]: ../config/options.md
+[API version selector]: ../config/selector.md

wiki/src/shared/how-to/naming-conventions-pre.md

@@ -20,4 +20,4 @@ Unfortunately, this can cause an issue for service API versioning if you want to
 different types. If the defining type is in a different .NET namespace, then there is no issue; however, if they are in
 the same namespace there would be a name collision. For example:
 
-[ApiVersioningOptions.DefaultApiVersion]: ../config/api-versioning-options.md#default-api-version
+[ApiVersioningOptions.DefaultApiVersion]: ../config/options.md#default-api-version

wiki/src/shared/how-to/overview-post.md

@@ -2,13 +2,13 @@
 
 Several API versioning methods are supported out-of-the-box:
 
-- [By Query String](how-to/version-by-query-string.md) (default)
-- [By Media Type](how-to/version-by-media-type.md)
-- [By Header](how-to/version-by-header.md)
-- [By URL Segment](how-to/version-by-url.md)
+- [By Query String](version-by-query-string.md) (default)
+- [By Media Type](version-by-media-type.md)
+- [By Header](version-by-header.md)
+- [By URL Segment](version-by-url.md)
 
 Multiple methods of API versioning can be supported simultaneously. Use the `ApiVersionReader.Combine` method to compose
 two or more [IApiVersionReader] instances together. You can also implement your own method of extracting the requested
 API version using a custom [IApiVersionReader].
 
-[IApiVersionReader]: config/api-version-reader.md
+[IApiVersionReader]: ../config/reader.md

wiki/src/shared/how-to/overview-pre.md

@@ -23,7 +23,7 @@ a collection of endpoints; for example the _Orders_ API. What if we saw the rout
 part of the _Orders_ API or some other API? For this reason, API Versioning collates on the logical name of an API and
 not individual route templates. For more information see: [Controller Conventions].
 
-[Controller Conventions]: how-to/controller-conventions.md
+[Controller Conventions]: naming-conventions.md
 
 ## Routing Methods
 

wiki/src/shared/how-to/version-advertisement-post.md

@@ -9,4 +9,4 @@ versions when new API versions are released. One possible solution to this limit
 database. If this is still undesirable, then there is still the option of using HTTP header injection by the host server
 or another mechanism to send the supported and deprecated API version information.
 
-[ApiVersioningOptions.ReportApiVersions]: ../configuring-your-application/api-versioning-options.md
+[ApiVersioningOptions.ReportApiVersions]: ../config/options.md#report-api-versions

wiki/src/shared/how-to/version-by-url-pre.md

@@ -11,4 +11,4 @@ is **not** part of the API version, but may be included in route templates if yo
 versioning. For more information and possible solutions to address this scenario, refer to the [known limitations].
 
 [version format]: ../version-format.md
-[known limitations]: ../known-limitations.md#url-path-segment-routing-with-a-default-api-version
+[known limitations]: ../limitations.md#url-path-segment

wiki/src/shared/quick-starts/migration-common.md

@@ -37,7 +37,7 @@ headers was an over-normalization that wasn't really necessary. Additional infor
 [sunset policies]. The `Report` overload that accepts `Lazy<ApiVersionModel>` has been removed as it's no longer used
 or necessary.
 
-[sunset policies]: https://github.com/dotnet/aspnet-api-versioning/wiki/Version-Policies
+[sunset policies]: ../version-policies.md
 
 ## API Version Model Extensions
 
@@ -51,4 +51,27 @@ The following is the mapping between the old and new extension methods or proper
 - `GetApiVersionModel(ApiVersionMapping) → ApiVersionMetadata`
 - `GetApiVersionModel() → ApiVersionMetadata.Map(ApiVersionMapping.Explicit)`
 - `MappingTo(ApiVersion) → ApiVersionMetadata.MappingTo(ApiVersion)`
-- `IsMappedTo(ApiVersion) → ApiVersionMetadata.IsMappedTo(ApiVersion)`
+- `IsMappedTo(ApiVersion) → ApiVersionMetadata.IsMappedTo(ApiVersion)`
+
+## Error Responses
+
+The `IErrorResponseProvider` service had been the hook to provide custom error responses. Problem Details ([RFC 7807])
+had only just been ratified when this project started and they were not part of ASP.NET yet. ASP.NET Core eventually
+added first-class support for Problem Details and `IErrorResponseProvider` had an adapter implementation for alignment
+in previous versions. Now that Problem Details are the de factor method for error reporting, it no longer makes sense to
+retain `IErrorResponseProvider` and it has been removed.
+
+The error responses bodies provided by `IErrorResponseProvider` complied with the
+[Microsoft REST Guidelines error response format], which is itself the error response format used by the OData protocol
+(see [OData JSON Format §21.1]). If you need to retain that format, the [Error Response backward compatibility] topic
+discusses how to enable it.
+
+`ProblemDetails.Type` could logically be used to model the established error `Code`; however, the value is supposed to
+be a URI. For backward compatibility, the existing error codes will be emitted as the `Code` extension in Problem
+Details. The [Error Responses] topic provides details for each well-known problem that may be returned in responses.
+
+[RFC 7807]: https://datatracker.ietf.org/doc/html/rfc7807
+[Microsoft REST Guidelines error response format]: https://github.com/Microsoft/api-guidelines/blob/master/Guidelines.md#710-response-formats
+[OData JSON Format §21.1]: https://docs.oasis-open.org/odata/odata-json-format/v4.01/odata-json-format-v4.01.html#_Toc38457793
+[Error Response backward compatibility]: ../errors.md#backward-compatibility
+[Error Responses]: ../errors.md