arcade: 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?
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 27 (27 by maintainers)
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.
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.
The main point of this feedback is not the specifics. We could debate those separately. I listed those as examples given to illustrate the larger problem. Microsoft.DotNet.Arcade.Sdk is very heavy handed about what it does with projects, and in my opinion, deviates too much from how Microsoft.NET.Sdk and MSBuild are designed. We’re having trouble adopting Arcade in aspnet repos because Microsoft.DotNet.Arcade.Sdk, the YAML templates, BAR manifest generation, publishing, and more are tightly coupled. It has not been reasonable or cheap for my team to adopt Arcade. I have basically had to read every line of Microsoft.DotNet.Arcade.Sdk to make sure using it will change important aspects of the product we produce. It has been so difficult getting just a few of our repos that I am considering just not doing it at all for our larger repos, like aspnet/AspNetCore.
I am not dismissing any specific feedback. I welcome feedback on any particular setting/convention and am ready to explain the reasons for them. What I am saying above is that we need to constrain repos to some degree and disallow some customizations to get a sane system.
Perhaps. It depends on what you consider magic and fancy. Again, this is not actionable unless we talk about specific feature.
Nobody. My statement included an “if” and I asked for confirmation.
What @nguerrera says. It is the goal of Arcade SDK to set certain standards and enforce some amount of uniformity. There is indeed a balance - we need to give repos freedom to customize certain things but not others. We can discuss each particular requirement, convention and default. But if this issue is asking for Arcade SDK to not do that then it can be closed as “won’t fix, by design”.