@copilot Repos can have a global.json which should definitely override the specified version in the frontmatter. This would then be used in the install task. I think there is a flag like useGlobalJson: true in the task. We should detect the presence of the global.json as a compiler error if the frontmatter specified a version. we should allow a special version specifier called global.json or similar that will take the version from global.json always by setting useglobalJson to true. Double check my assertions here.

@copilot Repos can have a global.json which should definitely override the specified version in the frontmatter. This would then be used in the install task. I think there is a flag like useGlobalJs...

Confirmed your assertions against the Microsoft Learn docs for UseDotNet@2 — useGlobalJson: true is the right knob, and when set the explicit version input is ignored. Implemented in 95888df:

• version: "global.json" (case-insensitive) → emits useGlobalJson: true (no version: input) with displayName Install .NET SDK (from global.json).
• If runtimes.dotnet.version is set to a concrete value AND a global.json exists at the agent's compile dir, compilation now errors out, telling the user to either drop the version or set it to "global.json".
• No-version + on-disk global.json is still allowed (default 8.0.x is used) — users opt into useGlobalJson explicitly with the sentinel rather than auto-promoting.
• Added 6 new tests; compile_dir is now plumbed through CompileContext so validators can probe the workspace.

/rust-review

@copilot Repos can have a global.json which should definitely override the specified version in the frontmatter. This would then be used in the install task. I think there is a flag like useGlobalJs...

Confirmed your assertions against the Microsoft Learn docs for UseDotNet@2 — useGlobalJson: true is the right knob, and when set the explicit version input is ignored. Implemented in 95888df:

• version: "global.json" (case-insensitive) → emits useGlobalJson: true (no version: input) with displayName Install .NET SDK (from global.json).
• If runtimes.dotnet.version is set to a concrete value AND a global.json exists at the agent's compile dir, compilation now errors out, telling the user to either drop the version or set it to "global.json".
• No-version + on-disk global.json is still allowed (default 8.0.x is used) — users opt into useGlobalJson explicitly with the sentinel rather than auto-promoting.
• Added 6 new tests; compile_dir is now plumbed through CompileContext so validators can probe the workspace.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

That'll do for now - we need to iron out config files in the future, but TODO!

✅ Rust PR Reviewer completed successfully!

🔍 Rust PR Review

Summary: Looks good overall — well-structured extension following the established pattern, thorough test coverage, correct validation. Two minor issues worth addressing.

Findings

🔒 Security Concerns

• src/runtimes/dotnet/mod.rs:222 — generate_ensure_nuget_config echoes the feed URL inside double quotes:

  echo \"Created nuget.config with source={feed_url}\"

  The {feed_url} is inlined by Rust's format!, but in the generated bash script any bare $IDENTIFIER or backtick patterns in that literal string will be expanded at runtime. validate_feed_url blocks $(...) ADO expressions but not bare $VAR references or backtick command substitution. The node runtime uses single-quoted echo throughout (lines 161-162 of node/mod.rs), which is immune to all shell expansion. Fix: change to echo 'Created nuget.config with source={feed_url}'.

⚠️ Suggestions

• src/runtimes/dotnet/extension.rs — validate block for config — the comment says:

  the path itself is user-supplied and ends up in displayName/log output

  But generate_nuget_authenticate() takes no arguments and emits a fixed string — the config value is never embedded anywhere in the generated YAML. The comment is misleading for future contributors (it reads like there's an injection risk that exists, when the value is simply never emitted). Either remove the comment or add the field to a future displayName.

✅ What Looks Good

• Heredoc uses <<'EOF' (single-quoted) — the XML content including the feed URL is fully protected from shell expansion at runtime. Correct.
• validate_feed_url is called on feed-url (blocks ", ', $(, ##vso[, newlines) while the simpler reject_pipeline_injection is correctly used for version (which doesn't go through XML or echo).
• global.json sentinel logic is clean: case-insensitive comparison, injection check skipped for the literal keyword (tested), and the on-disk conflict detection correctly uses ctx.compile_dir which is always Some in production paths.
• Mutual exclusivity between config and feed-url is enforced and tested.
• compile_dir: Option<&'a Path> threading through CompileContext is a clean approach that keeps on-disk probing test-friendly via for_test_with_compile_dir.
• 18 dedicated tests with good boundary coverage.

Generated by Rust PR Reviewer for issue #435 · ● 1.3M · ◷

@copilot implement suggestions and fixes for bug

@copilot implement suggestions and fixes for bug

Addressed both rust-review findings in 91cbe6c:

• Switched the Created nuget.config with source={feed_url} echo to single quotes in src/runtimes/dotnet/mod.rs, matching the node runtime convention. With double quotes, any $VAR / backtick characters that slipped past validate_feed_url (which only blocks $(, ADO ##vso[, quotes and newlines) could have been expanded by bash at agent runtime.
• Rewrote the comment above validate::reject_pipeline_injection for runtimes.dotnet.config to accurately describe the check as defence-in-depth (the value is never currently embedded in the generated YAML — NuGetAuthenticate@1 auto-discovers nuget.config).

All 18 dotnet tests still pass; clippy reports no new warnings.