Description

This PR implements end-to-end support for generating multiple resources that can share the same resource model but operate at different paths in the MPG (Management Plane Generator). This enables the legacy-operations pattern where two interfaces (e.g., BestPractices, BestPracticeVersions) use the same model (e.g., BestPractice) at different API paths.

Changes Made

Emitter (resource-detection.ts)

• Track resources by modelId + resourcePath combination instead of model ID alone
• Extract and prioritize explicit ResourceName from TypeSpec (LegacyOperations 4th parameter)
• Use pluralize npm package (pluralize.singular) inline for converting plural interface names to singular resource names (fallback only)
• Implement path-based parent-child detection: When resources share the same model at different paths, parent-child relationships are automatically detected through path prefix matching
• Enhanced matching logic for list operations across scopes (subscription vs resource group)
• Auto-merge entries without resource ID patterns
• Handle non-resource methods for models without CRUD operations
• Fixed all linter errors

Generator (ManagementInputLibrary.cs, ManagementOutputLibrary.cs, ResourceOperationMethodProvider.cs, ResourceCollectionClientProvider.cs)

• Process ALL @resourceSchema decorators on a model (changed from FirstOrDefault() to Where())
• Handle multiple resources sharing the same data type in resource data type dictionary
• Fixed return type bug: Modified InitializeTypeInfo in ResourceOperationMethodProvider to use enclosing type context (ResourceCollectionClientProvider or ResourceClientProvider) to determine correct resource type
• Added helper methods to ResourceCollectionClientProvider for resource type resolution
• Ensures methods return the correct resource type when multiple resources share the same data model

Path-Based Parent Detection

• For resources sharing the same model, parent-child relationships are detected by analyzing path structure
• Child path must start with parent path followed by "/" (e.g., /bestPractices/{name}/versions/{versionName} is child of /bestPractices/{name})
• The parentResourceId field is automatically set in metadata for child resources
• Child resource collection methods are correctly placed on the parent resource class

Example

TypeSpec demonstrating the same model used at different paths (legacy-operations pattern):

/** A best practice resource - used by both parent and child operations */
@tenantResource
model BestPractice is ProxyResource<BestPracticeProperties> {
  ...ResourceNameParameter<
    Resource = BestPractice,
    KeyName = "bestPracticeName",
    SegmentName = "bestPractices",
    NamePattern = ""
  >;
}

/** Best practice operations on /bestPractices/{bestPracticeName} */
@armResourceOperations
interface BestPractices {
  get is BestPracticeOps.Read<BestPractice>;
  createOrUpdate is BestPracticeOps.CreateOrUpdateSync<BestPractice>;
}

/** Best practice version operations on /bestPractices/{bestPracticeName}/versions/{versionName} */
@armResourceOperations
interface BestPracticeVersions {
  get is BestPracticesVersionOps.Read<BestPractice>;
  createOrUpdate is BestPracticesVersionOps.CreateOrUpdateSync<BestPractice>;
}

Generated Output:

• BestPracticeResource at /providers/MgmtTypeSpec/bestPractices/{bestPracticeName}
• BestPracticeVersionResource at /providers/MgmtTypeSpec/bestPractices/{bestPracticeName}/versions/{versionName}
• BestPracticeResource.GetBestPracticeVersions() correctly returns child collection
• BestPracticeResource.GetBestPracticeVersion(versionName) correctly returns child resource
• Both share the same BestPracticeData model with correct return types

Testing

• All 28 emitter tests passing (10 resource-detection + 18 others)
• All 71 generator tests passing
• Test validates the SAME model used by two interfaces at different paths
• Emitter correctly generates TWO @resourceSchema decorators on the same model
• Generator correctly establishes parent-child hierarchy through path detection
• End-to-end working solution verified with correct resource hierarchy

This checklist is used to make sure that common guidelines for a pull request are followed.

• Please add REST spec PR link to the SDK PR
• I have read the contribution guidelines.
• The pull request does not introduce breaking changes.

General Guidelines

• Title of the pull request is clear and informative.
• There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

• Pull request includes test coverage for the included changes.

SDK Generation Guidelines

• If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
• The generate.cmd file for the SDK has been updated with the version of AutoRest, as well as the commitid of your swagger spec or link to the swagger spec, used to generate the code.
• The *.csproj and AssemblyInfo.cs files have been updated with the new version of the SDK.

• Fixes Support multiple-path resource with same resource model in new MPG generator #54186

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.