Mono lacks support for ExtendedProtectionSelector

[scottoffen]

This lack of support leads to such problems as these, recently logged on StackOverflow:

Running Grapevine REST server in Mono Docker container

Error: System.TypeLoadException: Could not load type 'Grapevine.Interfaces.Server.HttpListener' from assembly 'Grapevine, Version=4.0.0.195, Culture=neutral, PublicKeyToken=null'.
  at Boerse.BoersenApplication.Main (System.String[] args) [0x0002f] in <407ced228a394aa7b9fc2fa883a239a9>:0
TypeRef ResolutionScope not yet handled (57) for .ExtendedProtectionSelector in image /boerse/Grapevine.dll
Could not load signature of Grapevine.Interfaces.Server.HttpListener:get_ExtendedProtectionSelectorDelegate due to: Could not resolve type with token 0100003a assembly: type:ExtendedProtectionSelector member:<none>
TypeRef ResolutionScope not yet handled (57) for .ExtendedProtectionSelector in image /boerse/Grapevine.dll
Could not load signature of Grapevine.Interfaces.Server.IHttpListener:get_ExtendedProtectionSelectorDelegate due to: Could not resolve type with token 0100003a assembly: type:ExtendedProtectionSelector member:<none>

Cannot load type HttpListener in simple Grapevine server example

System.TypeLoadException: Could not load type 'Grapevine.Interfaces.Server.HttpListener' from assembly 'Grapevine, Version=4.0.0.195, Culture=neutral, PublicKeyToken=null'. at Grapevine.Server.RestServer..ctor () [0x00006] in <5da3c1fcf3364795b3df98bfc8b714aa>:0 at TestServer.MainClass.Main (System.String[] args) [0x0000b] in /Users/blah/Projects/Test/TestServer/Program.cs:12

Both of which might be resolved once there is a Grapevine version that targets .NET 4.5 or 4.6.

[scottoffen]

Fixed in 4.1.0-alpha.0

[scottoffen]

Since I haven't heard anyone tell me otherwise, I'm going to assume this resolves the issue. As such, I will release a production version of 4.1 in the next week or so.

I'm going to stray from semver here. Because I am removing part of the API and therefore introducing a breaking change, I should do a major version change (from 4 to 5). But I'm not going to do that - opting instead to go to version 4.1 - for two reasons.

1. This API feature was actually making the library unusable for some people. And to the best of my knowledge, this isn't a feature anyone is using. I honestly don't get much feedback from my users base unless there is a problem, so it might just be a matter of not enough of the right kind of feedback, but if you really want to use this feature of the API, just stay on version 4.0.

2. Version 5 is already underway, and it not only includes many, many other breaking changes, it also provides a spectacularly better way of managing these kinds of API/dependency feature implementation thingys (i.e., exposing features of the underlying http implementation to the user). In fact, changes in version 5 will make it possible to provide future minor versions (e.g. 5.1, 5.2, etc.) that don't rely on the HttpListener class at all. I may never do this, but at least if I don't it won't be because my library is too tightly coupled to the existing HttpListener implementation.

Okay, that's all for now, the rest will go in a blog post.