fix(http-server-csharp): fix model file name when @friendlyName contains unresolved template placeholders

[Copilot]

When @friendlyName stores a format string with {paramName} placeholders that weren't substituted (e.g. {name}TagsUpdate), the generated file was named {name}TagsUpdate.cs while the class inside was correctly named NameTagsUpdate — a discrepancy caused by the class name going through pascalCase() (which treats {/} as word separators) while the file path used the raw string.

Changes

• src/components/models/model-helpers.ts — In getModelEmitName, sanitize the @friendlyName return value by replacing {paramName} placeholders with their PascalCase equivalents before using the name as a file path:

  return friendlyName.replace(/\{(\w+)\}/g, (_, n) => n.charAt(0).toUpperCase() + n.slice(1));

  {name}TagsUpdate → NameTagsUpdate.cs, matching the emitted class name.

• test/generation.test.ts — Regression test: verifies that a model decorated with @friendlyName("{name}TagsUpdate") produces NameTagsUpdate.cs with no literal {name} in the output path.

• Fixes [Bug]: http-server-csharp: Generated model file for NameTagsUpdate is {name}TagsUpdate.cs #11454

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).
1 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@typespec/compiler@11459

npm i https://pkg.pr.new/@typespec/http-server-csharp@11459

commit: dfd71f3

[azure-sdk-automation]

You can try these changes here

🛝 Playground	🌐 Website	🛝 VSCode Extension

[github-actions]

❌ There is undocummented changes. Run chronus add to add a changeset or click here.

The following packages have changes but are not documented.

• ❌@typespec/compiler

Show changes

@typespec/http-server-csharp - fix ✏️

Fix generated model file name when @friendlyName contains unresolved template parameter placeholders such as {name} (e.g. {name}TagsUpdate). The file is now named using the PascalCase expansion of the placeholder (e.g. NameTagsUpdate.cs) instead of the literal {name}TagsUpdate.cs.

[timotheeguerin]

@copilot we should never get to state where decorators are run with TemplateParameter passed to them , how did that happen? We should fix that even more upstream(in checker probably), and make sure to add a minimal regression test for that

[Copilot]

Good catch. After investigating, the decorator is not actually called with TemplateParameter arguments in the first place — the checker already prevents it by setting skipDecorators: true when checking template declarations (checkModelStatement, checkInterface, etc.). The guard I had placed in decorators.ts was therefore at the wrong layer and solving a phantom problem.

Fixed in the latest commit:

1. Removed the guard from decorators.ts — it was incorrect and misleading.

2. Added an explicit guard in applyDecoratorToType (checker.ts) — this is the right place. The check skips the decorator if any argument is a TemplateParameter or TemplateParameterAccess. The checker's skipDecorators: true already prevents this path for normal template declarations, but this guard makes the protection explicit and future-proof.

3. Updated the decorators.test.ts test — corrected the description to accurately explain the mechanism (skipDecorators: true in the checker, not a guard in the decorator), and retained the assertion that template declarations don't get unresolved friendly names while instantiations get correctly substituted names.

The existing tests in packages/compiler/test/checker/templates.test.ts (the "doesn't run decorators when checking template declarations" suite) already provide the minimal regression test for this behavior — they use @mark(T) with fail() to confirm the decorator is never invoked with an unresolved template parameter.