ef6: Add-Migration and Update-Database fail because of attempt to load assembly Microsoft.Build.Framework

With VS2017 15.4 or 15.5 (Preview), I regularly get a fail when adding or applying migrations due to the error 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.

The result from e.g. Update-Database is

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'
   at xxxxxx.Migrations.Configuration..ctor()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Data.Entity.Migrations.Utilities.MigrationsConfigurationFinder.FindMigrationsConfiguration(Type contextType, String configurationTypeName, Func`2 noType, Func`3 multipleTypes, Func`3 noTypeWithName, Func`3 multipleTypesWithName)
   at System.Data.Entity.Migrations.Design.ToolingFacade.BaseRunner.FindConfiguration()
   at System.Data.Entity.Migrations.Design.ToolingFacade.BaseRunner.GetMigrator()
   at System.Data.Entity.Migrations.Design.ToolingFacade.UpdateRunner.RunCore()
   at System.Data.Entity.Migrations.Design.ToolingFacade.BaseRunner.Run()

Obviously my class library and main project do not include any references to MSBuild Framework and the update does work at runtime.

Closing VS and re-opening then running the command before doing anything else sometimes seems to resolve the issue. I did find a proposed solution online which involved editing DevEnv.exe.config and replacing the relative path for the codebase element with an absolute path - although this doesn’t seem to have worked in my case.

      <dependentAssembly>
        <assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="2.0.0.0-99.0.0.0" newVersion="15.1.0.0" />
        <codeBase version="15.1.0.0" href="C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll" />
      </dependentAssembly>

This could be a red-herring however, as the solution said to close VS, edit the .config and then re-open which in my case seems to resolve the issue (temporarily) anyway.

Adding that section to my web.config results in a different error Loading this assembly would produce a different grant set from other instances. (Exception from HRESULT: 0x80131401)

Any guidance or ideas?

N.B. this happens to me with both EF 6.1.3 and the latest 6.2.0-beta2-60920 and I am targeting net461.

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 12
Comments: 62 (9 by maintainers)

Most upvoted comments

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.

+28

linguanostra on Dec 22, 2017

I had the same issue several times and always used to resolve it with a VS restart (which is annoying, because for a big solution and when using ReSharper, Task Runner, etc. it takes a long time for everything to start).

But this time, restarts were no longer working (tried to restart it like 4 times, running Clean solution, etc.) and I was desperate as I was under time pressure and couldn’t add migrations I needed… I finally tried the suggested fix and replaced this line in devenv.exe.config:

<codeBase version="15.1.0.0" href="..\..\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll" />

With this one (I’m using VS 2017 Community 15.5.0):

<codeBase version="15.1.0.0" href="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll" />

Then I restarted VS and it started working again. When I searched for a solution on Google, it seemed that many people are having the exact same issue…

I use EF 6.2.0.

+11

tompazourek on Dec 12, 2017

If you put the MSBuild assemblies in the GAC manually, you will end up breaking Visual Studio and/or other applications.

I found this issue during an investigation of bug reports filed by users for Visual Studio, and am updating the threads I find to make a note that this is a really, really bad idea. The steps to remove these assemblies if you already installed them were given in a comment above: https://github.com/aspnet/EntityFramework6/issues/382#issuecomment-387726506

sharwell on Aug 16, 2018

It looks like having the Microsoft.Build assemblies in GAC causes other issues since VS 15.6:

https://developercommunity.visualstudio.com/content/problem/208631/unable-to-create-or-open-solution.html

That means that the only workaround that actually works might not be possible anymore in the newest versions of Visual Studio.

tompazourek on Mar 22, 2018

@MikeDPeterson Still need a solid repo case.

ajcvickers on Oct 25, 2018

Mine looks much like @Jameskmonger report so I’ll just attach a text file with the data. I’m also seeing the following version numbers for Microsoft.Build.Framework in the bind log:

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

I have been able to replicate this problem at will - though it is different than the original cause (the method I’m using to replicate is based off a project I added to my solution about 3 months ago - but this problem has been happening off and on for much longer).

My current steps to reproduce:

Create empty solution (I’ll call this BrokenSolution)
Add a .NET Framework Class Library
Add a Windows Forms App
Add a reference to the Class Library in the Forms App
Add a Windows Setup project
Add the App to the Application Folder of the Setup project
Quit Visual Studio

Now that the setup is done, the actual steps to cause the error on my computer are consistently this:

Open visual studio
Load the BrokenSolution
After it loads, use the Recent Solutions menu and load the Rock solution
Run Update-Database -Project Rock.Migrations and get error.

Oddly enough, when I do the above with that bind logging thing enabled it does NOT produce the error.

Again, this is not the same actual root cause that I have been having for the past 2 years, but this was an easy way to get that same error on demand so hopefully it help leads to the core issue.

BindLog.txt

cabal95 on Oct 8, 2018

PLEASE PLEASE fix this bug.

I also need to re-open visual studio with every update-database command 👎

suarezafelipe on Sep 26, 2018

@thecodefish You’re right, but it’s the only thing that works right now. And you don’t need to update Visual Studio as often as Microsoft releases a new update, I myself only update when they release something useful for me.

It would be good if we had some official response and acknowledgment of this issue… It looks like there are lots people dealing with the same issue (I wonder if it actually affects everybody using VS2017 and EF6 Code-First):

tompazourek on Apr 12, 2018

