Remove all legacy data portal operation method support

[rockfordlhotka]

There are still some remnants of the old DataPortal_XYZ method concepts in the codebase, including an option flag added in #4616.

All of this should be removed, leaving only the data portal operation attribute concept.

Anyone still relying on the old naming scheme can add attributes to those methods or update their codebase in other ways.

[rockfordlhotka]

Implementation plan

Since main is now 11.0 (breaking changes welcome), this plan is to remove name-based operation support in 11.0. There will be no deprecation step in 10.x.

Background: the legacy "methods" are user methods matched by name (DataPortal_Fetch, Child_Update, …), so [Obsolete] can't target them directly. The main upgrade aid is analyzer CSLA0014 (DoesOperationHaveAttributeAnalyzer), which already detects attribute-less legacy-named methods and has a code fix that adds the attribute. Name matching has also caused real bugs (#4595 → #4616): an unrelated DataPortal_Execute got invoked unexpectedly.

Related: #4878 (analyzer suppressors). Once name matching is gone, the operation suppressors there only need the attribute check. See the note in Phase 3.

---

Phase 1: Runtime removal (main)

Source/Csla/Reflection/ServiceProviderMethodCaller.cs

• Remove the "if no attribute-based methods found, look for legacy methods" block in FindDataPortalMethod<T>.
• Remove useLegacyMethods from the method and from GetCacheKeyName(...).
• ObjectFactory path: replace the hard-coded m.Name == "Child_Create" lookups (the factory type walk and the fallback to the target type). Options:
  • (a) look for [CreateChild] on the target type, or
  • (b) add CreateChildMethodName to ObjectFactoryAttribute to match the other *MethodName properties.
  • Decision needed.

Source/Csla/Configuration/Fluent/DataPortalOptions.cs

• Remove UseLegacyOperationMethods.

Phase 2: Base classes that currently rely on name matching (main)

Several CSLA base classes have operation methods without attributes that are only reachable through the legacy fallback. Each one needs an attribute, removal, or an explicit decision:

• "Not supported" stubs (private, no attribute; they throw NotSupportedException with a friendly message):

  • CommandBase: DataPortal_Create/Fetch/Update/Delete
  • ReadOnlyBase: DataPortal_Create/Update (DataPortal_Delete already has [Delete])
  • ReadOnlyListBase, ReadOnlyBindingListBase, NameValueListBase, DynamicListBase, DynamicBindingListBase: DataPortal_Update/Delete

  Decision needed: add the matching attribute so the friendly NotSupportedException is kept, or delete them and accept the generic "method not found" error. Note that Dataportal operations of base classes are invoked #4090 filters out private attributed methods on base classes, so keeping them means making them protected (or private protected) plus the attribute. Also remove the obsolete SuppressMessage attributes (CA1801/CA1811) on them.

• Child create defaults (protected virtual, no attribute):

  • Core/BusinessBase.Child_Create(): calls BusinessRules.CheckRules(). Today this is what runs for a child with no [CreateChild] method, so removing it silently skips initial rule checking.
  • BusinessListBase.Child_Create() and BusinessBindingListBase.Child_Create(): no-op.

  Decision needed: mark them [CreateChild] (and check overload scoring against user-defined [CreateChild] overloads), or remove them and document that children need their own [CreateChild] that calls CheckRules().

• Sync Child_Update(params object[]) on BusinessListBase, BusinessBindingListBase, BusinessDocumentBase: the async versions already have [UpdateChild], so these just become ordinary protected helpers. Confirm that's intended, and consider renaming or obsoleting them.

• Clean up XML doc comments that refer to DataPortal_XYZ (CommandBase, Core/BusinessBase, DynamicListBase, DynamicBindingListBase, IDataPortal, IDataPortalT).

Phase 3: Analyzers (main)

• Remove naming-convention detection: ByNamingConvention in DataPortalOperationQualification / CslaOperationQualification, the name checks in IMethodSymbolExtensions.IsRootDataPortalOperation / IsChildDataPortalOperation, and the operation name constants in CslaMemberConstants.Operations.
• Review each analyzer that consumes the qualification: DoesChildOperationHaveRunLocalAnalyzer, EvaluateOperationAttributeUsageAnalyzer, FindOperationsWithIncorrectReturnTypesAnalyzer, FindOperationsWithNonSerializableArgumentsAnalyzer, FindRefAndOutParametersInOperationsAnalyzer, IsOperationMethodPublicAnalyzer, ObjectAuthorizationRulesAttributeAnalyzer.
• CSLA0014: keep it, but repurpose it. A method named like a legacy operation with no attribute will now never be called, so report it as a Warning (consider Error) and keep the add-attribute code fix. This is the main upgrade aid. Update docs/analyzers/CSLA0014-DoesOperationHaveAttributeAnalyzer.md to match; it still says "For now (CSLA version 5), this is only an informational analyzer".
• AddObjectAuthorizationRules naming convention: decide whether it goes too, or stays out of scope (it's a separate static-method convention; see IsAddObjectAuthorizationRulesOperation).
• Update AnalyzerReleases.Unshipped.md for any severity or ID changes.
• Coordinate with Create Suppressors for Specific Scenarios #4878: build the operation suppressor (IDE0051 / CA1822 / IDE0060) on the attribute-only check.

Phase 4: Tests (main)

About 150 test files use legacy names, mostly Csla.test (~123) and csla.netcore.test (~15), plus Csla.Web.Mvc.Test, Csla.Blazor.Test, Csla.Ios.Test, and the analyzer test projects.

• Convert test business objects to attributed operations. The CSLA0014 code fix (or a scripted rewrite) can do most of this mechanically, and renaming methods is optional.
• Delete the UseLegacyOperationMethods = false tests in ServiceProviderMethodCallerTests.cs, and add tests showing a legacy-named method with no attribute is not invoked.
• OperationNameFlowTests: switch its test types to attributed methods (the operation name comes from the attribute type, so behavior shouldn't change).
• Add tests for the Phase 2 decisions (not-supported stubs, child create default, ObjectFactory child create).
• Update analyzer unit and integration tests for the removed naming-convention detection and the new CSLA0014 behavior.

Phase 5: Docs & release notes (main)

• releasenotes.md (CSLA 11): breaking change entry with before/after examples, and a pointer to CSLA0014 plus its code fix.
• Add an upgrade doc section ("Upgrading to CSLA 11"), including the Phase 2 behavior changes (especially child CheckRules).
• Update samples in docs/analyzers/CSLA0002, CSLA0009, CSLA0010, CSLA0012, CSLA0013, CSLA0014, plus docs/Abstractions-in-CSLA.md and docs/Data-Access.md.

---

Out of scope

• The DataPortal_OnDataPortalInvoke / DataPortal_OnDataPortalInvokeComplete / DataPortal_OnDataPortalException and Child_On* hooks. These are overridable virtuals exposed through IDataPortalTarget, not name-matched operations. Renaming them would be a separate breaking change and should get its own issue if we want it.
• Call data portal operation methods explicitly #4359 (generated operation interfaces). Complementary, not required.

Suggested PR breakdown

1. main: Phases 1 + 2 + the required test conversions (these can't really be split without breaking CI).
2. main: Phase 3 (analyzers) + analyzer tests, followed by Create Suppressors for Specific Scenarios #4878.
3. main: Phase 5 (docs), or fold it into PR 1.