enable-internal-sources.yml runs SetupNugetSources.ps1 (which dot-sources Windows-centric tools.ps1) on Unix

[ViktorHofer]

Problem

eng/common/core-templates/steps/enable-internal-sources.yml invokes SetupNugetSources.ps1 through the PowerShell@2 task on all platforms, including Linux and macOS agents (where PowerShell@2 runs the script under pwsh):

https://github.com/dotnet/arcade/blob/main/eng/common/core-templates/steps/enable-internal-sources.yml

- task: PowerShell@2
  displayName: Setup Internal Feeds
  inputs:
    filePath: $(System.DefaultWorkingDirectory)/eng/common/SetupNugetSources.ps1
    arguments: -ConfigFile $(System.DefaultWorkingDirectory)/NuGet.config

While PowerShell itself is cross-platform, SetupNugetSources.ps1 dot-sources eng/common/tools.ps1:

. $PSScriptRoot\tools.ps1

tools.ps1 carries a number of Windows-only expectations and code paths (VS / MSBuild discovery, vswhere.exe, .exe tool resolution, windowsdesktop runtime paths, etc.). Dot-sourcing it on Unix pulls in a large surface area of Windows-centric logic that is not intended to run cross-platform, making the behavior fragile and surprising on Linux/macOS agents.

Note that a fully equivalent shell implementation already exists: eng/common/SetupNugetSources.sh.

Options to solve

Option 1 — Invoke SetupNugetSources.sh on Unix (preferred / lowest risk)

Branch in enable-internal-sources.yml on Agent.OS and call the matching script:

• PowerShell@2 → SetupNugetSources.ps1 on Windows
• Bash@3 → SetupNugetSources.sh on Linux/macOS

The .sh script already accepts the same inputs (ConfigFile as $1, credential token as $2), so this is a contained YAML change and avoids running tools.ps1 on Unix entirely. This is the recommended fix.

Option 2 — Make SetupNugetSources.ps1 not depend on tools.ps1

The .ps1 only needs a small set of helpers from tools.ps1. Inlining (or extracting into a small, cross-platform-safe shared file) just the functions it actually uses would let it run cleanly under pwsh on any platform without dragging in Windows-only logic. This keeps a single script but requires identifying and isolating the real dependencies.

Option 3 — Rewrite tools.ps1 to be fully cross-platform

The user notes this is likely feasible now. tools.ps1 already has IsWindowsPlatform() guards in several places; a broader pass could make the whole file safe to dot-source on Unix. This is the largest-scope option and affects every consumer of tools.ps1, so it carries the most risk and validation cost, but would remove the underlying foot-gun entirely.

Recommendation

Start with Option 1 (invoke SetupNugetSources.sh on Unix in the template) as the immediate, low-risk fix. Options 2 and 3 can be considered as longer-term cleanups.

Notes

• Files under eng/common are mirrored from Arcade, so the fix must be made here in dotnet/arcade to persist.
• There are existing tests under src/Microsoft.DotNet.SetupNugetSources.Tests that exercise both the .ps1 and .sh scripts and can help validate any change.

[ViktorHofer]

cc @mmitche

[mmitche]

Using the powershell version was largely due to convenience (since pwsh is available) and avoiding two set of steps to enable the sources, one of which will always be skipped.

• To go with option 1, we'll need to verify that SetupNuGetSources.sh is still fully compatible with the .ps1 version. Most repos are using SetupNugetSources.ps1 via the template now, so the .sh doesn't have much use.
• tools.ps1 does have a number of IsWindowsPlatform calls already, so there is a suggestion that we should continue on with this path. How much change is required to fix the break?

[ViktorHofer]

How much change is required to fix the break?

That's already done via e26a2de

This issue is non-tactical, it's about the overall strategy. We can't remove eng/common/tools.sh in favor of powershell due to new platform bring-up and distro partner support. This means that we will need to continue supporting the shell variants. If we now also start supporting the powershell variants on Unix, that means more work and the need for some validation.

I think it would be better to continue using the bash scripts on Unix and the Powershell ones on Windows. If we don't want to pay the cost of having both bash and powershell scripts for CI only workloads (which should have pwsh available), then that's also fine but needs a review of the existing tools.ps1 script or a decoupling from it.

[mmitche]

Fine by me. We should switch over to using SetupNuGetSource.sh then.