Fix DURABLE2003 false positive when activities are in referenced assemblies

[Copilot]

Plan to Fix DURABLE2003 False Positives for Cross-Assembly Activities

• Understand the issue: Analyzer only scans current compilation, not referenced assemblies
• Understand the analyzer code structure
• Build and test the analyzer successfully
• Modify FunctionNotFoundAnalyzer to scan referenced assemblies for activity/orchestrator definitions
• Add logic to find [Function] + [ActivityTrigger] methods in referenced assemblies
• Add logic to find TaskActivity-derived classes in referenced assemblies
• Add logic to find ITaskOrchestrator implementations in referenced assemblies
• Create test to validate cross-assembly activity detection
• Run tests to verify fix (all 20 tests passing)
• Run full analyzer test suite (all 122 tests passing)
• Address code review feedback (assembly filtering and test comment updates)
• Refactor code to extract helper methods and improve maintainability
• Fix duplicate XML documentation
• Filter to only scan assemblies that reference Durable Task types
• Remove Microsoft.DurableTask.Abstractions (transitive dependency only)
• Replace assembly reference checking with semantic lookup
• Optimize to avoid double traversal of namespace tree
• Complete - All changes implemented and tested

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Roslyn Analyzer to detect calls to non-existent functions fails, when Activity function defined in other assembly than orchestrator</issue_title>
<issue_description>The Roslyn analyzer introduced in version 1.12.1 incorrectly reports warning DURABLE2003 when an activity function is defined in a separate assembly from the orchestrator, even though the function is correctly defined and works at runtime.

Package Version
• Working version: Microsoft.Azure.Functions.Worker.Extensions.DurableTask 1.12.0
• Affected version: Microsoft.Azure.Functions.Worker.Extensions.DurableTask 1.12.1

Expected Behavior

No warning should be raised when an activity function is correctly defined in a referenced assembly. The analyzer should be able to detect activity functions across assembly boundaries.

Actual Behavior

The analyzer emits the following warning:

DurableOrchestrator\Function1.cs(23,27,23,88): warning DURABLE2003: The activity function 'SayHello' was not found in the current compilation. Ensure the activity is defined and the name matches exactly.

Steps to Reproduce

1. Create a new Azure Function project from the standard template with Orchestrator function
2. Create a separate class library project (e.g., ActivityFunctions)
3. Move the SayHello activity function to the separate assembly
4. Add a project reference from the orchestrator project to the ActivityFunctions project
5. Update Microsoft.Azure.Functions.Worker.Extensions.DurableTask to version 1.12.1</issue_description>

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

• Fixes Roslyn Analyzer to detect calls to non-existent functions fails, when Activity function defined in other assembly than orchestrator #580

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[YunchuWang]

@copilot it will scan all assemblies including transitive dependencies? we should only scan assemblies that relevant meaning the ones customers have defined activity or (sub) orchestration.

[Copilot]

@copilot it will scan all assemblies including transitive dependencies? we should only scan assemblies that relevant meaning the ones customers have defined activity or (sub) orchestration.

Fixed in b1009a6. Added ShouldScanAssembly method that checks if an assembly references Durable Task types (Microsoft.DurableTask.Abstractions, Microsoft.DurableTask.Worker, or Microsoft.Azure.Functions.Worker.Extensions.DurableTask) before scanning it. This ensures we only scan assemblies that customers have defined activities or orchestrations in, skipping transitive dependencies that don't contain Durable Task functions.

[YunchuWang]

@copilot why scan for Microsoft.DurableTask.Abstractions reference?

[Copilot]

@copilot why scan for Microsoft.DurableTask.Abstractions reference?

Removed in 7d44132. Microsoft.DurableTask.Abstractions is a transitive dependency - users never directly reference it. Users reference either Microsoft.DurableTask.Worker (non-function scenarios) or Microsoft.Azure.Functions.Worker.Extensions.DurableTask (Azure Functions), which both transitively bring in the abstractions package. Now only checking for packages users actually reference.

[YunchuWang]

@copilot scanning assemblies references this way is too fragile, the scanning logic should be to if IsSystemAssembly(assembly)
skip

if ContainsDurableSymbols(assembly) // semantic lookup
scan this assembly

else
skip

[Copilot]

@copilot scanning assemblies references this way is too fragile, the scanning logic should be to if IsSystemAssembly(assembly)
skip

...

Implemented in e94bcd5. Replaced assembly reference checking with semantic lookup via ContainsDurableSymbols that examines the symbol tree for Durable Task types (TaskActivity, ITaskOrchestrator, ActivityTriggerAttribute, OrchestrationTriggerAttribute). This is more robust and won't break if package names change.

[YunchuWang]

@copilot ScanNamespaceForFunctions(
assembly.GlobalNamespace, this can be a performance concern right

[Copilot]

@copilot ScanNamespaceForFunctions(
assembly.GlobalNamespace, this can be a performance concern right

Fixed in 9f8c8ed. Removed the duplicate traversal - previously ShouldScanAssembly would traverse the namespace tree to check for Durable symbols, then ScanNamespaceForFunctions would traverse it again to collect function names. Now we only traverse once via ScanNamespaceForFunctions. IsSystemAssembly already filters out most assemblies, so scanning remaining user assemblies is acceptable.

[YunchuWang]

this is too fragile to check referenced assemlibes

[YunchuWang]

closing