Bump Castle.Core from 4.4.0 to 5.0.0

[dependabot]

Bumps Castle.Core from 4.4.0 to 5.0.0.

Release notes

Sourced from Castle.Core's releases.

5.0.0

Enhancements

• .NET 6.0 support (@​Jevonius, #616)
• .NET Standard 2.0 and 2.1 support (@​lg2de, #485)
• Non-intercepted methods on a class proxy with target are now forwarded to the target (@​stakx, #571)
• Significant performance improvements with proxy type generation for interface proxies without target. Up until now, DynamicProxy generated a separate IInvocation implementation type for every single proxied method – it is now able to reuse a single predefined type in many cases, thereby reducing the total amount of dynamic type generation. (@​stakx, #573)

Bugfixes

• Generic method with differently named generic arguments to parent throws KeyNotFoundException (@​stakx, #106)
• Proxying certain [Serializable] classes produces proxy types that fail PEVerify test (@​stakx, #367)
• private protected methods are not intercepted (@​CrispyDrone, #535)
• System.UIntPtr unsupported (@​stakx, #546)
• DynamicProxy generates two modules when proceeding from a class proxy's protected method to the target, causing an InvalidOperationException when saving the generated assembly to disk (@​stakx, #569)
• Upgrade log4net to v2.0.13 (@​jonorossi, @​stakx, @​dschwartzni, #574, #605)

Deprecations

• Removed support for the .NET Framework < 4.6.2 and .NET Standard 1.x. (@​stakx, #495, #496; @​Jevonius, #614)
• Removed support for Code Access Security (CAS). (@​stakx, #502)
• Removed support for Remoting. This library no longer defines any types deriving from MarshalByRefObject, and ProxyUtil.IsProxy (which used to recognize remoting/"transparent" proxies) now tests only for DynamicProxy proxies. (@​stakx, #507)
• The following public members have been removed:
  • Castle.Core.Internal.CollectionExtensions (class)
  • Castle.Core.Internal.Lock (class) along with all related types and methods
  • Castle.Core.Internal.PermissionUtil.IsGranted (method)
  • Castle.Core.Pair<,> (type). Use System.ValueTuple<,> or System.Tuple<,> instead.
  • all type members in Castle.DynamicProxy.ModuleScope that gave direct access to DynamicProxy's type cache and ModuleBuilders. Only SaveAssembly, LoadAssemblyIntoCache, and members supporting these two facilities are left public.
  • almost all types and type members in the Castle.DynamicProxy.* sub-namespaces, as most of them are intended for internal use only.
  • DynamicProxy's custom exception types have been replaced by standard BCL exceptions (where appropriate), and by a single DynamicProxyException type for internal DynamicProxy errors.

5.0.0-beta001

Full release notes will be available in the future.

4.4.1

Bugfixes

• Prevent method name collisions when a proxy type implements more than two identically named interfaces having one or more identically named methods each. Name collisions are avoided by including the declaring types' namespaces in the proxy type's method names. (@​stakx, #469)
• Reduce lock contention while generating new proxy types which previously blocked new proxy instances (@​tangdf, #484)
• Fix mixins where proxy constructor fields were ordered differently to interfaces because of different case comparisons (@​zapov, #475)
• Fix proxy generation for types having only a private protected constructor (@​mriehm, #491)

Changelog

Sourced from Castle.Core's changelog.

5.0.0 (2022-05-11)

Enhancements:

• .NET 6.0 support (@​Jevonius, #616)
• .NET Standard 2.0 and 2.1 support (@​lg2de, #485)
• Non-intercepted methods on a class proxy with target are now forwarded to the target (@​stakx, #571)
• Significant performance improvements with proxy type generation for interface proxies without target. Up until now, DynamicProxy generated a separate IInvocation implementation type for every single proxied method – it is now able to reuse a single predefined type in many cases, thereby reducing the total amount of dynamic type generation. (@​stakx, #573)

Bugfixes:

• Generic method with differently named generic arguments to parent throws KeyNotFoundException (@​stakx, #106)
• Proxying certain [Serializable] classes produces proxy types that fail PEVerify test (@​stakx, #367)
• private protected methods are not intercepted (@​CrispyDrone, #535)
• System.UIntPtr unsupported (@​stakx, #546)
• DynamicProxy generates two modules when proceeding from a class proxy's protected method to the target, causing an InvalidOperationException when saving the generated assembly to disk (@​stakx, #569)
• Upgrade log4net to v2.0.13 (@​jonorossi, @​stakx, @​dschwartzni, #574, #605)

Deprecations:

• Removed support for the .NET Framework < 4.6.2 and .NET Standard 1.x. (@​stakx, #495, #496; @​Jevonius, #614)
• Removed support for Code Access Security (CAS). (@​stakx, #502)
• Removed support for Remoting. This library no longer defines any types deriving from MarshalByRefObject, and ProxyUtil.IsProxy (which used to recognize remoting/"transparent" proxies) now tests only for DynamicProxy proxies. (@​stakx, #507)
• The following public members have been removed:
  • Castle.Core.Internal.CollectionExtensions (class)
  • Castle.Core.Internal.Lock (class) along with all related types and methods
  • Castle.Core.Internal.PermissionUtil.IsGranted (method)
  • Castle.Core.Pair<,> (type). Use System.ValueTuple<,> or System.Tuple<,> instead.
  • all type members in Castle.DynamicProxy.ModuleScope that gave direct access to DynamicProxy's type cache and ModuleBuilders. Only SaveAssembly, LoadAssemblyIntoCache, and members supporting these two facilities are left public.
  • almost all types and type members in the Castle.DynamicProxy.* sub-namespaces, as most of them are intended for internal use only.
  • DynamicProxy's custom exception types have been replaced by standard BCL exceptions (where appropriate), and by a single DynamicProxyException type for internal DynamicProxy errors.

4.4.1 (2020-05-06)

Bugfixes:

• Prevent method name collisions when a proxy type implements more than two identically named interfaces having one or more identically named methods each. Name collisions are avoided by including the declaring types' namespaces in the proxy type's method names. (@​stakx, #469)
• Reduce lock contention while generating new proxy types which previously blocked new proxy instances (@​tangdf, #484)
• Fix mixins where proxy constructor fields were ordered differently to interfaces because of different case comparisons (@​zapov, #475)
• Fix proxy generation for types having only a private protected constructor (@​mriehm, #491)

Commits

• 652a250 Update changelog
• 773ed6b Update changelog for 5.0.0 release
• f49b72a Readme: Update conditional compilation symbols
• 51f4f92 Merge pull request #616 from Jevonius/add-net6-targets
• 0076083 Switch to preprocessor directives to avoid need for System.Runtime.InteropSer...
• 9da21a7 Switch SYSLIB0003 suppression to pragma rather than project-level
• 2de4707 Update CHANGELOG and README to reflect net6.0 change
• 3e6e22d Remove references of DOTNET462 as no longer used
• 8641c5f Update missed copyright header year for changed test file
• 14264bc Update PublicApiTestCase platform filtering to use NUnit attribute
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[jzabroski]

@JSkimming could i help with this

[JSkimming]

@jzabroski is there a reason you need this? I'd assumed users of this library could update Castle.Core to v5 if you are already targeting .NET 6 or other minimum frameworks referenced by Castle.Core.

Upgrading a dependency is a breaking change requiring a major version update. There are a few other breaking changes I was planning on implementing, and to minimise breaking change releases, I intended on combining the two. But if you're held back without this change, then a release just for the Castle.Core update is worth considering.

[jzabroski]

We're stuck on net48 for one ASP.NET Website project we are porting from WebForms to ASP.NET MVC 5 (and eventually Razor).

Your package is insanely important to us since we use it for asynchronous logical transactions, like so:

[Transaction(DbContextNames.MyDb)]
public async Task Save()

This approach has a downside in that composing two transactions requires both to be annotated, as well as the overarching transaction entry point to be annotated. As a result, we need to inject transactions in the Website Page subclasses.

[jzabroski]

I would add, our workaround for now is to create a binding redirect (Castle.Core 0.0.0.0-5.0.0.0 => 5.0.0.0), but that seems suboptimal.

[JSkimming]

I appreciate your situation, having been there myself many times, but binding redirects exist for this reason. I imagine you have many others in your web.config file. It's been a while since I worked with .NET Framework, but I believe binding redirects are automatically applied by nuget when applying package updates.

Given this isn't a blocker, I'm keen to stick to my Plan A of bunding the Castle.Core package update with other breaking changes.

[jzabroski]

Binding redirects aren't autogenerated for Websites, I believe. They are for Web applications instead.

[dependabot]

Superseded by #162.