[akirayamamoto]

Why

On macOS, installing an SDK or runtime into a folder that already has one can leave dotnet unusable: every launch is killed with Killed: 9 (exit code 137, crash report SIGKILL (Code Signature Invalid)). codesign --verify reports the file as valid, and copying it to a new file fixes it.

#232 reported this root cause and was closed with the --skip-non-versioned-files workaround. A comment there suggested it stopped happening on macOS 13 and later, but it still reproduces on macOS 26 (see Validation). #622 and #662 look like the same symptom but were attributed to an incompatible dotnet and to running out of memory.

Root cause

copy_files_or_dirs_from_list copies each non-versioned file with cp over the existing one. cp writes into the existing file rather than replacing it.

macOS attaches a binary's code signature to the file while any process has it loaded. If dotnet is rewritten in place while another dotnet process is still running (an MSBuild node, the Roslyn compiler server, an IDE language server), the next launch is checked against the old signature and the kernel kills it. With nothing else running, the overwrite is harmless, which is why it only fails some of the time.

Apple's guidance is to write the new file separately and rename it into place: Updating Mac software.

Approach

When the target is an existing regular file, copy to a temporary name in the same folder and mv it over the target. A rename gives a new file atomically, so a running process keeps the old one and new launches get a fresh signature check. Folders, symlinks and new files are copied as before, and --skip-non-versioned-files is unchanged.

This also avoids Text file busy on Linux when overwriting a binary that is running.

dotnet-install.ps1 is unchanged: it only installs Windows builds, and this signature caching is macOS-specific.

Validation

• New test OverwrittenNonVersionedFileIsReplacedNotRewrittenInPlace: holds the existing dotnet open during extraction, like a running process, and checks that handle still reads the old content. It fails without the fix.
• All BashTarExtractionTests pass via ./build.sh --test, filtered to that class.
• Manual repro on macOS 26.7.1 (Apple silicon): with a .NET 10 runtime installed and a dotnet app.dll from that folder running, install the .NET 8 runtime into the same folder (--runtime dotnet --channel 8.0), then launch dotnet again:

Script	Next dotnet --list-runtimes
main	Killed: 9, exit 137
This PR	exit 0

Without a running process, the in-place overwrite didn't fail in my runs.

🤖 Generated with Claude Code

[akirayamamoto]

@dotnet-policy-service agree company="Octopus Deploy"

[akirayamamoto]

/azp run

[azure-pipelines]

Commenter does not have sufficient privileges for PR 743 in repo dotnet/install-scripts

[akirayamamoto]

Hi @ellahathaway and @MichaelSimons, would one of you have a moment to look at this?

It fixes the "Killed: 9" crash on macOS when you install into a folder that already has dotnet and another dotnet process is still running. The script overwrites dotnet in place, so macOS checks the next launch against the old code signature and kills it. Copying to a temp file and renaming it over the old one avoids that (this is what Apple recommends).

The Windows failure looks like the dotnet.exe file lock flake during test cleanup. I opened #744 (retry test cleanup while Windows still locks dotnet.exe) for that. I can't trigger /azp run myself, so a rerun would help too.

Thanks!

[MichaelSimons]

Hi @ellahathaway and @MichaelSimons, would one of you have a moment to look at this?

It fixes the "Killed: 9" crash on macOS when you install into a folder that already has dotnet and another dotnet process is still running. The script overwrites dotnet in place, so macOS checks the next launch against the old code signature and kills it. Copying to a temp file and renaming it over the old one avoids that (this is what Apple recommends).

The Windows failure looks like the dotnet.exe file lock flake during test cleanup. I opened #744 (retry test cleanup while Windows still locks dotnet.exe) for that. I can't trigger /azp run myself, so a rerun would help too.

Thanks!

@akirayamamoto , thanks for your contribution. @dotnet/install-scripts-maintainers is the team to ping for approval or other questions. @ellahathaway and myself, are focusing in different areas at the moment.