Skip to content

Releases: icerpc/icerpc-csharp

0.4.1

15 Nov 16:51
Compare
Choose a tag to compare
  • Add support for .NET 9.0

Full Changelog: v0.4.0.1...v0.4.1

0.4.0.1

17 Sep 14:23
Compare
Choose a tag to compare

What's Changed

  • Update release workflow to build the reporter before packaging tools by @pepone in #4080

Full Changelog: v0.4.0...v0.4.0.1

0.4.0

16 Sep 20:12
f5b6244
Compare
Choose a tag to compare

What's Changed

  • Add support for .NET 9.0 (.NET 9.0 RC1).

  • QUIC transport

    • Add new KeepAliveInterval option to IceRpc.Transports.Quic.QuicClientTransportOptions. This new option is implemented with .NET 9.0 and has no effect with .NET 8.0.

      In .NET 8.0, .NET QUIC does not keep connections alive and does not provide an option to keep connections alive. For example, if you send a request to a server and the server takes a long time to return the corresponding response (more than the connection's idle timeout, which is by default 30 seconds) and there is no other activity (request/response) on this connection, .NET QUIC aborts the connection because it remained idle for too long. This is naturally an undesirable behavior, with unfortunately no good solution in .NET 8.0.

      In .NET 9.0, .NET QUIC provides the option to keep a connection alive with the KeepAliveInterval option (on System.Net.Quic.QuicConnectionOptions). This option instructs .NET QUIC to send a ping every KeepAliveInterval to keep the connection alive. The new KeepAliveInterval of IceRpc.Transports.Quic.QuicClientTransportOptions configures this option for client connections. The default value is 15 seconds (half of the default idle timeout). This way, with the default idle timeout and keep-alive interval, the previous scenario (a server that takes a long time to return a response) works perfectly fine and the connection is not aborted. If you reduce the idle timeout, you should also reduce this KeepAliveInterval to about half the idle timeout. IceRPC sets the KeepAliveInterval to infinite for server connections; in other words, IceRPC servers never send QUIC pings to clients.

  • Slice

    • Improve the mapping for fields in structs, classes and exceptions: fields with a non-optional Slice type mapped to a C# reference type are now required.
    • (Slice1) Simplify mapping for Slice classes and exceptions. A Slice class or exception is now mapped to C# class with a public parameterless constructor (and other constructors). This parameterless constructor is used by the ZeroC.Slice activator for decoding.
  • Slice and Protobuf compilation

    • Add build telemetry. IceRPC collects anonymous telemetry data when you compile Slice files or Protobuf files. You can find detailed information about what data is collected and how to opt-out in the READMEs for IceRpc.Slice.Tools and IceRpc.Protobuf.Tools.
  • Ice interop

    • Changed the default value for the EnableIceIdleCheck option on IceRpc.ConnectionOptions to true. See the documentation of this option for full details.

Full Changelog: v0.3.1...v0.4.0

0.3.1

28 Mar 20:42
Compare
Choose a tag to compare

What's Changed

  • Fix the version of the IceRPC assemblies used by the examples.
  • New --transport option for dotnet new templates, to make it easier to create IceRPC applications that use QUIC.
  • Upgrade Protobuf version to 3.26.1.
  • Include protoc binaries for arm64 in IceRpc.Protobuf.Tools.
  • Fix small Slice1 interop bug introduced in 0.3.0.

Full Changelog: v0.3.0...v0.3.1

0.3.0

15 Feb 16:21
Compare
Choose a tag to compare

What's Changed

This release is focused on the Slice language and adds two long-planned enhancements:

  • Add support for discriminated unions or "enums with fields".
    Enums with fields are mapped to record classes in C#, with helper methods generated by Dunet.

    Please refer to the updated enum documentation and the DiscriminatedUnion example.

  • Add new Result<Success, Failure> type to Slice.

    It's a new built-in generic type that behaves like an enum with 2 fields. In C#, it maps to a Dunet-enhanced generic record class.

    The main use-case for Result is as an operation return type - it allows you to return a "successful completion" value or a custom error. This is an increasingly common pattern found in Rust and Swift that works very nicely for RPCs.

    See the new Result documentation and the CustomError example.

Full Changelog: v0.2.1...v0.3.0

0.2.1

12 Dec 15:21
Compare
Choose a tag to compare

What's Changed

  • Compute if Protobuf files need to be rebuilt by @pepone in #3852
  • Fix IceRpc.Protobuf.Tools package to work on non Windows platforms by @pepone in #3862

Full Changelog: v0.2.0.1...v0.2.1

0.2.0

04 Dec 16:03
Compare
Choose a tag to compare

What's Changed

Full Changelog: v0.1.2...v0.2.0

0.1.2

09 Oct 15:38
Compare
Choose a tag to compare

What's Changed

Full Changelog: v0.1.1...v0.1.2

0.1.1

19 Sep 01:03
fece016
Compare
Choose a tag to compare

Small fixes to the NuGet packaging.

0.1.0

06 Sep 22:07
5c4d3e3
Compare
Choose a tag to compare