Feature Management in F#/Giraffe/ASP.NET Core
Following on from Joe’s post I thought I’d see how one would do this in F# and Giraffe because why not? Turns out its quite simple. First, create a features.json
file:
Following on from Joe’s post I thought I’d see how one would do this in F# and Giraffe because why not? Turns out its quite simple. First, create a features.json
file:
As some of you may already know, NancyFX has been archived 11 years after its first commit. You can read the announcement here for further information but I will never forget what I learnt from this codebase, the community around it and most especially the people involved with it. I am very proud and honoured to have been involved with it and a massive thank you to Andreas HÃ¥kansson for teaching me plenty via the 1:1 Skype calls we had in the early days. As many of you also know I created Carter which in my mind was Nancy v2 but sat on top of ASP.NET Core with the same approaches as Nancy, offering many things a web framework should have. The usage of Carter has steadily increased which is good to know people value similar things we achieved with Nancy. However, paradoxically I have had a feeling brewing for sometime that this effort is almost futile.
As of beginning of April 2018 Botwin has been renamed to Carter. Whilst I thought the name was genius it became obvious that some people didn’t like it or understand it and tried to interpret it as a Bot framework for Windows. After spending too long trying to think of a new name I finally decided upon Carter. Carter comes from the surname of Jay-Z (Shawn Carter) and in his song Empire State of Mind he sings “I’m the new Sinatra”. Sinatra is a web framework which inspired Nancy which heavily inspired Botwin.
The last release of Botwin was 3.5.0 but the same package has also been released under Carter 3.5.0
So by now using .Net Core on Linux is old news, everyone is doing it and deploying their production apps on Kubernetes to reach peak “I can scale” points. However, one thing that can get tricky is when you have a requirement to debug an application in a container. I believe VS on Windows and VS for Mac has some sort of capability to do that (I have no idea what it does underneath but hey who cares I can right click debug right!?) but the information about doing this in VSCode is a bit sketchy. I tend to use VSCode on OSX the most so I wanted to see how I could do this.
For demonstration purposes lets take a very simple application and we are going to publish it as a self contained application ie/one that has all the runtime and application binaries outputted so you don’t have to install dotnet in a container.
To be able to debug that application we are going to need VSDBG(the .Net Core command line debugger) inside the container.
curl -sSL https://aka.ms/getvsdbgsh | bash /dev/stdin -v latest -l ~/vsdbg
We are also going to need to append the launch.json for VSCode in your project’s root to have the below:
{
"name": ".NET Core Remote Attach",
"type": "coreclr",
"request": "attach",
"processId": "${command:pickRemoteProcess}",
"pipeTransport": {
"pipeProgram": "bash",
"pipeArgs": [ "-c", "docker exec -i json ${debuggerCommand}" ],
"debuggerPath": "/root/vsdbg/vsdbg",
"pipeCwd": "${workspaceRoot}",
"quoteArgs": true
},
"sourceFileMap": {
"/Users/jonathan/Projects/jsonfile": "${workspaceRoot}"
},
"justMyCode": true
}
I recently wrote a project for ASP.NET Core 2 and the time had come to get a CI system up and running. I develop on OSX and mainly test on OSX & Linux and so the defacto place to go is TravisCI. I’ve used it in the past and all has been great but I put out a tweet asking if Travis was still the place to go:
Whilst keeping my eye on what’s going on in .NET Core v2 I came across some planned changes for ASP.NET Core regarding the routing. I had also read this blog post from Filip about using the planned changes for microservices and a lightbulb went off in my head. I thought to myself I wonder if I could adapt the new extensions to create Nancy-esque routing. Turns out, I could!
public class ActorsModule : BotwinModule
{
public ActorsModule()
{
this.Get("/", async (req, res, routeData) =>
{
await res.WriteAsync("Hello World!");
});
}
}
As you may or may not know I try to work on OSX as much as possible and with .Net that’s quite painful to be honest. Things are moving along nicely with Jetbrains Rider, VSCode, Xamarin and Omnisharp. I’ll be honest, none of them are perfect and I often find myself using Visual Studio in a VM because it just works (yes, its clunky etc etc). Recently, VSCode got a 1.3 release with some new features, tabs being one of them. I never really got on with VSCode so dismissed it most of the time but this new release opened my eyes a bit more and thought I’d give it a go. Its C# support now runs on .Net Core RTM and most of my work at the moment is porting projects to .Net Core so it seemed this would be worthwhile. I’ve tried to setup keybindings that are the ones I know from Visual Studio and installed couple of extensions to make things easier and prettier.
As VSCode is language agnostic the one thing I found was how to build .Net Core projects was a bit off. For each project you have you have to configure a task runner. VSCode tries to
help you here and gives you a few languages to choose from. For .Net Core it creates a dotnet build
task. The problem with this is that it runs that command from the workspace root,
ie the folder where VSCode is opened. What if you open it from the git root folder and your project(s) are under a src/MyProject folder? It will fail as it cant find project.json.
What you can do is set the cwd
to be a specific directory by hardcoding it in the task configuration but thats not great if you have multiple projects. You could use some predefined
variables that VSCode provides eg/${fileDirname}
but again if you are in a folder 4 levels deep that wont work either.