Written by
Tomasz Saluszewski

Tomasz Saluszewski

Thoughts on ASP.NET Boilerplate

Boilerplate is a startup template for ASP.NET web applications, both Single-Page or Multi-Page. With one click of a button we get a project structure containing multiple preconfigured modules and libraries in an NLayer architecture (Domain, Application, Infrastructure and Presentation Layers), and Domain Driven Design (Entities, Repositories, Domain/Application Services, DTO’s…).

What differs from the “classic” Visual Studio template is the ABP framework, which offers many features available “out of the box”.

Some examples of these are:

  • Multi tenancy support;
  • Repositories (that can be used as is without developing custom extensions);
  • Unit of Work (application service can be decorated with a transactional aspect);
  • Server-side validation (via data annotations or custom validators);
  • Dynamic Web API controllers (automatically-generated web API layer for your application layer);
  • Background Services (jobs);
  • Real Time Services (SignalR integration);
  • Localization (multi-language support with helper classes for both server side and client code);
  • …and many more listed here

Module Zero is an additional framework offering tenant, role, user management, authorization and so on. I have not used it personally as it was immature at the time we started our projects.

The good thing is that you are not forced to use all of these features! You can mix and match and take what you need, but I think once you get into the framework you’ll prefer to stick with what you get. More about this later.

The current state (compared to what it was before)

I haven’t used this library since 2015 and I’m amazed how many new features have been developed since then (like Background, Real Time Services and Timing System, which we implemented on our own)! They actively add new features to both the open-source framework and its premium counterpart, which is called ASP.NET Zero. The latter is marketed as an “enterprise startup template” with active support from Volosoft (it even has a separate web site!).

When to use

Personally, I’ve observed that it’s best used for relatively small (targeting rather tens than thousands of users) and simple web sites (with no special constraints on Web API standards or authentication protocol) that need to be delivered to the market in a short time by developers of mixed backgrounds or skills 🙂

This was the case for our two projects, where we had only 3-6 months to deliver a complete, working application. Moreover, we had limited experience in SPA applications, except for the MVVM knowledge from the WPF app we had worked on before. ASP.NET Boilerplate did all the “nuts and bolts” to have the server-side application layer working with the client-side Angular pages. It was very easy and efficient to concentrate on business logic and customer needs rather than spent time on cross-cutting concerns like the Web API controllers’ syntax, Angular modules loading, localization (this benefits us now as we need to add Spanish language support to one of our ABP applications), etc.…

When to avoid

  • Whenever you want 100% control of your code and the libraries you are using (and want to know what you are doing).
  • For very complex web sites, when you need to adhere to certain REST standards for your web API or have some custom / special authentication / authorization needs. Of course, you can still achieve your objectives by customizing the framework, but this may be counterproductive. It’s better to start from scratch and build the web site by yourself.
  • Where high performance is a top priority. This is because ABP uses dynamic code generation for web API and JavaScript proxies.
  • In complex deployment scenarios (like cloud). This is because debugging of dynamic code or validation interceptors may be cumbersome.

What I’ve learned

This is nothing new or ABP-specific, my observations would probably hold true for other projects/frameworks 🙂

  • You need to spend some time on tweaking the template-generated code to adapt to Objectivity coding standards.
  • We don’t like ABP coding style for Angular views, controllers and services – we refactored them in accordance with John Papa guidelines.
  • It’s good to start with resources and localization helper classes from the start if you are thinking about multi-language support.
  • We struggled to get Date Times normalization between client and server in different time zones. We implemented a custom Clock provider which was later included in the framework.
  • Early implementation of ABP (2014) did not have a “Null” Unit of Work concept that could be used with application services with no database-level transaction needs. It caused run time exceptions, but luckily I was able to implement the appropriate class and extend the framework easily. I raised this issue on the ABP forum and it was quickly included in the framework.
  • I had a few issues debugging the ABP code in the Azure environment, particularly in respect of the Identity interface implementation where we inserted a “thread unsafe” code (to get user details from the database). The error could only be reproduced in Azure, and because of this we spent a lot of time identifying the root.
  • We had also a few issues with multiple versions of the same library across projects – Log4Net if I remember correctly. For some reason the ABP could use the same version across all projects/modules.


To sum up, ABP is best used for relatively small and simple web sites that need to be delivered with short time to market by developers of mixed backgrounds or skills. Whenever you want full control of your code and the libraries you are using, you should avoid ABP. This led to it being rated with a Trial mark in our 2016 edition of Technology Radar.

Share this post on


6 thoughts in Comments

  1. Adel Emam

    Hello ,
    I was wondering if there is a reply for what is mentioned here, as we are planning to use ABP in our enterprise solutions not small websites as mentioned here, is it right decision or not ? both Halil and Tomasez can give us a hint here about this, also performance is a big major aspect we need to consider if we will be trying ABP

    1. Tomasz Saluszewski Post author

      Hi Alper,
      I didn’t have a chance to look into recent changes of ABP, especially at the ASP.NET Zero product. Thus I cannot comment on its maturity or fit for large scale projects.
      Kind regards,

  2. Jobin

    Thanks for sharing your experience. I’m currently looking forward whether to use ABP or from scratch for a Custom Sales ERP since time constraint is a factor. Probably , it would be worth for the boilerplate code and need to check on “how difficult” is it to customise without being counterproductive. By the way any of your observation check list changed from the time of this writeup with the present scenarios ?

    1. Tomasz Saluszewski Post author

      Hi Jobin,
      I didn’t have a chance to look into recent changes of ABP, especially at the ASP.NET Zero product. It covers many cross functional features like user management or sample reporting. If you are not a software house and have a time constraint I would rather look for some packaged product (like Microsoft CRM) or a rich framework like ABP. Please not that with ABP you still have full access to all the code, so you can customise it as you wish.
      Kind regards,


Leave a Reply

Required fields are marked *

Read next

Date with a candidate – How to hire people who fit your company culture

When you have the task of “hiring a specialist”, verifying a candidate’s hard skills and knowledge is a piece of cake – the candidate knows it or not. Everything else, including cultural fit, is much more sophisticated and nuanced, it is perhaps much more like a going on a date.

How to find your date?
First, you want to hear […]

Read more