Implement all targets to avoid msbuild p2p problems

[AArnott]

This file should define all these targets to avoid regressions when people update from 3.4 to 3.5 of NB.GV.

[alexrp]

FWIW, I just ran into C:\Users\alex\source\repos\system-terminal\pkg\cache\nerdbank.gitversioning\3.5.50-alpha\build\PrivateP2PCaching.proj : error MSB4057: The target "Publish" does not exist in the project. when invoking dotnet publish.

[AArnott]

Gah! That's not even on the P2P protocol list. @rainersigwald, how complete is that list?

Thanks, @alexrp.

[AArnott]

Pack isn't listed there either.

[rainersigwald]

Ugh. I think it's complete for ResolveProjectReferences but of course anyone can consume @(ProjectReference) and do other stuff with it . . . and we should cover at least first-party stuff like that. dotnet/msbuild#7066

[alexrp]

It seems like there should be a way for users to resolve an error like that for third-party targets also, rather than requiring an update to NBGV?

[AArnott]

There should be a way to avoid the requirement altogether. But yes you're right: so long as we must use the ProjectReference item to satisfy msbuild --isolate --graph, I suspect you're right.
This issue is unique to 3.5. I'll keep this issue open till we either revert the entire effort pending a better solution from msbuild or I offer a hook of some kind to define these targets yourself in a pinch.

[rainersigwald]

@alexrp you're right: NBGV should use dotnet/msbuild#6852. but it doesn't exist yet, so for now this is the best @AArnott can do.

[medianick]

I came across this PrivateP2PCaching.proj project file when attempting to run the Stryker mutation tester against a project using NBGV 3.5.119; it led to this exception and stack trace:

Unhandled exception. System.Collections.Generic.KeyNotFoundException: The given key 'C:\redacted\.nuget\packages\nerdbank.gitversioning\3.5.119\build\PrivateP2PCaching.proj' was not present in the dictionary.
   at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
   at Stryker.Core.Initialisation.InputFileResolver.FindDependentProjects(IReadOnlyCollection`1 projectsUnderTest) in /_/src/Stryker.Core/Stryker.Core/Initialisation/InputFileResolver.cs:line 101
   at Stryker.Core.Initialisation.InputFileResolver.ResolveSourceProjectInfos(StrykerOptions options) in /_/src/Stryker.Core/Stryker.Core/Initialisation/InputFileResolver.cs:line 81
   at Stryker.Core.Initialisation.InitialisationProcess.GetMutableProjectsInfo(StrykerOptions options) in /_/src/Stryker.Core/Stryker.Core/Initialisation/InitialisationProcess.cs:line 58
   at Stryker.Core.Initialisation.ProjectOrchestrator.MutateProjects(StrykerOptions options, IReporter reporters, ITestRunner runner)+MoveNext() in /_/src/Stryker.Core/Stryker.Core/Initialisation/ProjectOrchestrator.cs:line 50
   at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
   at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
   at Stryker.Core.StrykerRunner.RunMutationTest(IStrykerInputs inputs, ILoggerFactory loggerFactory, IProjectOrchestrator projectOrchestrator) in /_/src/Stryker.Core/Stryker.Core/StrykerRunner.cs:line 61
   at Stryker.CLI.StrykerCli.RunStryker(IStrykerInputs inputs) in /_/src/Stryker.CLI/Stryker.CLI/StrykerCLI.cs:line 93
   at Stryker.CLI.StrykerCli.<>c__DisplayClass10_0.<Run>b__0() in /_/src/Stryker.CLI/Stryker.CLI/StrykerCLI.cs:line 68
   at McMaster.Extensions.CommandLineUtils.CommandLineApplication.<>c__DisplayClass143_0.<OnExecute>b__0(CancellationToken _)
   at McMaster.Extensions.CommandLineUtils.CommandLineApplication.ExecuteAsync(String[] args, CancellationToken cancellationToken)
   at McMaster.Extensions.CommandLineUtils.CommandLineApplication.Execute(String[] args)
   at Stryker.CLI.StrykerCli.Run(String[] args) in /_/src/Stryker.CLI/Stryker.CLI/StrykerCLI.cs:line 74
   at Stryker.CLI.Program.Main(String[] args) in /_/src/Stryker.CLI/Stryker.CLI/Program.cs:line 14

I'll look into a 3.6 upgrade to see if that solves the problem.

[medianick]

Indeed, upgrading to 3.6.133 resolved the issue above.