search

Particular / NServiceBus

Build, version, and monitor better microservices with the most powerful service platform for .NET
https://particular.net/nservicebus/
Other
2.07k stars 648 forks source link

Remove polyfil dependencies #7020

Closed thompson-tomo closed 4 months ago

thompson-tomo commented 4 months ago

Describe the feature.

Is your feature related to a problem? Additional dependencies are being added to my projects.

Describe the requested feature

System.Security.Cryptography.Xml is removed as a dependency due to it being able to be provided by the framework.

Describe alternatives you've considered

Accept the additional dependencies

Additional Context

No response

kentdr commented 4 months ago

@thompson-tomo thanks for raising the issue. There are reasons why we structured the dependencies the way we did, and removing it at this point would be a breaking change.

thompson-tomo commented 4 months ago

I don't see it as a breaking change if the framework ie net 8 still provides that dependency.

bording commented 4 months ago

I don't see it as a breaking change if the framework ie net 8 still provides that dependency.

@thompson-tomo System.Security.Cryptography.Xml is not part of the BCL for .NET 8, so I'm not sure what you mean here. That functionality is only included in the package.

System.Security.Cryptography.Xml is included in the .NET Framework BCL, but the functionality is in the System.Security assembly and not split out into a separate assembly like it is for .NET. That's why the package includes an assembly with TypeForwardedTo attributes to ensure the types can be loaded properly in all scenarios. I'm assuming this forwarding assembly is what you're referring to as a polyfil.

The primary reason we prefer not to condition dependencies based on target frameworks is that it leads to a more consistent experience. It avoids problems where it is possible to build an intermediate class library assembly that takes a dependency on the implementation assembly from the package, but when that intermediate assembly is used by an application, the forwarding assembly is not included as part of the application's dependencies, leading to runtime failures.

If we were to remove a package dependency at this point, anything built with the assumption of that package being referenced could observe a break of some kind. Given that there's no actual problem with having a potentially unneeded forwarding assembly in the bin output of your .NET Framework application, and that removing it could actually cause a break, we are not going to remove package dependencies outside of a new major version of NServiceBus.

If your .NET Framework application works fine without having System.Security.Cryptography.Xml.dll included, then you can always add a post-compilation step to your build that deletes it!