Update to 15.8.0 - projects won't load

Barry Durand reported Aug 15, 2018 at 01:42 AM

Invalid static method invocation syntax: "

[Microsoft.Build.Utilities.ToolLocationHelper]::GetPathToStandardLibraries($(TargetFrameworkIdentifier), $(TargetFrameworkVersion), $(TargetFrameworkProfile), $(PlatformTarget), $(TargetFrameworkRootPath), $(TargetFrameworkFallbackSearchPaths))

". Method '

Microsoft.Build.Utilities.ToolLocationHelper.GetPathToStandardLibraries
' not found.

From:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets

Not a single solution is capable of loading projects anymore. Worked fine immediately prior to the update.
Pretty infuriating.

I have:
1. Decompiled Microsoft.Build.Utilities.Core and confirmed the function signature exists to match the .targets script file
2. used the Visual Studio Installer to "Repair" visual studio. It downloaded the entire package, and reinstalled it.

Same ... explitive ... problem.

Add comment Show 22

Add Comment

Carl Brindle · Aug 15, 2018 at 11:35 AM 0

I also have this issue and have a submitted a technical support ticket to Microsoft as this is causing our company critical downtime to our developers

Barry Durand Carl Brindle · Aug 15, 2018 at 03:06 PM 0

Same here, it's unbelievable. I'm having to develop inside a virtual machine to get the job done right now.

If I were to take a wild guess, I'd say vstudio is running the wrong library somehow. But I don't have time right now to debug [devenv.exe] to see what it has loaded in modules.
If that's the case, it may just be a system PATH issue, or load precedence issue.

If I can find more info I will most certainly post it here.I highly suspect microsoft won't be providing assistance in a timely manor. Rather, we should see the generic "we need more info, and are willing to quickly close your topic as "Won't Fix"" standard reply.

Rainer Sigwald [MSFT] · Aug 15, 2018 at 03:38 PM 0

Thank you for the report. If you're observing this problem, can you please let us know the output of

gacutil /l Microsoft.Build.Utilities.Core

from a Developer Command Prompt for VS 2017?

If you're able to, I would also appreciate a fuslogvw trace of the load event for Microsoft.Build.Utilities.Core.dll. https://docs.microsoft.com/en-us/dotnet/framework/tools/fuslogvw-exe-assembly-binding-log-viewer has instructions for collecting those logs.

matthew.j.clark · Aug 15, 2018 at 04:24 PM 0

after runing the gacutil command I get:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise>gacutil /l Microsoft.Build.Utilities.Core Microsoft (R) .NET Global Assembly Cache Utility. Version 4.0.30319.0 Copyright (c) Microsoft Corporation. All rights reserved. The Global Assembly Cache contains the following assemblies: Microsoft.Build.Utilities.Core, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL Microsoft.Build.Utilities.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL Number of items = 2

WHen running fuslogvw, I am presented with a blank screen, and the settings page says log disabled and is unclickable.
Image here: https://imgur.com/a/Vu5CGLB

I have re-installed VS completely and still have the issue.

CFan · Aug 16, 2018 at 01:57 AM 0

I was wrong, solution above is right.

Killer, Helmut (ext) (HC DI MR R&D SYS ART) CFan · Aug 17, 2018 at 03:01 PM 0

Worked for me but additionally needed also gacutil the other 4 dlls in the MSBuild\15.0\Bin

Rainer Sigwald [MSFT] CFan · Aug 20, 2018 at 03:12 PM 0

Please do not install Microsoft.Build.* in your GAC. That will work for any single version of Visual Studio but will cause this problem again on the next Visual Studio update that includes MSBuild.

Marcel Fasseur Rainer Sigwald [MSFT] · Aug 21, 2018 at 09:45 AM 0

But what do you suggest if this is the solution? all my projects are broken. and this fixed it.

Show more comments

Krisztian Kocsis · Aug 26, 2018 at 10:09 AM 0

Uninstalling the specified assemblies didn't help me, here is my output of EnumerateMSBuild.ps1msbuild-versions.txt

msbuild-versions.txt (319.7 kB)

Tamás Szűcs · Aug 27, 2018 at 03:22 PM 0

same here: with all my non-dotnet core projects:

