CoreWCF v1.9.0

[mconnew]

Release Notes

Package Info

CoreWCF.ConfigurationManager 1.9.0
CoreWCF.Http 1.9.0
CoreWCF.Kafka 1.9.0
CoreWCF.Kafka.Client 1.9.0
CoreWCF.MSMQ 1.9.0
CoreWCF.NetFramingBase 1.9.0
CoreWCF.NetNamedPipe 1.9.0
CoreWCF.NetTcp 1.9.0
CoreWCF.Primitives 1.9.0
CoreWCF.Queue 1.9.0
CoreWCF.RabbitMQ 1.9.0
CoreWCF.RabbitMQ.Client 1.9.0
CoreWCF.Templates 1.9.0
CoreWCF.UnixDomainSocket 1.9.0
CoreWCF.WebHttp 1.9.0

.NET Compatibility

This release depends on .NET Standard 2.0 and runs on any .NET version which supports .NET Standard 2.0. This release supports .NET Framework 4.6.2 and above, .NET 8, .NET 9, and .NET 10. It is built on top of ASP.NET Core and has been tested and runs on all currently supported versions of ASP.NET Core up to 10.0. The CoreWCF.RabbitMQ.Client, CoreWCF.Kafka.Client, and CoreWCF.UnixDomainSocket packages only support .NET 8 or later.

New Features

A service using NetNamedPipe can now listen from inside an Application Container and be connected to by a WCF client from outside the application container.

What's Changed

• Provide opt-out switch for EnableCoreWCFOperationInvokerGenerator attribute by @mconnew in Provide opt-out switch for EnableCoreWCFOperationInvokerGenerator attribute #1706
• Reduce CoreWCF.BuildTools analyzer and source generator IDE performance overhead by @Copilot in Reduce CoreWCF.BuildTools analyzer and source generator IDE performance overhead #1689
• Move named pipe to RTM by @mconnew in Clean up package dependencies and move named pipe to RTM #1697
• Add support for NetNamedPipe listening inside a Win32 App Container by @mconnew in Add support for NetNamedPipe listening inside a Win32 App Container #1693
• Make operation invoker generator enabled by default with graceful fallback by @Copilot in Make operation invoker generator enabled by default with graceful fallback #1660
• Annotate WebApplicationExtensions with ExcludeFromCodeCoverage by @Copilot in Annotate WebApplicationExtensions with ExcludeFromCodeCoverage #1658
• Update the expected *.wsdl's for net10.0+ to include dateOnly/timeOnly by @StephenMolloy in Update the expected *.wsdl's for net10.0+ to include dateOnly/timeOnly #1654
• Add ServiceBehaviorAttribute.EnsureOrderedDispatch property by @Copilot in Add ServiceBehaviorAttribute.EnsureOrderedDispatch property #1645

Bug Fixes

• Eliminate HttpDateParse by @mconnew in Eliminate HttpDateParse #1705
• Update the Negotiate implementation for .NET 8+ compatibility by @nmangue in Update the Negotiate implementation for .NET 8+ compatibility #1575
• Fix adding HttpContext to message properties before potential Message disposal by @mconnew in Fix adding HttpContext to message properties before potential Message disposal #1691
• Fix authorization policy support for class-based service contracts by @Copilot in Fix authorization policy support for class-based service contracts #1661
• Fix analyzer packaging path to match Roslyn 4.8 dependency by @Copilot in Fix analyzer packaging path to match Roslyn 4.8 dependency #1662
• Fix nullable reference type mismatch in operation invoker key generation by @Copilot in Fix nullable reference type mismatch in operation invoker key generation #1659
• Fixing WSDL generation for NetNamedPipe by @mconnew in Fixing WSDL generation for NetNamedPipe #1637

Feedback

Your feedback is important and appreciated. Please use the discussion #1709 for your questions and comments.

New Contributors

• StephenMolloy made their first contribution in Update the expected *.wsdl's for net10.0+ to include dateOnly/timeOnly #1654

Full Changelog: v1.8.0...v1.9.0

---

This discussion was created from the release CoreWCF v1.9.0.

[jheier]

Why is this update still using Microsoft.AspNetCore.DataProtection v2.3,9 referencing System.Security.Cryptography.Xml v10.0.0 that contains vulnerabilities?

[mconnew]

We need to reference Microsoft.AspNetCore.DataProtection v2.3.9 to work on .NET Framework. This version is not vulnerable. As can be seen by the screenshot from the nuget package details, it doesn't depend on System.Security.Cryptography.Xml v10.0.0. It's depending on 8.0.3, which has the vulnerability fixed. We depend on the latest patch release of the oldest LTS version in support as experience has shown it's a lot easier to override your application to use newer versions than to downgrade them.

[mconnew]

Also as an added note, the vulnerabilities in System.Security.Cryptography.Xml are in classes which CoreWCF doesn't use. Other than tooling complaining about referencing a vulnerable package, there's actually no problem using the older package as the vulnerable code won't ever get hit by CoreWCF.