Could not load file or assembly 'Microsoft.Build.Framework'(VS 2017)

Question

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.`

Enteron

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". – Ber

Install Microsoft build tools – Charlsiecharlton

Answer 1

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.

Hulett

Yes, it would appear that "Turn-It-Off-And-On-Again" is the correct path to resolution in this case. – Simmon

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. – Parnassus

It happens everytime after a migration now and it requires a full PC reboot to work. – Uro

I have tried every of the proposed solutions. None of them seems to permanently solve the problem. I have to keep restarting Visual Studio. – Khadijahkhai

This is an open issue in Github here github.com/aspnet/EntityFramework6/issues/382 – Mcglone

Thanks for the info. I'm getting this exact error on Azure DevOps Build pipeline. Any suggestions on how to flick it off and on there? – Flesh

This exact same error will be emitted in Azure DevOps Build pipeline if using old version of NuGet. I had 4.4.1 and the fix was to upgrade into 5.5.0. – Flesh

Answer 2

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.

Doorstep

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. – Kittie

Thanks Corey. This fixed it for me too. – Pleonasm

Upgraded from 4.3.0 to 5.6 on my TeamCity. This fixed my issue. Thanks! – Glialentn

This was it. Thanks a bunch! Went from 4.4.1 to 5.4.0. – Canvasback

@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. – Groomsman

@ElderSmash That was exactly my problem and solution to, thanks! – Solace

nuget.exe update -self is another variation that may work – Climb

@Groomsman it looks like version 2 of the installer defaults to 4.1.0 by default. The tool installer seemed a bit complicated so i just went back to installer version 1 that let me specify the version learn.microsoft.com/en-us/azure/devops/pipelines/tasks/package/… – Impaction

This is why I love stackoverflow. I messed with this for hours trying to find why it would build. I've tried everything. Changing it to a new version of nuget fixed it right away. – Unscathed

This was my problem too. An old version of nuget.exe being used with newer Visual Studio tools – Thoroughfare

Answer 3

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\.

Schou

I am using Visual Studio Professioal should I also do the same. I am getting this error multiple times? – Wellgroomed

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. – Uro

I am using 2017 Pro and this fixed the issue for me. +1 – Irrepealable

I thought this has solved the problem but it happened again. I have VS 2017 Community version 15.5.4 – Khadijahkhai

Note that if you update VS2017 after making this fix, you might have to update devenv.exe.config again – Remonaremonetize

This answer just helped me for a second time - after updating VS2017 you need to do this again as @MikePeterson says. – Refrigerate

Another possible cause of this problem is that there is some Directory.SetCurrentDirectory code in your project and that Visual Studio is starting your project at design time. For example, if it is a WebSite project and Visual Studio is loading it in its process at design time. – Remonaremonetize

Worked for me /w VS 2017 Professional. Thanks a lot for this info. – Perform

Not working for me. Do i have to restart the computer for this to reflect? – Maintopmast

Answer 4

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"

4. 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.

Penstemon

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. – Threecolor

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/… – Irresoluble

Answer 5

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.

Ruction

Updating the used nuget version was also the way to correct the problem for me. – Enclosure

by upgrading Nuget version to 5.4.0, error is resolved in azure pipeline – Rhinarium

Answer 6

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.

Prajna

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. – Moreville

this was the issue for me. I had v15 and it wanted v14 – Orlan

Answer 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.

Staton

Answer 8

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.

Riemann

Answer 9

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

Suggest using Process Explorer

Anodyne

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. – Distraint

Answer 10

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

Tallulah

Answer 11

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

Fivespot

Answer 12

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.

Numerator

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

Answer 13

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

Edacity

Unfortunately not for me – Fowl

Answer 14

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..

Udelle

Answer 15

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

Bindman

Answer 16

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>

Fausta

your example seems to have vanished. – Brouhaha

Answer 17

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.

Interlaminate

Answer 18

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.

Mazard

Answer 19

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>

Performative

Answer 20

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

Litre

Answer 21

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.

Links

Answer 22

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

Washbasin

Answer 23

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

Culverin

Answer 24

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.

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

Dogger