Skip to content

Releases: launchdarkly/dotnet-server-sdk

5.7.1

01 Oct 22:56
1ad5332
Compare
Choose a tag to compare

[5.7.1] - 2019-09-13

(The changes below were originally released in 5.7.0, but that release was broken; 5.7.1 is its replacement.)

This release includes new types and deprecations that correspond to upcoming changes in version 6.0.0. Developers are encouraged to start adopting these changes in their code now so that migrating to 6.0.0 in the future will be easier. Most of these changes are related to the use of mutable types, which are undesirable in a concurrent environment. User and Configuration are currently mutable types; they will be made immutable in the future, so there are now builders for them. Arbitrary JSON values are currently represented with the Newtonsoft.Json type JToken, which is mutable (if it contains an array or a JSON object); the new type LdValue is safer, and will eventually completely replace JToken in the public API.

Also, generated HTML documentation for all of the SDK's public types, properties, and methods is now available online at https://launchdarkly.github.io/dotnet-server-sdk/. Currently this will only show the latest released version.

Added:

  • Configuration.Builder provides a fluent builder pattern for constructing Configuration objects. This is now the preferred method for building a user, rather than using ConfigurationExtension methods like WithStartWaitTime() that modify the existing configuration object.
  • Configuration.EventCapacity and Configuration.EventFlushInterval (new names for EventQueueCapacity and EventQueueFrequency, for consistency with other LaunchDarkly SDKs).
  • User.Builder provides a fluent builder pattern for constructing User objects. This is now the preferred method for building a user, rather than setting User properties directly or using UserExtension methods like AndName() that modify the existing user object.
  • User.IPAddress is equivalent to User.IpAddress, but has the standard .NET capitalization for two-letter acronyms.
  • The new LdValue type is a better alternative to using JToken, JValue, JArray, etc. for arbitrary JSON values (such as the return value of JsonVariation, or a custom attribute for a user).
  • There is now more debug-level logging for stream connection state changes.
  • XML documentation comments are now included in the package for all target frameworks. Previously they were only included for .NET Standard 1.4.

Changed:

  • Calls to flag evaluation methods such as BoolVariation are now somewhat more efficient because they no longer convert the default value to a JToken internally; also, user attributes no longer need to be converted to JToken internally when evaluating flag rules. If flag evaluations are very frequent, this reduces the number of ephemeral objects created on the heap.

Fixed:

  • Due to the default parsing behavior of Newtonsoft.Json, strings in the date/time format "1970-01-01T00:00:01Z" or "1970-01-01T00:00:01.001Z" would not be considered equal to an identical string in a flag rule.

Deprecated:

  • All ConfigurationExtension methods are now deprecated.
  • Configuration.SamplingInterval. The intended use case for the SamplingInterval feature was to reduce analytics event network usage in high-traffic applications. This feature is being deprecated in favor of summary counters, which are meant to track all events.
  • Configuration.EventQueueCapacity and Configuration.EventQueueFrequency (see new names above).
  • User constructors (use User.WithKey or User.Builder).
  • User.IpAddress (use IPAddress).
  • All UserExtension methods are now deprecated. The setters for all User properties should also be considered deprecated, although C# does not allow these to be marked with [Obsolete].
  • IBaseConfiguration and ICommonLdClient interfaces.
  • The InMemoryFeatureStore constructor. Use Components.InMemoryFeatureStore.

5.7.0

13 Sep 04:41
4ab5903
Compare
Choose a tag to compare

[5.7.0] - 2019-09-12

This release was broken and should not be used. It contains a bug that causes incorrect results from StringVariation. It has been delisted from NuGet.

5.6.5

31 May 18:24
7697fbf
Compare
Choose a tag to compare

[5.6.5] - 2019-05-30

Fixed:

  • If streaming is disabled, polling requests could stop working if the client ever received an HTTP error from LaunchDarkly. This bug was introduced in the 5.6.3 release.

5.6.4

11 May 00:39
Compare
Choose a tag to compare

[5.6.4] - 2019-05-10

Changed:

  • The NuGet package name and assembly name have changed: they are now LaunchDarkly.ServerSdk instead of LaunchDarkly.Client. There are no other changes in this release; the namespace used in .NET code is still LaunchDarkly.Client. Substituting LaunchDarkly.Client version 5.6.3 with LaunchDarkly.ServerSdk version 5.6.4 will not affect functionality.

5.6.3

13 Sep 04:40
Compare
Choose a tag to compare

[5.6.3] - 2019-05-10

