Open rainersigwald opened 6 months ago
@rainersigwald do you have in mind component in MSBuild where we can facilitate adding the extra information?
There is quite a lot layers to this onion.
Restore happens to be done by RestoreTaskEx
which is extending StaticGraphRestoreTaskBase
which runs the restore by spawning a new process, which then probably calls back to MSBuild (as msbuild error code is displayed), however that likely goes through API, as MSBUILDDEBUGONSTART
is ignored - so I'm left with blackbox that covers the actual entry of interest within our code
No, not sure where to keep track of and report this. Part of the adventure! My gut says it'd be in the core static graph evaluation stuff.
You're right that NuGet static graph restore uses the API; it does so here: https://github.com/NuGet/NuGet.Client/blob/b83566ec2369c4e9fd07e6f95d734dfe370a1e66/src/NuGet.Core/NuGet.Build.Tasks.Console/MSBuildStaticGraphRestore.cs#L866-L904
Consider a project:
When restored with static graph, this produces
In this example, it's pretty clear what caused that reference. But if you add a layer of indirection (
Entrypoint.csproj
->ExistentReference.csproj
->NonexistentReference.csproj
) you can get an error message that doesn't have any indication of why the graph is trying to resolveNonexistentReference.csproj
:If we could include some context in that error ("...referenced by Existent.csproj" or similar) that'd help debug errors like the one experienced by an internal dev who thought he'd eliminated all references to a project but wasn't quite right yet.