Creating a REST API Project Template

While web API and MVC tend to go together, there are cases where you want a pure web API project. This is most common with REST services that have no UI. You would think that this should be easy to set up but, surprisingly, the default web API project in Visual Studio includes MVC. MVC brings in a lot of stuff that you simply don’t need including styling, MVC routing and client libraries. For a REST service where there will be no UI this is wasteful. In this article I’m going to discuss how to create a basic project template for REST services without the need for MVC.

Base Template

We will start with an empty project so that we can add only the features we care about. Go ahead and start up Visual Studio and create a new project. For this template we will use the ASP.NET Web Application (.NET Framework) project. We won’t be opting into Application Insights so uncheck that box. On the Select a Template page choose Empty. Then check the box for Web API under Add folders and core references for. For the skeleton template we won’t be using the cloud or any security (you can add OAuth later if you want) so uncheck those options. Then generate the project.

Customizing the Project

At this point we can start customizing the project template to match whatever requirements we have for our REST APIs. One thing that I always do is disable the default routing. I prefer to have each of the controllers be explicit about their paths so go into App_Start\WebApiConfig.cs and remove the line that calls config.Routes.MappHttpRoute.

public static class WebApiConfig
    public static void Register(HttpConfiguration config)
        // Web API configuration and services

        // Web API routes

You can go ahead and add your DI container of choice, add any core NuGet references and other features that all your REST projects will use. I don’t use the App_Data folder so I’m going to go ahead and remove that.

The default web API project creates a dummy controller so you have a starting point. If you want to do a similar thing for this template then go ahead and add an API controller by right-clicking the Controllers folder and selecting Add\Controller\Web API 2 Controller – Empty. Customize it as needed but you should probably at least add a method.

public class ValuesController : ApiController
    public Task Get ()
        return Task.FromResult(DateTime.Now);

Adding a Test Harness

Personally I like for all my APIs to have a test harness that can be used to easily test the API. For that I am currently using Swagger and Swashbuckle so let’s add that functionality in next. First add Swashbuckle from Package Manager to your project. There are several different packages available. Personally I tend to use Swashbuckle by itself. There is also a Swashbuckle.Core package but that doesn’t include all the dependencies. Note also that there is a Swashbuckle.Blue package that seems newer.You can use this version if you like but be aware that OAuth is not supported in this version at this time.

