Release 5.2.1

[stakx]

I think we're almost ready for another release.

• The PRs Draft: Add support for by-ref-like (ref struct) parameter types such as Span<T> and ReadOnlySpan<T> #664 and Draft: Prevent disallowed conversions between object and by-ref-like parameter and return types #665 are both marked as drafts, and will require some more work. They probably won't be finalized it time for this release.
• PR Add support for default interface members in inheritance-based proxy types #661 is not a draft, and I'm hoping we can include it here. But if it needs more work & time, we could also do a release 5.1.2 without it instead.

---

Things to do after this next release

I'd love if we could tackle those larger discussions about this library's (and DynamicProxy's) future, possibly resulting in a major version bump:

• whether or not (and how) to extract deprecated DictionaryAdapter into a separate project (Future of Castle DictionaryAdapter #394);
• whether or not to abandon (especially binary) serialization of DynamicProxy proxies (Remove support for serialization? #562);
• what to do about the logging abstractions & integration packages (Future of Castle logging abstraction and adapters #408).

Depending on the outcome of those decisions, we may end up with a much slimmer library and a somewhat pared-down DynamicProxy implementation that's easier to manage, so I think it would be good to start there and get rid of as much "baggage" as soon as we can.

(If we decide to keep the logging abstractions, we could take a look at #418, which should be relatively straightforward.)

I'd also love to do some code exploration about whether we really need 5 different types of proxy; I suspect we have a lot of code duplication in DynamicProxy because of that. While working on #447, that suspicion has only increased, since one of the previously distinguishing characteristics of interfaces – that they may not contain any implementation bits – no longer holds true in modern C# and .NET. The distinction between class and interface proxies may no longer make sense. (Note that instead of CreateClassProxy<TClass>(), you can already do an practically equivalent (TClass)CreateInterfaceProxyWithoutTarget<IEmptyInterface>(new ProxyGenerationOptions { BaseTypeForInterfaceProxy = typeof(TClass) })). We could potentially cut the number of collectors / contributors / generators in half with only a few minor breaking changes, and simplify the public API of ProxyGenerator a lot.

[stakx]

I've been delayed with daytime (aka paid) work, but I think I'll find some time very soon to finally get DIM support published.

[stakx]

Apologies to everyone who's been awaiting this release for a long time. Version 5.2.0 is basically ready, as soon as we've dealt with an expired NuGet API key, we should be able to publish it to NuGet.

[304NotModified]

This is still open, isn't?

Could we help with this?

[stakx]

@304NotModified, sorry for the delay. I could release 5.2.0 (and I have wanted to for a long time), but there is #684. I am somewhat worried about breaking e.g. NSubstitute by releasing 5.2.0 as is. Currently very busy with work so I don't have much time to prepare a fix in advance.

P.S.: IIRC, NuGet has a slightly unusual approach to semver in that it conservatively defaults to the lowest version that matches the requested version (not the highest), so perhaps we can safely release 5.2.0 without breaking anything. NSubstitute would have to explicitly upgrade their Castle.Core dependency to notice a problem.

[stakx]

I just tried to re-release this as 5.2.1 (I don't have sufficient permissions to simply re-trigger the build for 5.2.0 and perhaps it wouldn't even help because...) only for the CI build to fail immediately. We need to fix that first (related: #683).

[304NotModified]

I see 5.2.1 now on nuget.org 🎉

[stakx]

You're right. I got so many pipeline failure emails that I overlooked the one that mattered re: publication didn't fail. It's a bit of a mess but I'm glad 5.2.1 made it through the door. The CI builds will still need fixing but we can do that for the next release.

[304NotModified]

Thanks @stakx!

Can you update the release/tag on GitHub? That will prevent confusion in the future. --> https://github.com/castleproject/Core/releases

PS: there are some build errors with NSubstitute when upgrading from 5.1.1 to 5.2.1. I haven't checked that yet (no pc, on mobile), so I'm not sure if this a breaking change (on source level, regarding nullability) in Caste.Core. See nsubstitute/NSubstitute#871
(This isn't the same as #684 right?)

[stakx]

Can you update the release/tag on GitHub? That will prevent confusion in the future.

@304NotModified, thanks for the hint. I trashed the 5.2.0 release (which still carried the unmet August 2024 release date) and recreated a 5.2.1 one.

As you can perhaps tell, I've probably spent too much time away from this project, I feel a little disorganized right now. 🙈

[stakx]

Also @304NotModified:

there are some build errors with NSubstitute [...] This isn't the same as #684 right?

No, those build errors seem unrelated to #684. I'd say they're a direct result of #668.