Support generating DataFactoryElement<> properties in the Azure generator

[Copilot]

• [x] Understand the issue: Generate DataFactoryElement<T> properties from InputUnionType with InputExternalType identity "Azure.Core.Expressions.DataFactoryElement"
• [x] Implement DataFactoryElement detection in AzureTypeFactory.CreateCSharpTypeCore()
• [x] Add package reference for Azure.Core.Expressions.DataFactory
• [x] Add factory methods to create InputUnionType and InputExternalType in tests
• [x] Add unit tests for DataFactoryElement type creation (7 tests total)
• [x] Add tests validating serialization/deserialization patterns (2 new tests)
• [x] Address PR feedback:
  • [x] Move DataFactoryElementIdentity constant to top of class
  • [x] Add logging using AzureClientGenerator.Instance.Emitter.ReportDiagnostic
  • [x] Remove InputExternalType branch (not needed)
  • [x] Add test for model inner type
  • [x] Add DataFactoryElement patterns to Basic-TypeSpec.tsp with alternateType decorators
  • [x] Verify serialization/deserialization is handled automatically by base generator
  • [x] Move alternateType decorator from each union to DfeExpressionModel

Summary

This PR adds support for generating DataFactoryElement<T> properties in the Azure generator when encountering an InputUnionType that contains an InputExternalType variant with identity "Azure.Core.Expressions.DataFactoryElement".

Key Changes:

1. AzureTypeFactory.cs:

   • Added TryCreateDataFactoryElementTypeFromUnion() method
   • Creates DataFactoryElement<T> where T is derived from the other union variant
   • Logs warning via Emitter when union has multiple variants

2. Azure.Generator.csproj: Added reference to Azure.Core.Expressions.DataFactory package

3. Tests: 9 comprehensive unit tests covering:

   • Type creation for string/int/bool/array/model variants
   • Edge cases (non-DFE external type, multiple variants)
   • Serialization using WriteObjectValue pattern
   • Deserialization using DeserializeDataFactoryElement pattern

4. Basic-TypeSpec.tsp: Added DataFactoryElement union patterns with alternateType decorator on DfeExpressionModel

Serialization/Deserialization

The base generator automatically handles DataFactoryElement<T> serialization and deserialization because:

• Serialization uses WriteObjectValue<T> which leverages IJsonModel<T> internally
• Deserialization uses the DeserializeDataFactoryElement static method No changes to KnownAzureTypes.cs were needed.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Support generating DataFactoryElement<> properties in the Azure generator</issue_title> <issue_description>In https://github.com/Azure/azure-sdk-for-net/blob/main/eng/packages/http-client-csharp/generator/Azure.Generator/src/AzureTypeFactory.cs#L66, we need to handle InputUnionType that has a variant type of InputExternalType where the identity is "Azure.Core.Expressions.DataFactoryElement" in a special way. The logic should be that we create a generic type DataFactoryElement<T> where T is given by the other variant in the union. If there is more than one variant we should just log a warning and not apply this specialized logic.

We should update our test spec https://github.com/Azure/azure-sdk-for-net/blob/main/eng/packages/http-client-csharp/generator/TestProjects/Local/Basic-TypeSpec/Basic-TypeSpec.tsp

This shows the full set of supported T values https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/core/Azure.Core.Expressions.DataFactory/src/DataFactoryElementJsonConverter.cs

include uses of this pattern. Here is the tsp:

union Dfe<T> {
  T,
  DfeModel,
}
model DfeModel {
  kind: "Expression";
  value: string;
}

/** A widget. */
@resource("widgets")
model Widget {
  /** The widget name. */
  @key("widgetName")
  @visibility(Lifecycle.Read)
  name: string;

  fooString: Dfe<string>;
  
  fooInt: Dfe<int>;

  fooModel: Dfe<SomeModel>;

  fooList: Dfe<string[]>;


  /** The widget color. */
  color: WidgetColor;

  /** The ID of the widget's manufacturer. */
  manufacturerId: string;
```</issue_description>

## Comments on the Issue (you are @copilot in this section)

<comments>
</comments>

• Fixes Azure/azure-sdk-for-net#54347

---

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

[JoshLove-msft]

@copilot please also add models/properties using alternateType with Dfe to https://github.com/Azure/azure-sdk-for-net/blob/main/eng/packages/http-client-csharp/generator/TestProjects/Local/Basic-TypeSpec/Basic-TypeSpec.tsp

[JoshLove-msft]

@copilot we need to update KnownAzureTypes to handle serialization/deserialization.

[JoshLove-msft]

@copilot we need to update KnownAzureTypes to handle serialization/deserialization.

Or is this already handled automatically? We should add a test that validates ModelReaderWriter is used for these properties.

[Copilot]

@copilot please also add models/properties using alternateType with Dfe to https://github.com/Azure/azure-sdk-for-net/blob/main/eng/packages/http-client-csharp/generator/TestProjects/Local/Basic-TypeS...

Done in 0ea2c90. Added:

• DfeExpressionModel - the expression model
• DfeStringUnion, DfeIntUnion, DfeBoolUnion, DfeStringArrayUnion - union types
• DataFactoryElementModel - model with DFE properties
• @@alternateType decorators mapping to Azure.Core.Expressions.DataFactoryElement
• Operations CreateDataFactoryModel and GetDataFactoryModel

[Copilot]

@copilot we need to update KnownAzureTypes to handle serialization/deserialization.

Or is this already handled automatically? We should add a test that validates ModelReaderWriter is used for the...

Yes, it's handled automatically by the base generator. Added tests in b1eebe7 that validate:

• Serialization uses WriteObjectValue<DataFactoryElement<T>> which internally leverages IJsonModel<T>
• Deserialization uses DeserializeDataFactoryElement static method

No changes to KnownAzureTypes.cs were needed since the base generator already handles types implementing IJsonModel<T> correctly.