SkyWalking 官方 .NET Agent 不支持 .NET Framework 是因依赖 .NET Core 3.1+ 的 DiagnosticSource 和 Activity 基础设施；仅支持 .NET Core 3.1+ 和 .NET 5+，.NET Framework 项目需升级或改用社区 SDK。
为什么 SkyWalking 官方 .NET Agent 不支持 .NET Framework？
目前（截至 SkyWalking v9.7），官方 skywalking-dotnet Agent 仅支持 .NET Core 3.1+ 和 .NET 5+，底层依赖 DiagnosticSource 和 Activity 的现代诊断基础设施。如果你项目还在用 .NET Framework 4.6.1+，直接装 NuGet 包会失败或无任何埋点效果。
可行路径只有两条：
- 升级到
.NET 6/8（推荐，长期维护有保障） - 改用手动 SDK 模式（
SkyApm.Agent.AspNetCore已停更，需回退到SkyApm.DotNetv1.x 或改用社区维护分支）
在 ASP.NET Core 中启用自动埋点的最小配置
以 .NET 6 + SkyAPM.Agent.AspNetCore（v2.4.0）为例，自动捕获 HTTP 请求、DB 查询、HttpClient 调用的关键是正确初始化和配置环境变量。
必须设置的环境变量（非代码内硬编码）：
ASPNETCORE_HOSTINGSTARTUPASSEMBLIES=SkyAPM.Agent.AspNetCoreSKYWALKING__SERVICENAME=your-service-nameSKYWALKING__COLLECTOR__BACKENDGRPC__HOST=127.0.0.1SKYWALKING__COLLECTOR__BACKENDGRPC__PORT=11800
注意：SKYWALKING__ 前缀不能省略，且大小写敏感；BACKENDGRPC 是默认传输协议，若服务端启用了 oap-server 的 HTTP 接收器，需换用 BACKENDHTTP 配置项。
DiagnosticListener 和 Activity 是埋点核心，但别手动订阅
有人尝试用 DiagnosticListener.AllListeners.Subscribe(...) 自己解析 Microsoft.AspNetCore 或 SqlClient 的事件，这不仅重复造轮子，还极易漏掉上下文传播逻辑（比如 TraceId 跨线程丢失）。官方 Agent 已封装好所有关键监听器：
-
Microsoft.AspNetCore.Hosting.HttpRequestIn→ HTTP 入口 -
Microsoft.Data.SqlClient.WriteCommandBefore→ SQL 执行前 -
System.Net.Http.HttpRequestOut→ HttpClient 出站调用
只要 Agent 加载成功且环境变量正确，这些监听器就自动生效；手动干预反而可能破坏 Activity.Current?.Context.TraceId 的链路一致性。
自定义 Span 必须用 TracingContext.Instance.NewEntrySpan()
对非 HTTP/DB/HTTPClient 的逻辑（如消息队列消费、定时任务、内部计算），需要显式创建 Span。不要用 new Span(...) 或直接操作 Activity，否则无法被 Collector 正确识别。
正确写法示例：
using SkyApm.Tracing;
<p>var span = TracingContext.Instance.NewEntrySpan("process-order", "/order/process");
try
{
span.Tag("order.id", orderId);
// your logic
}
catch (Exception ex)
{
span.Error(ex);
throw;
}
finally
{
span.End();
}</p>
重点：必须调用 span.End()，否则 Span 不会上报；NewEntrySpan 会自动继承上游 Context，无需手动传 TraceId。
最容易被忽略的是跨线程场景：比如 Task.Run(() => { /* 埋点代码 */ }) 中的 Span 不会自动延续。此时需显式使用 TracingContext.Instance.Continued(...) 或改用 AsyncLocal 安全的异步上下文传递方式——这点在 Kafka 消费者或 Hangfire 任务里特别容易出错。
