125

When I try running the command "update-database", I get this exception:

Specify the '-Verbose' flag to view the SQL statements being applied to the target database. System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. File name: 'Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

WRN: Assembly binding logging is turned OFF. To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1. Note: There is some performance penalty associated with assembly bind failure logging. To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

Could not load file or assembly 'Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.`

2
  • 3
    In German, this error message reads: "Die Datei oder Assembly "Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" oder eine Abhängigkeit davon wurde nicht gefunden". Commented Apr 20, 2020 at 13:04
  • 2
    Install Microsoft build tools Commented Apr 9, 2021 at 5:40

24 Answers 24

127

Our local build script was using an older version of nuget.exe (4.7.1.5393) to restore NuGet packages. We started getting this error after updating to Visual Studio 2019 version 16.5.0. Updating to the latest version of nuget.exe (5.4.0.6315) fixed the issue for us.

nuget.exe can be downloaded here: https://www.nuget.org/downloads.

Sign up to request clarification or add additional context in comments.

10 Comments

Faced that challenge when we installed only VS2019 on a build server. To fix this in our Azure DevOps build it works to request version 5.4.0 in the NuGet tool installer step.
Upgraded from 4.3.0 to 5.6 on my TeamCity. This fixed my issue. Thanks!
This was it. Thanks a bunch! Went from 4.4.1 to 5.4.0.
@ElderSmash We're using an Azure DevOps build too. In our case the problem was solved by updating the NuGet installer step from NuGetToolInstaller@0 to NuGetToolInstaller@1, even without specifying a newer version. Not sure though, whether this fixes the root cause of the problem or the fix is just a side-effect of clearing the local cache.
@ElderSmash That was exactly my problem and solution to, thanks!
|
109

I believe I had the same issue as you did. I didn't save the whole error message, but my error message was

'Could not load file or assembly 'Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.'

I am using Visual Studio 2017 and was trying to do Update-Database after Add-Migration.

To resolve the issue I closed Visual Studio and re-opened it, then re-ran Update-Database again.

This may or may not resolve your issue, but I thought I'd post just in case it would help.

7 Comments

Yes, it would appear that "Turn-It-Off-And-On-Again" is the correct path to resolution in this case.
This works but I don't consider it as a correct answer. I would like to fix it once and forever, without having to restart VS.
It happens everytime after a migration now and it requires a full PC reboot to work.
I have tried every of the proposed solutions. None of them seems to permanently solve the problem. I have to keep restarting Visual Studio.
This is an open issue in Github here github.com/aspnet/EntityFramework6/issues/382
|
45

The root cause of this problem comes from relative paths in the devenv.exe.config file to Microsoft.Build.Framework.dll (see xml tags).

Some Visual Studio Extensions are changing the current directory and makes relative paths invalid.

To fix it, open this file in the C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\ directory. and replace all ..\..\MSBuild\15.0\Bin\ by C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\.

9 Comments

I am using Visual Studio Professioal should I also do the same. I am getting this error multiple times?
I did not have a MSBuild folder under IDE (Community version), I copied my MSBuild from "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community" and it didn't fix anything.
I am using 2017 Pro and this fixed the issue for me. +1
Note that if you update VS2017 after making this fix, you might have to update devenv.exe.config again
This answer just helped me for a second time - after updating VS2017 you need to do this again as @MikePeterson says.
|
42

I've found a workaround that seems to resolve the issue for good, at least on my environment running VS 2017 Professional 15.5.2 and Entity Framework 6.1.1.

Basically, install the DLL (with a few related ones) into the GAC (Global Assembly Cache) and the issue will go away.

Follow these steps:

  1. Close all running instances of Visual Studio 2017

  2. Launch the Visual Studio 2017 Developer Command Prompt

  3. Type the following commands (replace Professional with your edition, either Enterprise or Community, or adjust the path accordingly):

gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll" gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.dll" gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.Engine.dll" gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.Conversion.Core.dll" gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.Tasks.Core.dll" gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.Utilities.Core.dll" 
  1. Restart Visual Studio 2017

In essence, the GAC will (in most cases) be given priority when .NET is trying to load a DLL and the FileNotFoundException will go away as your DLL will now be resolved through the GAC.

Again, it works for me and it's simply a workaround, it won't solve the core issue itself but at least I don't have to restart VS all the time when trying to work with EF migrations, and that's good enough for me.

2 Comments

Worked for me too. The Visual Studio 2017 Developer Command Prompt is in C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Visual Studio 2017\Visual Studio Tools and must be run as administrator.
FYI - this can cause problems when microsoft Upgrades the product and the GAC entries become invalid (newer version, or path change .. pro vs enterprise, etc). Notably an issue on upgrade to the latest 15.8.0 If your projects don't load (due to having used this solution), see here: developercommunity.visualstudio.com/content/problem/311136/…
24

This worked for me - appears to be a non-support issue beginning in 2020.

In the Azure Build Pipeline > NuGet tool installer step, change Version of NuGet.exe to install to a newer version, like 5.4.0. Check versions at https://dist.nuget.org/tools.json.

Issue disappeared and now builds successfully.

2 Comments

Updating the used nuget version was also the way to correct the problem for me.
by upgrading Nuget version to 5.4.0, error is resolved in azure pipeline
11

My missing file or assembly version is different with the question.

I have this error when I tried to publish my ASP.net project

Microsoft.Build.Framework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a 

I solved the problem by installing Microsoft Build Tools 2015

I think my problem caused by I publish project that was built with VS 2015 in VS 2017. Hope can help others that have same problem.

3 Comments

This helped fix a CI build in an on-prem TFS for me. One of my build servers did not have these tools and it kept failing with a very similar issue.
this was the issue for me. I had v15 and it wanted v14
This solved it!!
7

The following worked for me:

Add MSBuildLocator.RegisterDefaults(); before you actually use any MSBuild methods.

To add that, you will need to install Microsoft.Build.Locator. Do not specify ExcludeAssets=runtime. Install Microsoft.Build and for that one, do specify ExcludeAssets=runtime.

Found this solution from https://github.com/microsoft/MSBuildLocator/issues/64.

I didn't like a few of the other solutions here because they seemed to make you mess with more config files than I wanted. This solution just has you adding a line of code and installing a few packages :)

Of course, the others may work as well! I just don't trust myself enough to mess too much with configs, lest I mess something else up.

Comments

5

In my case, something (maybe a NuGet-Update) did add an AssemblyBinding into the web.config-File:

<dependentAssembly> <assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-15.1.0.0" newVersion="15.1.0.0" /> </dependentAssembly> 

After removing that dependentAssemby-Entry, I could Publish the Project again.

Comments

4

Just in case restarting Visual Studio does not work Go to Task Manager/ Process Explorer and skill VBCSCompiler.exe

enter image description here

Suggest using Process Explorer

1 Comment

I'm trying this solution "Just in case restarting Visual Studio does not work Go to Task Manager/ Process Explorer and skill VBCSCompiler.exe" and work fine.
4

In my Roslyn project, referencing the NuGet Package Microsoft.Build.Locator and calling MSBuildLocator.RegisterDefaults(); before creating the MSBuildWorkspace solved this problem.

Comments

3

This worked for me: The error occurs when I execute the nuget restore command. Nuget version 4.6.2. I have two ways to solve this problem.

Use Nuget 4.8.2 and higher. gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Current\Bin\Microsoft.Build.Framework.dll

Comments

1

We had this issue, and here is what we needed to do in our case:

Problem was that we had a database command interceptor (IDbCommandInterceptor) configured that called HttpRuntime.Cache["somekey"], and for some reason migration commands failed to run because of this. After removing this depencency, all commands ran perfect. Maybe HttpRuntime weren't able to find the Build Framework dll?

