Announcing Carter

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

Read more...

Debugging .Net Core apps inside Docker container with VSCode

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
}

Read more...

Using Docker with .Net Core in CI for OSS

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:

Read more...

Announcing Botwin

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!

Sample

public class ActorsModule : BotwinModule
{
    public ActorsModule()
    {
        this.Get("/", async (req, res, routeData) =>
        {
            await res.WriteAsync("Hello World!");
        });
    }
}

Read more...

Building all and current dotnet core projects in VSCode

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.

Read more...

Porting OWIN middleware to ASP.Net Core

In our application at work we make use of various middleware and as we are making everything run on .Net Core the time has come to port said middleware to .Net Core. If you don’t already know ASP.Net Core has a bridge that allows you to use OWIN components in an ASP.Net Core application. This will convert the HttpContext into a OWIN environment dictionary on input and then back again on output.

Lets take an example of some middleware

public class MyMiddleware
{
    private readonly Func<IDictionary<string, object>, Task> nextFunc;
    private readonly OwinUserMiddlewareOptions options;

    public OwinUserMiddleware(Func<IDictionary<string, object>, Task> nextFunc, MyMiddlewareOptions options)
    {
        this.options = options;
        this.nextFunc = nextFunc;
    }

    public Task Invoke(IDictionary<string, object> environment)
    {
        //Everything is awesome
        return nextFunc(environment);
    }
}

public static class MyMiddlewareExtensions
{
    public static IAppBuilder UseMyMiddleware(this IAppBuilder app, MyMiddlewareOptions options = null)
    {
        return app.Use(typeof(MyMiddleware), options);
    }
}

Read more...

What is a Hypermedia client?

I’ve been interested in Hypermedia for quite a while. I bugged Darrel Miller and Glenn Block (Glenn Miller) so much so they created a YouTube show called “In The Mood for HTTP”. I bought their book “Designing Evolvable Web APIs with ASP.NET”, I am waiting for “RESTful Web Clients Enabling Reuse Through Hypermedia” by Mike Amundsen, I have written about how to return different media types with NancyFX and I am looking at going to restfest.org in Edinburgh this year, a REST conference.

The one thing that I have always discussed with Glenn Miller is that there seems, or from my perception, that there is a lot of emphasis on the server returning media types(HAL,Siren,JSON-LD, Collection+Json) and very little information about hypermedia clients. The information that I have come across which is very little, again coulkd be due to my lack of Google-fu, seems to generate a mis-conception. The mis-conception I have come across is that if you have an API that returns hypermedia then your client should be able to magically work with it. It should know everything that is required to browse the API and discover its way around. I never quite grasped how that was supposed to happen and was serioulsy confused. I had seen a video that showed when the server returned its responses, using Javascript it would loop over all the properties in the payload and then display them in a HTML page. The emphasis was that if new bits of data were added then they would appear magically in the UI. That seemed like a nice feature but I still didn’t quite get how it went from hitting the root of the API to finding its way into the guts of it. The server would return links in the payload with “rels” and I was baffled how this magic client knew what to do with a rel or even how it knew what rels it would return.

Read more...

VQ Communications Funds NancyFX to run on CoreCLR

Nearly 2 years ago I was employed by VQ Communications primarily because of my open source contributions to NancyFX. They had started work on a v2 of their flagship product and had begun work with Nancy and needed someone to help drive a HTTP API and architect a scaling solution as their v2 product was addressing a requirement they had for it cope with large volumes of traffic. Also of interest to me was their aim to deliver all of this as a black box appliance to customers on a VM running a custom embedded version of Linux using Postgres as the database. I would work four days a week remotely and go into the office one day a week. They already had completely remote employees and since I have been there they have taken on more. There are lots more juicy technical examples in the stack I could go into however, this is not the point of this post.

Read more...

Profiling a CoreCLR application with dotMemory

I had ported an application over to CoreCLR (that’s a whole other blog post), along with my colleague James Humphries put it in a docker image and sat back and watched it do its thing. After 6 hours of running the docker container had crashed. Ah nuts we thought, so pulled up the logs from docker and the last line looked like this 2016-02-10T20:18:31.728783069Z Killed. I’m pretty sure when you have a log entry with Killed in it, things can’t be good. To the interweb…

I opened up the CoreFX repository on Github to search for the term Killed and there were 2 comments but nothing that was logged out anywhere. I then Googled for docker and killed and there was an entry that someone else had spotted on their container and the feedback was essentially it was probably out of memory.

Read more...

Introducing Negotiator - a GoLang content negotiation library

In my continued experience learning GoLang I started looking at how to best use it when dealing with HTTP. The idiomatic way to use GoLang and HTTP is to use the standard library which keeps things minimal but there are a few features missing. The first thing is a router. OOTB GoLang doesn’t have a router and the majority seem to suggest using a package called Mux from Gorilla Toolkit, a set of libraries that aims to improve the standard library from Go. After having a play with it I didn’t really warm to it so spent some time looking into the alternatives (and there are plenty!) and eventually decided upon Goji

Once I had started using Goji I then wanted to handle content negotiation in my HTTP handler. As I said earlier GoLang is minimal in its offerings OOTB and this is a good thing. Just for the record there are a few frameworks out there if you want/need and all encompassing framework such as Martini, Revel and Echo. These tend to bend the idioms of GoLang a bit and even the author of Martini blogged on this fact due to feedback from the community that although its capabilities are great they aren’t idiomatic Go.

Read more...