6.3.0

[6.3.0] - 2021-10-25

Added:

• ConfigurationBuilder.ServiceEndpoints provides a simpler way of setting custom service base URIs, if you are connecting to a LaunchDarkly Relay Proxy instance, a private LaunchDarkly instance, or a test fixture. Previously, this required setting a BaseURI property for each individual service (streaming, events, etc.). If using the Relay Proxy, simply remove any BaseURI calls in your SDK configuration and call ServiceEndpoints(Components.ServiceEndpoints().RelayProxy(myRelayProxyUri)) on the IConfigurationBuilder.
• Convenience methods for working with JSON object and array values: LdValue.Dictionary, LdValue.List, LdValue.ObjectBuilder.Set, LdValue.ObjectBuilder.Remove, and LdValue.ObjectBuilder.Copy.

Fixed:

• When using the adapter that allows SDK types to be deserialized with the System.Text.Json API, temporary JsonDocument instances are now disposed of immediately rather than leaving them to be garbage-collected. (Thanks, JeffAshton!)

Deprecated:

• StreamingDataSourceBuilder.BaseURI, PollingDataSourceBuilder.BaseURI, and EventProcessorBuilder.BaseURI. The preferred way to set these is now with ConfigurationBuilder.ServiceEndpoints.

6.2.2

[6.2.2] - 2021-10-06

There are no functional changes in the SDK in this release; its only purpose is to address the version conflict issue mentioned below.

Fixed:

• Fixed conflicting dependency versions that existed in several LaunchDarkly packages. In .NET Core these would be resolved automatically, but in .NET Framework they could result in runtime assembly loading errors for LaunchDarkly.CommonSdk, LaunchDarkly.Logging, or System.Collections.Immutable, unless binding redirects were used. Note that it may still be necessary to use a binding redirect if your application (or one of its dependencies) relies on an assembly that is also used by the SDK with a different version.

6.2.1

[6.2.1] - 2021-09-28

Changed:

• When event handlers are called for events such as IFlagTracker.FlagChanged, the sender parameter will be the LdClient instance that generated the event. Previously, sender was being set to one of several internal components that were not useful to application code.

Fixed:

