Add AddTasksAsServices extension for registering DurableTask types in DI container

[Copilot]

Summary

What changed?

• Added AddTasksAsServices extension method on IDurableTaskWorkerBuilder that registers all task types (activities, orchestrators, entities) as transient services in the DI container
• Added internal HashSet<Type> collections in DurableTaskRegistry to track types registered via type-based methods (AddActivity(Type), AddOrchestrator(Type), AddEntity(Type))
• Added 7 unit tests covering all scenarios: type registration, singleton instances, function-based tasks, and worker integration

Why is this change needed?

This enables DurableTask types to participate in DI container validation, allowing dependency resolution errors to be detected at startup rather than at runtime. This follows the same pattern as ASP.NET Core's AddControllersAsServices() extension.

Issues / work items

• Related Allow registering Function classes as services in the container #88

---

Project checklist

• Release notes are not required for the next release
• Backport is not required
• All required tests have been added/updated (unit tests, E2E tests)
• Breaking change? No

---

AI-assisted code disclosure (required)

Was an AI tool used? (select one)

• No
• Yes, AI helped write parts of this PR (e.g., GitHub Copilot)
• Yes, an AI agent generated most of this PR

If AI was used:

• Tool(s): GitHub Copilot Agent
• AI-assisted areas/files:
  • src/Abstractions/DurableTaskRegistry.cs - Added HashSet tracking for registered types
  • src/Worker/Core/DependencyInjection/DurableTaskWorkerBuilderExtensions.cs - Added AddTasksAsServices extension
  • test/Worker/Core.Tests/DependencyInjection/DurableTaskWorkerBuilderExtensionsTests.cs - Added comprehensive unit tests
• What you changed after AI output:
  • Updated HashSet initialization from collection expression [] to new HashSet<Type>() to new() based on code review feedback
  • Added test for singleton instance registration behavior based on code review feedback

AI verification (required if AI was used):

• I understand the code and can explain it
• I verified referenced APIs/types exist and are correct
• I reviewed edge cases/failure paths (timeouts, retries, cancellation, exceptions)
• I reviewed concurrency/async behavior
• I checked for unintended breaking or behavior changes

---

Testing

Automated tests

• Result: Passed (75 Worker.Tests pass including 7 new AddTasksAsServices tests)

Manual validation (only if runtime/behavior changed)

• N/A (unit tests provide sufficient coverage)

---

Notes for reviewers

• Only types registered via type-based methods (e.g., AddActivity<T>(), AddOrchestrator<T>()) are registered in DI
• Types registered via factory methods or singleton instances are NOT registered in DI (by design)
• The extension also calls AddTasks() internally, so tasks are registered with both DI and the worker
• Usage example:

builder.Services.AddDurableTaskWorker()
    .AddTasksAsServices(tasks =>
    {
        tasks.AddActivity<MyActivity>();
        tasks.AddOrchestrator<MyOrchestrator>();
        tasks.AddEntity<MyEntity>();
    });

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Request] Add extension to register all functions as services in DI container</issue_title>
<issue_description># Proposal

Introduce a new AddFuncitonsAsServices extension method on IFunctionsWorkerApplicationBuilder that automatically registers every function class detected by the functions framework in the dependency injection container.

This allows all function classes to participate in the container's self-checking logic during startup of the project, preventing runtime errors much later when actually executing specific functions if dependencies cannot be resolved.

Background

AspNetCore MVC provides a AddControllersAsServices() extension that registers all controllers in the container automatically.

This not only enables things such as being able to decorate controller classes via the container, but more importantly it allows controller classes to participate in the Microsoft DI container self-checking mechanism, which iterates through all services registered in the container and checks whether or not their dependencies can be resolved. This mechanism is enabled by default while in debug mode and allows developers to catch DI-related errors much earlier in the pipeline: the validation error is raised during container construction, instead of only during a specific call to the affected controller action.

My proposal is that a similar extension be created for functions/durable functions, which would allow consumers to easily add all functions as services. A potential name for such extension could be AddFuncitonsAsServices(), for consistency.

While consumers can register functions manually themselves and still have them participate in the container self-check process, this approach is error-prone, creates coupling with the durable tasks library, and potentially duplicates logic: users would be tasked with creating their own logic to "detect" all function classes, which is something that the functions framework already does to perform its main job. The alternative is to manually register each individual function as separate calls, which not only doesn't scale well, but is fairly noisy, leads to situations where some functions are forgotten to be registered (which could then potentially lead to runtime issues being detected only after deployment), and also forces developers to remember to add a registration whenever they create a new function.

If the team is resistant to adding such helper extension, the framework should at least expose discovered functions in some sort of callback so that consumers could then register those types themselves without having to replicate the function detection logic.

This is a spin-off of:

• Allow registering Function classes as services in the container #88</issue_description>

Comments on the Issue (you are @copilot in this section)

@jviau Oh, your request is for Azure Functions as a whole and not just Durable. This request would belong in https://github.com/Azure/azure-functions-dotnet-worker

However, there would be an applicable request for Durable as well, for registering all tasks on DurableTaskRegistry to the IServiceCollection. This issue can be repurposed for that functionality request.</comment_new>

