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).
dotnet new console
<ItemGroup>
<PackageReference Include="Microsoft.NoSuchProject" Version="1.0.0" GeneratePackagePath="true" />
</ItemGroup>
<Import Project="$(PkgMicrosoft_NoSuchProject)" />
dotnet /ppSyntax 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.
No output at all.
n/a
C:\scratch\repro>dotnet --version
6.0.100-preview.1.21103.13
C:\scratch\repro>ver
Microsoft Windows [Version 10.0.19042.804]
n/a
Related issue: https://github.com/dotnet/msbuild/issues/3971
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.
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.
@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.
Actually I don't have permissions anymore to assign this to myself, please assign it to me.
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?
Most helpful comment
@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.