.NET — Support Post‑Emit Execution Step in .NET Emitter

[lirenhe]

Context

We got the ask from Foundry team that there is a general requirement for post‑generation scripts to update the generated code.
e.g. update code emitter outputs and to deal with emitted code issues that service team hasn't decided the correct approach for yet.

Within team discussion, people suggested that this should be treated as a general emitter capability, not a language‑specific workaround. And Emitter‑level support is the preferred long‑term model.

Proposal

Add post‑emit execution support in the .NET emitter
The emitter should invoke a script after code emission but before downstream pipeline steps

[ArthurMa1978]

First, we need to clarify what kinds of changes cannot be expressed in TypeSpec or configured through code generation or emitters. I understand that in the data plane there are many client behaviors that cannot be modeled by TypeSpec and therefore require handwritten code. Given that, what is the concrete justification for still introducing post-generation hook support?
From my perspective, a more robust and sustainable approach would be to improve the expressiveness of TypeSpec so it can model more complex scenarios and common client-side logic patterns. If a scenario cannot be reasonably described in TypeSpec, then writing the code manually is still preferable to relying on post-generation hooks.
Finally, there are security concerns with exposing this kind of hook mechanism. Does the emitter take responsibility for validating or auditing code changes introduced by external scripts, and if so, how is that enforced?