search

dotnet / ef6

This is the codebase for Entity Framework 6 (previously maintained at https://entityframework.codeplex.com). Entity Framework Core is maintained at https://github.com/dotnet/efcore.
https://docs.microsoft.com/ef/ef6
MIT License
1.42k stars 545 forks source link

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

Closed CZEMacLeod closed 5 years ago

CZEMacLeod commented 6 years ago

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.

tompazourek commented 6 years ago

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.

linguanostra commented 6 years ago

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.

tompazourek commented 6 years ago

@linguanostra Thanks a lot, this workaround solved it for me as well.

Rob-Houweling commented 6 years ago

I have the same issue with VS2017 15.5.3. So the issue still exists with this version. Haven't tried the workarounds yet because the updates do get applied. So this error doesn't seem to block any task execution at first sight, but it is a bit of a disturbing error message.

titobf commented 6 years ago

I'm still having this issue in VS Community 15.5.7 when running "Add-Migration". I'll try some of the workarounds

tompazourek commented 6 years ago

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.

GregTerrell commented 6 years ago

We are in the midst of a significant set of db changes. The Microsoft.Build.Framework error is happening almost every update-database, but I have not seen there error on add-migration. Using Visual Studio Professional 15.6.5.

Based on comment from @tompazourek, not going to try the GAC workaround.

FYI... although the error appears, the update-database operation completed (i.e. SQL tables are changed) and _MigrationHistory has the new row.

BiNZGi commented 6 years ago

I am using Visual Studio Professional Version 15.6.5 with Entity Framework 6.2.0 and had the described problem. Applyed the GAC workaround and Update-Database works again.

Edit: Just updated to VS Version 15.6.6 and still works.

tompazourek commented 6 years ago

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

thecodefish commented 6 years ago

@BiNZGi @tompazourek The GAC workaround does work but I'd be careful with it - you'll be constantly removing and re-adding DLLs every time Microsoft release an update. The official response (when adding the MSBuild dlls to the GAC was brought up) is that this is a bad idea

tompazourek commented 6 years ago

@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):

BiNZGi commented 6 years ago

I wanted to Upgrade to Visual Studio 2017 from 15.6 to 15.7 and got the following error in Visual Studio Installer:

System.InvalidOperationException: Did not find product with ID Microsoft.VisualStudio.Product.Professional, version 15.7.27703.1, Instead found these versions: [15.6.27428.2043, 15.7.27703.2000] bei Microsoft.VisualStudio.Setup.ProductInstaller.InitializeProductAndDependencyGraph() bei Microsoft.VisualStudio.Setup.ProductInstaller.GetProductDependencyGraph(Boolean deepDetection, Boolean resetSelectedPackages) bei Microsoft.VisualStudio.Setup.ProductInstaller.GetSerializableInstalledProduct() bei Microsoft.VisualStudio.Setup.InstalledProductsProviderService.d__3.MoveNext()

I removed the above workaround putting Microsoft.Build assemblies in GAC with the following commands in Developer Command Prompt for VS 2017 run as Administrator:

gacutil /u "Microsoft.Build.Framework, Version=15.1.0.0"
gacutil /u "Microsoft.Build, Version=15.1.0.0"
gacutil /u "Microsoft.Build.Engine, Version=15.1.0.0"
gacutil /u "Microsoft.Build.Conversion.Core, Version=15.1.0.0"
gacutil /u "Microsoft.Build.Tasks.Core, Version=15.1.0.0"
gacutil /u "Microsoft.Build.Utilities.Core, Version=15.1.0.0"

The VS upgrade was succesful after the removal of the assemblies.

With the new VS version 15.7 the workaround seems not to be needed. Update-Database with my project (using EF v6.2.0) works without the error :thumbsup:

thecodefish commented 6 years ago

@BiNZGi I'm running 15.7 and the problem still exists for me, unfortunately.

bsimser commented 6 years ago

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

tompazourek commented 6 years ago

@bsimser In terms of the Update-Database command, it's also possible to execute it from the command-line tool migrate.exe included in the NuGet package. And from my experiences, it's not having these issues.

