Aras PLM更新DLL后为何不生效？需执行哪些关键操作？

Question

在Aras PLM中更新自定义或扩展DLL（如Method、Event Handler、SOAP服务引用等）后不生效，是高频运维问题。根本原因常为：① IIS应用程序池未回收，旧程序集仍被CLR锁定；② Aras缓存（如Method Cache、Server Cache）未清除，系统继续加载旧版本；③ DLL强名称/版本号未更新，导致GAC或bin目录下存在多版本冲突；④ Web.config或Innovator.xml中未正确注册新程序集或版本绑定重定向；⑤ 编译目标框架（如.NET 6+）与Aras Server运行时（通常为.NET Framework 4.7.2/4.8）不兼容。关键操作必须闭环执行：1）停止IIS应用池 → 2）清空`Innovator/Server/Cache/`及`Temp/`目录 → 3）替换DLL并校验签名与版本 → 4）更新`web.config`的``（如需）→ 5）重启应用池 + 清除浏览器缓存 → 6）在Aras客户端强制刷新方法列表（Tools → Refresh Methods）。建议配合事件日志与`fusionlogvw`排查程序集加载失败。

Answer 1

```html

一、现象层：典型失效场景与用户反馈

• 更新自定义Method DLL后，调用仍执行旧逻辑（如日志输出未变、返回值未更新）；
• Event Handler在Item状态变更时无响应，但调试日志显示“未进入OnAfterChange”；
• SOAP服务引用更新WSDL后，Aras客户端调用报System.ServiceModel.EndpointNotFoundException；
• Aras Server日志中反复出现Could not load file or assembly 'MyCustomLib, Version=1.0.0.0'...；
• 同一服务器上多个客户化项目共存时，A项目升级DLL导致B项目Method异常终止。

二、机制层：Aras运行时加载模型深度解析

Aras PLM基于.NET Framework构建，其扩展机制依赖三重加载路径：

加载阶段	触发时机	缓存位置	影响范围
CLR程序集绑定	首次调用Method/EventHandler时	GAC / Innovator/Server/bin	全局进程级锁定
Aras Method Cache	Server启动或Refresh Methods后	Innovator/Server/Cache/Methods/	仅影响Method元数据与IL缓存
IIS临时编译	ASP.NET动态编译.aspx/.ascx时	%WinDir%\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\	影响Web UI扩展（如CustomForm）

三、根因层：五大高频失效动因的实证分析

1. IIS应用池未回收：CLR对已加载Assembly执行强引用锁定，即使bin目录DLL被覆盖，旧内存镜像仍驻留——appcmd list wp可验证Worker Process PID未变；
2. Aras Server Cache残留：Method Cache不仅缓存元数据（.xml），还缓存JIT编译后的Native Image（.ni.dll），需清空Cache/与Temp/双目录；
3. 强名称版本冲突：若新DLL未更新AssemblyVersion且未配置bindingRedirect，GAC中v1.0.0.0与v1.1.0.0并存将触发FileLoadException；
4. 配置注册遗漏：web.config中<assemblies>未添加<add assembly="MyLib, Version=1.1.0.0..." />，或Innovator.xml中<method>节点仍指向旧assemblyName；
5. 框架不兼容：使用.NET 6 SDK编译的DLL含AssemblyFlags = 0x00000001 (SideBySide)，而.NET Framework 4.8 CLR拒绝加载——ildasm MyLib.dll可验证TargetFrameworkAttribute。

四、闭环操作层：六步黄金流程（附PowerShell自动化脚本）

# Step1: Stop AppPool & Clear Temp
Import-Module WebAdministration
Stop-WebAppPool "ArasInnovator"
Remove-Item "$env:INNOVATOR_SERVER\Server\Cache\*" -Recurse -Force
Remove-Item "$env:INNOVATOR_SERVER\Server\Temp\*" -Recurse -Force

# Step3: Verify Assembly Identity
$asm = [System.Reflection.Assembly]::LoadFile("C:\New\MyLib.dll")
Write-Host "Version: $($asm.GetName().Version)"
Write-Host "PublicKeyToken: $($asm.GetName().GetPublicKeyToken() | ForEach-Object {$_.ToString('x2')})"

# Step5: Restart & Refresh
Start-WebAppPool "ArasInnovator"
# Then manually: Tools → Refresh Methods in Aras Client

五、诊断层：融合式排错矩阵

graph TD
  A[Method不生效] --> B{IIS应用池是否重启？}
  B -->|否| C[强制回收AppPool]
  B -->|是| D{Cache目录是否清空？}
  D -->|否| E[删除Cache/Temp全量内容]
  D -->|是| F{Fusion Log是否启用？}
  F -->|否| G[启用fusionlogvw.exe捕获绑定失败]
  F -->|是| H[检查日志中“LOG: Attempting download”路径]
  H --> I[定位实际加载的DLL物理路径]
  I --> J[比对文件版本/强名称/签名]

六、架构层：面向未来的加固建议

• 建立DLL发布流水线：集成signtool verify /pa与Get-AssemblyIdentity校验步骤；
• 在Innovator.xml中统一采用assemblyName="MyLib, Culture=neutral, PublicKeyToken=abc123..."全限定名，规避版本歧义；
• 为关键EventHandler配置<add key="Aras.Server.Methods.DisableMethodCache" value="true" />（仅限调试期）；
• 将所有自定义DLL纳入NuGet私有源管理，通过packages.config显式声明依赖，避免bin目录手工覆盖；
• 在Aras Server Health Check脚本中嵌入Get-Process -Id $pid | Select-Object -ExpandProperty Modules | Where-Object {$_.ModuleName -eq 'MyLib.dll'}内存驻留检测。

```