安装 .NET SxS组件时，该装到系统哪个目录？

Question

**常见技术问题：** 安装 .NET Side-by-Side（SxS）组件时，应部署到哪个系统目录？许多开发者误将自定义程序集直接复制到 `C:\Windows\Microsoft.NET\Framework\v4.0.30319`（或对应版本路径）下，试图实现全局共享。但这是错误且危险的做法：该目录仅由 .NET Framework 安装程序受控管理，手动写入会破坏运行时完整性、引发GAC冲突或导致后续Windows更新失败。正确的SxS部署方式是——**不依赖系统目录**：对于强命名程序集，应通过 `gacutil`（开发环境）或 MSI 的 `` 元素（生产环境）安装至全局程序集缓存（GAC），路径为 `%windir%\Microsoft.NET\assembly`（.NET 4+）；对于非强命名或私有组件，则应随应用本地部署在应用程序目录（如 `bin\`）中，由CLR按探测策略自动加载。混淆SxS语义与传统“系统DLL覆盖”逻辑，是引发部署失败、版本混乱和“Could not load file or assembly”异常的主因。

Answer 1

```html

一、现象层：典型错误操作与表象症状

• 开发者将自定义强命名 DLL（如 MyCompany.Core.dll）手动拷贝至 C:\Windows\Microsoft.NET\Framework\v4.0.30319\ 目录下，期望“全局生效”；
• 部署后出现随机性 FileNotFoundException 或 FileLoadException，尤其在多版本应用共存时；
• Windows Update 失败并报错 0x80073712（CBS_E_INVALID_PACKAGE），或 .NET Framework 修复工具拒绝运行；
• 使用 fuslogvw.exe （绑定日志查看器）发现 CLR 尝试从 GAC 加载却失败，而实际程序集未注册；
• 同一台机器上，AppA 正常运行，AppB 却抛出 Could not load file or assembly 'XXX, Version=2.1.0.0...' —— 版本冲突暴露无遗。

二、机制层：.NET SxS 的核心设计原理

Side-by-Side 并非“多版本 DLL 共存于同一路径”，而是CLR 基于程序集标识（Assembly Identity）的精确匹配加载机制。关键要素包括：

维度	.NET Framework 2.0–3.5	.NET Framework 4.0+
主运行时目录	%windir%\Microsoft.NET\Framework\v2.0.50727	%windir%\Microsoft.NET\Framework\v4.0.30319
GAC 物理路径	%windir%\assembly（隐藏 Shell 命名空间）	%windir%\Microsoft.NET\assembly（真实文件系统结构）
加载策略优先级	私有路径 → GAC → 系统目录（仅限 Framework 内建程序集）	应用程序基目录（AppDomain.BaseDirectory）→ GAC → DEVPATH（仅开发启用）

三、误区层：为何直接写入 Framework 目录是反模式？

1. 违反信任边界：该目录受 Windows 文件保护（WFP）和 TrustedInstaller 权限控制，普通用户/管理员无权写入（即使绕过也会被 CBS 日志标记为“篡改”）；
2. 破坏版本契约：CLR 在 JIT 编译时校验程序集元数据签名与 mscorlib 的版本兼容性，非法注入会触发 SecurityException 或类型加载失败；
3. 阻断热更新通道：Windows Update 对 v4.0.30319 下所有文件执行 SHA256 完整性校验，任何变更将导致 KB500XXXX 补丁静默回滚；
4. 混淆探测上下文：CLR 不从此目录加载用户程序集——它仅用于承载 clr.dll、mscorwks.dll 及框架核心（如 System.dll），无对应 Fusion 绑定策略支持。

四、实践层：正确 SxS 部署路径决策树

graph TD A[程序集是否强命名？] -->|是| B[是否需跨应用共享？] A -->|否| C[必须本地部署：bin/ 或子目录] B -->|是| D[部署至 GAC：
• 开发：gacutil -i MyLib.dll
• 生产：MSI 中 <Assembly> 元素 + <File> 引用] B -->|否| C D --> E[验证：powershell -c “Get-ChildItem 'HKLM:\\SOFTWARE\\Microsoft\\Fusion\\GACChangeNotification'”]

五、治理层：企业级部署规范建议

• 禁止 CI/CD 流水线执行 copy /y *.dll %WINDIR%\Microsoft.NET\Framework\... 类脚本；
• 在 NuGet 包中通过 .nuspec 的 <frameworkAssemblies> 声明依赖，而非打包 Framework 程序集；
• 对遗留 COM-Interop 场景，使用 RegAsm /tlb /codebase 时须配合 /register 而非直接注册到 System32；
• 建立自动化检查项：PowerShell 脚本扫描 v4.0.30319 目录下非微软签名文件，并触发告警；
• 在 DevOps 文档中明确标注：“Framework 目录 = 运行时引擎容器，非用户程序集仓库”。

```