• When using IFlagTracker, flag change events would not fire if the data source was FileData and there was a change in the test data file(s). Now, any change to the test data will cause a flag change event to fire for every flag. (#144)
• A race condition could cause IDataSourceStatusProvider.WaitFor to wait indefinitely or time out even if the desired status was found.

6.2.0

[6.2.0] - 2021-07-22

Added:

• The SDK now supports evaluation of Big Segments. An Early Access Program for creating and syncing Big Segments from customer data platforms is available to enterprise customers.

6.1.0

[6.1.0] - 2021-06-22

Added:

• The SDK now supports the ability to control the proportion of traffic allocation to an experiment. This works in conjunction with a new platform feature now available to early access customers.

6.0.0

[6.0.0] - 2021-06-09

This is a major rewrite that introduces a cleaner API design, adds new features, and makes the SDK code easier to maintain and extend. See the .NET 5.x to 6.0 migration guide for an in-depth look at the changes in 6.0.0; the following is a summary.

Added:

• You can tell the SDK to notify you whenever a feature flag's configuration has changed (either in general, or in terms of its result for a specific user), using LdClient.FlagTracker.
• You can monitor the status of the SDK's data source (which normally means the streaming connection to the LaunchDarkly service) with LdClient.DataSourceStatusProvider. This allows you to check the current connection status, and to be notified if this status changes.
• You can monitor the status of a persistent data store with LdClient.DataStoreStatusProvider. This allows you to check whether database updates are succeeding, or to be notified if this status changes.
• The TestData class in LaunchDarkly.Sdk.Server.Integrations is a new way to inject feature flag data programmatically into the SDK for testing—either with fixed values for each flag, or with targets and/or rules that can return different values for different users. Unlike FileData, this mechanism does not use any external resources, only the data that your test code has provided.
• HttpConfigurationBuilder.Proxy allows you to specify an HTTP/HTTPS proxy server programmatically, rather than using .NET's HTTPS_PROXY environment variable. That was already possibly to do by specifying an HttpClientHandler that had a proxy; this is a shortcut for the same thing.
• HttpConfigurationBuilder.CustomHeader allows you to specify custom HTTP headers that should be added to every HTTP/HTTPS request made by the SDK.
• HttpConfigurationBuilder.ResponseStartTimeout sets the timeout interval for "start of request until beginning of server response", which .NET represents as System.Net.HttpClient.Timeout. The SDK previously referred to this as ConnectTimeout, but it was not a real connection timeout in the sense that most TCP/IP frameworks use the term, so the new name more clearly defines the behavior.
• There is now a DoubleVariation method for getting a numeric flag value as the double type (as opposed to FloatVariation which returns a float).
• The Alias method of LdClient can be used to associate two user objects for analytics purposes with an alias event.
• ConfigurationBuilder.Logging is a new configuration category for options related to logging. This includes a new mechanism for specifying where log output should be sent, instead of using the Common.Logging framework to configure this.
• LoggingConfigurationBuilder.LogDataSourceOutageAsErrorAfter controls the new connection failure logging behavior described below under "behavioral changes".
• The LaunchDarkly.Sdk.Json namespace provides methods for converting types like User and FeatureFlagsState to and from JSON.
• The LaunchDarkly.Sdk.UserAttribute type provides a less error-prone way to refer to user attribute names in configuration, and can also be used to get an arbitrary attribute from a user.
• The LaunchDarkly.Sdk.UnixMillisecondTime type provides convenience methods for converting to and from the Unix epoch millisecond time format that LaunchDarkly uses for all timestamp values.

Changed (requirements/dependencies/build):

• The SDK's build targets are now .NET Standard 2.0, .NET Core 2.1, .NET Framework 4.5.2, .NET Framework 4.7.1, and .NET 5.0. This means it can be used in applications that run on .NET Core 2.1 and above, .NET Framework 4.5.2 and above, .NET 5.0 and above, or in a portable library that is targeted to .NET Standard 2.0 and above.
• The SDK no longer has a dependency on Common.Logging. Instead, it uses a similar but simpler logging facade, the LaunchDarkly.Logging package, which has adapters for various logging destinations (including one for Common.Logging, if you want to keep an existing configuration that uses that framework).
• The SDK no longer has a dependency on Newtonsoft.Json. It uses the System.Text.Json API internally on platforms where that is available; on others, such as .NET Framework 4.5.x, it uses a lightweight custom implementation. This removes the potential for dependency version conflicts in applications that use Newtonsoft.Json for their own purposes. Converting data types like User and LdValue to and from JSON with System.Text.Json will always work; converting them with Newtonsoft.Json requires an extra package, LaunchDarkly.CommonSdk.JsonNet.
• The SDK's dependencies for its own implementation details are now LaunchDarkly.CommonSdk, LaunchDarkly.EventSource, LaunchDarkly.InternalSdk, and LaunchDarkly.JsonStream. You should not need to reference these assemblies directly, as they are loaded automatically when you install the main NuGet package LaunchDarkly.ServerSdk. Previously there was also a variant called LaunchDarkly.CommonSdk.StrongName that was used by the release build of the SDK, but that has been removed.

Changed (API changes):

• The base namespace has changed: types that were previously in LaunchDarkly.Client are now in either LaunchDarkly.Sdk or LaunchDarkly.Sdk.Server. The LaunchDarkly.Sdk namespace contains types that are not specific to the server-side .NET SDK (that is, they will also be used by the Xamarin SDK): EvaluationDetail, LdValue, User, and UserBuilder. Types that are specific to the server-side .NET SDK, such as Configuration and LdClient, are in LaunchDarkly.Sdk.Server.
• Many properties have been moved out of ConfigurationBuilder, into sub-builders that are specific to one area of functionality (such as streaming, or analytics events). See ConfigurationBuilder and Components.
• User and Configuration objects are now immutable. To specify properties for these classes, you must now use User.Builder and Configuration.Builder.
• The following things now use the type LdValue instead of JToken: custom attribute values in User.Custom; JSON flag variations returned by JsonVariation, JsonVariationDetail, and AllFlags; the optional data parameter of LdClient.Track.
• EvaluationReason is now a single struct type rather than a base class.
• LaunchDarkly.Client.Files.FileComponents has been moved to LaunchDarkly.Sdk.Server.Integrations.FileData.
• LdClient.Initialized is now a read-only property rather than a method.
• Interfaces for creating custom components, such as IFeatureStore, now have a new namespace (LaunchDarkly.Sdk.Server.Interfaces), new names, and somewhat different semantics due to changes in the SDK's internal architecture. Any existing custom component implementations will need to be revised to work with .NET SDK 5.x.
• The ILdClient interface is now in LaunchDarkly.Sdk.Server.Interfaces instead of the main namespace.
• The IConfigurationBuilder interface has been replaced by the concrete class ConfigurationBuilder.

Changed (behavioral changes):

• In streaming mode, the SDK will now drop and restart the stream connection if either 1. it receives malformed data (indicating that some data may have been lost before reaching the application) or 2. you are using a database integration (a persistent data store) and a database error happens while trying to store the received data. In both cases, the intention is to make sure updates from LaunchDarkly are not lost; restarting the connection causes LaunchDarkly to re-send the entire flag data set. This makes the .NET SDK's behavior consistent with other LaunchDarkly server-side SDKs.
• However, if you have set the caching behavior to "cache forever" (see PersistentDataStoreConfiguration), the stream will not restart after a database error; instead, all updates will still be accumulated in the cache, and will be written to the database automatically if the database becomes available again.
• Logging now uses a simpler, more stable set of logger names instead of using the names of specific implementation classes that are subject to change. General messages are logged under LaunchDarkly.Sdk.Server.LdClient, while messages about specific areas of functionality are logged under that name plus .DataSource (streaming, polling, file data, etc.), .DataStore (database integrations), .Evaluation (unexpected errors during flag evaluations), or .Events (analytics event processing).
• Network failures and server errors for streaming or polling requests were previously logged at Error level in most cases but sometimes at Warn level. They are now all at Warn level, but with a new behavior: if connection failures continue without a successful retry for a certain amount of time, the SDK will log a special Error-level message to warn you that this is not just a brief outage. The amount of time is one minute by default, but can be changed with the new LogDataSourceOutageAsErrorAfter option in LoggingConfigurationBuilder.
• Many internal methods have been rewritten to reduce the number of heap allocations in general.
• Evaluation of rules involving regex matches, date/time values, and semantic versions, has been sped up by pre-parsing the values in the rules.
• Evaluation of rules involving an equality match to multiple values (such as "name is one of X, Y, Z") has been sped up by converting the list of values to a set.
• If analytics events are disabled with Components.NoEvents, the SDK now avoids generating any analytics event objects internally. Previously they were created and then discarded, causing unnecessary heap churn.
• When accessing a floating-point fl...

6.0.0-rc.3

[6.0.0-rc.3] - 2021-06-07

Other than the fix described below, this release candidate is identical to rc.2.

Fixed:

• On platforms that do not support System.Text.Json, such as .NET Framework 4.5.2, the SDK's implementation of JSON parsing was rejecting feature flag data (or any other SDK type that you asked to parse from JSON) if it contained a numeric value that had an exponent but no decimal point. For instance, 1e8 (as opposed to 1.0e8) was incorrectly treated as a syntax error. It now accepts numbers in any of the formats that are valid in JSON.

6.0.0-rc.2

[6.0.0-rc.2] - 2021-05-17

Other than the fix described below, and improvements in unit test stability, this release candidate is identical to rc.1.

Fixed:

• Incorporated a fix in LaunchDarkly.EventSource 4.1.2 for a memory leak in previous 4.x versions of that library. The leak did not exist in the 3.x versions of LaunchDarkly.EventSource that were used in LaunchDarkly.ServerSdk 5.x.

6.0.0-rc.1

[6.0.0-rc.1] - 2021-05-07

This release candidate includes the following changes since 6.0.0-beta.1. No further changes in the API are expected before the GA release.

Added:

• HttpConfigurationBuilder.ResponseStartTimeout: this sets the timeout interval for "start of request until beginning of server response", which .NET represents as System.Net.HttpClient.Timeout. The SDK previously referred to this as ConnectTimeout, but it was not a real connection timeout in the sense that most TCP/IP frameworks use the term, so the new name more clearly defines the behavior.

Changed:

• HttpConfigurationBuilder.ConnectTimeout now sets the timeout for making a network connection, so it is consistent with what is called a connection timeout in other LaunchDarkly SDKs and in most networking libraries. It only has an effect in .NET Core 2.1+ and .NET 5.0+; other .NET platforms do not support this kind of timeout.
• The SDK package now includes builds for the target frameworks .NET Core 2.1 and .NET 5.0. Previously, applications built for those platforms would use the .NET Standard 2.0 build of the SDK; the additional builds were added to make the implementation of ConnectTimeout possible. This does not require any changes to the application build, since .NET automatically picks the most closely compatible version of the package.

Fixed:

• Incorporated the fix from 5.14.2 for custom base URI paths.

5.14.2

[5.14.2] - 2021-03-24

Fixed:

• Setting a custom base URI to use instead of the regular LaunchDarkly service endpoints did not work correctly if the base URI included a path prefix, as it might if for instance you were using a reverse proxy that would forward requests from http://my-proxy/launchdarkly-stream/some-endpoint-path to https://stream.launchdarkly.com/some-endpoint-path. In this example, the /launchdarkly-stream part was being dropped from the request URL, preventing this type of proxy configuration from working. Now the base path will always be preserved.