When generating Dataverse entity classes, pac modelbuilder creates a class named Task for the standard Dynamics 365 “Task” entity.
This causes a naming collision with the core .NET class System.Threading.Tasks.Task, which is fundamental for asynchronous operations in C#.
Even though the namespace can be defined manually, the default generation behavior (no namespace) leads to global name conflicts that break async code and reduce maintainability.
The generated entity class is emitted without any namespace by default, for example:
public partial class Task : Microsoft.Xrm.Sdk.Entity
{
// Entity fields and attributes...
}
This causes the compiler to interpret all references to Task as the Dataverse entity instead of System.Threading.Tasks.Task.
As a result, every async method must be explicitly qualified:
public async System.Threading.Tasks.Task ExecuteAsync()
{
await SomeOperationAsync();
}
This is technically valid, but highly impractical for real-world solutions that use async/await extensively.
Although this is not a runtime bug, it represents a design flaw that introduces significant developer friction.
Requiring explicit System.Threading.Tasks.Task qualifications throughout the codebase severely impacts readability, productivity, and code hygiene.
Even though developers can define a custom namespace to avoid the issue, the tool’s default behavior should be safe by design — preventing global symbol collisions by default.
When generating Dataverse entity classes, pac modelbuilder creates a class named Task for the standard Dynamics 365 “Task” entity.
This causes a naming collision with the core .NET class System.Threading.Tasks.Task, which is fundamental for asynchronous operations in C#.
Even though the namespace can be defined manually, the default generation behavior (no namespace) leads to global name conflicts that break async code and reduce maintainability.
The generated entity class is emitted without any namespace by default, for example:
public partial class Task : Microsoft.Xrm.Sdk.Entity
{
// Entity fields and attributes...
}
This causes the compiler to interpret all references to Task as the Dataverse entity instead of System.Threading.Tasks.Task.
As a result, every async method must be explicitly qualified:
public async System.Threading.Tasks.Task ExecuteAsync()
{
await SomeOperationAsync();
}
This is technically valid, but highly impractical for real-world solutions that use async/await extensively.
Although this is not a runtime bug, it represents a design flaw that introduces significant developer friction.
Requiring explicit System.Threading.Tasks.Task qualifications throughout the codebase severely impacts readability, productivity, and code hygiene.
Even though developers can define a custom namespace to avoid the issue, the tool’s default behavior should be safe by design — preventing global symbol collisions by default.