Debugging a Fody Weaver (Plugin) and/or debugging MSBuild


2 minute read - suggest an edit

Last night at an ungodly hour I did a massive refactor on a prototype codebase with no unit tests and now the once working project now no longer compiles because something I did is causing the most excellent Fody to blow up. Normally you would just go and do a bisect using git but in this case I didn’t incrementally commit on each change as I was on my own branch and the work was all related to a single higher unit of work. Old habits die hard, sometimes they come back to bite you hard…

So how exactly to you get yourself out of this situation? Your application won’t launch/debug because it won’t compile, hmm pickle…..

It turns out back when .NET 4.0 landed Microsoft added an unofficial /debug flag:

# cd C:\Windows\Microsoft.NET\Framework\v4.0.30319>
# msbuild /debug

Microsoft (R) Build Engine version 4.6.1038.0
[Microsoft .NET Framework, version 4.0.30319.42000]
Copyright (C) Microsoft Corporation. All rights reserved.

MSBUILD : error MSB1001: Unknown switch.
Switch: /debug

But it won’t work until you enable it from an elevated (admin) command prompt:

# reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSBuild\14.0" /v DebuggerEnabled /d true
# reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSBuild\12.0" /v DebuggerEnabled /d true
# reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSBuild\4.0" /v DebuggerEnabled /d true
# reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSBuild\3.5" /v DebuggerEnabled /d true
# reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\14.0" /v DebuggerEnabled /d true
# reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\12.0" /v DebuggerEnabled /d true
# reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\4.0" /v DebuggerEnabled /d true
# reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\3.5" /v DebuggerEnabled /d true

The next step is to debug the actual code that is being weaved, in my case the project was a portable class library whereby all dependancies came from NuGet so this process was super simple:

  • Clone the source code of the weaver that was misbehaving
  • Open the project in visual studio
  • Add “your misbehaving” library to the weaver solution.
  • Remove nuget references for that weaver.
  • Manually add the references to the weaver from the local project.
  • Save the solution.
  • Follow the Microsoft recommendations and enable Just My Code in the Visual Studio options.

The next steps from here is to invoke msbuild manually and wait for your build to fail:

# cd C:\Windows\Microsoft.NET\Framework\v4.0.30319>
# msbuild.exe /debug C:\...\ghuntley-reactiveui.fody\reactiveuifody.sln

Attach debugger to MSBuild

From this point, the workflow is pretty much same/same:

  • Select Debug, then the version of Visual Studio you wish to use.
  • Point Visual Studio to the source code of the Fody weaver.

Now we are cooking with gas!

Rewind the stack and inspect the previous variables to discover the offending attribute/viewmodel.

Offending ViewModel/Attribute found!

Remember kids, commits are cheap and git rebase exists - use it.

Related Posts

ReactiveUI v7.2.0 released

Learn these three buttons

Announcing ReactiveUI virtual community meetups

ReactiveUI v7.1.0 released

ReactiveUI v7.0.0 released

Semantic Versioning of Xamarin Applications

Announcing Serilog.Sinks.Xamarin

Announcing Cake.Raygun

Announcing Cake.AppleSimulator

Example of Xamarin iOS with Cake