[Generator Bug] @@alternateType to armResourceType emits WriteObjectValue instead of WriteStringValue

[live1206]

Description

When @@alternateType maps a property to Azure.Core.armResourceType (C# ResourceType), the generator emits WriteObjectValue(ResourceType, options) for serialization. But WriteObjectValue<T> has no case for ResourceType (which is a readonly struct wrapping a string), so it falls through to the default case and throws:

System.NotSupportedException: Not supported type Azure.Core.ResourceType

This also affects deserialization — the generator emits ResourceType.DeserializeResourceType() which doesn't exist as a public method.

Affected Model (Storage MPG Migration)

• StorageAccountNameAvailabilityContent — spec has type: "Microsoft.Storage/storageAccounts" (constant string), mapped via:

@@alternateType(StorageAccountCheckNameAvailabilityParameters.type, Azure.Core.armResourceType, "csharp");

Impact

This blocks 230 out of 287 tests in the Storage SDK because nearly every test calls CheckStorageAccountNameAvailability during setup.

Current Workaround

Custom [CodeGenSerialization] hooks for both directions:

[CodeGenSerialization(nameof(ResourceType),
    DeserializationValueHook = nameof(DeserializeResourceType),
    SerializationValueHook = nameof(SerializeResourceType))]
public partial class StorageAccountNameAvailabilityContent
{
    private static void SerializeResourceType(Utf8JsonWriter writer, ResourceType resourceType)
    {
        writer.WriteStringValue(resourceType.ToString());
    }

    private static void DeserializeResourceType(JsonProperty property, ref ResourceType resourceType)
    {
        resourceType = new ResourceType(property.Value.GetString());
    }
}

Note: The SerializationValueHook requires regeneration to take effect. The generated file still has WriteObjectValue until regenerated.

Comparison with Native Usage

When armResourceType is used as a native property type (not via @@alternateType), the generator correctly emits WriteStringValue(ResourceType). The bug is specific to the @@alternateType code path.

Works (native): testresourcetype.tsp

model ResourceTypeTestProperties {
  optionalResourceType?: Azure.Core.armResourceType;  // generates WriteStringValue ✓
}

Broken (alternateType): client.tsp

@@alternateType(SomeModel.type, Azure.Core.armResourceType, "csharp");  // generates WriteObjectValue ✗

Related PR

• SDK PR: [Mgmt] Migrate Azure.ResourceManager.Storage from Swagger/AutoRest to TypeSpec #56896

[live1206]

Minimal TypeSpec Repro

Add to eng/packages/http-client-csharp-mgmt/generator/TestProjects/Local/Mgmt-TypeSpec/testresourcetype.tsp:

// Bug repro: @@alternateType mapping a constant string to armResourceType
@doc("Model with a constant string type mapped to armResourceType via alternateType")
model ResourceTypeCheckContent {
  @doc("Name to check")
  name: string;

  @doc("Type of resource, constant string")
  type: "Microsoft.Storage/storageAccounts";
}

Add an operation to expose it (in the same file's ResourceTypeTests interface):

  @doc("Check name availability - repro for alternateType + armResourceType bug")
  @action("checkName")
  checkName is ArmResourceActionSync<ResourceTypeTestResource, ResourceTypeCheckContent, ArmResponse<void>>;

Add to main.tsp:

@@alternateType(ResourceTypeCheckContent.type, Azure.Core.armResourceType, "csharp");
@@clientName(ResourceTypeCheckContent.type, "ResourceType", "csharp");

Result with latest generator

Running pwsh eng/scripts/Generate.ps1 with the latest local generator produces correct code:

// ResourceTypeCheckContent.Serialization.cs line 96
writer.WriteStringValue(ResourceType);  // ✓ correct

However, Storage SDK was generated with emitter version 1.0.0-alpha.20260314.2 (March 14, 2026) and produces broken code:

// StorageAccountNameAvailabilityContent.Serialization.cs line 96
writer.WriteObjectValue(ResourceType, options);  // ✗ throws NotSupportedException

Conclusion

This bug appears to have been already fixed in the latest generator between March 14 and now. Storage just needs regeneration with the latest emitter to pick up the fix.

The [CodeGenSerialization] hooks added as workaround in PR #56896 can be cleaned up after regeneration.

[jsquire]

@live1206: Gentle reminder - please be sure to fully label issues that you're opening. Triage intentionally avoids updating issues opened by team members when an assignment or ang labels are added at creation. You'll need to ensure that you're following the correct pattern of having a single service (pink) and single category (yellow) label. Thanks.