Project description

CarTrackr is a sample application for the ASP.NET MVC framework using the repository pattern and dependency injection using the Unity application block. It was written for various demos in presentations done by Maarten Balliauw.

CarTrackr is an online software application designed to help you understand and track your fuel usage and kilometers driven.

You will have a record on when you filled up on fuel, how many kilometers you got in a given tank, how much you spent and how much liters of fuel you are using per 100 kilometer.

CarTrackr will enable you to improve your fuel economy and save money as well as conserve fuel. Fuel economy and conservation is becoming an important way to control your finances with the current high price.

Source code

Latest version: CarTrackr (ASP.NET MVC 1.0 version)

Author blog feed

 Maarten Balliauw {blog} News Feed 
Tuesday, February 17, 2015  |  From Maarten Balliauw {blog}

So you’re building a multi-tenant application. And just like many multi-tenant applications out there, the application will use a single (sub)domain per tenant and the application will use that to select the correct database connection, render the correct stylesheet and so on. Great! But how to do this with ASP.NET MVC 6?


A few years back, I wrote about ASP.NET MVC Domain Routing. It seems that post was more popular than I thought, as people have been asking me how to do this with the new ASP.NET MVC 6. In this blog post, I’ll do exactly that, as well as provide an alternative way of resolving the current tenant based on the current request URL.


Disclaimer: ASP.NET MVC 6 still evolves, and a big chance exists that this blog post is outdated when you are reading it. I’ve used the following dependencies to develop this against:



You’re on your own if you are using other dependencies.


Domain routing – what do we want to do?

The premise for domain routing is simple. Ideally, we want to be able to register a route like this:



The route would match any request that uses a hostname similar to *.localtest.me, where "*" is recognized as the current tenant and provided to controllers a a route value. And of course we can define the path route template as well, so we can recognize which controller and action to route into.


Domain routing – let’s do it!

Just like in my old post on ASP.NET MVC Domain Routing, we will be using the existing magic of ASP.NET routing and extend it a bit with what we need. In ASP.NET MVC 6, this means we’ll be creating a new IRouter implementation that encapsulates a TemplateRoute. Let’s call ours DomainTemplateRoute.


The DomainTemplateRoute has a similar constructor to MVC’s TemplateRoute, with one exception which is that we also want a domainTemplate parameter in which we can define the template that the host name should match. We will create a new TemplateRoute that’s held in a private field, so we can easily match the request path against that if the domain matches. This means we only need some logic to match the incoming domain, something which we need a TemplateMatcher for. This guy will parse {tenant}.localtest.me into a dictionary that contains the actual value of the tenant placeholder. Not deal, as the TemplateMatcher usually does its thing on a path, but since it treats a dot (.) as a separator we should be good there.


Having that infrastructure in place, we will need to build out the Task RouteAsync(RouteContext context) method that handles the routing. Simplified, it would look like this:



We match the hostname against our domain emplate. If it does not match, then the route does not match. If it does match, we call the inner TemplateRoute’s RouteAsync method and let that one handle the path template matching, constraints processing and so on. Lazy, but convenient!


We’re not there yet. We also want to be able to build URLs using the various HtmlHelpers that are around. If we pass it route data that is only needed for the domain part of the route, we want to strip it off the virtual path context so we don’t end up with URLs like /Home/About?tenant=tenant1 but instead with a normal /Home/About. Here’s a gist:



Fitting it all together, here’s the full DomainTemplateRoute class: https://gist.github.com/maartenba/77ca6f9cfef50efa96ec#file-domaintemplateroute-cs – The helpers for registering these routes are at https://gist.github.com/maartenba/77ca6f9cfef50efa96ec#file-domaintemplateroutebuilderextensions-cs


But there’s another approach!

One might say the only reason we would want domain routing is to know the current tenant in a multi-tenant application. This will often be the case, and there’s probably a more convenient method of doing this: by building a middleware. Ideally in our application startup, we want to add app.UseTenantResolver(); and that should ensure we always know the desired tenant for the current request. Let’s do this!


OWIN learned us that we can simply create our own request pipeline and decide which steps the current request is routed through. So if we create such step, a middleware, that sets the current tenant on the current request context, we’re good. And that’s exactly what this middleware does:



We check the current request, based on the request or one of its properties we create a Tenant instance and a TenantFeature instance and set it as a feature on the current HttpContext. And in our controllers we can now get the tenant by using that feature: Context.GetFeature<ITenantFeature>().


There you go, two ways of detecting tenants based on the incoming URL. The full source for both solutions is at https://gist.github.com/maartenba/77ca6f9cfef50efa96ec (requires some assembling).


Tuesday, January 27, 2015  |  From Maarten Balliauw {blog}

December 9th, 2012., was my first day at JetBrains, after being in consultancy for a good 7 years. Hadi Hariri, my new boss, showed the world how new employees are treated. If you know Hadi, that was obviously just for laughs. Not one day have I considered him as a boss, yet as a friend who worked with me on great things. I had a great time in the past two years working with him and the many awesome people at JetBrains. I have traveled a lot, written many blog posts and tutorials (less on my own blog, I admit) and much, much more. Thanks, JetBrains, thanks, community I have worked with, and thanks, Hadi, for making this an awesome time! It’s been a great opportunity and a great adventure.

As a moonlighting project, Xavier Decoster and I have been working on MyGet, a software-as-a-service. It started as a simple prototype, which evolved into a service that hosts thousands of feeds and provides a solution for many developers, OSS projects and companies worldwide. You can find us in the Azure Store, we became VSO Launch partners at TechEd, and we even host nightly builds for ASP.NET and many other Microsoft and non-Microsoft products!

But then along came Microsoft. The NuGet team had an open position (well, two, in fact), for working on the various NuGet tools and the gallery. Both Xavier and myself will be working remotely in this team, starting February. Switching to Microsoft means we can continue our passion and help build a better NuGet. And with the npm and bower support in ASP.NET vNext, we’re pretty sure package management for the .NET developer isn’t going away in the near future…

What does this mean for MyGet? Well, it remains our side business and product. We’ll continue to provide the great service and support you’re used to! The only difference is that both Xavier and my agenda are now more aligned, and we’ll be in package management 24/7.

I’m a bit sad to be leaving JetBrains, but also look very much forward to ’joining Microsoft.

 Maarten Balliauw {blog} News Feed 

Last edited Oct 15, 2008 at 8:15 AM by maartenba, version 4