UnitTests.csproj : error : Invalid static method invocation syntax: "[Microsoft.Build.Utilities.ToolLocationHelper]::GetPathToStandardLibraries($(TargetFrameworkIdentifier), $(TargetFrameworkVersion), $(TargetFrameworkProfile), $(PlatformTarget), $(TargetFrameworkRootPath), $(TargetFrameworkFallbackSearchPaths))". Method 'Microsoft.Build.Utilities.ToolLocationHelper.GetPathToStandardLibraries' not found. Static method invocation should be of the form: $([FullTypeName]::Method()), e.g. $([System.IO.Path]::Combine(`a`, b)). C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets

gac uninstall solution did not uninstall anything, and the error persists. Going to uninstall reinstall VS, but its pretty bad.

Rainer Sigwald [MSFT] Tamás Szűcs · Aug 27, 2018 at 04:10 PM 0

Can you please download and run this powershell script and share the results?

Andy Gerlicher [MSFT] · Sep 12, 2018 at 07:21 PM 0

Thank you for your feedback! We have determined that this issue is not a bug.

Jorge Castillo Andy Gerlicher [MSFT] · Sep 28, 2018 at 06:22 PM 2

This issue is completely a bug. It is happening when you upgrade to VS 2017 15.8.5 from within VS in my case. An upgrade should not corrupt an existing working installation.

Andy Gerlicher [MSFT] Jorge Castillo · Oct 01, 2018 at 06:02 PM 0

The reason I marked the issue not a bug is there's not much we can do about this, by design. The design of the global assembly cache (GAC) is to load all assemblies from there first. So if you add MSBuild to the GAC, Visual Studio can no longer ever load MSBuild assemblies from the MSBuild install path. Once these get out of sync, behavior gets unpredictable. Options we've discussed:

1) Install script to remove MSBuild from the GAC during Visual Studio setup/upgrade. This isn't great because it's undoing something that the user explicitly did. We also don't have a great mechanism to do this.

2) Change the assembly version on every release. NuGet does this for this reason, but for us it would mean any consumers would have to update binding redirects in their application for every release. This would be really painful for a small number of customers and likely not something we should do.

3) Add some detection and warn the user that MSBuild assemblies were loaded from the GAC and therefore will experience unexpected behavior and a link to instructions to remove it.

We are leaning towards #3, but haven't implemented this yet.

I hope this helps explain why I marked it not a bug, even though it is an unfortunate scenario. Ultimately MSBuild should never be in the GAC (for v15+). Or if you do, be sure to remove/readd it everytime there's a Visual Studio update (and side by side versions could still be broken even doing that).

James Wilkins · Oct 11, 2018 at 10:29 PM 1

I have this same problem also. I just updated to VS 15.8 (the most recent version as for this moment) and it broke VS - none of my solutions will load, so thanks for nothing. I tried the gacutil solution as mentioned, and restarted, but nothing gets uninstalled, so perhaps the issue is elsewhere. VS gives me enough headaches as it is, I don't need to spend another 2 hours installing VS because MS screwed something up again. Whatever productivity I get from VS it's always offset by bugs and slow IDE issues, then they say "it's by design/not a bug" and/or "won't fix" - such a lazy response. If I have to install VS again I'm dropping VS from the multi-million $ company I work for and switching to somerthing else that doesn't waste my time.

James Wilkins James Wilkins · Nov 21, 2018 at 08:14 PM 0

I forgot to give an update on this: I fixed it myself. For the record, I got this working by uninstalling VS 2015 and restarting the system. I have projects I am not yet authorized to upgrade to 2017, but I'm working on 2017 projects at the moment and don't need 2015 yet. It's obvious there is a conflict somewhere since 2017 is now working after the uninstall.

Baris Acar · Nov 21, 2018 at 01:39 PM 0

@Rainer Sigwald [MSFT], @Andy Gerlicher [MSFT] - Can you give a clear description of what you believe has happened to cause this problem, please?

The implication from Andy Gerlicher's comment, "So if you add MSBuild to the GAC, Visual Studio can no longer ever load MSBuild assemblies from the MSBuild install path" - is that this problem is caused by me explicitly adding the MSBuild assemblies to my GAC to cause this problem. However, I am not convinced that I have done this, and nobody on my team is aware of any shared scripts or anything that might have done this.

How certain are MSFT that the v14 vis studio installer didn't do this? (the version I found in my gac is 14.0.0.0)?

Many thanks

Rainer Sigwald [MSFT] Baris Acar · Nov 21, 2018 at 03:49 PM 0

