App crashes immediately after running `dotnet run` exclusively on Mac with error code 137

[WhitWaldo]

Apple platform

macOS

Framework version

net9.0-*

Affected platform version

.NET 8.0-*, .NET 9.0.203

Description

I maintain the Dapr .NET SDK and have been fielding reports from several different people over the last couple of weeks that out of the blue, they're unable to run one of the Dapr .NET quickstarts, specifically this one.

If you clone the repo and cd into the 'service' directory within this directory and have Dapr installed on your system (instructions), you should just be able to run dapr run --app-id actorservice --app-port 5001 --app-protocol http --dapr-http-port 56001 --resources-path ../../../resources -- dotnet run --urls=http://localhost:5001/

Running this on Windows, I see the following in my console:

On Mac though, I'm getting repeated reports of the following:

ℹ️  Checking if Dapr sidecar is listening on GRPC port 50059
ℹ️  Dapr sidecar is up and running.
ℹ️  Updating metadata for appPID: 6310
ℹ️  Updating metadata for app command: dotnet run --urls=http://localhost:5001/
✅  You're up and running! Both Dapr and your app logs will appear here.

❌  The App process exited with error code: exit status 137
ℹ️  
terminated signal received: shutting down
✅  Exited Dapr successfully
❌  Error exiting App: exit status 137

I prompted several users to try inserting a Console.WriteLine at the top of their programs - when they rebuild and run the app, it does not show the log output to the console, suggesting that the app is crashing before it even starts running.

This quickstart has been validated to work as expected on Windows and Linux - it's only having this reproduceable problem on several different Macs.

For what it's worth, we released the latest version of Dapr on September 16 and beforehand, this and other quickstarts were cross-platform validated to work fine at and just before this release, so this is just something that's changed in the last month. I appreciate any guidance you can share on what might be going on.

Steps to Reproduce

1. Clone this repo
2. Install Dapr CLI to your system - this might not actually be necessary to experience the issue as I think the app is crashing before it tries to communicate with Dapr, but you shouldn't be able to reproduce the "correct" output I shared from Windows above without this installed
3. cd into actors/csharp/sdk/service relative to where you cloned the repository
4. Run the Dapr sidecar + launch the dotnet app with dapr run --app-id actorservice --app-port 5001 --app-protocol http --dapr-http-port 56001 --resources-path ../../../resources -- dotnet run --urls=http://localhost:5001/

Did you find any workaround?

The reporter of this issue suggests that it works if the DLL is directly invoked:

dotnet ./bin/Debug/net8.0/SmartDevice.Service.dll

Relevant logs

No response

[rolfbjarne]

This doesn't look like it's related to anything from this repository (dotnet/macios), just plain .NET running on macOS, so I'm moving to dotnet/runtime.

[vcsjones]

This looks like a duplicate of #93716.

For reasons we never quite understood, macOS does not like loading things where the name ends in .Service or .App (this is not specific to .NET). If you rename the output assembly so that it does not end in Service does dotnet run work?

[WhitWaldo]

@vcsjones Oddly, this wasn't a problem a month ago and the affected projects haven't themselves changed, but I've got at least four reports of that quickstart no longer working. Did anything change as a result of the upcoming .NET 10 release? I haven't seen anything in the release notes, but I assume they're not final yet.

[vcsjones]

I am not aware of anything, but I am not the best informed on any host changes either. @agocke may know more.

The ".Service" and ".App" thing is unfortunate but a known behavior of macOS, and is also seemingly nondeterministic. But not specific to .NET.

[jkotas]

The ".Service" and ".App" thing is unfortunate but a known behavior of macOS

Can the build issue a warning for these on macOS so that it does not take users by surprise?

[agocke]

I honestly have no idea what causes this. My only info was that a bunch of different languages were running into this, including Node, Go, and Rust: https://github.com/orgs/nodejs/discussions/4816. I'm not aware of anything specifically related to the names .Service or .App (not to say that isn't true, I just haven't seen it).

[WhitWaldo]

I've confirmed that by adding <AssemblyName>NameThatDoesNotEndInService</AssemblyName> to all affected projects appears to work. Bizarre issue, but I appreciate your help tackling it!

[agocke]

@baronfel Thoughts on having the SDK produce a build warning whenever the app ends in ".App" or ".Service"?