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):
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)
Installing from Nuget and referencing the version in my
local packages folder, which seemed to just default back to the system-wide version.
Reinstalling all my dependencies in Nuget PM with: update-package -reinstall -ignoreDependencies
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.]
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.
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.
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.
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.
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.
Related
I have an ASP.NET 4.7.2 Framework project. At runtime, upon loading a view, it says System.Runtime version 4.0.0.0 cannot be found. We have written about this extensively here: ASP.NET: .NET Framework/Standard/Core DLL collisions, caused by Nuget. "You must add a reference to assembly System.Runtime..."
It's been over a week and we still don't have a solution. All development has been halted.
Yesterday we tried side-by-side loading by simply calling on application start up:
Assembly systemRuntime = Assembly.Load("System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a");
Upon start up. We don't do anything with systemRuntime. It's only there for us to confirm that indeed 4.0.0.0 was loaded. Unfortunately, that didn't fix anything.
This makes me think that maybe since views are compiled at run-time, maybe somehow they are not referencing the right System.Runtime, or that we need to do the side-by-side loading there.
This problem is so severe we've started porting the site to .NET Core, because no one has any ideas how to solve it. According to analyzer, we'll have to rewrite approximately 15% of the site. We cannot go without deploying to production for potentially weeks, so a temporary solution must be found as soon as physically possible. We already have fixes that need to go to up.
Dai, in the first comment, directed me in the right direction: the view engine doesn't necessarily use the same references as the main project.
After some Googling, I found a way to reference assemblies for the view engine. In web.config:
<configuration>
...
<system.web>
<compilation debug="true" targetFramework="4.7.2" batch="false">
<assemblies>
<add assembly="System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</assemblies>
</compilation>
</system.web>
...
</configuration>
I also followed Dai's recommendation to try precompiling views. This is done by editing the MVC project's .csproj file with:
<MvcBuildViews>true</MvcBuildViews>
Precompiling the views is not necessary, but did prove it was indeed views compiling differently than the main project, and made it a tiny bit faster to test because I didn't have to run the site to see it blow up.
When creating a new ASP.NET AJAX Web Application in Visual Studio 2005, the default web.config contains the following section (inside the compilation node):
<assemblies>
<add assembly="System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
</assemblies>
Whether or not the assemblies node exists doesn't seem to affect the AJAX functionality. Update panels, etc work fine regardless of whether or not the reference to System.Web.Extensions is included in Web.Config.
What's the purpose of this section, and can it be safely removed?
It may or may not be safely removed. The Assemblies node is for configuration-based reference addition. It's used by ASP.NET websites that deploy uncompiled .cs code files to their website, rather than (as sensible people do) compiled assemblies.
If you are deploying code-behind files to your website rather than assemblies, then keep it in. If you are deploying assemblies, remove it.
Rick Strahl's Web log has short but concisely explaining article on the subject.
I have the problem in my project ,I must load the assembly .
my problem is "impossible de charger l'assembly nom_dll" I am working with c# and framework 4 in my project I have v4.0
I use gacutil / if nom_dll to installe my dll in GAC ,it is install in path C:\Windows\Microsoft.NET\assembly\GAC_MSIL
Since it is for an ASP.NET application there are 2 options:
The new dll is in your bin directory but in your web.config you should not include the version, culture and PublicKeyToken details in your reference.
or
Your new dll is in the GAC (C:\Windows\Assembly) and your web.config should contain at least a valid PublicKeyToken.
<compilation targetFramework="4.0">
<assemblies>
<add assembly="SomeNS.SomeDllName, Version=1.0.0.0, Culture=neutral, PublicKeyToken=568C4712810GD043"/>
I have been taught that there are essentially two GACS:
One at "C:\Windows\assembly", which is for .Net Framework 3.x and lower, and
One at "C:\Windows\Microsoft.NET\assembly\", which is for .Net Framework 4.x and above.
We are going through this right now, with some discussion as to which GAC to use. Our folder structure under "C:\Windows\assembly" only has a "download" folder, which is empty.
The folder structure under "C:\Windows\Microsoft.NET\assembly\" is:
"C:\Windows\Microsoft.NET\assembly\GAC_32"
"C:\Windows\Microsoft.NET\assembly\GAC_64"
"C:\Windows\Microsoft.NET\assembly\GAC_MSIL"
Our latest .DLLs are in the "C:\Windows\Microsoft.NET\assembly\GAC_MSIL".
I hope this helps.
Randy
I'm trying to upgrade an app to ServiceStack 4 but I'm getting an error with the reference to System.Web.WebPages.Razor in Web.config:
Could not load file or assembly 'System.Web.WebPages.Razor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
The offending reference is the exact same that is included in various ServiceStack examples:
<compilation targetFramework="4.5" debug="true">
<assemblies>
<add assembly="System.Web.WebPages.Razor,
Version=1.0.0.0,
Culture=neutral,
PublicKeyToken=31BF3856AD364E35"/>
</assemblies>
...
I tried to run the official examples (Razor RockStar and EmailContacts) but I'm also getting the same error when I run them.
If I change the library declaration to use Version=2.0.0.0 instead, I'm not getting any error.
So my question is:
Are the example wrong and should they be moved to 2.0.0.0 as well or am I doing something wrong?
My setup:
Windows 8.1 Pro x64
Visual Studio 2013 Pro
App targeting for .Net 4.5, x86
ServiceStack 4.0.15
The razor Web.config sections added by ServiceStack.Razor normally use the version of ASP.NET WebPages that's installed on your computer included with VS.NET installation and updates and is normally located under:
C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages\
This holds the different version of ASP.NET Web pages installed, e.g:
v1.0\
v2.0\
Another option for installing ASP.NET WebPages is via NuGet, i.e:
PM> Install-Package Microsoft.AspNet.WebPages
This will install the latest version of WebPages which is currently at v3.1.1 and means you would need to change the version number in the Web.config to Version=3.0.0.0.
You can install the specific 1.0.0.0 version of ASP.NET Web pages with:
PM> Install-Package Microsoft.AspNet.WebPages -Version 1.0.20105.408
Only configuration section used
ServiceStack doesn't use the WebPages implementation itself, the configuration is primarily included to keep VS.NET intelli-sense happy as well as providing a way to configure the default namespaces added to Razor pages.
Although this can also be done in code by adding to the Config.RazorNamespaces collection, but adding them to the config section lets VS.NET knows about them so you can get proper intell-sense, otherwise it doesn't have any effect on the execution of the pages at runtime.
I am trying to use TextfieldParser that was found within Reading CSV files using C#. I am using VS 2010 and doing this in C#.
I keep on getting "the type or namespace "TextFieldParser" could not be found.."
When I try and add the using line, it will only go using Microsoft.VisualBasic; deep and not using Microsoft.VisualBasic.FileIO;
Any help would be great.
In Visual Studio, right click on References in the Solution Explorer side panel. Click "Add Reference".
In that list be sure to check Microsoft.VisualBasic. Hit OK.
Now in the namespace, add Using Microsoft.VisualBasic.FileIO.
That will allow you to use TextFieldParser. For a good, easy example on how to use it, look here: http://geekswithblogs.net/brians/archive/2010/07/07/whats-a-nice-class-like-textfieldparser-doing-in-a-namespace.aspx
For uncompiled files (aspx / ashx), you need to put an reference in the web.config. (They cannot use the project references.)
<system.web>
<compilation debug="true" targetFramework="4.6.1">
<assemblies>
<add assembly="Microsoft.VisualBasic, Version=10.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />
</assemblies>
</compilation>
</system.web>
Alternatively for web applications, it would be preferred to put the code in a compiled file (cs/vb) and add a reference to the project.
See this question microsoft.visualbasic.fileio does not exist.
Application references are not available to uncompiled files in your application (aspx, ashx). The reference would need added to the web.config or else the code would need moved to a compiled file (cs/vb).