Why "Scope Validation" is being done only at "Development" environment

[fkucuk]

Great article. But I wonder why the "Scope Validation" is being done at "Development" environment?

We've just noticed that a Net6 application throwing exeption (Cannot consume scoped service 'My Interface registered as Scoped' from singleton 'Microsoft.Extensions.Hosting.IHostedService'.) on my computer while building perfectly on my collegue's machine. And we realized that my friend has no Development environment variable which caused the application to run in production mode.

https://docs.microsoft.com/en-us/dotnet/core/extensions/dependency-injection#scope-validation

I mean why .Net is validating the scope only in development environment? Isn't that confusing?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 8fd55089-b683-2202-6641-c7b61a132f14
• Version Independent ID: cc5f00d0-fb50-1229-8fa2-e66b1f45b284
• Content: Dependency injection in .NET
• Content Source: docs/core/extensions/dependency-injection.md
• Product: dotnet-fundamentals
• GitHub Login: @IEvangelist
• Microsoft Alias: dapine

[IEvangelist]

Hi 👋 @fkucuk
Thank you so much for posting this issue. We really appreciate it.

I wonder why the "Scope Validation" is being done at "Development" environment?

This is the pattern as the most common environments are either "Development" or "Production". The Properties/lanuchSettings.json file is usually source controlled and part of all the templates for .NET 6. With that said, it sets the environment:

{
  "profiles": {
    "Example.Project": {
      "commandName": "Project",
      "launchBrowser": true,
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "applicationUrl": "https://localhost:56599;http://localhost:56600"
    }
  }
}

The reason this is done, is to ensure that while you're actively developing the app any possible dependency issues will be immediately raised. When you're running in a production environment you'll get the same issue, but at the call site in which the DI infrastructure attempts to resolve a dependency. In dev you just get them earlier. Does that make sense?

[haridasnykiel]

Hi @IEvangelist, Why is this designed this way? In my mind it would make more sense to default the validate scope to true and have a configuration that will set it to false is required.

[IEvangelist]

Hi @IEvangelist, Why is this designed this way? In my mind it would make more sense to default the validate scope to true and have a configuration that will set it to false is required.

Hi @haridasnykiel - that's a product question, you could ask them in the dotnet/runtime repo and reference this issue.