Could not load file or assembly Microsoft.Bcl.AsyncInterfaces - f#

I can not use the SqlType provider due to an issue with Microsoft.Bcl.AsyncInterfaces.
I am using a minimal program with .NET 4.7.2 and F# 4.7.0.0.
My Nuget packages contain a reference to:
package id="Microsoft.Bcl.AsyncInterfaces" version="1.0.0"
targetFramework="net472"
Severity Code Description Project File Line Suppression State
Error FS3033 The type provider 'FSharp.Data.Sql.SqlTypeProvider'
reported an error: Unable to load one or more of the requested types.
Retrieve the LoaderExceptions property for more information. Details:
Could not load file or assembly 'Microsoft.Bcl.AsyncInterfaces,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or
one of its dependencies. Das System kann die angegebene Datei nicht
finden. TestSqlProvider C:\Users\weism\source\repos\TestSqlProvider\TestSqlProvider\Program.fs 9 Active
What can I do to fix this issue?

For me, installing the Microsoft.Bcl.AsyncInterfaces (Nuget package) fixed the issue.

This error also happens when you try using Microsoft.EntityFrameworkCore v5 in a dotnet core v3.1 project.
To resolve, down-version Microsoft.EntityFrameworkCore to latest v3 version.

For .Net Core, This problem basically occur , when we use layered architecture. Just make sure the version of Microsoft.EntityFrameworkCore should be same in all project, wherever it is used.

I don't use Microsoft.Bcl.AsyncInterfaces at all in my .NET 4.8 project. Some library depends on version 1.0.0.0. I resolved the issue using a binding redirect:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Bcl.AsyncInterfaces" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
</dependentAssembly>
Microsoft.Bcl.AsyncInterfaces.dll 5 was copied to Bin after build.

I think you update package in one layer.
for me i worked in project with three layers (api, AdminTool, Data) the AdminTool Layer had a reference to Data Layer i updated all packages in AdminTool only so i had this error i update package also in data layer and api layer so the problem solved.
I hope that help you.

My Entity Framework Core just needed upgraded
TO

Make sure you have unique single version of that dll. Another step would be to add a binding redirect in the app.config as told in the above comments.

Check in your installed nuget packages---
If version of Microsoft.EntityFrameworkCore and your .net project is different then it can be a problem.
Example - If EntityFrameworkCore is at v5.1.5 or higher & your project dotnet core v3.1 project, this can be the issue.
To solve,
down-version Microsoft.EntityFrameworkCore to equal version of project such as v3 version. to down version click on tool in visual studio -->Nuget Package Manager--> Manage Nuget package for Solutions --> click on installed ---> select nuget package which you want to downgrade --> click on uninstall and then select the same nuget package and then install version 3.1.5 or relevent package.
or
Install Microsoft.Bcl.AsyncInterfaces (Nuget package)

Updating the Microsoft.Bcl.AsyncInterfaces assembly via NuGet did everything it needed to do, including adding the bindingRedirect entries in the appropriate config files.
I also did all the other hygienics. I cleaned my solution, deleted the bin and obj directory entries, and also cleaned my localhost deploy locations.
However, I still got this error. I reviewed the output (my application is a .NET 4.8 MVC Web application, so the web page showed the error log in detail), and I found that it was failing on loading SimpleInjector.
I updated SimpleInjector to the latest version via NuGet and that fixed my error.
Unfortunately, I didn't keep a copy of the error page, so I can't show you what I saw, but the bottom line is to examine the output or log in detail, see if you can find where the application is attempting to load the assembly that is failing, and update that assembly that appears to be calling the load.

I was able to fix it by removing <Private>True</Private> from csproj for Microsoft.Bcl.AsyncInterfaces. Just reinstall this NuGet package

Related

Exception – Could not load file or assembly 'System.Web.Mvc, Version=4.0.0.1…'

