We Keep Coding

Unable to load System.Threading.Tasks.Extensions

I have a web project build on .net framework 4.5.1. We are trying to added PostgreSQL support for the project. Using Nuget, I have installed 4.0.4 npgsql to the project. Under references, I see the following being added to the project.
Npgsql - 4.0.4.0 - Runtime version v4.0.30319
System.Threading.Tasks.Extensions - 4.2.0.0 - Runtime version v4.0.30319
When I tried run the project and connect and get the data from the database, I am getting the following error saying FileNotFoundException:
System.TypeInitializationException
HResult=0x80131534
Message=The type initializer for 'com.rsol.RConfig' threw an exception.
Source=RConfig
StackTrace:
at com.rsol.RConfig.getInstance() in C:\Workspaces\PS\RConfig\RConfig.cs:line 1113
at RAdmin.Global.Application_Start(Object sender, EventArgs e) in C:\Workspaces\PS\RAdmin\Global.asax.cs:line 528
Inner Exception 1:
TypeInitializationException: The type initializer for 'com.rsol.Db.DbMgr' threw an exception.
Inner Exception 2:
FileNotFoundException: Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=4.2.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
Inner Exception 3:
FileNotFoundException: Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
System.Threading.Tasks.Extensions which is installed using Nuget is not getting loaded to the project. When I checked the properties of System.Threading.Tasks.Extensions reference, the dll file exists in the location. I have also tried installing System.Threading.Tasks.Extensions.dll file to assembly using gacutil. I am still getting the same error.
Please let me know if you need any additional information.
Any help is really appreciated.

In my case, I got the issue after upgrading to version 4.5.4 and tried #user2713341 answer. It didn't work but put me in the right direction.
My project had no bindings for this library, so I added the binding and it worked
<dependentAssembly>
<assemblyIdentity name="System.Threading.Tasks.Extensions" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
</dependentAssembly>
and it worked.
Note that it should be 4.2.0.1 even though the version is 4.5.4.

Update Nuget Package
https://www.nuget.org/packages/System.Threading.Tasks.Extensions/
will solve your problem

Update Nuget Package is not working for me.
What works?
In app.config need to change
<bindingRedirect oldVersion="0.0.0.0-4.2.0.1" newVersion="4.2.0.1" />
To
<bindingRedirect oldVersion="0.0.0.0-4.5.4" newVersion="4.5.4" />
for current version 4.7.2 should work.
Microsoft like ;)

The response from #Keyjote was at the root of the solution for me, but rather than cherry-picking the assemblies, I was able to just reinstall. This seemed to automatically repair the app.config file.
Tools -> Nuget Packet Manager -> Packet Manager Console
Update-Package -reinstall -Project <your project name>
This way you don't need to mess with the syntax or have to figure out the PublicKeyToken values.
If you want to do it for the whole solution, you can omit the -Project <> parameter.

I got the error in a different context when trying to migrate using Entity Framework Core (EFC) Version 3.1.8 using the Package Manager Console. The project built successfully.
Trying the binding redirects as suggested in this thread and (re)installing different versions of System.Threading.Tasks.Extensions as well as EFC (as suggested also elsewhere) did not work for me.
I managed to solve the problem by
deleting the packages/ directory in my project's root directory
using manual NuGet Package Restore (link to Microsoft Docs) via Visual Studio

problem lies in *.csproj file. having wrong reference for System.Threading.Tasks.Extensions.4.5.4 because this dll not loading.
after referring correct framework version folder from lib its start working
old Reference:
<Reference Include="System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL">
<HintPath>..\packages\System.Threading.Tasks.Extensions.4.5.2\lib\netstandard2.0\System.Threading.Tasks.Extensions.dll</HintPath>
</Reference>
corrected one:
<Reference Include="System.Threading.Tasks.Extensions, Version=4.2.0.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51, processorArchitecture=MSIL">
<HintPath>..\packages\System.Threading.Tasks.Extensions.4.5.4\lib\net472\System.Threading.Tasks.Extensions.dll</HintPath>
</Reference>
please clean the nuget cache first, then run test case it will work

