The common targets convention is to generate all source inputs to the compiler before BeforeCompile target.
Targets that fail to do so break Source Link (see https://github.com/dotnet/sourcelink/issues/572).
@tmat If the fix for this was merged into master, what SDK version does that mean it would arrive in? Does it need to be ported to any other branches?
@nguerrera
master is 5.0. If this is needed sooner than that, then this would need to be ported to 3.1.2xx to coincide with 16.5. That will require approval at this point. The 16.6 / 3.1.3xx would next opportunity, but branch does not exist yet.
I imagine we could get this approved if you want to put up a port to release/3.1.2xx
Reopening and targeting 3.1.2xx milestone for now.
Yeah, I can port it to release/3.1.2xx.
FYI, @wli3 Note that there is a possibility it will not be approved for 3.1.2xx, but then we can leave the PR open and retarget to 3.1.3xx when the branch opens. That is still much sooner than 5.0.1xx that master is targeting.
PR for 3.1.2: https://github.com/dotnet/sdk/pull/10616
10616 was merged to 3.1.3xx.
Does this mean that the fix landed in the official .NET Core 3.1.300 SDK? I just tried to dotnet pack a project using the dotnet CLI version 3.1.300 but NuGet Package Explorer still reports that the package contains untracked sources. This is confusing. Also, this issue is in the 3.1.2xx milestone, adding even more confusion.
FTR, given that NuGet packages exist which ship .targets files which rely on the shape of the dependency graph, this is effectively a breaking change.
Does this mean that the fix landed in the official .NET Core 3.1.300 SDK?
Answering myself: yes, the fix landed in the official .NET Core 3.1.300 SDK. My untracked sources issue was because the repository was missing a .gitignore file.
Most helpful comment
@tmat If the fix for this was merged into master, what SDK version does that mean it would arrive in? Does it need to be ported to any other branches?