`dotnet.workingWithTestSignedSdk` setting doesn't work anymore

[jtschuster]

The dotnet.workingWithTestSignedSdk setting doesn't seem to work anymore (see #1606 (comment)). This option should probably be removed or a note added to the setting doc that it no longer works in the latest version of MacOS.

[ocallesp]

@nagilson does this belong to sdk ?

[nagilson]

No, we don't own that functionality. @lifengl @adrianvmsft was this possibly impacted by the migration to the Path API? I don't recall the logic around this getting deleted, but maybe it did.

[jtschuster]

It doesn't look like any functionality got deleted, but MacOS updated their rules and whatever logic is there no longer works. This is the error message I get (with or without the setting enabled):

.NET server STDERR: Failed to load /usr/local/share/dotnet/host/fxr/10.0.0-preview.6.25309.101/libhostfxr.dylib, error: dlopen(/usr/local/share/dotnet/host/fxr/10.0.0-preview.6.25309.101/libhostfxr.dylib, 0x0001): tried: '/usr/local/share/dotnet/host/fxr/10.0.0-preview.6.25309.101/libhostfxr.dylib' (code signature in <220E4C4C-1E91-3DB3-9766-2F8CA361097D> '/usr/local/share/dotnet/host/fxr/10.0.0-preview.6.25309.101/libhostfxr.dylib' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/share/dotnet/host/fxr/10.0.0-preview.6.25309.101/libhostfxr.dylib' (no such file), '/usr/local/share/dotnet/host/fxr/10.0.0-preview.6.25309.101/libhostfxr.dylib' (code signature in <220E4C4C-1E91-3DB3-9766-2F8CA361097D> '/usr/local/share/dotnet/host/fxr/10.0.0-preview.6.25309.101/libhostfxr.dylib' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs)
The library libhostfxr.dylib was found, but loading it from /usr/local/share/dotnet/host/fxr/10.0.0-preview.6.25309.101/libhostfxr.dylib failed

[adrianvmsft]

@jtschuster Could you please try checking the following setting (and reload the workspace) to see if that addresses the issue?

Dotnet: Use Legacy Dotnet Resolution

[jtschuster]

@adrianvmsft setting that to true gets the LSP functionality to work, thank you!

[nagilson]

We should coordinate to see if we can update the logic in CDK to respect the old setting or if we need to update the API to be aware of this setting @adrianvmsft

I have a lot to do and I'm guessing so do you but this is likely relatively higher-pri :/
I'll try to take a look relatively soon

[ocallesp]

@adrianvmsft assigning this issue to you since it appears to be more related to CPS than to testing. It looks like we might be able to resolve it, but I’ll defer to your judgment.

[nagilson]

Thank you @lifengl and @adrianvmsft , who has a PR up.

To quote them:

In the new runtime resolution logic, because you happen to have stable NET 9 runtime installed in the same location. The new resolver will use the location. However, because it has unsigned fxhost, it would fail to load CDK server process. Basically Mac security will block it to use any unsigned binaries.

In the old resolver logic, when you turn on the option to use test SDK on mac, we disable the logic to reuse local runtime