However, this issue is not only with Update-Database, I experienced these issues with Add-Migration as well, and AFAIK it's not possible to call that one from any command-line tool.

CZEMacLeod commented 6 years ago

@tompazourek @bsimser I use a variation of the GetPendingMigrations and Update technique which works because it is running in the application's context it doesn't suffer from loading the wrong assemblies etc. I think this problem is caused by the code that creates a new AppDomain to run as if it were the application but injects the wrong assembly list.

My trick is that I wrap the Update in a try catch and catch Entity.Migrations.Infrastructure.AutomaticMigrationsDisabledException

If this occurs it is because we need to call Add-Migration. At this point I call a function I wrote called GenerateMigration

Private Shared Sub GenerateMigration(config As DbMigrationsConfiguration,
                                     contextType As Type,
                                     dependencyResolver As IDbDependencyResolver,
                                     outputDirectory As String,
                                     migrationName As String)
    Dim scaffolder = New Design.MigrationScaffolder(config) With {
                    .Namespace = config.MigrationsNamespace
                    }

    Dim migration = scaffolder.Scaffold(migrationName)

    Dim userCodeExtension = migration.Language
    Dim designerCodeExtension = "Designer." & userCodeExtension

    Dim migName = System.IO.Path.Combine(config.MigrationsDirectory, migration.MigrationId)

    Log.ErrorFormat("Writing new migration files to {0} as {1}", outputDirectory, migName)

    migration.UserCode.WriteObjectToDisc(migName, outputDirectory, userCodeExtension, contextType, True)
    migration.DesignerCode.WriteObjectToDisc(migName, outputDirectory, designerCodeExtension, contextType, True)

    Using ms = New System.IO.MemoryStream()

        Using writer As IResourceWriter = New ResXResourceWriter(ms)

            For Each resource In migration.Resources
                writer.AddResource(resource.Key, resource.Value)
                If resource.Key = "Target" Then
                    Dim mc = New Edm.ModelCompressor()
                    Dim edmx as System.Xml.Linq.XDocument = mc.Decompress(Convert.FromBase64String(resource.Value))
                    edmx.Save(System.IO.Path.Combine(outputDirectory,migName & "_Target.edmx"))
                End If
            Next

            writer.Generate()

            ms.Seek(0, System.IO.SeekOrigin.Begin)
            ms.WriteObjectToDisc(migName, outputDirectory, "resx", contextType, True)

        End Using ' This will close the memory stream

    End Using
End Sub

I have some code that uses the contextType's assembly version number as the migrationName and hard code the outputDirectory to a location on my developer machine as well as only making the call if the machine name is my dev machine so it doesn't run in production.

System.Data.Entity.Migrations.Edm.ModelCompressor is not accessible outside the EF assembly so I have to embed a copy of the code.

This is only needed to write out the edmx file which is not actually required but it is useful if you want to check the model visually and use code first.

I'm sure this could be neater and I apologise to all the C# fans that it is written in VB ;)

Hope this helps the people struggling with this.

rafael-yure commented 6 years ago

I'm using VS 2017 15.7.2 (updated it today) and this error still persists. Every now and then I have to close VS and edit devenv.exe.config. It's pretty annoying.

twilly86 commented 6 years ago

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

titobf commented 6 years ago

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

tompazourek commented 6 years ago

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

sharwell commented 6 years ago

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

tompazourek commented 6 years ago

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

thecodefish commented 6 years ago

I thought i'd add another snippet of info in case it helps. I've just tried running a fresh install of Visual Studio Community 2017 (15.8.2) with no 3rd party extensions installed (e.g. no ReSharper etc) and the problem still occurs. So the problem appears to be something in core VS or entity framework (not specific to any edition) and not related to interactions with any 3rd party extensions.

Jameskmonger commented 6 years ago

On a fresh installation of Visual Studio Enterprise 2017, version 15.7.5, I am getting this error. I have no third party extensions installed.

I am unable to add any migrations to my project and am completely blocked by this bug

jfreal commented 5 years ago

I'm having the same issue with 15.8.2. This is a debilitating issue and its very difficult to do any EF work.

suarezafelipe commented 5 years ago