@cabal95 I missed that you has posted repro steps as well as the binding logs. I will try when I next get time to work on EF6.

ajcvickers on Oct 25, 2018

@sharwell I’ve actually linked to some issues caused by the GAC registration above in this thread already: https://github.com/aspnet/EntityFramework6/issues/382#issuecomment-375397800

However, for me, and probably many others (see https://github.com/aspnet/EntityFramework6/issues/382#issuecomment-380715699), it’s the only way how to make EF6 work in VS2017. There’s just no other solution I know of to fix these issues that would actually work; the only thing that works is putting those assemblies in GAC.

tompazourek on Aug 17, 2018

I had the same issue several times and always used to resolve it with a VS restart (which is annoying, because for a big solution and when using ReSharper, Task Runner, etc. it takes a long time for everything to start).

But this time, restarts were no longer working (tried to restart it like 4 times, running Clean solution, etc.) and I was desperate as I was under time pressure and couldn’t add migrations I needed… I finally tried the suggested fix and replaced this line in devenv.exe.config:
<codeBase version="15.1.0.0" href="..\..\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll" />
With this one (I’m using VS 2017 Community 15.5.0):
<codeBase version="15.1.0.0" href="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll" />
Then I restarted VS and it started working again. When I searched for a solution on Google, it seemed that many people are having the exact same issue…

I use EF 6.2.0.

This works for me

habib-developer on Mar 26, 2020

@ajcvickers here you go. Let me know if you need more details

*** Assembly Binder Log Entry  (9/27/2018 @ 10:27:54 AM) ***

The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable  C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Microsoft.VisualStudio.Web.Host.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: DisplayName = Microsoft.Build.Framework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
 (Fully-specified)
LOG: Appbase = file:///C:/Github/SparkDevNetwork/Rock/RockWeb/
LOG: Initial PrivatePath = C:\Github\SparkDevNetwork\Rock\RockWeb\bin
LOG: Dynamic Base = C:\Users\admin\AppData\Local\Temp\Temporary ASP.NET Files\root\f44d6687
LOG: Cache Base = C:\Users\admin\AppData\Local\Temp\Temporary ASP.NET Files\root\f44d6687
LOG: AppName = a8a42995
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Github\SparkDevNetwork\Rock\RockWeb\web.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Binding succeeds. Returns assembly from C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\Microsoft.Build.Framework\v4.0_4.0.0.0__b03f5f7f11d50a3a\Microsoft.Build.Framework.dll.
LOG: Assembly is loaded in default load context.

`*** Assembly Binder Log Entry  (9/27/2018 @ 10:26:40 AM) ***

The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable  C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\devenv.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: DisplayName = Microsoft.Build.Framework, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
 (Fully-specified)
LOG: Appbase = file:///C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/IDE/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = devenv.exe
Calling assembly : Microsoft.Build.Tasks.CodeAnalysis, Version=2.9.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
===
LOG: This bind starts in LoadFrom load context.
WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with Assembly.Load().
LOG: Using application configuration file: C:\Users\admin\AppData\Local\Microsoft\VisualStudio\15.0_c7e19b06\devenv.exe.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Redirect found in application configuration file: 14.0.0.0 redirected to 15.1.0.0.
LOG: Using codebase from policy file: file:///C:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/MSBuild/15.0/Bin/Microsoft.Build.Framework.dll.
LOG: Post-policy reference: Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
LOG: Switch from LoadFrom context to default context.
LOG: Binding succeeds. Returns assembly from C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll.
LOG: Assembly is loaded in default load context.

MikeDPeterson on Sep 27, 2018

I also get the same thing every time I need to work with Migrations and it causes a lot of frustration having to constantly restart Visual Studio in between each command. VS Enterprise 2017 v15.8.5 but this has been the same for the last few versions before 15.8.5 and on any PC.

PLEASE FIX IT

BaronBeans on Sep 26, 2018

@titobf Just beware when you update your VS to a newer version (when a new one gets released). It’s possible that it will break your VS (it will just start crashing during start), and you’ll need to remove the old assemblies from GAC and then add again the updated assemblies to GAC.

tompazourek on May 27, 2018

The workaround about loading the dlls into the GAC is working for me on VS 15.7.2

titobf on May 27, 2018

ditto, 15.7.2, this error is killing me, what can we do to escalate this?

twilly86 on May 27, 2018

I’m running VS 15.6.6 with EF 6.2 and it’s happening with me on a regular basis. Other than the GAC workaround (which sounds like a bad idea a royal PITA) is there something more official or is anyone looking at this?

I have my own workaround that I added to run migrations at Application_Start in my MVC project:

            var migrator = new DbMigrator(configuration);
            if (migrator.GetPendingMigrations().Any())
            {
                migrator.Update();
            }

This works all of the time (for me) but don’t like having this in my code as I want to control the migrations explicitly (however the advantage to this is that I can debug my seed methods so there is that).

Hope someone is looking at this as it sounds like it’s been around for a few months now and keeps rearing it’s ugly head.

Thanks

bsimser on May 11, 2018

@BiNZGi I’m happy to hear that. So it might be that the solution would be to have the only the latest MSBuild assemblies in GAC. I had issues when I had VS 15.5 MSBuild assemblies in GAC, and then updated to 15.6. So maybe if I removed the GAC assemblies from 15.5, then updated, and then added the 15.6 assemblies to GAC, it would work. I’ll have to try this again when I have some time.

tompazourek on Apr 11, 2018