There is a problem – only when I request one single controller – I get the exception:
Could not load file or assembly 'System.Web.Mvc, Version=4.0.0.1, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040
It's strange because in my config file I see that the version is 4.0.0.0 and and all the other controllers are fine and only when I upload the application on the server this thing happens.
This is a known issue. Seems you have migrated recently from 3.0 to 4.0 or this application is a fresh clone from the repository. The one single controller may not have nuget restored. I have also faced this issue. I got this msdn link and browsing it had a solution. Here are the steps mentioned.
The problem can be resolved by implementing one of the following
solutions:
(Preferred) Install Microsoft.AspNet.Mvc from the NuGet gallery (this will install a binding redirect in your web.config). You can do
this from the NuGet package manager or the NuGet console inside Visual
Studio:
Install-Package Microsoft.AspNet.Mvc -Version -Project PROJECTNAME
MVC 4 version: 4.0.40804.0
MVC 3 version: 3.0.50813.1
Manually update the reference to System.Web.MVC.dll (don’t use the one in the GAC).
Try the Add Reference -> Assemblies -> Extensions dialog box.
In either case ensure that the Copy Local project property for the
assembly is set to true so it ends up in your bin folder which is
needed for deployment. There is a known NuGet bug that resets the Copy
Local flag: https://nuget.codeplex.com/workitem/4344
Install Nuget Package Microsoft.AspNet.Mvc for all the project referencing System.Web.Mvc dll Hope this solves your problem
I got this build error on a VSO agent thanks to the ASP.Net assembly resolve weirdness. I had changed some of my build configurations and Visual Studio modified the output directory for the MVC project to \bin\x86\Debug or something similar.
This had bitten me before and I remembered ASP.Net wants to be built to \bin ONLY.
So when you get any kind of "reference could not be found" on build time, remember to check that your build output directory is only \bin:
More on the problem here:
Changing output directory for asp.net project in Visual Studio
Hope this helps someone.
You maybe can reference ASP.NET MVC as reference to GAC, but it can happens that different developers have different version of MVC installed.
Remove references to ASP:NET MVC and add ASP.NET MVC as nuget package.
Go to Nuget manager, search for: "Microsoft.AspNet.Mvc", and press update button.
That work on my case.
I got this also at run-time, and it was due to my project (a unit test project using NuGet PackageReference) referencing an ASP.NET website project that already had the necessary binding redirects in place (as suggested by the compiler warnings when building). I had to add the same binding redirect in the unit test project.
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Web.Mvc" culture="neutral" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="0.0.0.0-5.2.6.0" newVersion="5.2.6.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>

Visual Studio Online Hosted Build Controller Could not locate the assembly Microsoft.WindowsAzure.Diagnostics

we're using VSO hosted build controller to run our CI builds. A build has started failing that was working fine.
C:\Program Files (x86)\MSBuild\12.0\bin\amd64\Microsoft.Common.CurrentVersion.targets (1697): Could not resolve this reference. Could not locate the assembly "Microsoft.WindowsAzure.Diagnostics, Version=2.4.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
This assembly should resolve to the Azure SDK which should be included in the host according to http://listofsoftwareontfshostedbuildserver.azurewebsites.net/ although http://www.visualstudio.com/en-us/get-started/hosted-build-controller-vs.aspx states the host only supports upto 2.3. We have had this building though.
All our assemblies for Azure SDK are for version 2.4. It builds locally and there are no previous versions of the SDK installed on my machine. We have binding redirects like so...
<dependentAssembly>
<assemblyIdentity name="Microsoft.WindowsAzure.Diagnostics" publicKeyToken="31BF3856AD364E35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.4.0.0" newVersion="2.4.0.0" />
</dependentAssembly>
Has anyone else seen this?
You can fix this by setting the "Specific Version" property in your Microsoft.WindowsAzure.Diagnostics reference in the affected project, using Visual Studio (right click on the reference and choose Properties in Solution Explorer). This will cause the build server to use the 2.3 version of the assembly.
If you're using any new classes or methods in the 2.4 SDK this might not work but it at least gives you a temporary solution until MS gets the problem fixed.
Here's a picture of my working reference
Finally, check out the link (Really old) for more info on specific reference version: http://www.codemag.com/article/0507041,
I started experiencing same today. Not sure what has changed.
Following was raised https://connect.microsoft.com/VisualStudio/feedback/details/1007907/error-deploying-to-azure-sdk-2-4
What I did to overcome this issue is that I created old style lib folder, and added diagnostics and runtime dll to it. I change my csproj to reference from there. And this seem to have fixed it
The bug is now fixed. A workaround is no longer required to use Azure SDK 2.4.
I added a powershell script to print out all libraries on the build server. A full guide on this can be found here. The script consists of the following line
gp HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*
The Windows Azure Libraries for .NET - v2.4 was missing from the printed list, all other versions are available. This has been raised as an active bug on connect.microsoft.
Until this is fixed adding the 2.4 libraries to source or reverting to an earlier version of azure will be the only work around.

ASP.NET MVC4 solution fails to build after installing KB2993928