Fixed:

  • If Track or Identify is called without a user, the SDK now will not send an analytics event to LaunchDarkly (since it would not be processed without a user).

Note on future releases

The LaunchDarkly SDK repositories are being renamed for consistency. This repository is now dotnet-server-sdk rather than dotnet-client.

The NuGet package name and assembly name will also change. In the 5.6.3 release, it is still LaunchDarkly.Client; in all releases after 5.6.3, it will be LaunchDarkly.ServerSdk. No further updates to the LaunchDarkly.Client package will be published after this release.

5.6.2

26 Mar 23:48
2d3707a
Compare
Choose a tag to compare

[5.6.2] - 2019-03-26

Changed:

  • The default value for the configuration property capacity (maximum number of events that can be stored at once) is now 10000, consistent with the other SDKs, rather than 500.

Fixed:

  • Under some circumstances, a CancellationTokenSource might not be disposed of after making an HTTP request, which could cause a timer object to be leaked. (#100)
  • In polling mode, if the client received an HTTP error it would retry the same request one second later. This was inconsistent with the other SDKs; the correct behavior is for it to wait until the next scheduled poll.
  • The HttpClientTimeout configuration property was being ignored when making HTTP requests to send analytics events.

5.6.1

05 Mar 00:38
59eae75
Compare
Choose a tag to compare

[5.6.1] - 2019-01-14

Fixed:

  • The assemblies in this package now have Authenticode signatures.

5.6.0

11 Jan 21:19
Compare
Choose a tag to compare

[5.6.0] - 2019-01-09

Added:

  • There are now helper classes that make it much simpler to write a custom IFeatureStore implementation. See the LaunchDarkly.Client.Utils namespace.
  • The new FeatureStoreCaching class will be used by database feature store integrations in the future. It is not used by the SDK client itself.

Changed:

  • Some support code has been moved into a separate assembly, LaunchDarkly.Cache.
  • The published assemblies are now built in Release configuration and no longer contain debug information.
  • If you are building a copy of the SDK yourself, the Debug configuration no longer does any signing, so does not require a key file.

5.5.0

11 Jan 21:18
c678077
Compare
Choose a tag to compare

[5.5.0] - 2018-10-30

Added:

  • It is now possible to inject feature flags into the client from local JSON or YAML files, replacing the normal LaunchDarkly connection. This would typically be for testing purposes. See LaunchDarkly.Client.Files.FileComponents.

  • The AllFlagsState method now accepts a new option, FlagsStateOption.DetailsOnlyForTrackedFlags, which reduces the size of the JSON representation of the flag state by omitting some metadata. Specifically, it omits any data that is normally used for generating detailed evaluation events if a flag does not have event tracking or debugging turned on.

  • The non-strong-named version of this library (LaunchDarkly.Common) can now be used with a non-strong-named version of LaunchDarkly.Client, which does not normally exist but could be built as part of a fork of the SDK.

Changed:

  • Previously, the delay before stream reconnect attempts would increase exponentially only if the previous connection could not be made at all or returned an HTTP error; if it received an HTTP 200 status, the delay would be reset to the minimum even if the connection then immediately failed. Now, if the stream connection fails after it has been up for less than a minute, the reconnect delay will continue to increase.

Fixed:

  • Fixed an unobserved exception that could occur following a stream timeout, which could cause a crash in .NET 4.0.

  • Fixed a NullReferenceException that could sometimes appear in the log if a stream connection failed.

  • Fixed the documentation for Configuration.StartWaitTime to indicate that the default is 10 seconds, not 5 seconds. (Thanks, KimboTodd!)

  • JSON data from AllFlagsState is now slightly smaller even if you do not use the new option described above, because it completely omits the flag property for event tracking unless that property is true.

5.4.0

30 Aug 22:52
fc225dc
Compare
Choose a tag to compare

[5.4.0] - 2018-08-30

Added:

  • The new LDClient methods BoolVariationDetail, IntVariationDetail, DoubleVariationDetail, StringVariationDetail, and JsonVariationDetail allow you to evaluate a feature flag (using the same parameters as you would for BoolVariation, etc.) and receive more information about how the value was calculated. This information is returned in an EvaluationDetail object, which contains both the result value and an EvaluationReason which will tell you, for instance, if the user was individually targeted for the flag or was matched by one of the flag's rules, or if the flag returned the default value due to an error.

Fixed:

  • When evaluating a prerequisite feature flag, the analytics event for the evaluation did not include the result value if the prerequisite flag was off.