PLEASE PLEASE fix this bug.

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

BaronBeans commented 5 years ago

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

MikeDPeterson commented 5 years ago

I've been using the GAC fix for a while (like @tompazourek says, it is the only way to make EF6 work in VS2017). Just make sure to re-run it after updating VS. It really seems like this bug is not going to be fixed any time soon. If and when they fix it, it is pretty easy to undo the GAC Fix.

ajcvickers commented 5 years ago

A quick update on this: I have tried to reproduce this multiple times on multiple versions of VS and so far have not been able to make it fail. I just tried again with 15.8.5 and it still works for me. So the next steps are to try to figure where the bad Microsoft.Build.Framework is coming from. Unfortunately, I don't have any good leads on this. It could be related to the workloads installed into VS, or possible the application type. For the latter, if someone could post a simple solution/project that reproduces for them, then I'll try that. If that works, then it looks like it must be something in the VS install. The workloads being used when this happens would be useful information.

gabbsmo commented 5 years ago

@ajvickers I am using the Azure, Office and Web workloads VS 2017 1.5.8. Application is based on the MVC 5 template in VS 2015. I also have Web API 2 code in it. I am not able to post code at this time.

MikeDPeterson commented 5 years ago

@ajcvickers we have a public project that might help you reproduce it. The Rock.sln at https://github.com/SparkDevNetwork/Rock. It is a WebForms project. The EF project is Rock.Migration. Several people have had this problem on our team. Let me know if that helps, or if you need more details.

BiNZGi commented 5 years ago

Someone who has the problem should try reproduce it with a sample application like Get Started with ASP.NET Core and Entity Framework 6 from the Docs, check the link to the solution in the article.

The mentioned sample application is running without errors on my VS 2017 Pro Version 18.8.5

ajcvickers commented 5 years ago

@MikeDPeterson Thanks. When you say "several people have had this problem" does that mean that not everybody has this problem? If so, any chance you could figure out what is different for the people that have the problem?

cabal95 commented 5 years ago

@ajcvickers I'm one of the people @MikeDPeterson mentioned. Anytime I try to run Update-Database or the rare times I run Add-Migration I get that error. The only way I've been able to get around it is to restart VS, re-open the solution and make the very first thing I do is run the Add-Migration or Update-Database command. As best I can tell something else that is happening in VS after running for a bit triggers the problem.

I'm on VS 2017 Community 15.8.5 (though I just updated today). I've had this happen through various versions of VS 2017. As far as I know, the only non-standard extensions I have is a "generate new guid" extension and the GhostDoc extension.

To be fair, usually when I'm to the point of running Update-Database it's because I've already been running the project for a few minutes and hit a page that touched a property that doesn't exist yet. For Add-Migration I've usually been coding for at least an hour with multiple build and runs and then am ready to actually build the migration from the manual SQL changes I've made. So that is part of what has made it not worth it for me to try and track down yet, I usually only run into it when VS has been running for a good hour or more and who knows whats been happening during that time.

ajcvickers commented 5 years ago

@cabal95 Thanks for the detailed reply.

MikeDPeterson commented 5 years ago

@ajcvickers I asked around and so far have found 5 people on our team that have the problem and 1 that doesn't. All 5 have SSMS 17.x installed, and the 1 has the older SSMS 2014. That could just be a coincidence so I'll see if I can find out anything else.

ajcvickers commented 5 years ago

@MikeDPeterson Thanks. I had 17.8 installed and also tried updating to 17.9--still no failures for me.

gabbsmo commented 5 years ago

@mikedpetersson @ajcvickers I have SSMSS 17 as well.

ajcvickers commented 5 years ago

Can people who are seeing this error try the following:

On my machine, I see two loads:

*** Assembly Binder Log Entry  (9/27/2018 @ 8:31:43 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\Community\MSBuild\15.0\Bin\MSBuild.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: DisplayName = Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
 (Fully-specified)
LOG: Appbase = file:///C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/MSBuild/15.0/Bin/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = MSBuild.exe
Calling assembly : Microsoft.NET.Build.Extensions.Tasks, Version=2.1.400.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:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.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: 15.1.0.0 redirected to 15.1.0.0.
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\Community\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll.
LOG: Assembly is loaded in default load context.
*** Assembly Binder Log Entry  (9/27/2018 @ 8:31:43 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\Community\MSBuild\15.0\Bin\MSBuild.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/Community/MSBuild/15.0/Bin/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = MSBuild.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:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\MSBuild.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: 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\Community\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll.
LOG: Assembly is loaded in default load context.
MikeDPeterson commented 5 years ago

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

image

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

image

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

image

Jameskmonger commented 5 years ago

@ajcvickers:

*** Assembly Binder Log Entry  (01/10/2018 @ 15:35:28) ***

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable  D:\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=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
 (Fully-specified)
LOG: Appbase = file:///D:/Code/Foo/Migrations/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: D:\Code\Foo\WorkerRoleRunner\tmpAE42.tmp
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
LOG: The same bind was seen before, and was failed with hr = 0x80070002.
ERR: Unrecoverable error occurred during pre-download check (hr = 0x80070002).
*** Assembly Binder Log Entry  (01/10/2018 @ 15:35:28) ***

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  D:\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=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
 (Fully-specified)
LOG: Appbase = file:///D:/Code/Foo/Migrations/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: D:\Code\Foo\WorkerRoleRunner\tmpAE42.tmp
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Found assembly by looking in the GAC.
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  (01/10/2018 @ 15:31:39) ***

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  D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\MSBuild.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: DisplayName = Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
 (Fully-specified)
LOG: Appbase = file:///D:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/MSBuild/15.0/Bin/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = MSBuild.exe
Calling assembly : Microsoft.NET.Build.Extensions.Tasks, Version=2.1.200.62827, 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: D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\MSBuild.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: 15.1.0.0 redirected to 15.1.0.0.
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 D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll.
LOG: Assembly is loaded in default load context.
*** Assembly Binder Log Entry  (01/10/2018 @ 15:31:39) ***

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  D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\MSBuild.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:///D:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/MSBuild/15.0/Bin/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = MSBuild.exe
Calling assembly : Microsoft.Build.Tasks.CodeAnalysis, Version=2.8.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: D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\MSBuild.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: 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 D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll.
LOG: Assembly is loaded in default load context.
*** Assembly Binder Log Entry  (01/10/2018 @ 15:29:59) ***

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  D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\MSBuild.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:///D:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/MSBuild/15.0/Bin/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = MSBuild.exe
Calling assembly : NuGet.Build.Tasks, Version=4.7.0.5, 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: D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\MSBuild.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: Switch from LoadFrom context to default context.
LOG: Binding succeeds. Returns assembly from D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll.
LOG: Assembly is loaded in default load context.
*** Assembly Binder Log Entry  (01/10/2018 @ 15:27:25) ***

The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.

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

=== Pre-bind state information ===
LOG: DisplayName = Microsoft.Build.Framework, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
 (Fully-specified)
LOG: Appbase = file:///D:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\ServiceHub\Services\Microsoft.VisualStudio.ThreadedWaitDialog\Microsoft.VisualStudio.ThreadedWaitDialog.dll.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: The same bind was seen before, and was failed with hr = 0x80070002.
ERR: Unrecoverable error occurred during pre-download check (hr = 0x80070002).
*** Assembly Binder Log Entry  (01/10/2018 @ 15:27:46) ***

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  D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\ServiceHub\Hosts\ServiceHub.Host.CLR.x86\ServiceHub.RoslynCodeAnalysisService32.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: DisplayName = Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
 (Fully-specified)
LOG: Appbase = file:///D:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/IDE/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Users\JamesMonger\AppData\Local\Microsoft\VisualStudio\15.0_5fa4e03d\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: Binding succeeds. Returns assembly from D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll.
LOG: Assembly is loaded in default load context.
*** Assembly Binder Log Entry  (01/10/2018 @ 15:27:39) ***

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  D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\ServiceHub\Hosts\ServiceHub.Host.CLR.x86\ServiceHub.RoslynCodeAnalysisService32.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:///D:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/IDE/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Users\JamesMonger\AppData\Local\Microsoft\VisualStudio\15.0_5fa4e03d\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: Binding succeeds. Returns assembly from D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll.
LOG: Assembly is loaded in default load context.
*** Assembly Binder Log Entry  (01/10/2018 @ 15:26:57) ***

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  D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\ServiceHub\Hosts\ServiceHub.Host.CLR.x86\ServiceHub.SettingsHost.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:///D:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\ServiceHub\Services\Microsoft.Developer.Settings\Microsoft.Developer.Settings.dll.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Found assembly by looking in the GAC.
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  (01/10/2018 @ 15:26:52) ***

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  D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\ServiceHub\Hosts\ServiceHub.Host.CLR.x86\ServiceHub.VSDetouredHost.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: DisplayName = Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
 (Fully-specified)
LOG: Appbase = file:///D:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/IDE/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Users\JamesMonger\AppData\Local\Microsoft\VisualStudio\15.0_5fa4e03d\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: 15.1.0.0 redirected to 15.1.0.0.
LOG: Using codebase from policy file: file:///D:/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: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///D:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/MSBuild/15.0/Bin/Microsoft.Build.Framework.dll.
LOG: Assembly download was successful. Attempting setup of file: D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: Microsoft.Build.Framework, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
LOG: Binding succeeds. Returns assembly from D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll.
LOG: Assembly is loaded in default load context.
*** Assembly Binder Log Entry  (01/10/2018 @ 15:27:03) ***

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  D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\ServiceHub\Hosts\ServiceHub.Host.CLR.x86\ServiceHub.VSDetouredHost.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: DisplayName = Microsoft.Build.Framework, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
 (Fully-specified)
LOG: Appbase = file:///D:/Program Files (x86)/Microsoft Visual Studio/2017/Enterprise/Common7/IDE/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Users\JamesMonger\AppData\Local\Microsoft\VisualStudio\15.0_5fa4e03d\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: Binding succeeds. Returns assembly from D:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll.
LOG: Assembly is loaded in default load context.
cabal95 commented 5 years ago

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:

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:

  1. Create empty solution (I'll call this BrokenSolution)
  2. Add a .NET Framework Class Library
  3. Add a Windows Forms App
  4. Add a reference to the Class Library in the Forms App
  5. Add a Windows Setup project
  6. Add the App to the Application Folder of the Setup project
  7. Quit Visual Studio

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

  1. Open visual studio
  2. Load the BrokenSolution
  3. After it loads, use the Recent Solutions menu and load the Rock solution
  4. 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

DPPWurd commented 5 years ago

Running into the same issue here after a VS 2017 update. Closing and reopening works at the moment.

LeonardoX77 commented 5 years ago

same issue, please fix asap!

MikeDPeterson commented 5 years ago

@ajcvickers Are you still in need of a more solid repro case, or do you have enough information to start working on a fix?

ajcvickers commented 5 years ago

@MikeDPeterson Still need a solid repo case.

cabal95 commented 5 years ago

@ajcvickers Did my case above not work for you to reproduce the problem?

ajcvickers commented 5 years ago

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

cabal95 commented 5 years ago

@ajcvickers Got it. Let me know if you can't reproduce from my steps above and I can see about building up a big fat zip file that has everything needed to reproduce. Didn't want to do that unless necessary as our Rock repo is pretty big.

avonwyss commented 5 years ago

I came across this issue while searching for a solution for the same error message in a slightly different context (not EF6 but a MSBuild task). Having solved it in my case I think it may be related.

In my case the problem was related to the code spinning up a separate AppDomain to do some reflection. Being a MSBuild task, this code uses some MSBuild types, but it could not find the MSBuild assemblies when running in the new AppDomain. My solution was to add MSBuildLocator.RegisterDefaults(); (as outlined in https://docs.microsoft.com/en-us/visualstudio/msbuild/updating-an-existing-application?view=vs-2017 ) into the static constructor of the MarshalByRefObject descendant being used to perform the reflection, this made the load successful.

I suppose that EF Migrations are also doing reflection, so I suspect that this issue may have a similar cause. Maybe this helps... ;)