RouteAttribute is missing

Question

I am using Microsoft ASP.NET Web API 2.2 in a web application.

A controller looks like this:

public class EventsController: ApiController
{
  [HttpGet]
  [Route("GetAllActivities")]
  public IEnumerable<IActivity> GetEvents()
  {
    /* stuff */
  }
}

Problem description We are trying to have the RouteAttribute class included in our project and we found that it is hard to do so. Sometimes, we think we got it, but when we remove the bin directory and try to build again, its not there and the word Route is colored red. Another symptom is that GlobalConfiguration.Configure and HttpConfiguration.MapHttpAttributeRoutes will be missing. We also fail to understand the difference it makes to wipe away the bin directory and build from scratch. It is even hard to understand how attribute based routing is not already a part of WebAPI 2.2, but an add-on. If we get it right, some packages are mandatory and some packages are not allowed to get this working. Is that true?

This is what we have tried, in no special order:

• Install-Package AttributeRouting
• Install-Package AttributeRouting.WebApi
• Install-Package Microsoft.AspNet.WebApi.WebHost
• Update-Package -reinstall Microsoft.AspNet.WebApi.WebHost
• Update-Package -reinstall
• Uninstall-Package AttributeRouting

I had all this working once, then a colleague could not find the RouteAttribute class when checking out the code from our repository, not ignoring a single file. Then I removed the bin directory and rebuilt my version and I regressed to not being able to find the RouteAttribute class.

We ensured that we had the same version of visual studio by updating, but the problems remains.

I am aware of MVC having route attributes as well and that they are not the same thing as webapi route attributes. I am also aware of webapi route attributes are split up in web hosted and self hosted kinds. I am trying to have a reference to Ssytem.Web.Http.WebHost in my reference list, because we are hosting this on an IIS.

Unfortunately, they made that decision to keep the name of the classes the same for all those applications. If they were different, misunderstandings would not occur.

Here is the list of references in the project, from the csproj file.

<Reference Include="AttributeRouting, Version=3.5.6.0, Culture=neutral, PublicKeyToken=c10f85d521a011a9, processorArchitecture=MSIL">
    <HintPath>..\..\packages\AttributeRouting.Core.3.5.6\lib\net40\AttributeRouting.dll</HintPath>
    <Private>True</Private>
</Reference>
<Reference Include="AttributeRouting.Web, Version=3.5.6.0, Culture=neutral, PublicKeyToken=c10f85d521a011a9, processorArchitecture=MSIL">
    <HintPath>..\..\packages\AttributeRouting.Core.Web.3.5.6\lib\net40\AttributeRouting.Web.dll</HintPath>
    <Private>True</Private>
</Reference>
<Reference Include="AttributeRouting.Web.Http, Version=3.5.6.0, Culture=neutral, PublicKeyToken=c10f85d521a011a9, processorArchitecture=MSIL">
    <HintPath>..\..\packages\AttributeRouting.Core.Http.3.5.6\lib\net40\AttributeRouting.Web.Http.dll</HintPath>
    <Private>True</Private>
</Reference>
<Reference Include="Microsoft.CSharp" />
<Reference Include="Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
    <HintPath>..\..\packages\Newtonsoft.Json.6.0.4\lib\net45\Newtonsoft.Json.dll</HintPath>
    <Private>True</Private>
</Reference>
<Reference Include="System.Net.Http" />
<Reference Include="System.Net.Http.Formatting, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
    <HintPath>..\..\packages\Microsoft.AspNet.WebApi.Client.5.2.3\lib\net45\System.Net.Http.Formatting.dll</HintPath>
    <Private>True</Private>
</Reference>
<Reference Include="System.Net.Http.WebRequest" />
<Reference Include="System.Web.DynamicData" />
<Reference Include="System.Web.Entity" />
<Reference Include="System.Web.ApplicationServices" />
<Reference Include="System.ComponentModel.DataAnnotations" />
<Reference Include="System" />
<Reference Include="System.Data" />
<Reference Include="System.Core" />
<Reference Include="System.Data.DataSetExtensions" />
<Reference Include="System.Web.Extensions" />
<Reference Include="System.Web.Http, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
    <HintPath>..\..\packages\Microsoft.AspNet.WebApi.Core.5.2.3\lib\net45\System.Web.Http.dll</HintPath>
    <Private>True</Private>
</Reference>
<Reference Include="System.Web.Http.WebHost, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
    <HintPath>..\..\packages\Microsoft.AspNet.WebApi.WebHost.5.2.3\lib\net45\System.Web.Http.WebHost.dll</HintPath>
    <Private>True</Private>
</Reference>
<Reference Include="System.Xml.Linq" />
<Reference Include="System.Drawing" />
<Reference Include="System.Web" />
<Reference Include="System.Xml" />
<Reference Include="System.Configuration" />
<Reference Include="System.Web.Services" />
<Reference Include="System.EnterpriseServices" />
<Reference Include="WebActivator, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL">
    <HintPath>..\..\packages\WebActivator.1.0.0.0\lib\WebActivator.dll</HintPath>
    <Private>True</Private>
</Reference>

Answer 1

You have multiple question and I'll try to answer them all.

Attribute routing

Attribute routing is a standard functionality of WebAPI 2.2. You can use it by decorating your method with an RouteAttribute as you've already done. This attribute comes with the package Microsoft.AspNet.WebApi.WebHost.

The NuGet package AttributeRouting is another third party package that's not included in a WebAPI project by default. If you want to add that to your project you can install it like this:

Install-Package AttributeRouting

My guess is, you will probably not be needing this package.

Next, Packages

NuGet packages are third-party modules that you can add to your solution. Added packages are stored in a solution folder called packages (that's why your project file contain HintPath to ..\..\packages\*. All packages used by any project in your solution are stored there. The packages used by a single project are referenced in a project level file packages.config.

Now, when a co-worker retrieves your solution from a source control system (e.g. TFS) and builds your solution, the packages should automatically be retrieved (from NuGet) and the solution should work. This is default behavior for Visual Studio. It is, however, possible to opt-out from automatically retrieval as described here. If you, or your co-worker have opted out, the packages won't be retrieved and the solution won't build because of missing references.

Then, the bin folder

The bin folder is a folder where Visual Studio will put your compiled solution. That means, every time you build your solution, VS will clean that folder, compile the sources to assemblies and put the compiled assemblies as well as the referenced assemblies in the bin folder.

E.g. when a new co-worker retrieves your solution from source control he will not have a bin folder. As soon as he builds the solution the bin folder will be created an filled with the build assemblies.

Finally, fixing your solution

To fix your original problem (Route not recognized) check whether NuGet packages are automatically retrieved. The options

• Allow NuGet to download missing packages
• Automatically check for missing packages during build in Visual Studio

should both be checked. Both options are available on the Package Manager General settings in Visual Studios options.

After that you'll have to add the WebAPI package to your solution:

Install-Package Microsoft.AspNet.WebApi

This will also install some dependencies (Microsoft.AspNet.WebApi.Client, Microsoft.AspNet.WebApi.Core, Microsoft.AspNet.WebApi.WebHost and Newtonsfot.Json) and afterwards Route and GlobalConfiguration.Configure and HttpConfiguration.MapHttpAttributeRoutes will be recognized.