ProduceReferenceAssembly should exclude exe by default

Starting with .NET 5 SDK we’ve enabled the $(ProduceReferenceAssembly) flag by default. I think this is excellent as it will really help our inner loop scenarios by removing unneeded compilations in a number of scenarios.

I think we should disable this by default for exe projects though. The reasons being:

1. Reference assemblies are only beneficial when there is a good chance the project being built will be referenced by another. Yes this can happen for exes but it’s the rare case.
2. Reference assemblies appear in the bin output directory. That means it’s an extra, and often unnecessary, concept that we’re exposing to our customers that contributes to the look of us being more complex than our customers.

Believe we should tweak this setting so that it’s enabled only when building library projects.

[jaredpar]

@dsplaisted

They are initially written out to the intermediate output folder, under a sub-folder named ref, by the compilation task. MSBuild then uses the CopyRefAssembly task to move it to the output folder.

https://github.com/dotnet/msbuild/blob/41441946c883903cef0334ce872e9ce10918e2bf/src/Tasks/Microsoft.Common.CurrentVersion.targets#L4489

Part of this is necessary. The compiler always emits a reference assembly to disk because it’s an output of compilation. MSBuild though is timestamp based so we cannot use the reference assembly emitted by the compiler as the output reference assembly consumed by referencing projects. That would cause every referencing project to re-compile even when the reference assembly was identical because the timestamp changed.

This is where the CopyRefAssembly task comes into play. It generally takes the source the reference assembly emitted by the compiler and copies it to the location that other projects will reference it from. That copy operation is “smart” though, it will only do the copy if the MVID of the source and dest are different. So when the build produces the same reference assembly it does not perform a copy and downstream compilations are avoided.

As to why we chose the final location of the reference assembly to be the output folder vs. the intermediate output folder I can’t answer. I don’t have any memory of that decision, or it even being a decision point. My intuition is that project references always grab from the output folder, not the intermediate output folder, so likely it was put there because it’s where we used it previously. @rainersigwald would best be able to answer “why” though.

[marcpopMSFT]

Agreed. Moved to the backlog.