.NET SDK Documentation
The guide will walk you through the installation and usage of the Floodgate .Net SDK.
Requirements
The .NET SDK requires version 4.5 or later of the .NET framework.
Getting Started
The first step is to install the Floodgate SDK as a dependency in your application using your application’s dependency manager.
Install-Package FloodGateSDK
Next import the package into your application.
using FloodGate.SDK;
Now you have the Floodgate SDK installed and imported you can create a new instance of the Floodgate Client. This instance should be created as a Singleton. You will need to specify your environment SDK Key when creating the client.
var floodgateClient = new FloodGateClient("ENTER-YOUR-SDK-KEY");
Important
It’s important that the Floodgate Client is created as a Singleton. This be because the Client will hold the state of your flags internally and creating a new instance of the Client would result in multiple calls back to the Floodgate servers when it’s not necessary.
Evaluating a Flag
Using the floodgateClient
object you can now evaluate a flag using the GetValue
method. The GetValue
method requires two parameters with an optional third.
Property | Required | Description |
---|---|---|
Key | Yes | This is the Flag Key which you entered when creating the flag. |
Default Value | Yes | This is the value which you want the flag to evaluate to if no flag data can be found. |
User Object | No | This is an optional value which can be passed containing information about the user. This information is required to evaluate flags when doing user targeting or percentage rollout releases. |
The example below shows an evaluation of a flag called send-push passing in a default value of false. Because the return type is going to be a Boolean we can implement a very simple if else condition and act accordingly.
var sendPush = floodgateClient.GetValue("send-push", false);
if (sendPush)
{
// Send push notification
}
else
{
// Send email
}
Finally before your application is going to terminate you should dispose of the Floodgate Client object. This ensures that any resources being used by the client will be released.
floodgateClient.Dispose();
Customizing the Floodgate Client
The Floodgate Client offers the following customization options to help with your implementation.
Option | Description |
---|---|
Timeout | By default the Floodgate Client will timeout after 10 seconds on startup. What this means is the client cannot obtain the necessary flag configuration data needed for operation it will throw an exception which you can handle in your application. You can use the Timeout property to override that value. For example you may wish to wait 2 seconds only before having the timeout exception thrown. The Timeout value is expressed in milliseconds. |
Logger | The Floodgate SDK comes with 3 build in logging methods. This is useful if you want to debug what is happening inside the client. By default the DefaultLogger is used, this is actually a NULL logger and will simply ignore any log messages sent to it. You can also use the FileLogger and ConsoleLogger to log to the file system or console respectively. |
RefreshInterval | The Floodgate Client stores and evaluates your flag configurations locally. From time-to-time the client will request an update from the server to make sure it always has the most up-to-date flag configuration data. By default this happens every 60 seconds. You can override this value using the RefreshInterval setting. The RefreshInterval expressed in seconds. |
In the example below we are setting the startup Timeout value to 2 seconds, the RefreshInterval to 5 seconds and we will be logging the SDK output to a file located at “/path/to/log/file”.
AutoUpdateClientConfig config = new AutoUpdateClientConfig()
{
SdkKey = "your-sdk-key",
Timeout = 2000,
Logger = new FileLogger("/path/to/log/file"),
RefreshInterval = 5
};
floodgateClient = new FloodGateClient(config);
Targeting users with the User Object
User targeting is a key aspect of getting the most benefit out of using feature flags. By defining users we are able to take advantage of features like user targeting and percentage rollouts (canary releases).
Security and User Data
Even though Floodgate requires data about your users to allow for targeted flag evaluations, this data is never sent to the Floodgate servers. All evaluations are done locally on your servers within your application.
User Object
Property | Required | Type | Description |
---|---|---|---|
User Id | Yes | string | Every user is required to be assigned a unique id. This could be a database id or the users email address for example. Session IDs or UUIDs are suited best. |
No | string | You can optionally set the users email address if you would like to evaluate against specific users emails. | |
Custom Attributes | No | Array | Each user can have any number of custom attributes assigned to them. This is a very powerful feature of Floodgate as it gives you the flexibility to evaluate flags against any data element that may belong to your users. The SDK you are using will determine the exact data type of the custom attributes. |
Below is an example of creating a Floodgate User Object.
var customAttributes = new Dictionary() {
{ "name", "Peter Parker" },
{ "subscription", "Gold" },
{ "country", "UK" },
{ "role", "Admin" }
};
User user = new User("a-unique-id")
{
Email = "spiderman@marvel.com",
CustomAttributes = customAttributes
};
Once we have created the User Object we can pass this into the GetValue method to have the flag evaluated specifically for the user as shown below.
var sendPush = floodgateClient.GetValue("send-push", false, user);
View the Code
All our SDKs are open source and you are free to check out what’s going on inside them. In fact we encourage contributions from the Floodgate community. You can view the source code on GitHub.