Ale, music and enjoying life.
Hide Endpoints And Schemas from Swagger / OpenAPI
I have a requirement to hide a few of the API’s controller endpoints from Swagger along with their respective schemas that aren’t yet ready for public consumption. I still want them to be available for Postman/Newman tests as part of the CI/CD. This can be achieved using the following Swashbuckle filter and MVC convention to successfully hide Swagger endpoints :-
Upgrade to dotnet 3.1 from 2.2 causes foreign key conflicts
EF Core 3+ Breaking Changes 🙂
Just following on from my web api/swagger/data .net core 2.2 to 3.1 upgrade and here. I hit another blocker just as everything was going so smoothly!. Basic functional testing on the API was going well until I noticed some POST operations failing with “ERROR The INSERT statement conflicted with the FOREIGN KEY constraint <FK>. The conflict occurred in database “DATABASE”, table “dbo.<tablename>”, column ‘<column name>’. “
OData .Net Core 3.1 with Swagger
Object reference not set to an instance of an object. at Microsoft.AspNetCore.Mvc.Routing.ApiVersionMatcherPolicy
I recently upgraded .net core 2.2 web api with Odata and Swagger to 3.1 following Microsoft’s recent endpoint routing support with OData 7.40. All was going great until I realised certain API endpoints were failing with “Object reference not set to an instance of an object. at Microsoft.AspNetCore.Mvc.Routing.ApiVersionMatcherPolicy”. On closer inspection the endpoints failing were all child resources. For example ../api/company/1 works fine ../api/company/1/staff and ../api/company/1/staff/1 were failing with
Upgrading .Net Core 2.2 Web API with SWAGGER and ODATA to .Net COre 3.1
Decided to take the plunge and update a fairly sizeable WebAPI with OData and Swagger to .Net Core 3.1. Why the hell would you do this you may ask? Well to take advantage of 3.1’s endpoint routing and OData’s recent support for this with OData 7.40. Inspired by Hassan Habib’s blog entry on Microsoft Dev blogs and decided to go for it.
Web API Adventures – Part 1 – Swagger
Surely decorating the API method in question with Summary attributes would make it’s way through to the Swagger API documentation? After a bit of head scratching and googling I realised I was just a step away from achieving this.  I needed to enable the Build Output “XML Documentation file” in the projects build properties.  Give the XML a sensible name i.e bin\WebApiSwagger.XML .
Finally, in the SwaggerConfig.cs create yourself a method:-
protected static string GetXmlCommentsPath()
{
return System.String.Format(@”{0}\bin\WebApiSwagger.XML”, System.AppDomain.CurrentDomain.BaseDirectory);
}