VS2022中Windows Forms设计器报错：未找到Eco.Handles.ColumnCollection.AddRange方法

问题背景 #

我们开发了自定义Windows Forms组件，这些组件依赖Eco.Handles.Design.dll中的编辑器，用于设计阶段引用句柄（ExpressionHandle/ReferenceHandle）或通过OCL编辑器输入表达式。自Visual Studio 2022起，Eco.Handles.Design.dll仅能通过VSIX包安装，且其版本与项目引用的NuGet包版本不一致，导致创建包含该组件的Windows Form时，设计器报错：Method 'Eco.Handles.ColumnCollection.AddRange' not found。推测是VS2022的devenv.exe调用该方法时，因版本差异找不到对应实现。

问题解答 #

1. 版本差异是否为报错原因？能否通过devenv.exe.config重定向？ #

• 是，版本不匹配大概率是核心原因：VSIX安装的Eco.Handles.Design.dll调用了Eco.Handles.dll的AddRange方法，但项目引用的NuGet包版本中该方法可能被移除、签名变更或版本不兼容。
• 可以尝试通过devenv.exe.config进行程序集版本重定向，在<runtime>节点下添加类似配置：

<dependentAssembly>
  <assemblyIdentity name="Eco.Handles" publicKeyToken="你的公钥令牌" culture="neutral" />
  <bindingRedirect oldVersion="当前VSIX依赖的版本" newVersion="项目NuGet引用的版本" />
</dependentAssembly>

注意：需替换公钥令牌、新旧版本号，修改devenv.exe.config需管理员权限，建议先备份原文件。

2. 能否获取特定版本的Eco.Handles.Design.dll验证版本问题？ #

• 若Eco官方提供版本归档，可尝试下载对应项目NuGet版本的Eco.Handles.Design.dll；若没有，可从已安装VS2019的环境中提取对应版本的文件（需确认版本匹配），替换VS2022 VSIX安装目录下的文件进行测试（注意备份原文件）。
• 另外，可查看NuGet包是否包含设计器组件部分，部分组件会将设计器dll打包在NuGet的tools或designer目录下。

3. 分析问题的方法与日志查看 #

• 程序集绑定日志：启用Fusion日志查看器（fuslogvw.exe），配置记录程序集绑定失败日志，可明确看到devenv.exe加载Eco.Handles.dll时尝试的版本、实际加载的版本，以及失败原因。
• 设计器日志：VS2022的Windows Forms设计器日志可在%APPDATA%\Microsoft\VisualStudio\<版本号>\Designer\Logs目录下找到，其中会记录方法查找失败的详细调用栈，帮助定位具体是哪个版本的程序集导致问题。
• 反射验证：使用ILSpy或dnSpy工具，分别查看VSIX安装的Eco.Handles.Design.dll依赖的Eco.Handles.dll版本，以及项目引用的Eco.Handles.dll是否包含AddRange方法、方法签名是否一致。

4. 其他恢复设计器正常运行的办法 #

• 降级VS版本：临时切换回VS2019开发，直到版本兼容问题解决。
• 自定义设计器包装：为自定义组件编写自己的设计器，避免直接依赖Eco.Handles.Design.dll的编辑器逻辑，改用项目兼容的API实现设计阶段的句柄引用和OCL输入功能。
• 联系Eco官方：反馈版本兼容问题，请求提供与NuGet包版本匹配的VSIX安装包，或获取兼容的设计器dll。
• 清理缓存：清理VS的组件缓存（%LOCALAPPDATA%\Microsoft\VisualStudio\<版本号>\ComponentModelCache）和项目的bin/obj目录，重新生成项目后再尝试打开设计器。

内容的提问来源于stack exchange，提问作者Peter Buchmann