[http-client-csharp] Custom-code attribute providers need supported opt-out from source input views

[ArcturusZhang]

Problem

#10981 added CodeModelGenerator.AddCustomCodeAttributeProvider(TypeProvider provider), which lets derived C# generators register generator-specific custom-code attributes without mutating CustomCodeAttributeProviders via reflection. Azure management has started using this for a management-specific attribute provider (CodeGenResourceDataAttributeDefinition) in Azure/azure-sdk-for-net#59851.

However, there is still a root-cause gap when the contributed provider is a normal TypeProvider outside the Microsoft.TypeSpec.Generator assembly.

Real generation path

In CSharpGen.ExecuteAsync, the generator adds custom-code attribute providers to the custom-code workspace before SourceInputModel is initialized:

`csharp
GeneratedCodeWorkspace customCodeWorkspace = await GeneratedCodeWorkspace.Create(isCustomCodeProject: true);

foreach (var attributeProvider in CodeModelGenerator.Instance.CustomCodeAttributeProviders)
{
generateAttributeTasks.Add(customCodeWorkspace.AddInMemoryFile(attributeProvider));
}

await Task.WhenAll(generateAttributeTasks);

CodeModelGenerator.Instance.SourceInputModel = new SourceInputModel(
await customCodeWorkspace.GetCompilationAsync(),
await GeneratedCodeWorkspace.LoadBaselineContract());
`

AddInMemoryFile(attributeProvider) writes the provider. For a normal TypeProvider, this can touch the provider's lazy CustomCodeView / LastContractView. Since SourceInputModel has not been initialized yet, generation crashes with:

ext SourceInputModel has not been initialized yet at Microsoft.TypeSpec.Generator.CodeModelGenerator.get_SourceInputModel() at Microsoft.TypeSpec.Generator.Providers.TypeProvider.BuildCustomCodeView(...) at Microsoft.TypeSpec.Generator.Providers.TypeProvider.get_CustomCodeView() at Microsoft.TypeSpec.Generator.Providers.TypeProvider.get_Type() at Microsoft.TypeSpec.Generator.Providers.TypeProvider.get_Name() at Microsoft.TypeSpec.Generator.GeneratedCodeWorkspace.AddInMemoryFile(TypeProvider type)

Why built-in CodeGen attributes work

Built-in providers such as CodeGenTypeAttributeDefinition avoid this by overriding:

csharp private protected sealed override NamedTypeSymbolProvider? BuildCustomCodeView(...) => null; private protected sealed override NamedTypeSymbolProvider? BuildLastContractView(...) => null;

That is the right behavior for generated attribute definitions: the attribute definition itself should not participate in source-input customization lookup.

But these methods are private protected, so a derived generator in another assembly (for example Azure management) cannot override them.

Base test does not catch this path

The current base test for the new extension point manually adds the provider syntax tree into a mock compilation:

csharp return compilation.AddSyntaxTrees(GeneratedCodeWorkspace.GetTree(customAttributeProvider));

That happens in a test helper path where SourceInputModel is already mocked/available, so it does not reproduce the real CSharpGen.ExecuteAsync ordering above.

Current downstream workaround

Azure management can use the new AddCustomCodeAttributeProvider(...) API to avoid reflection for provider registration, but it still needs a workaround to suppress source-input views on its contributed attribute provider. The downstream provider currently has to mutate TypeProvider private lazy fields via reflection so CustomCodeView and LastContractView return null.

Request

Please provide a supported way for contributed custom-code attribute providers to opt out of source-input views, or adjust the custom-code attribute provider writing path so it does not evaluate CustomCodeView / LastContractView before SourceInputModel is initialized.

Possible options:

1. Make BuildCustomCodeView / BuildLastContractView overridable by derived generator assemblies (protected internal or a dedicated protected opt-out property/method).
2. Add a base CustomCodeAttributeDefinition provider type that derived generators can inherit from, with source-input views disabled.
3. Update GeneratedCodeWorkspace.AddInMemoryFile or the custom-code attribute provider path to write attribute providers without evaluating customization views.
4. Extend AddCustomCodeAttributeProvider to wrap/mark providers as attribute definitions that should not resolve source-input views.

Related downstream PR

Azure SDK for .NET PR: Azure/azure-sdk-for-net#59851

The first extension point from #10981 helps, but this remaining issue prevents downstream generators from fully removing reflection workarounds.

[github-actions]

🎯 Issue Triage

The AddCustomCodeAttributeProvider API (introduced in #10981) crashes when a contributed provider is a normal TypeProvider from an external assembly, because BuildCustomCodeView/BuildLastContractView are private protected and cannot be overridden outside Microsoft.TypeSpec.Generator. The request is to expose a supported way for downstream generators to opt out of source-input view evaluation for custom-code attribute providers.

Category: Feature Request
Area: emitter:client:csharp

🔍 Analysis

• Crash path: CSharpGen.ExecuteAsync calls AddInMemoryFile(attributeProvider) on custom-code attribute providers before SourceInputModel is initialized. Built-in providers (e.g., CodeGenTypeAttributeDefinition) avoid this by overriding BuildCustomCodeView/BuildLastContractView to return null, but these methods are private protected sealed — inaccessible to external assemblies.
• Affected component: Microsoft.TypeSpec.Generator / CSharpGen in http-client-csharp
• Related issue: [http-client-csharp] Expose extension point for custom-code attribute providers #10981 (introduced the AddCustomCodeAttributeProvider API)
• Downstream impact: Azure SDK management generators must currently use reflection to mutate private lazy fields — exactly the workaround the API was meant to eliminate (see Add mgmt CodeGenResourceData customization Azure/azure-sdk-for-net#59851).
• Proposed fixes (from reporter): (1) make override methods protected internal; (2) add a base CustomCodeAttributeDefinition type with views disabled; (3) adjust AddInMemoryFile to skip source-input view evaluation for attribute providers; (4) wrap/mark providers inside AddCustomCodeAttributeProvider.
• Test gap: The existing base test mocks SourceInputModel availability, so it does not reproduce the real execution ordering in CSharpGen.ExecuteAsync.

📝 Suggested next steps

• Choose one of the four proposed fixes
• Update the base test to cover the real CSharpGen.ExecuteAsync ordering where SourceInputModel is not yet initialized when attribute providers are written
• Verify the Azure SDK downstream can remove its reflection workaround after the fix

Generated by Agentic Triage