Releases: launchdarkly/dotnet-server-sdk
5.7.1
[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 constructingConfiguration
objects. This is now the preferred method for building a user, rather than usingConfigurationExtension
methods likeWithStartWaitTime()
that modify the existing configuration object.Configuration.EventCapacity
andConfiguration.EventFlushInterval
(new names forEventQueueCapacity
andEventQueueFrequency
, for consistency with other LaunchDarkly SDKs).User.Builder
provides a fluent builder pattern for constructingUser
objects. This is now the preferred method for building a user, rather than settingUser
properties directly or usingUserExtension
methods likeAndName()
that modify the existing user object.User.IPAddress
is equivalent toUser.IpAddress
, but has the standard .NET capitalization for two-letter acronyms.- The new
LdValue
type is a better alternative to usingJToken
,JValue
,JArray
, etc. for arbitrary JSON values (such as the return value ofJsonVariation
, 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 aJToken
internally; also, user attributes no longer need to be converted toJToken
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 theSamplingInterval
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
andConfiguration.EventQueueFrequency
(see new names above).User
constructors (useUser.WithKey
orUser.Builder
).User.IpAddress
(useIPAddress
).- All
UserExtension
methods are now deprecated. The setters for allUser
properties should also be considered deprecated, although C# does not allow these to be marked with[Obsolete]
. IBaseConfiguration
andICommonLdClient
interfaces.- The
InMemoryFeatureStore
constructor. UseComponents.InMemoryFeatureStore
.
5.7.0
[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
[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
[5.6.4] - 2019-05-10
Changed:
- The NuGet package name and assembly name have changed: they are now
LaunchDarkly.ServerSdk
instead ofLaunchDarkly.Client
. There are no other changes in this release; the namespace used in .NET code is stillLaunchDarkly.Client
. SubstitutingLaunchDarkly.Client
version 5.6.3 withLaunchDarkly.ServerSdk
version 5.6.4 will not affect functionality.
5.6.3
[5.6.3] - 2019-05-10
Fixed:
- If
Track
orIdentify
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
[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
[5.6.1] - 2019-01-14
Fixed:
- The assemblies in this package now have Authenticode signatures.
5.6.0
[5.6.0] - 2019-01-09
Added:
- There are now helper classes that make it much simpler to write a custom
IFeatureStore
implementation. See theLaunchDarkly.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
[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
[5.4.0] - 2018-08-30
Added:
- The new
LDClient
methodsBoolVariationDetail
,IntVariationDetail
,DoubleVariationDetail
,StringVariationDetail
, andJsonVariationDetail
allow you to evaluate a feature flag (using the same parameters as you would forBoolVariation
, etc.) and receive more information about how the value was calculated. This information is returned in anEvaluationDetail
object, which contains both the result value and anEvaluationReason
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.