The VS 2015 installer did install MSBuild assemblies versioned 14.0.0.0 to the GAC. As part of the Visual Studio-wide effort to improve the installer and side-by-side experience, the VS 2017 installer does not install MSBuild assemblies versioned 15.1.0.0 to the GAC. They are loaded from the Visual Studio installation instead.

If MSBuild 15.1 is GACed, it overrides the version installed in Visual Studio, meaning that an update to Visual Studio gets ignored, because the GAC has loader priority. That causes the problem that resulted in this behavior, because there were coordinated changes to MSBuild but only some of them are seen.

If running the gacutil /u commands solved your problem, something installed MSBuild to your GAC. If you discover what that was, I'd like to know so I can reach out and get that stopped. I've already commented on a few Stack Overflow and GitHub posts warning against it.

If running the gacutil /u commands does not resolve your problem, you probably have a different issue. If you're in that situation, please file new feedback so we can investigate.

Baris Acar Rainer Sigwald [MSFT] · Nov 22, 2018 at 04:01 PM 0

I didn't have it in the gac.

I realised that my route to this error message was different. I'm not having trouble building/loading projects -- I get this error when I execute code that uses Microsoft.Build.* nuget libraries.

Use of the Microsoft.Build.Locator library resolved my issue.
It still seems surprising to me that before we made this change, when we referenced the nuget Microsoft.Build. assemblies directly at runtime it partially used those assemblies and partially fell through to the locally installed MSBuild (the .targets file from the installed 15.8 MSBuild was being invoked from the Microsoft.Build. v15.7 nuget packages, which led to the conflict above). I would have thought that when you reference a specific version of the Microsoft.Build.* packages, it uses that version of the msbuild stack throughout.

Best Solution

Solution by matthew.j.clark · Aug 15, 2018 at 04:32 PM

I got an email from Rainer Sigwald [MSFT] saying to run the below gac commands. This fixed the issue. Thanks!
gacutil /u "MSBuild, Version=15.1.0.0"

gacutil /u "Microsoft.Build.Conversion.Core, 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.Tasks.Core, Version=15.1.0.0"

gacutil /u "Microsoft.Build.Utilities.Core, Version=15.1.0.0"

gacutil /u "Microsoft.Build.Framework, Version=15.1.0.0"

Add comment Show 11 · Share

Add Comment

Daniel Edwards · Aug 15, 2018 at 04:39 PM 1

Fantastic, works great.

Carl Brindle · Aug 15, 2018 at 06:06 PM 0

Perfect solution!

Tom Spilman · Aug 15, 2018 at 08:06 PM 1

Too bad the search didn't show this issue to me before i uninstalled VS2017 and reinstalled it to discover that it didn't solve the issue.

The gacutil technique above solved it.

Henrik Sommerfeld · Aug 16, 2018 at 06:11 AM 0

Worked after reboot for me.

Simon Laszcz · Aug 16, 2018 at 08:59 AM 0

Worked for me. However, the update reintroduced a problem when running update-database from PMC.

