安装VS时未勾选.NET desktop development会导致新建WinForms/WPF项目报“无法找到目标框架”错误，必须通过Visual Studio Installer补选该组件及其他必要工作负载。
创建项目时选错工作负载会导致后续功能缺失
VS 安装时没勾选 .NET desktop development，后续新建 Windows 窗体或 WPF 项目会直接报错“无法找到目标框架”，连设计器都打不开。这不是项目问题，是环境缺组件。
必须在 Visual Studio Installer 中修改已安装版本，勾选：
- .NET desktop development
- ASP.NET and web development（如果涉及 Web API 或 Blazor）
- Data storage and processing（含 SQL Server Data Tools，用于数据库项目）
- 可选但推荐：.NET Core cross-platform development（跨平台部署需要）
注意：Universal Windows Platform development 和 Game development with Unity 不属于企业级常规需求，除非明确做 UWP 或 Unity 插件集成，否则不建议勾选——它们会拖慢安装速度、占用磁盘，且可能干扰 .NET Framework 项目加载。
解决方案结构里混用 .NET Framework 和 .NET Core/5+ 项目会出编译错误
企业级项目常需复用旧有类库（比如封装了 COM 组件调用的 LegacyHelper.dll），这类库只能基于 .NET Framework 4.7.2 或更高版本；而新模块往往用 .NET 6 或 .NET 8。直接添加引用会提示“无法解析引用”或“目标框架不兼容”。
可行方案只有两个：
- 把旧类库升级为 .NET Standard 2.0（兼容 .NET Framework 4.6.1+ 和所有现代 .NET）并重新编译，这是最干净的做法
- 在新项目中启用 UseWpf 或 UseWindowsForms 并保留 TargetFramework 为 net6.0-windows 或 net8.0-windows，再通过 AssemblyLoadContext 动态加载旧程序集（仅限无法修改源码的场景）
别试 multi-targeting（如 <TargetFrameworks>net48;net6.0</TargetFrameworks>）来硬扛——它会让 NuGet 包解析混乱，尤其涉及 System.Data.SqlClient 这类已拆分的包时，极易在 CI 构建中失败。
调试时断点失效或变量显示“不可用”，大概率是优化开关或 PDB 路径问题
发布配置下默认开启 <Optimize>true</Optimize>，即使你手动改回 false，若没同步清理 bin 和 obj 目录，旧的优化后 IL 仍会被加载，导致断点灰色、DebuggerDisplay 不生效、局部变量值显示为 <Cannot evaluate expression>。
实操步骤：
- 检查当前配置是否为 Debug，且项目属性 → “生成”页中“优化代码”未勾选
- 手动删除整个 bin 和 obj 文件夹（不要只删 Debug 子目录）
- 在项目文件（.csproj）中确认包含：<DebugType>portable</DebugType>（.NET Core/5+ 默认）或 <DebugType>full</DebugType>（.NET Framework 必须）
- 若使用共享 PDB（如符号服务器），确保 Tools → Options → Debugging → Symbols 中启用了对应路径，且网络可访问
特别注意：在 WPF 项目中，如果 XAML 后置代码里的 InitializeComponent() 断点不命中，90% 是因为 obj 下的 g.cs 文件未重新生成——删 obj 后 Clean + Rebuild 即可。
发布到客户环境时缺少运行时，不能只靠“单文件发布”蒙混过关
dotnet publish -p:PublishSingleFile=true 看似方便，但企业客户机器上没装过 .NET Runtime 时，首次启动会静默失败（进程秒退，无日志），连 Windows 事件查看器都抓不到异常——因为单文件依赖的原生启动器（dotnet.exe 的精简版）本身需要系统级运行时支撑。
真正稳妥的发布方式：
- 对 .NET 6+ 项目，用 win-x64 或 win-arm64 RID 发布，并勾选 <SelfContained>true</SelfContained>（即自包含部署）
- 客户端若禁止安装全局运行时，可将 publish 输出整个文件夹打包，无需额外安装
- 若必须用单文件，务必在目标机器上先运行 dotnet --list-runtimes 验证是否存在对应版本；没有就需提前部署 dotnet-runtime-8.0.x-win-x64.exe（从 https://www.php.cn/link/c9f8941c38b7d49a586adf043f2acf21 获取离线安装包）
还有一个隐形坑：SelfContained 发布体积大（约 80–120MB），但它是唯一能绕过客户 IT 部门 GPO 策略限制的方式——他们常禁用非白名单 MSI 安装，却对解压即用的文件夹放行。
