Merge branch 'main' into release/stable

Directory.Build.props

@@ -10,7 +10,7 @@
     <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
     <SuppressNETCoreSdkPreviewMessage>true</SuppressNETCoreSdkPreviewMessage>
     <_SkipUpgradeNetAnalyzersNuGetWarning>true</_SkipUpgradeNetAnalyzersNuGetWarning>
-</PropertyGroup>
+  </PropertyGroup>
 
   <PropertyGroup>
     <PackageIconUrl>http://go.microsoft.com/fwlink/?LinkID=288859</PackageIconUrl>
@@ -19,4 +19,18 @@
     <EnableSourceControlManagerQueries>true</EnableSourceControlManagerQueries>
     <GitHubRepositoryName>diagnostics</GitHubRepositoryName>
   </PropertyGroup>
+
+  <PropertyGroup>
+    <!-- This represents the minimum supported .NET Version, so the min
+    version that the tools must be able to run against for a simple customer
+    experience.
+    When bumping this, bump __targetRid in build.sh/build-native.cmd
+    and modify the Debugger.Tests.Configs to reflect the new TFMs -->
+    <NetCoreAppMinVersion>6.0</NetCoreAppMinVersion>
+    <NetCoreAppMinTargetFramework>net$(NetCoreAppMinVersion)</NetCoreAppMinTargetFramework>
+    <!-- this is the list of TFMs we build our debuggees and tracees as. -->
+    <SupportedSubProcessTargetFrameworks>net6.0;net8.0;net9.0</SupportedSubProcessTargetFrameworks>
+    <!-- this is the list of TFMs we build our unit tests as. -->
+    <SupportedXUnitTestTargetFrameworks>net6.0;net8.0</SupportedXUnitTestTargetFrameworks>
+  </PropertyGroup>
 </Project>

NuGet.config

@@ -5,15 +5,21 @@
   </solution>
   <packageSources>
     <clear />
-    <add key="dotnet9" value="https://dnceng.pkgs.visualstudio.com/public/_packaging/dotnet9/nuget/v3/index.json" />
-    <add key="dotnet9-transport" value="https://dnceng.pkgs.visualstudio.com/public/_packaging/dotnet9-transport/nuget/v3/index.json" />
+    <add key="dotnet10" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet10/nuget/v3/index.json" />
+    <add key="dotnet10-transport" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet10-transport/nuget/v3/index.json" />
+    <add key="dotnet9" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet9/nuget/v3/index.json" />
+    <add key="dotnet9-transport" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet9-transport/nuget/v3/index.json" />
     <!-- Need this for the old version of System.CommandLine we use -->
-    <add key="dotnet5" value="https://dnceng.pkgs.visualstudio.com/public/_packaging/dotnet5/nuget/v3/index.json" />
+    <add key="dotnet5" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet5/nuget/v3/index.json" />
     <add key="dotnet-tools" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-tools/nuget/v3/index.json" />
     <add key="dotnet-eng" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-eng/nuget/v3/index.json" />
     <add key="dotnet-diagnostics-tests" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-diagnostics-tests/nuget/v3/index.json" />
     <!-- Standard feeds -->
     <add key="dotnet-public" value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public/nuget/v3/index.json" />
   </packageSources>
+  <auditSources>
+    <clear />
+    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
+  </auditSources>
   <disabledPackageSources />
 </configuration>

documentation/FAQ.md

@@ -1,6 +1,32 @@
 Frequently Asked Questions
 ==========================
 
+* On MacOS if you see any of the following errors:
+    ```
+    (lldb) plugin load libsosplugin.so
+    error: this file does not represent a loadable dylib
+    ```
+    or if the sos plugin loads correctly but you see this error on any command:
+    ```
+    (lldb) setsymbolserver -ms
+    Error: Fail to initialize coreclr 80070008
+    ```
+    or something like this error:
+    ```
+    (lldb) setsymbolserver -ms
+    SOS_HOSTING: Fail to initialize hosting runtime '/usr/local/share/dotnet/shared/Microsoft.NETCore.App/6.0.29/libcoreclr.dylib' 80004005
+    Unrecognized command 'setsymbolserver' because managed hosting failed or was disabled. See sethostruntime command for details.
+    ```
+
+    Try the following workaround for Apple's standard lldb installation:
+    ```
+    $ sudo cp /Applications/Xcode.app/Contents/Developer/usr/bin/lldb /usr/local/bin
+    $ sudo install_name_tool -add_rpath /Applications/Xcode.app/Contents/SharedFrameworks /usr/local/bin/lldb
+    $ sudo codesign --force --sign - /usr/local/bin/lldb
+    ```
+
+This will make a copy of Xcode lldb and adhoc sign it. Note that this workaround is only applicable to Xcode lldb, not the System lldb (`/usr/bin/lldb`), which may still fail to load. You may need to delete or rename `~/.lldbinit` to use `/usr/bin/lldb`.
+
 * `dotnet-dump analyze` running on Windows doesn't support MacOS .NET 5.0 and 6.0 core dumps. `dotnet-dump` running on MacOS does support .NET 5.0 but not 6.0 core dumps (which will be fixed in a future dotnet-dump release). MacOS .NET 6.0 core dumps generated by the runtime via [createdump](https://github.com/dotnet/runtime/blob/main/docs/design/coreclr/botr/xplat-minidump-generation.md#os-x) are supported by lldb/SOS running on MacOS.
 
 * If SOS or dotnet-dump analyze commands display "UNKNOWN" for types or functions names, your core dump may not have all the managed state. Dumps created with gdb or gcore have this problem. Linux system generated core dumps need the `coredump_filter` for the process to be set to at least 0x3f. See [core](http://man7.org/linux/man-pages/man5/core.5.html) for more information.