We have an ASP.NET MVC 4 solution with a couple of references that has been building without problems for about 2 years now. However, after installing KB2993928 and KB2993937 this morning, we cannot run FxCop on this solution on our Windows 7 machines anymore.
I have a feeling this is because this update changed the DLL version of the System.Web.Mvc assembly in the GAC. This is because in the GAC I can currently find 3 different System.Web.Mvc DLLs, which are all updated today.
The error we receive in the build is as follows:
6>MSBUILD : error : CA0001 : The following error was encountered while reading module 'FrontEnd.Implementation': Assembly reference cannot be resolved: System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35. [C:\Project\FrontEnd\02-Implementation\02-Implementation.csproj]
6>MSBUILD : error : CA0058 : The referenced assembly 'System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' could not be found. This assembly is required for analysis and was referenced by: S:\Deliverables\FrontEnd\bin\FrontEnd.Implementation.dll. [C:\Project\FrontEnd\02-Implementation\02-Implementation.csproj]
Since we use ASP.NET MVC 4, this version 3.0 DLL is referenced indirectly by one of our references. For instance, RazorGenerator references version 3.0.0.0. Possibly others as well. There is no new version of RazorGenerator from what I can tell.
The System.Web.Mvc versions I see in the GAC are: 3.0.50813.1, 4.0.40804.0 and 5.0.20821.0.
I removed the reference to System.Web.Mvc from our projects and added Mvc as a NuGet package instead. This fixes our compilation, but FxCop still doesn't work due to the indirect references.
If any additional information is required please let me know.
If this issue is caused by references which in turn have dependencies on those specific assemblies, you can remedy this by coercing FxCop to use only the StrongName and ignore the version number. This solution is described here.
Of course the real solution would be to update the referenced assemblies (with the indirect dependencies) to newer versions.
Solution:
Uninstall the MVC Framework via "Programs and Features" (whichever version you're using)
Re-install MVC Framework (http://www.asp.net/mvc/mvc4)
Should fix the problem - no changes to the build/solutions is required.
This was done by a security update on October 15th from Windows Update. You will need to run the updates on your build servers too.
Link to update:
http://www.microsoft.com/en-ie/download/details.aspx?id=44533
This update fixes other versions as well.
You will likely have to update your projects to the newer version, as it changes the version number and removes the older version completely.
Remove any references to System.Web.MVC and then re-add them by manually browsing to the dll (C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Web.Mvc\v4.0_5.1.0.0__31bf3856ad364e35\System.Web.MVC.dll on our machine). A lot faster than re-installing MVC if this has just taken your production server down!
The security updates update the assembly version of system.web.mvc.dll. You need to update your csproject to correct the version. Check this post:
ASP.NET MVC security patch to version 3.0.0.1 breaks build
I used the following solution and it's work perfectly:
https://stackoverflow.com/a/26490590
(don't forget to select the default project on the Package Manager Console for each project with the build failed)

NuGet - dependency installed but not found

I have a problem with the NuGet package manager. I published my library (a type provider, but I don't think this matters) and then testet it, but it fails to find a dependency. The complete error message is (full namespace/name ommitted for brevity):
The type provider 'TypeProviderImplementation....' reported an error:
Could not load file or assembly 'dotNetRDF', Version=1.0.3.0, Culture=neutral, PublicKeyToken=...' or one of its dependencies.
The thing is that when installing the library, it looks like the dependencies are installed correctly. The correct libraries are downloaded and there is no error showing up.
In an attempt to solve the problem, I specified the exact version in the .nuspec file, but this didn't change anything.
...
Installing dotNetRDF via NuGet and then manually referencing my precompiled DLL (without going through NuGet) seems to work fine.
So I'm basically out of ideas on how to solve or even debug the problem. I'm thankful for any pointers.
Addign more information about .NET version numbers as my comment below is quite hard to read:
I checked framework versions as suggested. I did this via looking at the FrameworkDisplayName in the object browser. Basically, my library was using 4.5 and dotNetRDF was using 4.0.
I switched to .NET 4.0, but nothing changed.
My library = ".NET Framework 4"
dotNetRDF = ".NET Framework 4"
HtmlAgilityPack = ".NET Framework 4.5"
Newtonsoft.Json = ".NET Framework 4.5"
VDS.Common = ".NET Framework 4 Client Profile"
My dependency is dotNetRDF, the remaining ones are dependencies of dotNetRDF.
Latest NuSpec file can be found here. I create the package via the command nuget pack LITEQ.fsproj -Prop Configuration=Release.
The package id is LITEQ.RDF.
Some additional information:
The library is a F# project. I just tested what happens if I create a console project and install the library via NuGet and then send the references to the F# Interactive Console. It actually works in this case.
So it feels like there is some problem with the project configuration after installing the library via NuGet.
To reproduce, the error, download the library, open up the UniKo.West.Liteq namespace and for example use the NpqlTypeProvider:
open Uniko.West.Liteq
type A = NpqlRdfProvider< #"">
Certainly for me I can't see any obvious problems, when I install your package into an empty console project I don't have any issues and I can write a trivial example that uses the dotNetRDF APIs just fine. If you can produce a minimal example project into which installing the packages creates an issue then that would be very helpful.
Your Issue
However the dependencies you state for your project look wrong, you have .Net 4.0 for your project and some dependencies but .Net 4.5 for others which will not work. Note that when you downgrade a projects target framework NuGet does not cope nicely with that, it is best to completely uninstall and reinstall NuGet packages any time you change the target framework version. It is perfectly fine for a newer version of the framework to rely on dependencies that target older versions, so your .Net 4.5 project can happily depend on the .Net 4.0 version of dotNetRDF. However the reverse is not true which may be the cause of your problems.
You can sometimes tell if this is the case because VS may highlight bad dependencies under References in the solution explorer with little warning icons (sadly it doesn't always do this). Even if this is not the case you should see output like the following in the Output Window when you try and build if you have incompatible dependencies and this may also yield compile errors about missing namespaces:
C:\Program Files
(x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5):
warning MSB3274: The primary reference "HtmlAgilityPack" could not be
resolved because it was built against the ".NETFramework,Version=v4.5"
framework. This is a higher version than the currently targeted
framework ".NETFramework,Version=v4.0".
So I would strongly suggest that you uninstall all packages via NuGet and reinstall them whenever you change the target .Net framework of your project.
Other Issues
In terms of other possible issues you are using dotNetRDF 1.0.3 which is not the latest version, versions prior to 1.0.5 have a known issue related to interactions with the versioning and framework profiles of Json.Net. If a project you are installing into also has dependencies on Json.Net you may run into version conflict issues. See CORE-405: Resolve Issues with Json.Net dependency for some discussion on this.
I would suggest that you also upgrade your dependency to the latest dotNetRDF release which is 1.0.6.3421 at the time of writing this answer and see if that resolves your problem.
Edit - NuGet Package Versions
NuGet packages versions do not have to correspond to the assembly version, as it happens 1.0.6.3421 does have an assembly version of 1.0.3.0. That was actually not our intention but a flaw in our build process but that isn't really relevant here.
What it looks like is that your library is compiled against a different version of dotNetRDF than the one NuGet is installing for you. However without seeing the source of your package it is impossible to debug further.
What if neither solution works?
If neither of these things resolves your problem then you are going to need to provide a minimal project that reproduces the problem.
A temporary solution (or more of a hack) is to not rely on dependencies, but to directly put the DLLs into the NuGet package. When I do this, the library works fine. The NuSpec file in this case looks like this (excerpt):
<package>
<metadata>
...
</metadata>
<files>
<file src="bin\Release\dotNetRDF.dll" target="lib/net40" />
<file src="bin\Release\HtmlAgilityPack.dll" target="lib/net40" />
<file src="bin\Release\HtmlAgilityPack.pdb" target="lib/net40" />
<file src="bin\Release\HtmlAgilityPack.xml" target="lib/net40" />
...
</files>
</package>
But obviously, this isn't a good solution.

assembly uses System.Web.Http 5.1 which has a higher version than referenced assembly System.Web.Http 5.0

I created a new Project in Visual Studio 2013, a WebApi & MVC 5 project and updated all nuget packages. It updated to mvc 5.1. Now I cannot Successfully build the project it says
assembly uses System.Web.Http 5.1.0.0 which has a higher version than referenced assembly System.Web.Http 5.0.0.0
Anyone run into this before? Why these kind of problems do occur so often in Visual Studio? Does anybody know how to solve this because I really am trying hard but no luck so far...
Solved
I opened the Package Manager Console in Visual Studio and run the command
PM> Update-package
It magically resolved everything for me. You can find Package Manager Console under
Tools
Nuget Package Manager
Package Manager Console
This command deletes all the old packages under the package folder and updates everything if necessary, you may also run the command on a specific package. Here all the variants of the command http://docs.nuget.org/docs/reference/package-manager-console-powershell-reference#Update-Package
Let me know if you found this useful I'm curious to know if it just happened to me accidentally
A new version of ASP.NET was released. Announcement here : http://blogs.msdn.com/b/webdev/archive/2014/01/20/announcing-the-release-of-asp-net-mvc-5-1-asp-net-web-api-2-1-and-asp-net-web-pages-3-1.aspx
You probably have two projects in your solution, where project A references project B. Both projects reference ASP.NET, but there is a version mismatch.
I had a very similar problem to yours exactly with a reference to System.Web.Http and have documented it here:
Could not load assembly error
When you update a Nuget package it would update dependent packages. But it would not update other packages in your solution that depend on the updated packages. These other packages might not even have a newer version built with the udpated packages.
So the solution is either to udpate all your packages like you did (this might not always work) or add binding redirects to the latest version of your assembly reference to your application config.
I solved this way. As I currently have fwk 4.0.0.0 and don't want to install 5.X:
I removed the referenced DLLs
I removed a couple of bindingRedirects at packages.config,
Then I rebuilded that solution, that throws me errors
Then I added the reference again
And voilà, the solution is running with the fwk that I have.

Resources