Fody: Visual Studio 2017 RC cannot find Microsoft.Build.Framework

Cross posting from the Costura repo where I originally posted this https://github.com/Fody/Costura/issues/173

Seems that an unmodified project that is building fine in VS2015 using Costura.Fody can’t find the Microsoft Build framework and throws the following exception at compile time

Error       Fody: An unhandled exception occurred:
Exception:
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.
StackTrace:

Server stack trace: 
   at System.Signature.GetSignature(Void* pCorSig, Int32 cCorSig, RuntimeFieldHandleInternal fieldHandle, IRuntimeMethodInfo methodHandle, RuntimeType declaringType)
   at System.Reflection.RuntimeMethodInfo.FetchNonReturnParameters()
   at System.Reflection.RuntimeMethodInfo.GetParameters()
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg)

Exception rethrown at [0]: 
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at IInnerWeaver.set_Logger(ILogger value)
   at Processor.ExecuteInOwnAppDomain() in c:\ConsoleBuildAgent\work\ed448661dbb30d2e\Fody\Processor.cs:line 146
   at Processor.Inner() in c:\ConsoleBuildAgent\work\ed448661dbb30d2e\Fody\Processor.cs:line 93
   at Processor.Execute() in c:\ConsoleBuildAgent\work\ed448661dbb30d2e\Fody\Processor.cs:line 45
Source:
mscorlib
TargetSite:
Void GetSignature(Void*, Int32, System.RuntimeFieldHandleInternal, System.IRuntimeMethodInfo, System.RuntimeType)
Could not load file or assembly 'Microsoft.Build.Framework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
StackTrace: DiagnosticsSharp.Runner

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 27 (14 by maintainers)

Most upvoted comments

Sorry I have found the problem, my project was using an older version of Fody, I have upgraded the package to version 29 and everything is working now

+10

rvhelden on Feb 9, 2017

I’ve just run into this problem today. It seems to go away if you install MSBuild version 14 - which is the one associated with VS2015. https://www.microsoft.com/en-us/download/details.aspx?id=48159

atzimler on Mar 14, 2017

I ran into a similar issue this evening and did some investigation that I hope will provide useful information to others…

Here is the relevant portion from the MSBuild output

