Use the same logger for Restore and other targets about buildalyzer

[daveaglick]

I suspect this is still a problem in 2.x because I'm still performing restore in a separate MSBuild submission and attaching the binary logger to it and then the main build (even though it's out-of-process now). I can't find the /restore switch documented anywhere though. It would simplify things a bit if I could use it, but I don't want to rely on an unofficial flag that might get removed later. Any more insight into the /restore option?

[daveaglick]

Update: just remembered dotnet/msbuild#2414 which has information on the flag. Going to take a look at collapsing my separate restore submission into a single MSBuild invocation with the /restore flag.

[dfederm]

It will still require 2 separate and serial builds in the BuildManager, but as long as you use the same loggers collection, it'll log to the same logger.

/restore is an official flag and can be considered a stable feature. In fact, I recommend generally adding it to your Directory.Build.rsp so that it just always happens and you don't have to type it every time (Directory.Build.rsp is a set of command-line switches added to every msbuild.exe command you run from the command-line).

[daveaglick]

It will still require 2 separate and serial builds in the BuildManager, but as long as you use the same loggers collection, it'll log to the same logger.

I might be able to get away with just one now - in 2.x Buildalyzer was changed/simplified to fork msbuild.exe directly instead of going through the MSBuild APIs. I'm thinking because of that, I should be able to add the /restore switch and it'll just work (same way it would work if running MSBuild directly from the CLI).

Giving it a shot now. If it works, it'll simplify some other stuff too in addition to fixing this logger problem since I won't have to deal with an explicit restore target and managing a separate submission.