Refer to my previous blog about configuring Swagger for your needs. For this post I’m simply going to adjust the URLs to where the documentation resides to use docs/ui instead.

                .EnableSwagger("help/{apiVersion}", c =>

 .EnableSwaggerUi("help/ui/{*assetPath}", c =>

Go ahead and compile and run the project and make sure the API is working properly. To get the document you need to go to the URL <serverpath>/help/ui/index.

Setting the Default Document

We’re almost done with the project but the last thing that I want to do is have the help page come up as the default document. If this were an ASP.NET site I’d use the default documents in the config file. For MVC I’d put a redirect in the HomeController or update the routing but none of this works with Web API. Instead we’ll have to use URL rewriting. This is actually pretty trivial. All we need to do is add a rewrite rule in the config that maps any requests to the root URL (and only the root) to our help page.

   <!-- This rule causes any request to the root URL to be redirected to the documentation without the need for MVC -->
             <rule stopprocessing="true" name="Show Help">
                 <match url="^$">
                 <action type="Redirect" url="help/ui/index">

The only thing to be aware of is that this requires the URL Rewrite module to be installed. For IISExpress this will just work but for a full version of IIS you need to install it via the Web Platform Installer. Once you’ve done that the redirect should occur automatically.

Export the Template

We have the project set up so now we can convert it to the project template. With the solution open in VS go to the File\Export Template menu and click. Since we want a new project type ensure Project Template is checked and our API project is selected. On the next page enter some basic information about the template.

Template name
The name as it will appear in the project template dialog
Template description
A description of the template
Icon Image
The icon shown next to the template in the list (optional)
Preview Image
The preview that will be shown to the right (optional)
Output Location
Where the generated template file (.zip) is stored
Automatically Import
Indicates whether to go ahead and import the template into VS or not

Once the template has been generated you can create a new project and your template should show up (under Visual C#). But the generated template is not quite consistent with how the rest of the templates work so we are going to adjust it.

Adjusting the Template

One change you might want to make is to generate multiple projects from a single template. This is supported but not well documented. Personally I am fine breaking up multi-project solutions into multiple templates so I can mix and match the stuff I need but if you want to create a multi-project template you’ll need to manually adjust the template as documented here.

The changes that I’m going to focus on for this article is getting the template to show up under the correct category (Web in this case) and giving it a slightly better default name. To do that we need to extract the .vstemplate file from the generated .zip file. Then open it in a text editor or Visual Studio.

<VSTemplate Version="3.0.0" xmlns="http://schemas.microsoft.com/developer/vstemplate/2005" Type="Project">
    <Name>Standard REST API</Name>
    <Description>A standard REST API project</Description>
    <DefaultName>Standard REST API</DefaultName>
    <Project TargetFileName="SimpleRestProject.csproj" File="SimpleRestProject.csproj" ReplaceParameters="true">
      <Folder Name="App_Start" TargetFolderName="App_Start">
        <ProjectItem ReplaceParameters="true" TargetFileName="SwaggerConfig.cs">SwaggerConfig.cs</ProjectItem>
        <ProjectItem ReplaceParameters="true" TargetFileName="WebApiConfig.cs">WebApiConfig.cs</ProjectItem>
      <Folder Name="Controllers" TargetFolderName="Controllers">
        <ProjectItem ReplaceParameters="true" TargetFileName="ValuesController.cs">ValuesController.cs</ProjectItem>
      <ProjectItem ReplaceParameters="true" TargetFileName="Global.asax">Global.asax</ProjectItem>
      <ProjectItem ReplaceParameters="true" TargetFileName="Global.asax.cs">Global.asax.cs</ProjectItem>
      <Folder Name="Models" TargetFolderName="Models" />
      <ProjectItem ReplaceParameters="true" TargetFileName="packages.config">packages.config</ProjectItem>
      <Folder Name="Properties" TargetFolderName="Properties">
        <ProjectItem ReplaceParameters="true" TargetFileName="AssemblyInfo.cs">AssemblyInfo.cs</ProjectItem>
      <ProjectItem ReplaceParameters="true" TargetFileName="Web.config">Web.config</ProjectItem>
      <ProjectItem ReplaceParameters="true" TargetFileName="Web.Debug.config">Web.Debug.config</ProjectItem>
      <ProjectItem ReplaceParameters="true" TargetFileName="Web.Release.config">Web.Release.config</ProjectItem>

As you can see some of the values came from the export UI. We want to change the following values.

The default name of the new project. We will set it to RestApi.
The type of the project (which controls category). There are various supported types including standard C# and Visual Basic templates.
Some project types support a subtype that further identifies the project type.
Added this attribute and set it to true otherwise NuGet will not work properly.

To test the changes, update the .zip file with the new template file. Be careful here as there are two places the .zip file resides. The version in the My Exported Templates folder is the template that you exported. But for VS to see it you have to “import” it into VS by copying it to the Visual Studio 2015\Templates\ProjectTemplates folder. It is that version that VS uses. But the template can also be stored in any of the folders under an existing template to further category the template. In general you can put templates into language-specific folders (ex. /Visual C#/1033/Mine).

For getting our template into the Web folder I tried several different things including:

  • Setting ProjectType to Web and ProjectSubType to CSharp
  • Putting the template under /Visual C#/1033/Web
  • Putting the template under /Visual Web Developer

Nothing really worked. The template always showed up under the root templates but never under Web. It is possible, just not sure if it can be done with only a vstemplate.

Once you’ve modified a template you need to tell VS to refresh the installed templates. You can do that by ensuring VS is not running and then starting an elevated command prompt and then running the command devenv /installvstemplates. This will cause VS to relate the templates.

Updating Generated Files

The final set of changes that would be useful is to update the files to reflect the options selected when creating the project. In general the namespace should follow the project name. The template is already set up to replace values inside the source files with values from the project and therefore the namespace will follow the project name. But you may want to adjust other values as well, such as the Swagger name. By default, exporting the template will cause it to scan and replace all namespace references (string or otherwise) with the safe project name parameter.

We could also adjust the file names themselves if we wanted. MSDN documents the supported parameters we can use.


This completes this article. Feel free to update the template according to your needs and create other templates as needed. One unfortunate caveat to all this is that C++, while documented as being supported, doesn’t behave properly as a project template. For C++ projects you have to revert to the legacy wizard interface.

Download the code.

.NET Core 1.0.0 VS 2015 Tooling Preview 1 Uninstall

With the recent announcement that .NET Core 1.0.0 is officially released, Microsoft also announced that Preview 2 for .NET Core 1.0.0 is available. However to install it you must first uninstall Preview 1 if you have it installed. The issue is that to uninstall you have to have the original setup program. If you go to any current links they will take you to the Preview 2 installer so you are in a catch-22. Fortunately Barry Dorrans tweeted a link to the Preview 1 installer here. So if you need to uninstall Preview 1 first then use that link to get the installer. I also recommend that you keep the Preview 2 installer around for the inevitable uninstall later.

Creating an SSIS Custom Task, Part 6

It is time to wrap up this series on creating a custom task for SSIS. We are going to finish our discussion with some advanced, but common, UI needs including:

  • Support for viewing and creating connections
  • Support for viewing and creating variables
  • Support for dynamic properties
  • Support for enumerating reports in SSRS
Read More

Creating an SSIS Custom Task, Part 4

In the last article we set up some infrastructure for creating tasks. We then implemented the shell of the task to generate SSRS reports. In this article we are going to finish up the runtime side of the SSRS task. To do that we need to talk about task parameters, persisting the parameters, getting access to connections at runtime and how to work with variables at runtime.

Read More

Creating an SSIS Custom Task, Part 3

In the first part of this series we generated an SSRS report using an SSIS script task. In the second part we created a custom task to display “Hello World”. In this article we will combine the work to create a custom task to generate an SSRS report. For this post we will simply get the runtime side of the task working. Design time support will be added in a later article.

Read More

Creating an SSIS Custom Task, Part 2

In the last article we created a simple SSIS package to generate an SSRS report and save it to disk. For a single report this is fine as it didn’t require a lot of code but imagine if we wanted to write new packages and reuse this code. This is where script tasks break down. Each script task is a standalone block of code, basically its own .NET project. Code in one script task has no access to any other script, even in the same package. The only way to share code is copy/paste. This is error prone and unmaintainable.

One way to work around this is to create code outside the script task and copy paste the source files into each script task. This works but can be difficult to maintain over time. The ideal solution is to move this code into its own assembly and then reference the assembly in each script. Unfortunately SSIS requires that all script references be in the GAC. This complicates deployment as we’ll see later but is doable.

This is where SSIS custom tasks become useful. When you want to use the same script task in several different places or packages then it is time to promote it to a custom task. This provides several benefits.

  1. Code duplication is eliminated.
  2. The need for a script task goes away and is replaced by a reusable task.
  3. A custom task is easier to use in packages then script tasks.
  4. The custom task can access functionality that is difficult or impossible to do inside a script task.

For this article we will replace the existing script task to generate SSRS reports with a custom task. Creating the task and building the UI is straightforward once you get past the initial learning curve. Surprisingly though working with Winforms proves to be the most challenging aspect of the process. Before continuing be sure that everything is setup as discussed in the previous article.

Read More

Documenting Web APIs with Swagger

A while back I posted an article on how to extend the existing help pages generated by Visual Studio for Web API projects to use reflection instead of XML documentation. One of the limitations of that approach was that you could not test the APIs directly. You had to use SoapUI or equivalent. Since then I have started using Swagger for documentation. As a documentation/testing tool it fills the need. In this article I will demonstrate how to integrate Swagger into a Web API project. Additionally I will continue to use the reflection provider from the previous article.

Read More

Creating an SSIS Custom Task, Part 1

Recently I had the need to create a couple of custom tasks for SQL Server Integration Services (SSIS) at work and I was shocked at how few the resources were for doing this. There are a lot of blogs and articles about creating SSIS custom tasks, but most of them are outdated or wrong. Even Microsoft’s own documentation has clearly been promoted from older versions and is no longer accurate. This leads to a lot of wasted time and scratching of your head trying to figure out what is wrong.

In this series of articles I’m going to demonstrate how to create a custom task for SSIS 2014. This information is also applicable to SSIS 2012 but doesn’t necessarily work with earlier or later versions of SSIS. In this first article we will set up a simple SSIS package that we can use for the remainder of the series.

Read More

Documenting Web APIs

Prerequisite: This post assumes you understand what web APIs are, what they are designed for and how to write them. If not then take a look at this MSDN article first.

In order for web APIs to be useful they need documentation. Unlike traditional APIs there is no function signatures to look at. Even if you know the name of the “function” there is no easy way to get the parameters or return value. Hence documentation is important to anyone wanting to use such an API. If you are writing a REST API then the documentation is technically where the HATEOAS concept comes in. The reality is, for now at least, most people write web APIs using the REST API philosophy but without HATEOAS. Hence documentation is still needed.

The biggest issue with documentation is keeping it in sync with the code. We have XML doc tags for .NET languages and can use them with web API. But to be useful we have to ensure the documentation is refreshed whenever the API changes.  ASP.NET solves this problem by relying on the existing XML doc tags that you’re likely already using. At runtime the documentation is rendered on demand based upon the existing comments. This is one approach to solving the problem. In this article I will take a look at the “built in” functionality, identify when it might not be useful to you and provide an alternative approach that I use.

Read More