• Fixes [Request] Add extension to register all functions as services in DI container #107

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[Copilot]

Pull request overview

This PR adds the AddTasksAsServices extension method to enable DurableTask types (activities, orchestrators, entities) to participate in DI container validation, allowing dependency resolution errors to be detected at startup rather than at runtime.

Key Changes:

• Added internal HashSet collections in DurableTaskRegistry to track types registered via type-based methods
• Implemented AddTasksAsServices extension that extracts registered types and registers them as transient services
• Added comprehensive test coverage for the new functionality

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/Abstractions/DurableTaskRegistry.cs	Added internal HashSet properties to track activity, orchestrator, and entity types
src/Abstractions/DurableTaskRegistry.Activities.cs	Modified AddActivity(TaskName, Type) to track type in ActivityTypes collection
src/Abstractions/DurableTaskRegistry.Orchestrators.cs	Modified AddOrchestrator(TaskName, Type) to track type in OrchestratorTypes collection
src/Abstractions/DurableTaskRegistry.Entities.cs	Modified AddEntity(TaskName, Type) to track type in EntityTypes collection
src/Worker/Core/DependencyInjection/DurableTaskWorkerBuilderExtensions.cs	Added AddTasksAsServices extension method with XML documentation and implementation
test/Worker/Core.Tests/DependencyInjection/DurableTaskWorkerBuilderExtensionsTests.cs	Added comprehensive test suite including tests for activities, orchestrators, entities, function-based tasks, and worker registration

[YunchuWang]

@copilot address comments

[YunchuWang]

@copilot update pr description to follow .github/PULL_REQUEST_TEMPLATE.md

[Copilot]

@copilot address comments

All comments have been addressed:

1. HashSet initialization already uses target-typed new() syntax (commit b490b9c)
2. Added test for singleton instance registration behavior (commit 88c4998)

All 7 AddTasksAsServices tests pass.

[Copilot]

@copilot update pr description to follow .github/PULL_REQUEST_TEMPLATE.md

Updated PR description to follow the template in .github/PULL_REQUEST_TEMPLATE.md:

Summary

What changed?

• Added AddTasksAsServices extension method on IDurableTaskWorkerBuilder that registers all task types (activities, orchestrators, entities) as transient services in the DI container
• Added internal HashSet<Type> collections in DurableTaskRegistry to track types registered via type-based methods (AddActivity(Type), AddOrchestrator(Type), AddEntity(Type))
• Added 7 unit tests covering all scenarios: type registration, singleton instances, function-based tasks, and worker integration

Why is this change needed?

This enables DurableTask types to participate in DI container validation, allowing dependency resolution errors to be detected at startup rather than at runtime. This follows the same pattern as ASP.NET Core's AddControllersAsServices() extension.

Issues / work items

• Related Allow registering Function classes as services in the container #88

---

Project checklist

• Release notes are not required for the next release
• Backport is not required
• All required tests have been added/updated (unit tests, E2E tests)
• Breaking change? No

---

AI-assisted code disclosure (required)

Was an AI tool used? (select one)

• No
• Yes, AI helped write parts of this PR (e.g., GitHub Copilot)
• Yes, an AI agent generated most of this PR

If AI was used:

• Tool(s): GitHub Copilot Agent
• AI-assisted areas/files:
  • src/Abstractions/DurableTaskRegistry.cs - Added HashSet tracking for registered types
  • src/Worker/Core/DependencyInjection/DurableTaskWorkerBuilderExtensions.cs - Added AddTasksAsServices extension
  • test/Worker/Core.Tests/DependencyInjection/DurableTaskWorkerBuilderExtensionsTests.cs - Added comprehensive unit tests
• What you changed after AI output:
  • Updated HashSet initialization from collection expression [] to new HashSet<Type>() to new() based on code review feedback
  • Added test for singleton instance registration behavior based on code review feedback

AI verification (required if AI was used):

• I understand the code and can explain it
• I verified referenced APIs/types exist and are correct
• I reviewed edge cases/failure paths (timeouts, retries, cancellation, exceptions)
• I reviewed concurrency/async behavior
• I checked for unintended breaking or behavior changes

---

Testing

Automated tests

• Result: Passed (75 Worker.Tests pass including 7 new AddTasksAsServices tests)

Manual validation (only if runtime/behavior changed)

• N/A (unit tests provide sufficient coverage)

---

Notes for reviewers

• Only types registered via type-based methods (e.g., AddActivity<T>(), AddOrchestrator<T>()) are registered in DI
• Types registered via factory methods or singleton instances are NOT registered in DI (by design)
• The extension also calls AddTasks() internally, so tasks are registered with both DI and the worker
• Usage example:

builder.Services.AddDurableTaskWorker()
    .AddTasksAsServices(tasks =>
    {
        tasks.AddActivity<MyActivity>();
        tasks.AddOrchestrator<MyOrchestrator>();
        tasks.AddEntity<MyEntity>();
    });

[YunchuWang]

verified working as expected

[halspang]

Does this solve the initial ask of the issue? It seems like we are adding the types, yes, but they were asking specifically about named types.

[YunchuWang]

issue is fixed already closing it