My First Suave Api(tm)

Subtitle: You Know Nothing Eelco Mulder

With my previous blogs I’ve been setting up everything around developing with F#, but now it’s really time for me to just start coding. I’ve read a lot about F#, but when I start to code myself… I seem to know very little! So from now I’m just gonna get my hands dirty and just learn by coding, meanwhile blogging about it so I hope it’ll stick better.

So I started with this little simple Crud web api (source here:, build using F# on .Net Core, Suave and a SQL Server Express database. To connect to the database I used the SQLProvider, I found it easy to use and it has the linq syntax to query the database; automatic win for me.

I see other F# developers put their code in a few files, sometimes just one, but because I’m a C# developer and not some SAVAGE I got the urge to bundle certain code in separate files 😉

In the file Types.fs I created a little type Serie. In Database.fs I create the connection to the database using the SqlProvider. At first, when I ran dotnet build, I got the following error:

The type ‘String’ is required here and is unavailable. You must add a reference to assembly ‘System.Private.CoreLib, Version=, Culture=neutral, PublicKeyToken=7cec85d7bea7798e’

This is because the SqlProvider is a Type Provider and those are not supported by .Net Core out-of-the-box. To fix this, add the FscToolPath and FscToolExe to your fsproj:

In Serie.fs I created a module for database specific actions, you might call this a repository. I Had a little light bulb moment when I found out how to pass the datacontext. Use the type provider young Skywalker! When I implemented the add function and tested it by posting data it gave me this error:

System.NotSupportedException: Enlisting in Ambient transactions is not supported.

I found a solution on the GitHub of the SqlProvider here, so I could solve it quickly by changing to call the GetDataContext function.

Then Api.fs, I use this to convert to or from Json and wrap http response around the calls to the repository. I made it generic what was a bit out of scope of this blog, but it was a good exercise.

Again check the GitHub for the code, I know it needs a lot of work but I’m happy I’m getting some where. Mostly it is fun! Always open to suggestions on how to solve things better or differently!

Setup basic CI/CD for a Suave .Net Core 2.0 application running on an Azure App Service – Part II

< Part 1 you’ll need to read this first 😉

Setup continuous integration

Now for the second part, setting up ci and cd. Warm up that mouse because this requires a lot of clicking around in VSTS.

Connect VSTS to GitHub

The first thing we’re gonna do is to connect VSTS to GitHub. To do this go to settings > services:

Then add a new GitHub endpoint and click ‘Authorize’:

Setup build

Now it’s time to setup the build. Just click ‘New build’ and select the empty template. For the Agent queue I choose the Hosted 2017. The first step in the build is to get the sources from GitHub. We connected that the step before and we’ll just have to select the repository.

After that, we’re gonna add the steps for restore, build and publish, so we’ll need 3 .NET Core Tasks.

First step choose ‘restore’ as the Command, set the Path to projects to */*.fsproj. All .NET Core steps need that.

Next the build step, pretty straight forward:

And now the next step publish, the part that cost me the most troubles. If you look at the Arguments, you’ll see the -r win10-x64 switch. That makes it a self contained deployment If you don’t do that, the combination .NET Core 2.0 + Suave will give the following error on the Azure Web App:

System.IO.FileNotFoundException: Could not load file or assembly ‘System.Runtime, Version=

I tried a lot of things to get it to work, I ended up using this solution (part of my quest here)

We now add the last Task ‘Publish Build Artifact’, which will drop the package in the $(BuildArtifactStagingDirectory)

And now some of that VSTS magic, just flip the switch and set the trigger so that every commit will result in a new build.

All Done! Now create a new build to test if everything works. (Or commit a change of course!)

Setup release

Last but not least, releasing the freshly build package. Create a new release definition and select the ‘Azure App Service Deployment’ template.

We need to select which artifact to build and we’ll choose the stuff we just created with the build. This is all just too easy.

Set the automatic deployment by clicking the trigger button and enable Continuous deployment.

Then we need to configure where we want to deploy to, do this by clicking the 1 phase, 1 task link.

Here you can select your Azure Subscription and the App service where you want to deploy. And that’s almost all folks.

I Added 2 extra steps to stop the app service before deployment. I got some file in use errors before so stopping the app prevents that. You might want a staging slot to prevent down time, but it’s a bit overkill for this blog post.

Now release! Just by clicking or again commit some code. If everything went well as it should, you should see this beautiful message:

Next blog, maybe unit testing, maybe some database access…. maybe both!

Setup basic CI/CD for a Suave .Net Core 2.0 application running on an Azure App Service – Part I


Well I started this to learn F#, but I haven’t written a lot of lines of code yet. Before the real dive into F# I wanted to test out my stack, I wanted to use a lot of new technologies because… shiny new things. So I tried using all technologies with the volume set to 11, as latest as possible. This blog is about setting up an Suave application on .Net Core 2.0 to run on an Azure Web App, using the ci and cd facilities of VSTS. Missing here is tests, I’ll get to that in a later blog. Also I thought I had things working with Paket, but I ran in some problems I might try to solve later, so I ditched that.


Before we start you’ll need to have a GitHub repository, a VSTS project and an Azure Web App setup. And of course the bits and pieces installed I described in my previous blog post, plus Git. I also installed a VS Code extension gitignore so folders won’t be committed to git.

Setup the application

Setup solution and project

We’ll start with adding a console project and add it to a newly created solution using the dotnet cli:

Next add a new file to the project directory named web.config. Make sure to add it to the fsproj too:

Another thing we should do for our application to deploy correctly later is the add the RuntimeIdentifier to the fsproj. This is used to created a self contained deployment package.

Add references

Since Paket didn’t work for me during the writing of this blog, so I tried using the Install-Package and the dotnet add package commands to add project references and both failed adding the PackageReference tag to the fsproj file. So I just manually added the tag to the project file so it looks like this:

By calling dotnet restore in the terminal the package was downloaded. So everybody happy I guess.

Add code

Next some code! I know nothing yet so I got this from some examples I found on internet and modified it little. I won’t get into the code too much now, but the function appWebPart is used to configure the routing, the getPort function translates an argument to a integer. We’ll use this later to get an argument passed to the console application and configure this as the port number the suave web server will listen to.

The web.config should be looking like this:

Check if everything by running the build command or even running the application

Add to git

Now we need to put this in a git repository. I used gitignore extension to add the folder obj and bin to the .gitignore file. Then initialized git and committed the files. I normally would have used the UI more, but I’m a good boy and used the git commands for this blog post.

The application is prepared and safely in GitHub

Next part in the next part we’ll setup build & release.