Wasting Time
Ale, music and enjoying life.
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
Solution
After a bit of digging (I removed the OData versioning Nuget packages as these are now served via .Net) I realised I had the [ApiController] attribute decorating every Controller. Looking at some of the recent examples online I noticed this wasn’t present. Once I’d removed the attribute I was back in business.
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.
3 Plates Spinning
It’s been quite a challenge getting .Net Core, OData and Swagger to play nicely with each other over the last few months since I’ve been involved with the project so making the switch to 3.1 was not a casual afternoon’s work. That said I was pretty much there after a working day. In order to satisfy all 3 factors what follows is some of the key changes I took on and resolved in order to get all components working.
Upgrading
Ensuring that you have a solid working build and your ready to make the upgrade then it’s pretty straightforward. Simply target your projects to 3.1
Then you’ll need to upgrade your Nuget Packages in particular OData to 7.40 and Swashbuckle I went with 5.0.0. Ensure you’re getting a good build and then you’ll need to sort out the routing.
Routing
The .Net Core 2.2 Web API routing with OData and translating that into some kinda of meaningful Swagger OpenAPI out felt very sellotape and blu tack. For example, here’s the recommended approach….
Then if you want to use XML formatters you need to include those also. Which is pretty standard to be fair but as of 2.2 you’d need to take endpoint routing off and set the compatibility version to 2.2. What really changes in the upgrade are the Controllers. Whereas before without using endpoint routing you’ll decorate your routes with ODataRoute theses now simply become the standard api Route. Also bear in mind that if you’ve been using OData routes similar to [ODataRoute(“{id}/childcollection/{childId}”] then you’ll find that you’ll have to specify the id types otherwise they won’t be served. So in the example above this becomes [ODataRoute(“{id:int}/childcollection/{childId:int}”].
It works!
Simply put the upgrade was pretty straight forward and it worked. A quick rattle through Postman and all OData functionality was working as expected, Selects, Expands etc all fit and working.
Disclaimer
As is the case throughout my blog any business context is removed.
C# Recursive Hierarchy. Get the parent’s children, and their children, and their children, and ……….
The Issue
This one cropped up at work recently. As part of a project there was a requirement for an API to carry out a check as part of an update on an object to ensure that none of the object’s children met a certain criteria (I’m avoiding business context here).
Easy right?
I thought I’d sail through this and it would be a breeze but before I knew it I was getting tangled up in loops and in a right old mess. Whilst it’s very easy to get the direct children it’s more difficult to get their children (and so on). I needed a nice simple succinct approach with a sprinkling of code. Also, there appears to be little online that goes beyond simply getting the immediate children or writing lines of code or building up loads of extension methods.
Ohhh, won’t somebody please think of the children!
So, removing the business context. Here’s a solution
There is a final consideration here. If you specify the “God” Id (1) then you’ll receive a stack overflow message. So a there’s room for improvement (comments below please). In the meantime I’ll use a belt and braces approach to handle an Id of 1.
How to fix briefly unavailable for scheduled maintenance error in WordPress
Occasionally, on updating a plugin you might see the ‘Briefly unavailable for scheduled maintenance’ message in WordPress. This will be visible even if logged in as Admin. As part of the update process a “.maintenance” file is temporary created in the root folder of WordPress.
To remove the message simply remove the file.
Magic Whiteboards!
What?
What are magic whiteboards you may ask? Well they’re pretty magic. They comprise of tear off white sheets that are statically charged and can stick to just about any wall.
The Test
I grabbed a pack of 5 sheets from Amazon and gave them a try. As you can see they stick to the wall just fine and they are wipeable.
As you can see they are a bit translucent so any walls with busy wallpaper (as above) will shine through. I think over time they simply won’t wipe as well and probably lose their static but so far so good.