Sdk: deps file is not regenerated when non-nuget references change

[nguerrera]

Currently the target that generates the deps file only runs when project.assets.json is older than deps.json, but if non-package references are changed, then the deps file would also need to change.

We do want to keep incrementality because it is an expensive operation, but we should account for the other task parameters that can change the deps file.

[livarcocc]

Is this something that we should/can address for 2.1? I ask so that I can figure out which milestone to put this at.

Also, where is the code for this? I saw the GenerateDepsFilei is set to true for core or for PreserverCompilationContext == true.

Is this in the task?

[nguerrera]

Code is here:

https://github.com/dotnet/sdk/blob/9f97fce72d9d095425b72270b2b8e85d2b6acfd1/src/Tasks/Microsoft.NET.Build.Tasks/build/Microsoft.NET.Sdk.targets#L121-L122

This only input is the assets file.

As far as milestone, since I found this by code inspection, and haven't seen a report yet, it can maybe wait until after 2.1.3xx.

[livarcocc]

I missed the inputs, only looked at condition. All right. Marking for a future release then.

[nguerrera]

Cheap fix is adding MSBuildAllProjects to inputs. It isn't perfect, but many other targets use the same approximation for incrementality. We should maybe just do that. Otherwise, need to do fancier tricks like CoreCompile and GenerateAssemblyInfo do.

[livarcocc]

I like simple fixes.

[ericstj]

Do you gather anything more than just TargetPath from project references? (EG: copy local content, or binaries referenced by a ProjectReference) If so, that complicates things since those wouldn't be covered by MSBuildAllProjects of this project. If not then its probably OK.

[nguerrera]

Do you gather anything more than just TargetPath from project references? (EG: copy local content, or binaries referenced by a ProjectReference) If so, that complicates things since those wouldn't be covered by MSBuildAllProjects of this project. If not then its probably OK.

@tannergooding is looking at gathering the reference dependencies.

[dsplaisted]

I will likely include the simple fix for this (add $(MSBuildAllProjects) to the target inputs) together with the fix for #1847