“The type or namespace name 'Route' could not be found” using “attribute routing”

Question

Just trying to splice some code from one working project to another. The \"from\" project uses \"attribute routing\" where you embed [Route(…)] directives in the W

Answer 1

Attribute Routing is native in ASP.NET MVC 5, or later, and ASP.NET Web API 2.

However, there is a project that allows to use attribute routing it in previous version of ASP.NET MVC,and Web API. You should read this page carefully.

As you can see in the linked page, this project is available as a NuGet package, so that it can be installed like this:

• Install-Package AttributeRouting (for MVC)
• Install-Package AttributeRouting.WebApi (for Web API)
• Install-Package AttributeRouting.WebApi.Hosted (for self-hosted Web API)

Please, be aware that the namespaces of attribute routing are different for each version and for MVC and Web API. So, you must browse the .dll included by the installed package to find out the right namespace, and change your using accordingly. For example:

using AttributeRouting.Web.Http;

Answer 2

When projects are shared between multiple solutions, the reference of libraries downloaded with Nuget have to be configured in .csproj manually at solution related path.

For example, log4net should be configured as:

<Reference Include="log4net, Version=1.2.15.0, Culture=neutral, PublicKeyToken=669e0ddf0bb1aa2a, processorArchitecture=MSIL">
   <HintPath>$(SolutionDir)\packages\log4net.2.0.5\lib\net45-full\log4net.dll</HintPath>
   <Private>True</Private>
</Reference>

Answer 3

In my case, in web api project there were two using references:

using System.Web.Http;
using System.Web.Mvc; 

As soon as I removed System.Web.Mvc, the error was gone.

Answer 4

This comment from Vedran Mandić solved the problem for me. I'm re-posting it here because I think it should be the answer (or at least a answer).

I did an 'Update-Package Microsoft.AspNet.WebApi.WebHost -reinstall' and it worked. Funny this happens after getting the latest version on different PCs from TFS. I guess this happens because of nuget packages not working properly with the versioning system