Too many defaults that are opt-out, and they are different from what MSbuild and the .NET Core SDK chose as defaults

Aspnet has a defined set of properties which are different from the default values in Arcade so they had to put workarounds. i.e.

• https://github.com/aspnet/Extensions/blob/master/eng/Workarounds.BeforeArcade.props
• https://github.com/aspnet/Extensions/blob/master/eng/Workarounds.AfterArcade.targets
• https://github.com/aspnet/Extensions/blob/master/eng/Workarounds.AfterArcade.props

Full list of properties they had to work around were:

• Xliff tasks for resx generation.
• DebugType == embedded
• Strong name key == MicrosoftShared
• Test framework == xunit 2.4.1-pre.build.4059. (We were on 2.3 and there are breaking changes between 2.3 and 2.4)
• Using ref assemblies from a NuGet package for .NET Framework projects (Microsoft.NETFramework.ReferenceAssemblies). This breaks some ASP.NET scenarios
• MSBuild warnings as errors. Sometimes warnings are inevitable and we don’t have a way to fix the warnings.
• Projects, by default, do not produce packages when calling dotnet pack. (This is the opposite default that Microsoft.NET.Sdk chose.)
• Any project named “Tests” gets automatic references to xunit. We have some tests that use NUnit.
• The obj/ and bin/ folders are moved to the repo root. (I actually like this but…) it’s not the default MSBuild chose, and we rely on some tools which don’t work unless bin/ and obj/ are in the default MSbuild location.

Is the idea for customers to have these types of workarounds in place defining the values of the properties or we should have a better overriding story in place?

[nguerrera]

Moving between different infrastructure is always hard.

Arcade being opinionated is a big part of its appeal to me. There are a number of things that are requirements for our infrastructure that don’t apply to file -> new project. I don’t think we can make it a requirement that all default behaviors are the same between those. I think having certain important things done for me by default if I follow opinionated conventions is a good approach. Historically, when we have relied on each team to do it their own way, we have duplicated effort at best and had gaps in which parts of the stack were meeting certain requirements at worst. We finally have things like source linking and symbol publishing just working without having to maintain it ourselves.

I get that if you already built the equivalent with a different approach, then migrating is hard. The dividends will still come in the future when we can share improvements across more teams with less duplicated effort.

[nguerrera]

For any default we decide to revert, we need a plan to roll out without breaking everyone. Silently stopping localization for example could go unnoticed. I’m not against that default being the other way (also just an example), we just have to be prepared to go through and opt everyone who needs it back in.