PM> update-database 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 Litecast.WebAPI.DAL.LitecastWebAPIContext..ctor(String connectionString) at Litecast.WebAPI.DAL.LitecastWebAPIContext..ctor() in C:\BitBucket\elsie\Elsie.WebAPI\DAL\LitecastWebAPIContext.cs:line 37 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Data.Entity.Infrastructure.DbContextInfo.CreateInstance() at System.Data.Entity.Infrastructure.DbContextInfo..ctor(Type contextType, DbProviderInfo modelProviderInfo, AppConfig config, DbConnectionInfo connectionInfo, Func`1 resolver) at System.Data.Entity.Migrations.DbMigrator..ctor(DbMigrationsConfiguration configuration, DbContext usersContext, DatabaseExistenceState existenceState, Boolean calledByCreateDatabase) at System.Data.Entity.Migrations.DbMigrator..ctor(DbMigrationsConfiguration configuration) at System.Data.Entity.Migrations.Design.ToolingFacade.BaseRunner.GetMigrator() at System.Data.Entity.Migrations.Design.ToolingFacade.UpdateRunner.Run() at System.AppDomain.DoCallBack(CrossAppDomainDelegate callBackDelegate) at System.AppDomain.DoCallBack(CrossAppDomainDelegate callBackDelegate) at System.Data.Entity.Migrations.Design.ToolingFacade.Run(BaseRunner runner) at System.Data.Entity.Migrations.Design.ToolingFacade.Update(String targetMigration, Boolean force) at System.Data.Entity.Migrations.UpdateDatabaseCommand.<>c_DisplayClass2.<.ctor>b_0() at System.Data.Entity.Migrations.MigrationsDomainCommand.Execute(Action command) 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.

This was fixed by re-applying the following gac commands (from StackOverflow)

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"

Zaid Ajaj · Aug 17, 2018 at 08:19 AM 0

Running these commands didn't work for me. I am still unable to load the projects

Rainer Sigwald [MSFT] Zaid Ajaj · Aug 17, 2018 at 02:17 PM 0

Can you please download and run this powershell script and share the results? Are you seeing this exact "Invalid static method invocation syntax" error, or something different?

Killer, Helmut (ext) (HC DI MR R&D SYS ART) · Aug 21, 2018 at 08:11 AM 0

Did not work for me. Had to add it to gac again.

Rainer Sigwald [MSFT] Killer, Helmut (ext) (HC DI MR R&D SYS ART) · Aug 21, 2018 at 02:46 PM 0

How did it not work? Can you please download and run this powershell script and share the results after removing the assemblies from the GAC and reproducing the failure?

Maicon Carlos Pereira (TI MTZ) · Aug 21, 2018 at 04:08 PM 0

Thanks! This work for me.

gacutil /u "MSBuild, Version=15.1.0.0"

gacutil /u "Microsoft.Build.Conversion.Core, 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.Tasks.Core, Version=15.1.0.0"

gacutil /u "Microsoft.Build.Utilities.Core, Version=15.1.0.0"

gacutil /u "Microsoft.Build.Framework, Version=15.1.0.0"

gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Build.Framework.dll"

gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Build.dll"

gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Build.Engine.dll"

gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Build.Conversion.Core.dll"

gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Build.Tasks.Core.dll"

gacutil /i "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Build.Utilities.Core.dll"

Rainer Sigwald [MSFT] Maicon Carlos Pereira (TI MTZ) · Aug 21, 2018 at 04:12 PM 0

Please do not use gacutil /i. It will cause this problem again on the next Visual Studio update. Removing the assemblies from the GAC should be sufficient to solve this problem.

Solution by philippe.vinhais · Aug 27, 2018 at 04:06 PM

Hi guys, I've the same proble as Krisztian. I run the ps script provided by Rainer with the output put as attachment. I didn't succeed to fix this problem on my sidemsbuild-versions.txt.

Help will be really appreciated

Hi guys, I've the same proble as Krisztian. In attachment my output of the ps script msbuild-versions.txt

Add comment · Share

Add Comment

Solution by Darrell Tunnell · Aug 19, 2018 at 07:07 PM

I have some XUnit tests that I run from Test Explorer. They use the MS Build NuGet packages to build a project file at test time. These were passing before the upgrade to VS.

After the upgrade, they all started failing with the error reported in this thread.

I managed to get them passing again by updating the referenced MSBuild nuget packages from version "15.7.179" to version "15.8.166".

To replicate, create a test, pull in the package references shown below, and set these environment variables, then try and build an SDK style project.

Environment.SetEnvironmentVariable("VisualStudioVersion", "15.0"); 
Environment.SetEnvironmentVariable("VSINSTALLDIR", "C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\Community");
Environment.SetEnvironmentVariable("MSBuildSDKsPath", "C:\Program Files\dotnet\sdk\2.1.103\Sdks\");

<PackageReference Include="Microsoft.Build.Utilities.Core" Version="15.7.179" />
<PackageReference Include="Microsoft.Build.Framework" Version="15.7.179" />
<PackageReference Include="Microsoft.Build" Version="15.7.179" />
<PackageReference Include="Microsoft.Build.Tasks.Core" Version="15.7.179" />

Add comment Show 1 · Share

Add Comment

Rainer Sigwald [MSFT] · Aug 20, 2018 at 03:11 PM 0

Can you update your tests to use the Microsoft.Build.Locator package? That should make them robust to this type of change in the future

https://docs.microsoft.com/en-us/visualstudio/msbuild/updating-an-existing-application

Developer Community

Get help from our community supported forum

Update to 15.8.0 - projects won't load

Add Comment

Solutions

Add Comment

Add Comment

Add Comment

Developer Community

Get help from our community supported forum

Update to 15.8.0 - projects won't load

Add Comment

Solutions

Add Comment

Add Comment

Add Comment

Related Problems