Repository navigation
Release 5.2.1 #662
Description
Activity
- pinned this issue
on Sep 1, 2023 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.
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.
- unpinned this issue
on Aug 31, 2024 - pinned this issue
on Aug 31, 2024 This is still open, isn't?
Could we help with this?
Reacted by xeromorph@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.
I see 5.2.1 now on nuget.org 🎉
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.
Reacted by Julian VerdurmenThanks @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?)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. 🙈
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.
Reacted by Julian Verdurmen- unpinned this issue
on Mar 10, 2025 @stakx could you please create a new patch release? :)
E.g. 5.2.2
@304NotModified, I'll look into it.
-
I'm assuming you're thinking primarily about
invocation.MethodInvocationTargetthrowsArgumentNullExceptionfor default interface method #684? Have you verified that you can get your side working properly after our bugfix for this? -
Would you require anything else to go into a patch release? I've done a fair bit of code refactoring, so currently not sure what else could easily be backported.
-
- I'm assuming you're thinking primarily about
invocation.MethodInvocationTargetthrowsArgumentNullExceptionfor default interface method #684?
Yes indeed :)
- Have you verified that you can get your side working properly after our bugfix for this
If there is a test package, I would be happy to test it.👍
- I'm assuming you're thinking primarily about
If there is a test package, I would be happy to test it.
There used to be a preview NuGet feed (mentioned in the README), but I am not sure if that is still working.
Then there are
.nupkgartifacts per build (e. g. this one and its accompanying symbol package).But if none of these work, perhaps it's easiest to clone the repo, temporarily add it to your solution and reference the main project instead of a NuGet package.
Reacted by Julian Verdurmen@stakx I can confirm that this issue in Castle Core 5.2.1 has been fixed in 6.0.0 preview (taken from https://ci.appveyor.com/project/castleproject/core/builds/53542581/job/b0vpahb8rymgngak/artifacts)
Reacted by Dominique Schuppli
I think we're almost ready for another release.
ref struct) parameter types such asSpan<T>andReadOnlySpan<T>#664 and Prevent disallowed conversions betweenobjectand 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.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:
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 ofProxyGeneratora lot.