Skip to content

Document that C# script steps require the .NET SDK - #3333

Draft
NickJosevski wants to merge 1 commit into
mainfrom
nj/csharp-script-sdk-requirement
Draft

Document that C# script steps require the .NET SDK#3333
NickJosevski wants to merge 1 commit into
mainfrom
nj/csharp-script-sdk-requirement

Conversation

@NickJosevski

@NickJosevski NickJosevski commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

C# scripts (.csx) run through dotnet-script, which always shells out to dotnet restore — even for a script with no NuGet references — so the machine running the step needs the .NET SDK, not just the runtime. That machine is a deployment target, a worker, or the Octopus Server.

This has been true since the scriptcs → dotnet-script migration, but was only ever stated in a 2021 blog post that is now stale on the version. A runtime-only target fails with:

Unable to restore packages from '/root/.cache/dotnet-script/work/net8.0/script.csproj'
Make sure that all script files contains valid NuGet references

which points people at their NuGet references rather than the missing SDK. The docs now quote that message so a search for it lands here.

Changes

  • deployments/custom-scripts/index.md — new "C# script requirements" section
  • infrastructure/deployment-targets/linux/ssh-requirements.md — its .NET section said the opposite, which is true for self-contained Calamari but not for C# scripts
  • projects/variables/system-variables.md — only one NuGet source can be supplied via Octopus.Action.Script.CSharp.NuGetSource, and it replaces the default rather than adding to it

No SDK version is named. dotnet-script derives the generated project's target framework from whichever runtime the dotnet on the path resolves, so the requirement is relative to that runtime rather than a number that would go stale the way the blog post's net6.0 did.

Docs only.

🤖 Generated with Claude Code

@NickJosevski
NickJosevski marked this pull request as draft August 11, 2026 02:12
C# scripts (.csx) run through dotnet-script, which always shells out to
`dotnet restore` -- even for a script with no NuGet references -- so the
machine running the step needs the .NET SDK, not just the runtime.

This has been true since the scriptcs to dotnet-script migration, but was
only ever stated in a 2021 blog post that is now stale on the version. A
runtime-only target fails with "Unable to restore packages from
'.../script.csproj' / Make sure that all script files contains valid NuGet
references", which points people at their NuGet references rather than the
missing SDK. The docs now quote that message so a search for it lands here.

- custom-scripts/index.md: new "C# script requirements" section
- linux/ssh-requirements.md: its ".NET" section said the opposite, which is
  true for self-contained Calamari but not for C# scripts
- system-variables.md: only one NuGet source can be supplied via
  Octopus.Action.Script.CSharp.NuGetSource, and it replaces the default

No SDK version is named. dotnet-script derives the generated project's
target framework from whichever runtime the `dotnet` on the path resolves,
so the requirement is relative to that runtime.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@NickJosevski
NickJosevski force-pushed the nj/csharp-script-sdk-requirement branch from 1455c0b to 90d8995 Compare August 11, 2026 02:14
@team-marketing-branch-protections

Copy link
Copy Markdown

Pull request environment is available at https://stoctodocspr3333.z22.web.core.windows.net.

You can view the ephemeral environment status in Octopus Deploy.

This environment will be automatically deprovisioned when the pull request is closed, or after 7 days of inactivity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants