BugTracker Sample Application

By Erik Reitan|
Important: Visual Studio "14" CTP introduces tooling support for ASP.NET vNext. You do not need Visual Studio "14" CTP to run the samples, but if you want to work with the BugTracker vNext sample project in Visual Studio, you must first install Visual Studio "14" CTP. For information on working with the vNext project in Visual Studio "14" CTP, see Getting Started with ASP.NET vNext and Visual Studio.

Welcome to the BugTracker application written for ASP.NET vNext!

Here you can explore how an ASP.NET application is written to run on ASP.NET vNext. Much of the MVC 6 functionality is still being finalized, but you can get familiar with ASP.NET vNext by reviewing this sample application and learning how things are changing, as well as see some new features in action.


The BugTracker application shows how you can use ASP.NET MVC 6 and SignalR in an ASP.NET vNext project to send message between multiple clients. This sample allows you to prioritize bugs into three groups (Backlog, Working, and Done). When you move a bug from one group to another, all clients will update to reflect the change.

BugTracker Single Page application

You can run BugTracker using Visual Studio "14" CTP or from the command line. For details on how to run the sample, please see the readme at

Project Highlights

The BugTracker sample app contains similar aspects to ASP.NET MVC Web applications in ASP.NET 4.5. For instance, several of the ASP.NET vNext project folders are similar to the folder structure of MVC projects. However, the project has the following changes:

  • There is no longer Global.asax file.
  • Web.config files are used only for running the application in IIS Express.
  • The .NET Framework and project dependencies are defined in the project.json file.

The following table lists specific files and their basic purpose.





Used to configure the application. This includes adding and configuring services, such as MVC, SignalR, static files, and routing.

In previous versions of .NET, this file contains similar functionality to the functionality contained in the global.asax and web.config files.


Used to configure the application in ASP.NET vNext. This file also sets up dependencies and commands for the project.

In previous versions of .NET, this file contains similar functionality to the functionality contained in NuGet packages and cs.proj files.


In ASP.NET vNext, this console app initializes and starts the BugTracker application when using the Custom Host option to run the application.

Code Highlights

The BugTracker sample application is a single page application (SPA). Single-Page Applications (SPAs) are Web apps that load a single HTML page and dynamically update that page as the user interacts with the app.

When running BugTracker as a Web application, The ASP.NET vNext runtime looks for a Startup class with the following method signature to configure the Web application:

public void Configure(IApplicationBuilder app) {}

When running BugTracker as a console application, the following code in Program.cs likewise looks for the same Startup class to configure the Web application:

var engine = services.GetService<IHostingEngine>();


In ASP.NET vNext, Web applications are no longer dependent on System.Web namespaces. This change enables you to slim down your Web applications, so that you can add only the HTTP services you need to the application deployment, making your application as lean and fast as possible. Take a look at the Startup.cs file by opening it from Solution Explorer. In the Configure method, find the following code:

app.UseServices(services =>
    //Add all MVC related services to IoC.

    //Add all SignalR related services to IoC.

//Configure SignalR

This code adds the MVC service and the SignalR service to the application.

Then, find the following lines of code:

app.UseMvc(routes =>
        new { controller = "Home", action = "Index" });

        new { controller = "Home", action = "Index" });

        new { controller = "Home" });

This is where you can add more routes to your Web application.


The HomeController class renders a view that defines the main HTML page for the application.

The BugsController class implements the REST API that clients use to update bugs:



GET /api/bugs

Returns a list of bugs.

POST /api/bugs/backlog

Moves a bug to the backlog list.


Moves a bug to the working list.

POST /api/bugs/done

Moves a bug to the done list.

For the POST methods, the client sends the bug ID as a JSON object:


The POST methods return a JSON representation of the updated bug.

BugsController is very similar to an ASP.NET Web API controller, except it derives from the Controller class, not ApiController. In ASP.NET vNext, the MVC and Web API frameworks are unified, so web API controllers do not use a separate base class. The BugsController class also uses SignalR to notify other clients when a bug is moved. For more information, see Getting Started with ASP.NET vNext.

No System.Web.* Dependencies

The controller code (Controllers\HomeController.cs) is still the same as in previous versions, except that you don’t see any reference to the namespaces System.Web and System.Web.* any more, as mentioned previously. In place of System.Web.Mvc, you find Microsoft.AspNet.Mvc.

The BugTracker sample application uses the SignalR Hubs API. This API enables you to make remote procedure calls (RPCs) from a server to connected clients and from clients to the server. This functionality allows the BugTracker sample application to update all clients simultaneously. For more information, see ASP.NET SignalR Hubs API Guide - JavaScript Client.

Additional Resources


This article was originally created on June 3, 2014

Author Information

Erik Reitan

Erik Reitan – Erik Reitan is a Senior Programming Writer at Microsoft. During his spare time he enjoys developing Windows Phone and Windows 8 apps. Follow him on Twitter at @ReitanErik.