Open
Conversation
Add dotnetExecutor implementing HookExecutor for .NET (C#) hooks with two execution modes: - Project mode: discovers .csproj/.fsproj/.vbproj via walk-up, runs dotnet restore + build during Prepare, then dotnet run --project - Single-file mode: .cs scripts without a project file, validated against .NET 10+ SDK requirement Changes: - pkg/tools/language/dotnet_executor.go: dotnetExecutor implementation - pkg/tools/language/dotnet_executor_test.go: 14 unit tests (project mode, single-file mode, error cases, table-driven) - pkg/tools/dotnet/dotnet.go: add SdkVersion() for version detection - pkg/tools/language/project_discovery.go: add DiscoverDotNetProject() to avoid Python/Node.js project files shadowing .NET project files - cmd/container.go: register HookKindDotNet in hookExecutorMap - test/mocks/mocktools/hook_executors.go: register for test IoC - docs/language-hooks.md: add .NET examples, update status table Closes Azure#7623 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
wbreza
requested review from
JeffreyCA,
hemarina,
jongio,
rajeshkamal5050,
tg-msft and
weikanglim
as code owners
Contributor
There was a problem hiding this comment.
Pull request overview
Adds first-class C#/.NET support to azd’s hook execution framework, enabling .cs hooks to run via the .NET SDK in either project-backed or single-file mode.
Changes:
- Implemented a new
.NET (dotnet)hook executor with Prepare/Execute/Cleanup lifecycle support. - Added .NET-specific project discovery to avoid mixed-language project-file shadowing.
- Extended tooling/tests/docs/IoC registration to enable
.cshook auto-detection and execution.
Reviewed changes
Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| cli/azd/pkg/tools/language/dotnet_executor.go | New HookExecutor implementation for .NET project and single-file execution modes. |
| cli/azd/pkg/tools/language/dotnet_executor_test.go | Unit tests covering Prepare/Execute behavior for both execution modes and error paths. |
| cli/azd/pkg/tools/language/project_discovery.go | Adds DiscoverDotNetProject walk-up discovery for *.*proj files. |
| cli/azd/pkg/tools/dotnet/dotnet.go | Adds SDK version detection via dotnet --version. |
| cli/azd/cmd/container.go | Registers the dotnet hook executor in the common IoC hook executor map. |
| cli/azd/test/mocks/mocktools/hook_executors.go | Registers dotnet CLI + executor in the mock container for tests. |
| cli/azd/pkg/tools/language/executor.go | Updates HookKindDotNet comment now that it’s supported. |
| cli/azd/docs/language-hooks.md | Documents .NET hook usage (project mode, single-file mode, explicit kind). |
jongio
approved these changes
Apr 10, 2026
Member
jongio
left a comment
jongio
left a comment
There was a problem hiding this comment.
Solid implementation. dotnetTools interface, IoC registration, ErrorWithSuggestion usage, and DiscoverDotNetProject all match established executor patterns. Tests cover both modes and error paths thoroughly.
- Add --no-build to dotnet run in project mode since Prepare already runs restore + build, avoiding redundant work - Error on ambiguous project discovery when multiple *.*proj files exist in the same directory, guiding users to set the hook dir field - Add tests for both fixes Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
Author
|
Reply to review thread — \dotnet_executor.go\ (--no-build): Fixed in 3ef113d — added --no-build\ to \dotnet run\ in project mode. Since Prepare already runs \dotnet restore\ + \dotnet build, this avoids redundant restore/build during Execute. Added a test assertion for the flag. Reply to review thread — \project_discovery.go\ (ambiguous matches): Fixed in 3ef113d — \DiscoverDotNetProject\ now returns an error when multiple *.*proj\ files exist in the same directory, with guidance to set the hook \dir\ field. Added a dedicated test case. |
Copilot AI
added a commit
that referenced
this pull request
Apr 10, 2026
Agent-Logs-Url: https://github.com/Azure/azure-dev/sessions/c140f0aa-67af-4e2e-8ec0-98c8bb4906c8 Co-authored-by: trangevi <26490000+trangevi@users.noreply.github.com>
Collaborator
Azure Dev CLI Install InstructionsInstall scriptsMacOS/Linux
bash: pwsh: WindowsPowerShell install MSI install Standalone Binary
MSI
Documentationlearn.microsoft.com documentationtitle: Azure Developer CLI reference
|
trangevi
added a commit
that referenced
this pull request
Apr 11, 2026
* Initial plan * Prepare azure.ai.agents 0.1.22-preview release (#7652) Agent-Logs-Url: https://github.com/Azure/azure-dev/sessions/c140f0aa-67af-4e2e-8ec0-98c8bb4906c8 Co-authored-by: trangevi <26490000+trangevi@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: trangevi <26490000+trangevi@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What Changed
azd now supports C#/.NET hook scripts (
.csfiles) alongside the existing Bash, PowerShell, Python, JavaScript, and TypeScript executors. .NET developers — especially those working with Aspire-based projects — can now write hook automation in C# using either a project-backed approach or single-file scripts.Two execution modes are supported:
.csproj(or.fsproj/.vbproj) is discovered near the script via walk-up, azd automatically runsdotnet restore→dotnet buildduring the Prepare phase, then executes viadotnet run --project..csfiles run directly viadotnet run script.cswithout needing a project file. On older SDKs, a clear error with upgrade guidance is shown.Auto-detection works out of the box — a hook with
run: ./hooks/seed.csautomatically selects the .NET executor. Explicitkind: dotnetoverride is also supported.How It Works
The implementation follows the same
HookExecutorPrepare/Execute/Cleanup lifecycle used by all other language executors. AdotnetToolsinterface decouples the executor from the concretedotnet.Clifor testability, matching thepythonToolsandnodeToolspatterns. A dedicatedDiscoverDotNetProject()function (mirroringDiscoverNodeProject()) walks up from the script to find.NETproject files, avoiding false negatives in mixed-language directories where Python or Node.js files would shadow.csprojin the generic discovery priority list. SDK version detection via a newSdkVersion()method ondotnet.Cligates single-file mode to .NET 10+. Missing SDK errors useErrorWithSuggestionwith install links.Issue References
Resolves #7623
Notes
.fsproj/.vbprojproject discovery works via the existing*.*projglob pattern..csprojor upgrade.