4 Transition to Swashbuckle 5.0

This version of Swashbuckle makes the transition to Swagger 2.0. The 2.0 specification is significantly different to its predecessor (1.2) and forces several breaking changes to Swashbuckle's configuration API. If you're using Swashbuckle without any customizations, i.e. App_Start/SwaggerConfig.cs has never been modified, then you can overwrite it with the new version. The defaults are the same and so the swagger-ui should behave as before.

* If you have consumers of the raw Swagger document, you should ensure they can accept Swagger 2.0 before making the upgrade.

If you're using the existing configuration API to customize the final Swagger document and/or swagger-ui, you will need to port the code manually. The static Customize methods on SwaggerSpecConfig and SwaggerUiConfig have been replaced with extension methods on HttpConfiguration - EnableSwagger and EnableSwaggerUi. All options from version 4.0 are made available through these methods, albeit with slightly different naming and syntax. Refer to the tables below for a summary of changes:

4.0	5.0 Equivalent	Additional Notes
ResolveBasePathUsing	RootUrl
ResolveTargetVersionUsing	N/A	version is now implicit in the docs URL e.g. "swagger/docs/{apiVersion}"
ApiVersion	SingleApiVersion	now supports additional metadata for the version
SupportMultipleApiVersions	MultipleApiVersions	now supports additional metadata for each version
Authorization	BasicAuth/ApiKey/OAuth2
GroupDeclarationsBy	GroupActionsBy
SortDeclarationsBy	OrderActionGroupsBy
MapType	MapType	now accepts Func<Schema> instead of Func<DataType>
ModelFilter	SchemaFilter	IModelFilter is now ISchemaFilter, DataTypeRegistry is now SchemaRegistry
OperationFilter	OperationFilter	DataTypeRegistry is now SchemaRegistry
PolymorphicType	N/A	not currently supported
SupportHeaderParams	N/A	header params are implicitly supported
SupportedSubmitMethods	N/A	all HTTP verbs are implicitly supported
CustomRoute	CustomAsset