Resolve Azure.Core.Expressions.DataFactory identities in AzureTypeFactory.CreateFrameworkType

[Copilot]

Description

Properties whose model type is identity-aliased to an Azure.Core.Expressions.DataFactory.* type via @@alternateType(..., { identity: "..." }, "csharp") were silently dropped from generated SDKs (e.g. SecretBase, LinkedServiceReference, SecureString in Azure.ResourceManager.DataFactory).

The base generator routes InputType.External != null through CreateExternalType → CreateFrameworkType(Identity). The base CreateFrameworkType resolves via Type.GetType, which cannot find types in Azure.Core.Expressions.DataFactory without an assembly-qualified name. Resolution returns null, CreateExternalType fails, and the property is dropped with no diagnostic.

Changes

• AzureTypeFactory.CreateFrameworkType: added three explicit fully-qualified-name cases to the existing switch — Azure.Core.Expressions.DataFactory.DataFactorySecret, Azure.Core.Expressions.DataFactory.DataFactoryLinkedServiceReference, and Azure.Core.Expressions.DataFactory.DataFactorySecretString — mapped to their respective typeof(...) values, matching the existing style used for ResourceIdentifier, AzureLocation, ResponseError, and ETag. ManagementTypeFactory inherits the fix.
• InputFactory.Model (test helper): added an optional externalTypeMetadata parameter so tests can construct InputModelTypes with External set (mirrors the existing Union helper).
• AzureTypeFactoryTests: end-to-end coverage through CreateCSharpType for an Azure.Core identity and the issue's DataFactorySecret case, plus direct CreateFrameworkType cases for all three documented DataFactory identities.

return fullyQualifiedTypeName switch
{
    "Azure.Core.ResourceIdentifier" => typeof(ResourceIdentifier),
    "Azure.Core.AzureLocation" => typeof(AzureLocation),
    "Azure.ResponseError" => typeof(ResponseError),
    "Azure.ETag" => typeof(ETag),
    "Azure.Core.Expressions.DataFactory.DataFactorySecret" => typeof(DataFactorySecret),
    "Azure.Core.Expressions.DataFactory.DataFactoryLinkedServiceReference" => typeof(DataFactoryLinkedServiceReference),
    "Azure.Core.Expressions.DataFactory.DataFactorySecretString" => typeof(DataFactorySecretString),
    _ => base.CreateFrameworkType(fullyQualifiedTypeName)
};

---

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.

[jsquire]

This approach is brittle and not a direction that I'm comfortable with. We shouldn't be special casing libraries via hardcode. We'll want to come up with a more generic approach before moving forward.

[JoshLove-msft]

I'm not sure this is needed as DFE is already handled through the CreateCSharpType override.

[JoshLove-msft]

Also MTG already has a fallback for unknown types - https://github.com/microsoft/typespec/blob/main/packages/http-client-csharp/generator/Microsoft.TypeSpec.Generator/src/TypeFactory.cs#L287-L294

[JoshLove-msft]

This approach is brittle and not a direction that I'm comfortable with. We shouldn't be special casing libraries via hardcode. We'll want to come up with a more generic approach before moving forward.

Azure.Core.Expressions.DataFactory is a core library that the azure generator already takes a dependency on. However based on my other two comments, I'm not sure why this change is needed.

[JoshLove-msft]

@copilot can you clarify why the existing code path in CreateCSharpType is not sufficient? DFE is used as a union type so we need the additional union metadata to resolve the generic arg.

[jsquire]

Per offline conversation with Josh, I've come to learn that this is an efficiency pattern already established, not a new pattern. Clearing my blocker.

[Copilot]

You're right on both counts — I've reverted the change in 8086b37.

To clarify the original concern: the issue is about non-DFE types (DataFactorySecret, DataFactoryLinkedServiceReference, DataFactorySecretString) appearing as InputModelType.External.Identity, not as union variants — so the CreateCSharpType union override doesn't apply here. However, the base TypeFactory.CreateExternalType (decompiled) does already have the generic fallback you pointed at: when CreateFrameworkType returns null, it calls ExternalTypeReferenceResolver.TryResolve(externalProperties) using the Package/MinVersion metadata, and reports an unsupported-external-type diagnostic only when both fail.

So my fix was special-casing what the generic resolver should handle. The real gap is on the emitter side — @@alternateType(..., { identity: "..." }, "csharp") needs to also emit package (and ideally minVersion) metadata on the InputExternalTypeMetadata so ExternalTypeReferenceResolver can locate the type without hardcoded assembly lookups in the generator. Happy to look at the emitter side if you'd like, but wanted to confirm direction before moving forward.

[JoshLove-msft]

Since the Azure Generatory is already aware of DataFactory types I think we can extend to include them here. Though, I would prefer just hardcoding the fully qualified name for each type rather than using the startswith and looking up the type from the assembly.
@copilot

[Copilot]

Done in 3d25ee1 — added the three DataFactory FQNs (DataFactorySecret, DataFactoryLinkedServiceReference, DataFactorySecretString) as explicit cases in the existing switch alongside ResourceIdentifier/AzureLocation/ResponseError/ETag, no StartsWith or reflection-based assembly lookup. All 41 AzureTypeFactoryTests pass.

concerns resolved by offline discussion

[JoshLove-msft]

@copilot remove these comments

[Copilot]

Removed in aa8aaac.

[Copilot]

Pull request overview

Fixes a generator type-resolution gap where @@alternateType(..., { identity: "Azure.Core.Expressions.DataFactory.*" }, "csharp") identities could not be resolved via Type.GetType, causing external/aliased model types to fail resolution and (downstream) generated properties to be dropped.

Changes:

• Added explicit CreateFrameworkType switch mappings for DataFactorySecret, DataFactoryLinkedServiceReference, and DataFactorySecretString.
• Extended the test InputFactory.Model helper to allow setting InputModelType.External metadata.
• Added tests covering external identity resolution through CreateCSharpType and direct CreateFrameworkType resolution for the DataFactory identities.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
eng/packages/http-client-csharp/generator/Azure.Generator/src/AzureTypeFactory.cs	Adds explicit framework-type mappings for DataFactory identities to avoid Type.GetType resolution failures.
eng/packages/http-client-csharp/generator/Azure.Generator/test/common/InputFactory.cs	Enables constructing InputModelType instances with External metadata for test scenarios.
eng/packages/http-client-csharp/generator/Azure.Generator/test/AzureTypeFactoryTests.cs	Adds regression tests for external identity → framework type resolution, including DataFactory types.