3>Task "Fody.WeavingTask"
3>    Fody: Fody (version 1.29.4.0) Executing
3>    Fody: ProjectDirectory: 'C:\Dev\AutoDI\AssemblyToProcess\'.
3>    Fody: AssemblyPath: 'C:\Dev\AutoDI\AssemblyToProcess\obj\Debug\AssemblyToProcess.dll'
3>    Fody: Found path to weavers file 'C:\Dev\AutoDI\AssemblyToProcess\FodyWeavers.xml'.
3>    Fody: SolutionDirectory path is 'C:\Dev\AutoDI\'
3>    Fody: Finding weavers
3>    Fody: Adding weaver dlls from 'C:\Dev\AutoDI\Packages'.
3>    Fody: Fody weaver file added 'C:\Dev\AutoDI\Packages\AutoDI.Fody.1.0.0\AutoDI.Fody.dll'
3>    Fody: Could not find packages dir from nuget config.
3>    Fody: SolutionDirectoryPath: C:\Dev\AutoDI\
3>    Fody: Adding weaver dlls from 'C:\Dev\AutoDI\packages'.
3>    Fody: Fody weaver file added 'C:\Dev\AutoDI\packages\AutoDI.Fody.1.0.0\AutoDI.Fody.dll'
3>    Fody: SolutionDirectoryPath: C:\Dev\AutoDI\
3>    Fody: Skipped scanning 'C:\Dev\AutoDI\Tools' for weavers since it doesn't exist.
3>    Fody: No Weaver project file found.
3>    Fody: Finished finding weavers 23ms
3>    Fody: A Weaver HasChanged so loading a new AppDomain
3>    Fody: Creating a new AppDomain
3>    Fody: Reference count=11
3>    Fody: Found debug symbols at 'C:\Dev\AutoDI\AssemblyToProcess\obj\Debug\AssemblyToProcess.pdb'.
3>    Fody: Weaver 'C:\Dev\AutoDI\Packages\AutoDI.Fody.1.0.0\AutoDI.Fody.dll'.
3>    Fody:   Initializing weaver
3>    Fody:   Loading 'C:\Dev\AutoDI\Packages\AutoDI.Fody.1.0.0\AutoDI.Fody.dll' from disk.
3>MSBUILD : error : Fody: An unhandled exception occurred:
3>MSBUILD : error : Exception:
3>MSBUILD : 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.
3>MSBUILD : error : StackTrace:
3>MSBUILD : error :    at System.Signature.GetSignature(Void* pCorSig, Int32 cCorSig, RuntimeFieldHandleInternal fieldHandle, IRuntimeMethodInfo methodHandle, RuntimeType declaringType)
3>MSBUILD : error :    at System.Reflection.RuntimeMethodInfo.FetchNonReturnParameters()
3>MSBUILD : error :    at System.Reflection.RuntimeMethodInfo.GetParametersNoCopy()
3>MSBUILD : error :    at System.Reflection.RuntimePropertyInfo.GetIndexParametersNoCopy()
3>MSBUILD : error :    at System.Reflection.RuntimePropertyInfo.GetIndexParameters()
3>MSBUILD : error :    at System.RuntimeType.GetPropertyCandidates(String name, BindingFlags bindingAttr, Type[] types, Boolean allowPrefixLookup)
3>MSBUILD : error :    at System.RuntimeType.GetPropertyImpl(String name, BindingFlags bindingAttr, Binder binder, Type returnType, Type[] types, ParameterModifier[] modifiers)
3>MSBUILD : error :    at System.Type.GetProperty(String name, BindingFlags bindingAttr, Binder binder, Type returnType, Type[] types, ParameterModifier[] modifiers)
3>MSBUILD : error :    at PropertyDelegateBuilder.TryBuildPropertySetDelegate[T](Type targetType, String propertyName, Action`2& action) in C:\projects\fody\FodyIsolated\DelegateBuilders\PropertyDelegateBuilder.cs:line 18
3>MSBUILD : error :    at DelegateBuilder.BuildDelegateHolder(Type weaverType) in C:\projects\fody\FodyIsolated\DelegateBuilders\DelegateBuilder.cs:line 31
3>MSBUILD : error :    at DelegateBuilder.GetDelegateHolderFromCache(Type weaverType) in C:\projects\fody\FodyIsolated\DelegateBuilders\DelegateBuilder.cs:line 15
3>MSBUILD : error :    at InnerWeaver.InitialiseWeavers() in C:\projects\fody\FodyIsolated\InnerWeaver.cs:line 120
3>MSBUILD : error :    at InnerWeaver.Execute() in C:\projects\fody\FodyIsolated\InnerWeaver.cs:line 81
3>MSBUILD : error : Source:
3>MSBUILD : error : mscorlib
3>MSBUILD : error : TargetSite:
3>MSBUILD : error : Void GetSignature(Void*, Int32, System.RuntimeFieldHandleInternal, System.IRuntimeMethodInfo, System.RuntimeType)
3>MSBUILD : error : Could not load file or assembly 'Microsoft.Build.Framework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
3>MSBUILD : error : 
3>    Fody:   Finished Fody 902ms.
3>Done executing task "Fody.WeavingTask" -- FAILED.

Clearly something is failing to load the Microsoft.Build.Framework assembly. Examining my weaver I can see that it is compiled against version 4.0.0.0 (ILDasm)

.assembly extern Microsoft.Build.Framework
{
  .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A )                         // .?_....:
  .ver 4:0:0:0
}

Firing up Fuslog the problem is a little more clear:

*** Assembly Binder Log Entry  (2/18/2017 @ 10:15:50 PM) ***

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  C:\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:///C:/Dev/AutoDI/packages/Fody.1.29.4
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = MSBuild.exe
Calling assembly : (Unknown).
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\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: 4.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: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/Dev/AutoDI/packages/Fody.1.29.4/Microsoft.Build.Framework.DLL.
LOG: Attempting download of new URL file:///C:/Dev/AutoDI/packages/Fody.1.29.4/Microsoft.Build.Framework/Microsoft.Build.Framework.DLL.
LOG: Attempting download of new URL file:///C:/Dev/AutoDI/packages/Fody.1.29.4/Microsoft.Build.Framework.EXE.
LOG: Attempting download of new URL file:///C:/Dev/AutoDI/packages/Fody.1.29.4/Microsoft.Build.Framework/Microsoft.Build.Framework.EXE.
LOG: All probing URLs attempted and failed.

Of particular interest are these two lines:

LOG: Using application configuration file: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\MSBuild.exe.Config
LOG: Redirect found in application configuration file: 4.0.0.0 redirected to 15.1.0.0.

Looking into the new MSBuild.exe.config file and sure enough there is a binding redirect to forward all versions of Microsoft.Build.Framework to version 15.1.0.0

So I then decided to take a peek to see why my weaver was relying on the Microsoft.Build.Framework. As it turns out I had started my weaver by copying the default weaver which contains this line:

// Will log a message to MSBuild. OPTIONAL
public Action<string, MessageImportance> LogMessage { get; set; }

The MessageImportance class lives in the Microsoft.Build.Framework. Since I was not using this property I simply removed it and the reference to Microsoft.Build.Framework and my problem was solved. However I suspect this issue may end up breaking other weavers.

Looking into it more, it appears that Fody loads the weaver assemblies from byte arrays which causes them to be loaded without context. Which I suspect this is likely the reason for it not being able to resolve the dependency. Any thoughts on how this could be addressed?

Keboo on Feb 19, 2017