Move the default location for ref assemblies to obj (from bin)

[rainersigwald]

Today, ref assemblies are copied into the bin/ref folder by default. However, this is a sometimes confusing and unexpected output that is primarily used for internal build-performance reasons.

For Visual Studio 2022 we'd like to move this to a folder under obj.

The code change is to update this:

msbuild/src/Tasks/Microsoft.Common.CurrentVersion.targets

Line 326 in 18a8ddc

<TargetRefPath Condition=" '$(TargetRefPath)' == '' and '$(ProduceReferenceAssembly)' == 'true' ">$([MSBuild]::NormalizePath($(TargetDir), 'ref', $(TargetFileName)))</TargetRefPath>

The compat impact is less clear; some customers may have projects that expect the presence in ref. We could provide an opt-out (and/or put this under a changewave) but we'd like to hear from anyone who objects to this plan.

[rainersigwald]

Microsoft-internal link to discussion where we were unable to remember any specific reason that it should be in bin. .

[jaredpar]

Ended up finding a number of other issues discussing ref appearing in the bin directory. Think most will end up being dupes but want to let you decide:

• ProduceReferenceAssembly should exclude exe by default sdk#16193
• Move the default location for ref assemblies to obj (from bin) #6543
• .NET8: Ability to not include ref diretory in published single exe file sdk#16759
• Questions regarding ref folder in publish output sdk#6310
• CLI files layout includes "ref" directories that aren't required and add to size on disk/installer time sdk#16197

[jaredpar]

We could provide an opt-out (and/or put this under a changewave) but we'd like to hear from anyone who objects to this plan.

Can't any customer that prefers the current location just override $(TargetRefPath) to match the current pre-Dev17 logic?

[rainersigwald]

Can't any customer that prefers the current location just override $(TargetRefPath) to match the current pre-Dev17 logic?

Yes, but they'd have to discover it. I think that's likely good enough personally but I've been wrong before . . .

[Nirmal4G]

I'm not okay with obj since, reference assembly is also the final output of a build. Much as it would be confusing for some people that we would have it in bin it would also be more confusing if it's under obj.

This is also why I proposed a root build folder, where we can keep Assets which doesn't come under bin or obj. This way, we could have build\ref along side build\bin, build\obj and build\ext (NuGet, Paket and other MSBuild extensions).

[rainersigwald]

I'm not okay with obj since, reference assembly is also the final output of a build.

Is it? It is generally an internal implementation detail of intermediate assemblies in the build. It's not generally shipped to customers, for example. In the cases where it is, you can opt to specify that it go in your own bin folder.

[Nirmal4G]

True but I think of them as a stripped down version of the main Assembly, much like .NET Framework reference assemblies!

I'm not okay with either way, bin or obj but having it in bin\ref for final output and obj\ref for intermediate output made sense. This proposal takes away that intuition.

I do get that some do copy/move all assemblies by wildcard and that might be confusing but producing reference assemblies is not a novice feature. So, in that perspective, we can keep it as it is or we could introduce build/publish folders early on as an opt-in feature.