Today, we released version 0.1.0 of our .NET SDK! After almost two months of heavy development work, I’m excited to get this code into the hands of the community. In this article, I’ll cover the basics of how to install and use the SDK from a C# project, as well as talk about some of the design behind the code.
This is a very early release, so please share your questions and feedback in the comments below, email me at [email protected], or issue a pull request.
The authentication story in .NET has long been a complicated one. In the past, we had big, heavy identity solutions like ASP.NET Membership. Often, these solutions meant being locked into using SQL Server. The situation has improved with ASP.NET Identity, which adopts a modular architecture.
Even still, there’s a good chance you’ll need to descend into the trenches if you’re not planning on using Entity Framework or SQL Server as your data store.
What if you want multiple web applications to share a user store? Or you’re building an API and need token authentication for untrusted clients? Or you want to support social login providers? What if you’re on a non-IIS environment, like Nancy? Or on completely different platform with Xamarin? We want to make your life easier!
Stormpath already provides a strong (and lightweight) REST API for user authentication and authorization. This library is the first step in our efforts to make it super easy to drop the Stormpath authentication layer into any ASP.NET, C#, or VB.NET application (or anything else on the .NET stack).
Soon, you’ll be able to add social login, single sign-on across your apps, and token authentication to your .NET project with just a few clicks and zero headache. This first release provides the core functionality that will power all the cool stuff to come.
Let’s get started!
If you’re impatient (like a good developer should be), installation couldn’t be easier:
install-package Stormpath.SDK from the Visual Studio Package Manager Console. Or, if you’re GUI-inclined, you can search for Stormpath.SDK in the NuGet Package Manager.
The official C# quickstart covers the essentials in about 10 minutes:
The SDK supports the .NET Framework (version 4.5 and above), as well as Mono 4.0 and higher, so you can drop it into any recent project. These examples are in C#, but it works just as well for VB.NET, too.
Go try it out! I’ll wait here.
LINQ is a beautiful query language for interacting with data sources. It makes perfect sense to use LINQ to build queries for the Stormpath API.
With the .NET SDK, you can write a strongly-typed, expressive query like this:
var newUsersThisMonthNamedSkywalker = await myApp.GetAccounts()
.Where(x => x.Surname == "Skywalker" && x.CreatedAt.Within(2015, 09))
.OrderBy(x => x.Email)
And it’s automagically translated into the appropriate GET request:
I think that’s pretty sexy. <3
Let’s talk about async.
From the beginning, my goal was to design a modern .NET SDK. That meant embracing the Task Parallel Library and
await. Every network call to the Stormpath API is made asynchronously. The methods exposed by the SDK return awaitable
Tasks, and have optional overloads that take a
Why does this matter? If you’re building an ASP.NET application, you can easily integrate the SDK into asynchronous controllers that won’t block a thread while you’re making an API request to Stormpath. No blocking means your application can process more requests faster. That’s pretty cool!
But what about situations where you can’t use these keywords? The Stormpath .NET SDK includes a compatibility layer (in the
Stormpath.SDK.Sync namespace) that provides synchronous access to the API. Because sync-over-async is a bad idea, this isn’t just a wrapper – it’s a full dual-programming model with separate synchronous and asynchronous execution paths.
The SDK depends on a few external libraries: JSON.NET for JSON (de)serialization, and RestSharp for making HTTP requests. However, if you don’t want to use either of those in your project, no problem! The SDK is designed to be modular, and both of these dependencies sit behind abstraction layers. Just write your own implementation and plug it in!
Compiling with Mac OS or Linux in mind? No problem. Running code on Mono is only going to become more important with the upcoming introduction of ASP.NET vNext and DNX. I’m happy to report that every bit of the SDK compiles and runs perfectly under Mono.
This is an exciting release, but there’s still plenty more to do. Here’s what’s on the roadmap:
Like what you see? Follow @goStormpath to keep up with the latest releases.