dotnet-releaser: Windows: MSB4016 error on build

Thanks, I’ve filed https://github.com/KirillOsenkov/MSBuildStructuredLog/issues/558 and will investigate it there.

Ouch.

And fantastic job @rgwood, this is really helpful.

I guess we haven’t seen this because not a lot of people use the BinaryLogger copy from StructuredLogger.dll (almost everyone uses the original from MSBuild). Yeah, let’s think about what’s the right thing to do is here.

I filed https://github.com/KirillOsenkov/MSBuildStructuredLog/issues/556 so feel free to watch that for further development. For now the cheapest tactical fix is to probe for both field names and use the one that’s not null.

Disabling Just My Code worked!

System.NullReferenceException
  HResult=0x80004003
  Message=Object reference not set to an instance of an object.
  Source=StructuredLogger
  StackTrace:
   at Microsoft.Build.Logging.StructuredLogger.BuildEventArgsWriter.GetMessageFlags(BuildMessageEventArgs e, BuildEventArgsFieldFlags flags, Boolean writeMessage, Boolean writeImportance) in C:\MSBuildStructuredLog\src\StructuredLogger\BinaryLogger\BuildEventArgsWriter.cs:line 667

It doesn’t, and I can’t repro on my machine, but I’d certainly be the right person to investigate this and it’s likely my fault somehow 😃 Do you have a full call stack?

You can use the Child Process Attach VS extension: https://marketplace.visualstudio.com/items?itemName=vsdbgplat.MicrosoftChildProcessDebuggingPowerTool

Then debug dotnet-releaser.exe with Mixed mode (Managed + Native) in VS, enable Child Process Attach, enable first-chance exceptions (Debug -> Exceptions -> All .NET exceptions), then debug and it will get you a call stack of the exception. Paste that callstack here (and ideally the source location where it happens) and we can investigate further.

It looks like a bug in MSBuild currently (nothing a user is doing should be causing a NullRef in MSBuild), but we need to understand what is going on first (and whether it’s MSBuild or the SDK).

Excellent repro steps @rgwood, I appreciate good bugs when I see them!

Plus, I think even StructuredLogger.dll of recent versions has lost any hope of working with MSBuild < 16.0, so there’s really no scenario I can think of where StructuredLogger.dll should be used for recording.

Great, thanks! I have removed using it from 0.1.8+

Great. The changelog issue should be fixed in 0.1.3+

I think the error is The changelog.path was not setup in the log above, so in dotnet-releaser. Gonna push a fix because it’s supposed to skip it when it is not set.

And to answer your question about why Reflection is necessary - these fields shouldn’t be exposed to the general public, but I need access for obscure reasons (binary serialization). Maybe it’s worth thinking about opening them up, but in MSBuild land, once we open anything up, we can never change it, so we’ve been cautious about making more foundational stuff public. The perf improvement two months ago that broke my reflection wouldn’t have been possible had we had those fields public.

Thanks for reproducing the bug @rgwood and investigating it!

There’s a way to debug an .exe in VS if you don’t have the sources. In VS, open the .exe as a Project (File -> Open Project), it will open as a pseudo-project, you can right-click the “project” in Solution Explorer, open Properties, fill out the arguments, working directory, environment variables, debug engine (has to be Mixed for Child Process Attach to work), then just F5.

This trick is generally useful if you don’t have the source.

Or you can attach to an already running process, but it’s less convenient and since JIT optimizes all modules on load by default, you won’t see any variables in the locals window.