HttpRequestMessage could not be found, yet System.Net.Http is referenced

Question

I have a new .Net 4.5.2 (checked that this is the target framework) Web API Application (in VS 2015). I have referenced System.Net.Http, and as you can see the version is 4.0.0.0:

In my Filter/Attribute I am trying to reference HttpRequestMessage which is in the System.Net.Http namespace (I have the correct using at the top of my file), yet am getting the message that

The type 'HttpRequestMessage' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

And although I can't reference that class, I can browse to it in the Object Exploerer (I assume this uses the .xml file of the same name next to the .dll).

I have tried (edit: as well as the usual restarting VS and rebuilds etc):

1. Removing and re-adding the reference (from both the Framework and Extensions - although I'm certain it's meant to be the Framework version, I was getting desparate)
2. Installing from Nuget and referencing the version in my local packages folder, which seemed to just default back to the system-wide version.
3. Reinstalling all my dependencies in Nuget PM with: update-package -reinstall -ignoreDependencies
4. Adding the assembly manually to the web.config Adding the assembly manually to the .csproj file

[Edit: Solution:

OK, I created a few new VS Web API projects (and solutions) to see if I could reproduce the problem. In the end I created a new "Filters" folder, created a new Filter class in there, copied the contents of my pared-down original over, and lo-and-behold HttpRequestMessage was recognised. Did the same thing going back the other way (my filter was originally created in an App_Code folder) and it was still working. I think perhaps there was an unseen reference to an old System.Net.Http that was throwing a spanner in the works and even though I may have commented out the code that called it, somehow it was being remembered. That's just a guess. But anyway, paring it down to barest bones and going from there was the final approach that led to a solution.]

Answer 1

In my case, willing to actually use dynamically compiled files inside the App_Code, I had to add explicitly the assembly in the compilation node of the Web.Config:

<system.web>
  <compilation targetFramework="4.8">
    <assemblies>
      <add assembly="System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
    </assemblies>
  </compilation>
  ...

This solved my case. Of course, adjust the target framework according to your project needs.

Answer 2

I am having the same problem, (which is how I stumbled on this question) and there is one thing that I noticed that nobody seems to have latched onto yet.

I am building a WebApi2 application, and I added in a class library to turn into an nunit test library. I started getting conflicts with System.Web.Http. It appears that the webapi2 uses 5.2.6.0, where other things will try to default to 4.0.0.0.

Make sure that you are using the correct version of System.Web.Http, and that you also have the System.Net.Http assembly referenced. Once both assemblies were referenced and running the same version numbers across all solutions, all problems were resolved. VS doesn't always load the correct versions by itself.

Answer 3

I've tried this highly suggested solution (on Web.Config)

<system.web>
    <compilation debug="true" targetFramework="4.5" />
    <compilation debug="true" targetFramework="4.0">
      <assemblies>
        <add assembly="System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
      </assemblies>
</compilation>
</system.web>

But unfortunately, this didn't work me. At last, I've found a solution (this worked for me)

Right-click the References folder > Add Reference... Expand Assemblies on the left side of the window and select Framework. Scroll to and select System.Net.Http in the list of assemblies. Make sure the box next to System.Net.Http is checked, then click OK. Rebuild the project.

Answer 4

If you're coming from creating web sites, but are now creating a web application, don't add the App_Code folder or any code into it as each class file will either be set to "Content" (click on the class, look in the Properties pane under "Build Action") and so won't be picked up by Intellisense in the rest of the application, or you can set to "Compile" but then that has its own problems at release time: See Vishel Joshi's blog all about it.

Answer 5

I also managed to resolve this by moving my custom RouteConstraints out of the App_Code folder. Just added a new folder to my project and copied them there.