Feature request: allow -pp to produce some output even in presence of import and schema errors

Issue Description

The -pp or -preprocess will produce no output if the project experiences schema or import errors. In the past, this was acceptable as you could usually just fix the error in question. However, the new PackageReference and Sdk mechanisms often result in a situation where one error in the project will cause package restore to fail, but if that error is not syntactic or schematic, the only diagnostics reported by msbuild will be for the failed Sdk or PackageReference import. This makes debugging the /t:restore target very difficult, as we have no way to see what the project looks like to msbuild when it runs the restore target.

This motivates a need for -pp to function with incomplete projects -- where either the Imports fail, or where errors are caused by incorrect property values (e.g. UsingTask can fail with syntax errors if the task factory value is set wrong, due to improperly initialized properties).

Steps to Reproduce

1. Create a new C# project, e.g. dotnet new console
2. Add the following to the project:

   <ItemGroup>
     <PackageReference Include="Microsoft.NoSuchProject" Version="1.0.0" GeneratePackagePath="true" />
   </ItemGroup>
   <Import Project="$(PkgMicrosoft_NoSuchProject)" />
   

3. dotnet /pp

Expected Behavior

Syntax errors, and partial result of preprocessing (at least up until the first error. Preferably preprocessed exactly as the /t:restore project would see the project.

Actual Behavior

No output at all.

Analysis

n/a

Versions & Configurations

C:\scratch\repro>dotnet --version
6.0.100-preview.1.21103.13

C:\scratch\repro>ver

Microsoft Windows [Version 10.0.19042.804]

Attach a binlog

n/a

Related issue: #3971

[benvillalobos]

Team Triage: Have you tried passing /bl and viewing the generated binlog?

Yes, but the binlog doesn't show me what I need to know. It won't show me, for instance, which order different projects were imported, or let me search to find that some property was never defined. While sometimes helpful, /bl is not sufficient in all cases.

[benvillalobos]

Hmm, try -flp:v=diag instead of /pp. You should see an msbuild.log file where you ran the command.

Again, my goal is to see what msbuild is seeing when restore is running. If I run msbuild -t:Restore -flp:v=diag, it doesn't report any errors. None at all. But some of my packages weren't restored properly, and msbuild -t:Build fails with "The imported project "C:\Sdk\Sdk.props" was not found."

I'd like to see what my project looked like to msbuild before it ran the restore target. But when I run msbuild -pp:tmp.pp, I get an empty file out.

[jeffkl]

@benvillalobos I'm going to assign this to myself and work on it. Its a feature I've wanted for a while, sometimes I try to get a preprocess file but its empty because of some problem with the project. At the very least, MSBuild should log an error telling me why the preprocess doc couldn't be generated. I'll debug it and figure out why the file's just empty and nothing is logged.

[jeffkl]

Actually I don't have permissions anymore to assign this to myself, please assign it to me.

[jeffkl]

I've found something interesting, MSBuild is logging something if the preprocess fails.

<Project>
  <Import Project="$(Foo)" />
</Project>

MSBuild.exe correctly reports the problem:

D:\msbuild>msbuild /pp:pp.log D:\Stuff\pp.proj
D:\Stuff\pp.proj(2,3): error MSB4020: The value "" of the "Project" attribute in element <Import> is invalid.

But dotnet msbuild /pp does not?

D:\msbuild>dotnet msbuild /pp:pp.log D:\Stuff\pp.proj

But if you directly execute MSBuild from dotnet it does?

D:\msbuild>dotnet exec "C:\Program Files\dotnet\sdk\5.0.200\MSBuild.dll" /pp:pp.log D:\Stuff\pp.proj
D:\Stuff\pp.proj(2,3): error MSB4020: The value "" of the "Project" attribute in element <Import> is invalid.

This makes me think the MSBuildForwardingApp is causing the issue, but I haven't had a chance to debug that yet. Does that sound familiar to anyone?