How to use VS 2017 REST API Template for .NET Core 2.1.x?

When it comes to building REST APIs we are often confronted to common and repetitive technical issues. That led me to try to industrialize and factorize the creation of REST API solutions.

Visual Studio 2017 REST API Template for .NET Core is the first attempt of building a Visual Studio 2017 project template (solution template actually) for creating a complete .NET Core 2.1.x solution fully usable.


  • Industrialization
  • Fast
  • Very simple to use
  • Repeatable structure (easier to handle, understand and maintain)
  • Extendable
  • Allows to concentrate effort on creating value (business value most of the time)


How to install it?

Very easy.

Through a web browser

VS 2017 – .NET Core REST API Template


Through Visual Studio

  • Open Visual Studio 2017.
  • Go to Tools -> Extensions & Updates.
  • Look for the Extension (for instance, by “.Net Core”).
  • Once found, click the Download button.


Visual Studio 2017 – Tools and Extensions


What does the project template do?

Once the template installed, when we go to File -> New Project, we should see the screen below:


Many inputs can be customized:

  • Name
  • Location
  • Solution name


After clicking on “Ok”, a Visual Studio solution is created with the structure below:

Template structure

It is what it is; I guess the proposed structure can be discussed, reviewed, completed, etc. I am open to discussions :). The purpose was to propose something usable, simple, fulfilling common REST API projects technical requirements (from the production point of view) and allowing to focus most of our effort on creating business value.

Feel free to change the content, adapt it to your requirements (you should ;)) or to provide feedback in order to evolve the template and share that capitalization.


How to use VS 2017 REST API Template for .NET Core 2.1.x?

3 thoughts on “How to use VS 2017 REST API Template for .NET Core 2.1.x?

  1. Hey man, been looking for a template like this, boilerplate just has too much in it. Diving into it today and hoping I can use it as a starting point for moving our API from .net to .net core. Appreciate the effort. I noticed the repository’s blank, I’m assuming that you did that to not impose EF onto people. I’m curious however, what’s your preferred data access framework? I’ve only used EF, dapper, and raw ADO stuff with the API. Always interesting to hear about other solutions. Cheers


    1. Hi Patrick,

      Sorry for the delay. I missed the notification of your comment. Sorry.

      Thanks for the feedback, I really appreciate.
      As you started figuring out, the purposes of the template were:
      – a simple but complete (business oriented) template. A solution built from production and business perspectives and keeping in mind their constraints (multilayered, roles separation, testability, factorization, documentation, integration, architecture best practices, “simplicity” even though I understand this point could be extremely relative, etc)
      – with minimal artifacts, references, etc

      I’m sure the solution can be improved. This is the starting point and I’m using it in production, with different teams.
      I rely on users’ feedback to improve it….so, feel free to tell me what you think or what could be improved.

      You guessed it ;). Repository’s blank to let you complete your solution with your choices. The variety of choices (relational database, NoSQL, files, etc….with so different technical platforms) is so diverse that I preferred to focus the template on API features and offer a complete experience from the API perspective.
      As for as I’m concerned and to answer to your question, I use EF whenever it’s possible and it makes sense (many providers do not work properly in terms of performance).
      I’ve also used ADO.Net a lot but I have to confess I’m using it fewer and fewer (mainly because of the type of projects I’m involved). Lastly, I’m using ComosDB and Azure Storage with their SDKs/APIs.
      I’ve never used dapper. Do you recommend it?

      To give you some insights about what’s coming, I tried to update the template to .NET Core 2.2 but it’s not that simple (breaking changes in many libraries, mainly in API versioning and OpenAPI).
      Knowing .NET Core 3.0 should be released soon, I’ll focus on that new version for the udpate.
      About the features, I’ve been asked to add OpenIdConnect many times. This is a very good point but in terms of architecture/genericity of the template, I’m thinking whether it’s a really good idea to include it by default.
      Maybe, it would be better to offer the choice through a configuration manager/wizzard (API projects may include gateways taking in charge security workloads…what means that including OpenIdConnect settings by default within the API could end up being counterproductive).

      Sorry once more for the delay.
      I hope your experience with the extension is being good :).

      Looking forward to hearing from you, Patrick.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s