net472 to netstandard1.3 -> extra diagnostics dll

Repro steps:

• Extract ds.zip somewhere
• dotnet build the app project
• Look at bin\Debug\net472, notice extra S.D.DiagnosticSource.dll

This is coming transitively from the netstandard.library 1.6.1 implicit ref in lib.csproj. Recall that netstandard1.x projects don’t get privateassets=“all” applied to that.

But, regardless, why does this assembly survive conflict resolution, etc. net472 should be able to consume netstandard1.x without app-local framework assemblies.

I’m not sure if this is a regression, but I’m very surprised that I haven’t heard about it before, so it may well have crept in.

cc @dsplaisted @ericstj

[nguerrera]

but there’s an easy workaround: manually reference a newer NETStandard.Library package. If we heard about this impacting a customer and could quantify that impact against the risk that Nick suggests I’d push harder.

I agree here. I’m closing this since I haven’t seen other reports and we can reopen if there are any. There are other more severe issues with the 1.6.1 reference, though. https://github.com/dotnet/sdk/issues/2261

It seems that fixing that would fix this, so I’ll close and let the discussion of risk reward focus on the more severe issue.

Also, in past discussions, it seems we’re ok bumping 2.0.x to latest for 2.0+ projects, but not 1.6.x -> latest for 1.x projects as 1.x projects manifest their dependency. I am actually averse to all implicit bumps in principle, but that is not what I see recorded as the policy in past issues. It also seems that 2.0.x won’t actually bring substantially different dependencies to 1.x projects like 1.6.1 did over 1.6.0 so I may be overindexing on that.

[nguerrera]

(Maybe unpopular opinion, but I regret all implicit versioning. I wish that project files specified all versions and that we relied on features to tell you if you had insecure versions in your project files, and prompted you to upgrade. Even for self-contained apps.)