So check the entire callstack when migration commands fails to see if you have a similar problem.

1 Comment

Very interesting, my stack trace included a call to a method using HttpContext.Current. Removing this removed the issue.
1

Closing and re-opening Visual Studio works like a charm!

1 Comment

Unfortunately not for me
1

After trying all of the above methods and more - running WCF app still failed for me. Error: Could not load file or assembly 'Microsoft.Build.Framework, Version=15.1.0.0..

note: tried Restarting VS, PC, killing processes, cleaning up the VS caches, nuget caches, obj, bin, .vs, packages folders

What worked for me is removing the projects' *.csproj.user file.. Apparently it had some obsolete configuration in it. Lost 4 hours trying to figure it out..

Comments

1

I've experienced the same issue developing with .Net 6 but I've fixed it by installing from NuGet Packages Management Microsoft.Build.Framework.

enter image description here

Comments

0

I've faced with same issue when updated XCode/Mono components on macOS.

Solution is to update Visual Studio for Mac to latest version.

I think that issue cause in using new MSBuild tools from .NET Core 3.0 package which installed with new XCode/Mono version.

Comments

0

Thanks to those who already posted. My situation was solved by a combination of the above. I have had several version of Visual Studio: 2015, 2017, 2019. At some point the version of MSBUILD went from 15.1 to 15.9, and I solved this issue by updating the C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\devenv.exe.config file to point to the 15.9 library. Here is an example of one of the entries:

<dependentAssembly> <assemblyIdentity name="Microsoft.Build.Utilities.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/> <bindingRedirect oldVersion="2.0.0.0-99.0.0.0" newVersion="15.9.0.0"/> <codeBase version="15.9.0.0" href="..\..\MSBuild\15.0\Bin\Microsoft.Build.Utilities.Core.dll" /> </dependentAssembly> 

1 Comment

your example seems to have vanished.
0

I did a restart, following which I found that the local web service I have been running was blocked by another process which had taken that port. I checked the process running and and killed the process using TCPView and all seemed to start working again.

Comments

0

I had this part in my web.config and simply removed it and then it start working :)

<compilation debug="true" targetFramework="4.5.2"> <assemblies> <add assembly="Microsoft.Build.Framework, Version=14.0.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A"/> </assemblies> </compilation> 

Comments

0

Calling "MSBuildLocator.RegisterDefaults();" before DLLs are accessed worked for me.

Comments

0

Problem: Could not load file or assembly 'Microsoft.Build.Framework...

Solution: I had Microsoft.Build.Framework Nuget package referenced in my project and setting the reference for this NuGet package's Copy Local to True, issue was resolved for me.

Comments

0

I had to install visual studio with the .NET cross-platform development option. I did also get universal windows platform development too

https://learn.microsoft.com/en-us/visualstudio/install/install-visual-studio?view=vs-2022

Comments

0

On macOS with .NET 6, I started seeing this error after upgrading form 6.0.1 to 6.0.2. The fix is to uninstall and reinstall dotnet-ef cli:

dotnet tool uninstall --global dotnet-ef dotnet tool install --global dotnet-ef 

Comments

0

The OP doesn't include any of the stack trace as part of the exception, but in my case there was a reference in the call stack to my version of the DbContext class.

In the constructor I check the environment to see if we're running on Live. This is because I don't want to throw exceptions if the migrations aren't up to date.

However, in order to do this check it looks up a custom section of the web.config. And, during run time this code creates an "instance" of this custom section, so that the environment can be referred to in various areas of the code.

I don't know whether it's the custom section of the web.config or the way the static "instance" is created in my code, but it seems that this is the root of my exception.

Wrapping it in a #if !DEBUG statement ensures that the PackageManager doesn't trigger this code (which is unnecessary anyway) and I no longer get the exception.

enter image description here

My recommendation would be to strip back your DbContext. If you are using a custom constructor, empty it and test whether it works.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.