Skip to content

[repo-assist] Fall back to User/Machine scoped environment variables in paket.dependencies - #4406

Merged
dsyme merged 1 commit into
masterfrom
repo-assist/fix-issue-3562-user-env-vars-f9a2f06cb5ebb50f
Aug 30, 2026
Merged

dsyme merged 1 commit into
masterfrom
repo-assist/fix-issue-3562-user-env-vars-f9a2f06cb5ebb50f

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

🤖 This PR was authored by Repo Assist, an automated AI assistant.

Root cause

EnvironmentVariable.Create (used to resolve %VAR% references in paket.dependencies, e.g. for credentials) called Environment.GetEnvironmentVariable(name), which only reads the current process's environment block. Variables set at the User or Machine scope via [System.Environment]::SetEnvironmentVariable(name, value, 'User') are persisted (e.g. in the Windows registry) but are not reflected in an already-running process's environment — a new process must be started to see them. This caused Paket to warn environment variable '%VAR%' not found even though the variable was correctly set, as reported in #3562.

Fix

EnvironmentVariable.Create now falls back to explicitly querying the User and Machine EnvironmentVariableTarget scopes when the Process scope lookup misses, before giving up and warning. PlatformNotSupportedException (thrown on non-Windows platforms, where these scopes don't exist) is caught so the fallback is a safe no-op there.

Trade-offs

  • Slightly more work per variable lookup (up to 2 extra GetEnvironmentVariable calls) only in the miss case; negligible cost since credential resolution happens rarely (parse-time).
  • No change in behavior for variables already resolvable at Process scope — same value, same order of preference (Process wins if a variable is defined at multiple scopes, matching normal Windows semantics).

Closes #3562

Test Status

  • Added two unit tests in PackageSourceSpecs.fs — resolving a process-level env var, and warning/empty-value for an unknown var.
  • dotnet test tests/Paket.Tests/Paket.Tests.fsproj --filter "FullyQualifiedName~PackageSourceSpecs": 16/16 passed on net9.0. The net461 target could not execute in this sandbox (mono host not installed) — this is an environment limitation, not a code failure; the same assembly built successfully for both target frameworks.

Generated by 🌈 Repo Assist, see workflow run. Learn more.
Comment /repo-assist to run again

Add this agentic workflow to your repo

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@ae8d551f07c7ed7619f8c58c7bb4c3ac89395d38

…dencies

Environment.GetEnvironmentVariable(name) only reads the current
process's environment block, which doesn't reflect variables set at
the User or Machine level via SetEnvironmentVariable until a new
process is started. This caused '%VAR%' references in
paket.dependencies to fail to resolve for such variables.

Now falls back to explicitly reading the User and Machine scopes
(Windows-only concept; PlatformNotSupportedException is caught on
other platforms) when the process-level lookup misses.

Closes #3562

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@dsyme
dsyme marked this pull request as ready for review August 29, 2026 22:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

paket.dependencies cannot resolve user level environment variables

1 participant