microsoft/aspire · error · ArgumentNullException

Object reference not passed for parameter 'args'…

Error message

Object reference not passed for parameter 'args' (ArgumentNullException: args)

What it means

RustCargoArgsCallbackContext's constructor guards its 'args' parameter with 'args ?? throw new ArgumentNullException(nameof(args))'. The Args list is the mutable output the callback populates with cargo-level command-line arguments, so it must always be a live list instance. Passing null is treated as a caller bug and rejected immediately at construction.

Solutions

Pass a real list instance, e.g. new List<string>(), for the args parameter
Initialize the argument-list field/property before constructing the context
Fix any producer method so it returns an empty list rather than null

Example fix

// before
IList<string>? args = config.GetArgs(); // may return null
var context = new RustCargoArgsCallbackContext(resource, args, ct);
// after
IList<string> args = config.GetArgs() ?? new List<string>();
var context = new RustCargoArgsCallbackContext(resource, args, ct);

Defensive patterns

Strategy: type-guard

Validate before calling

if (args is null) throw new InvalidOperationException("Callback context requires a non-null args list.");

Type guard

bool HasArgsList(IList<string>? a) => a is not null;

Try / catch

try { var ctx = new RustCargoArgsCallbackContext(resource, args, ct); } catch (ArgumentNullException ex) when (ex.ParamName == "args") { log.LogError(ex, "Null args list for callback context"); }

Prevention

Default nullable list producers to an empty list with ?? new List<string>()
Keep constructor argument order (resource, args, token) consistent to avoid passing the wrong variable
Initialize argument-list fields at declaration

When it happens

Trigger: Constructing RustCargoArgsCallbackContext directly with a null IList<string> for args — e.g. a field that was never initialized, a method returning null on some path, or a misordered constructor call passing the wrong variable.

Common situations: Unit tests building callback contexts by hand; custom pipelines assembling the context where the argument list comes from a nullable source; refactoring that swapped the resource and args parameters.

Related errors

AI-assisted analysis of microsoft/aspire@25830f84bd (2026-09-16). Data as JSON: /api/errors/59bd38266b9aea09. Report an issue: GitHub.

Appendix: source

Thrown at src/Aspire.Hosting.Rust/RustCargoArgsCallbackAnnotation.cs:61

/// starts, so there is nothing for a deferred value such as an endpoint reference to resolve against;
/// those belong after the <c>--</c> separator and are added with <c>WithArgs</c>.
/// </remarks>
public sealed class RustCargoArgsCallbackContext(RustAppResource resource, IList<string> args, CancellationToken cancellationToken = default)
{
    /// <summary>
    /// Gets the Rust application resource whose cargo arguments are being built.
    /// </summary>
    /// <remarks>
    /// The same callbacks run for both the local <c>cargo run</c> command line and the generated
    /// Dockerfile, so a callback that needs to know which resource it is configuring — or that needs to
    /// read annotations placed on it — reads them from here rather than capturing the resource itself.
    /// </remarks>
    public RustAppResource Resource { get; } = resource ?? throw new ArgumentNullException(nameof(resource));

    /// <summary>
    /// Gets the list of command-line arguments.
    /// </summary>
    public IList<string> Args { get; } = args ?? throw new ArgumentNullException(nameof(args));

    /// <summary>
    /// Gets the cancellation token associated with the callback context.
    /// </summary>
    public CancellationToken CancellationToken { get; } = cancellationToken;
}

View on GitHub (pinned to 25830f84bd)