Compiler Warning ASPIREPROBES001

Version introduced: 9.5

Probe-related types and members are for evaluation purposes only and are subject to change or removal in future updates. Suppress this diagnostic to proceed.

This diagnostic warning is reported when using experimental health probe APIs in Aspire, including:

• IResourceWithProbes interface
• ProbeAnnotation class and derived types
• ProbeType enumeration
• WithHttpProbe extension methods
• EndpointProbeAnnotation class

These APIs enable configuring HTTP health probes for resources to monitor startup, readiness, and liveness states, similar to Kubernetes health check concepts.

Example

The following code generates ASPIREPROBES001:

C# — Using HTTP probes

var builder = DistributedApplication.CreateBuilder(args);

// Add readiness probe to ensure service is ready before routing traffic
var api = builder.AddProject<Projects.Api>("api")
    .WithHttpProbe(ProbeType.Readiness, "/health/ready");

// Add liveness probe to detect if service needs restart
var worker = builder.AddProject<Projects.Worker>("worker")
    .WithHttpProbe(ProbeType.Liveness, "/health/live");

// Multiple probe types on one resource
var service = builder.AddProject<Projects.Service>("service")
    .WithHttpProbe(ProbeType.Startup, "/health/startup",
        initialDelaySeconds: 15, failureThreshold: 10)
    .WithHttpProbe(ProbeType.Readiness, "/health/ready",
        periodSeconds: 5, timeoutSeconds: 3)
    .WithHttpProbe(ProbeType.Liveness, "/health/live",
        periodSeconds: 30, failureThreshold: 3);

builder.Build().Run();

Understanding health probes

Health probes allow you to configure monitoring for your resources’ health state. Aspire supports three types of probes that align with Kubernetes health check concepts:

Probe types

ProbeType.Startup

• Determines when the application has started successfully
• Runs during container startup before readiness or liveness probes begin
• Useful for applications with long initialization times
• Typically has higher failure thresholds to allow for startup time

ProbeType.Readiness

• Determines when the resource is ready to receive traffic
• If the probe fails, traffic is not routed to the resource
• Useful for checking dependencies like database connectivity
• Can temporarily fail without restarting the container

ProbeType.Liveness

• Detects if the service is still functioning properly
• If the probe fails repeatedly, the resource may be restarted
• Useful for detecting deadlocks or unrecoverable errors
• Should check core application health

Probe configuration

path — The HTTP path to probe (default: ”/”)

initialDelaySeconds — Delay before the first probe execution (default: 5)

periodSeconds — Interval between probe executions (default: 5)

timeoutSeconds — Seconds after which the probe times out (default: 1)

failureThreshold — Consecutive failures before marking as failed (default: 3)

successThreshold — Consecutive successes needed to mark as successful after failure (default: 1)

endpointName — Specific endpoint to probe (optional)

Custom endpoint targeting

C# — Probe specific endpoint

var builder = DistributedApplication.CreateBuilder(args);

// Probe specific endpoint by name
var api = builder.AddProject<Projects.Api>("api")
    .WithHttpEndpoint(8080, name: "management")
    .WithHttpProbe(ProbeType.Readiness, "/actuator/health",
        endpointName: "management");

// Probe with endpoint selector function
var service = builder.AddProject<Projects.Service>("service")
    .WithHttpProbe(ProbeType.Liveness, "/status",
        endpointSelector: () => service.GetEndpoint("https"));

builder.Build().Run();

Integration with resource dependencies

Probes work seamlessly with resource wait dependencies:

C# — Probes with dependencies

var builder = DistributedApplication.CreateBuilder(args);

var database = builder.AddPostgres("postgres");
var cache = builder.AddRedis("redis");

// API with probes that check dependencies
var api = builder.AddProject<Projects.Api>("api")
    .WithHttpProbe(ProbeType.Readiness, "/health/ready")
    .WaitFor(database)
    .WaitFor(cache)
    .WithReference(database)
    .WithReference(cache);

// Frontend waits for API to be ready (not just started)
var frontend = builder.AddProject<Projects.Frontend>("frontend")
    .WaitFor(api)  // Waits for API readiness probe to pass
    .WithReference(api);

builder.Build().Run();

Deployment integration

Probes are automatically configured when deploying to supported compute environments:

• Azure Container Apps — Probes are translated to Container Apps health probes
• Kubernetes — Probes are mapped to Kubernetes liveness, readiness, and startup probes
• Docker Compose — Health checks are configured based on probe settings

To suppress this warning

Suppress the warning with either of the following methods:

• Set the severity of the rule in the .editorconfig file.

  .editorconfig

  [*.{cs,vb}]
  dotnet_diagnostic.ASPIREPROBES001.severity = none

  For more information about editor config files, see Configuration files for code analysis rules.

• Add the following PropertyGroup to your project file:

  C# project file

  <PropertyGroup>
      <NoWarn>$(NoWarn);ASPIREPROBES001</NoWarn>
  </PropertyGroup>

• Suppress in code with the #pragma warning disable ASPIREPROBES001 directive:

  C# — Suppressing the warning

  var builder = DistributedApplication.CreateBuilder(args);
  
  #pragma warning disable ASPIREPROBES001
  var api = builder.AddProject<Projects.Api>("api")
      .WithHttpProbe(ProbeType.Readiness, "/health/ready")
      .WithHttpProbe(ProbeType.Liveness, "/health/live");
  #pragma warning restore ASPIREPROBES001
  
  builder.Build().Run();