I have been struggling a lot with bindingRedirect.
I finally found a real gotcha that solved my problems.
I have a WCF server project in .net 4.8, depending on projects in .net standard 2.0.
I was updating Nuget packages in the referred projects.
I got al sorts of problems, I won't try to mention them here.
I had bindingRedirects in web.config. I had to rediscover that those were unnecessary, and maybe even conflicting, because of automatic generation of those into the dll.config. There are various aspects to make that work, see elsewhere.
But the real gotcha for me was that for IIS, I had to LINK web.config to the dll.config. The latter being the complete config-file, with all the bindingRedirects, which turned out to be working after all.

Try to download the package and add reference to your project explicitly . should work , I just resolved it .

I got a similar error message - but for a different reason. In packages.config set by NUGET manager There was a ref for the new version - but in project reference there was a ref for an old version. The solution - delete the ref in project reference

How to reference a strongly-named DLL at compile time, or for ASP.NET view compilation?

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.

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

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.

Razor dependency issues in ServiceStack 4

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.

Installed .Net 4.5 but can't use ZipFile class in Visual C#

I'm kind of a newbie to Visual Studio programming.
I recently upgraded .Net 4.0 to 4.5 in order to use the ZipFile class under System.IO.Compression, but after the installation completed, Visual Studio (I'm using 2012) still cannot recognize ZipFile as a class name.
I've made sure that .Net 4.5 appears in Control Panel programs list and my C# solution sets .Net Framework 4 as the target framework.
Could someone help me figure this out?

See ZipFile Class on MSDN. It shows the required framework version is 4.5. Once the framework version is fixed check you have added a reference to the System.IO.Compression.FileSystem.dll assembly and added a using System.IO.Compression directive to your class.

You also need to reference the System.IO.Compression.FileSystem.dll assembly.

Just to further clarify the previous answers, here's how to add the references manually to a Web.config:
<configuration>
<system.web>
<compilation targetFramework="4.5">
<assemblies>
<add assembly="System.IO.Compression, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
<add assembly="System.IO.Compression.FileSystem, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
</assemblies>
</compilation>
</system.web>
</configuration>
Or to a *.csproj:
<Project ...>
<ItemGroup>
<Reference Include="System.IO.Compression, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089, processorArchitecture=MSIL" />
<Reference Include="System.IO.Compression.FileSystem, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089, processorArchitecture=MSIL" />
</ItemGroup>
</Project>
The files can be found in C:\Windows\Microsoft.NET\assembly\GAC_MSIL\ and the subfolders contain the necessary info on version, culture and PublicKeyToken as well.

You need to change the target framework of the current project from .Net 4 to .Net 4.5.

New features in .NET 4.5
Zip compression improvements to reduce the size of a compressed file. See the System.IO.Compression namespace.
Add System.IO.Compression assembly as reference to your project. You
may also want to reference System.IO.Compression.FileSystem assembly
to access three extension methods (from the ZipFileExtensions class)
for the ZipArchive class: CreateEntryFromFile, CreateEntryFromFile,
and ExtractToDirectory. These extension methods enable you to compress
and decompress the contents of the entry to a file.
Sample
const string zipFilePath = #"C:\apps\Sample Pictures.zip";
using (FileStream zipFileToOpen = new FileStream(zipFilePath, FileMode.Open))
using (ZipArchive archive = new ZipArchive(zipFileToOpen, ZipArchiveMode.Read)) {
foreach (var zipArchiveEntry in archive.Entries)
Console.WriteLine(
"FullName of the Zip Archive Entry: {0}", zipArchiveEntry.FullName
);
}
References:
http://msdn.microsoft.com/en-us/library/ms171868.aspx
http://www.tugberkugurlu.com/archive/net-4-5-to-support-zip-file-manipulation-out-of-the-box

For Windows Phone 8.1, use NuGet to add the Microsoft Compression package to your project and reference it.
If you had an older WP8 project you may have been using a different package that would create conflicts with the System.IO.Compression dll that is part of the .NET 4.5 that comes with WP8.1. You need to get rid of that and use Microsoft Compression which works harmoniously with .NET 4.5. That's how I got here!

In my case I needed to manually delete all dll references that started with System.IO.Compression and then add one by one the needed ones (System.IO.Compression.FileSystem, etc.) even though I only wrote a single using statement
using System.IO.Compression;
I hope this helps someone