企业官网建设流程全解析

在SolidWorks二次开发里，“C# solidworks 获取选中零件的名称”是很多需求清单里排在前面的那一条。做BOM清单、做物料编码匹配、做批量改名，第一步几乎都是让程序知道用户当前选中了哪个零件。看起来就是几行API调用的事，可实际做起来你会发现，选不中、类型判断不对、装配体路径为空、64位环境COM异常……各种问题都等着你。这篇文章不打算只是丢给你一个SelectionManager的最小Demo，而是从需求拆解、API关系、代码实现到调试排障，把完整链路走一遍。适合刚入门SolidWorks API的C#开发，也适合已经写了几年插件、但还想把选择逻辑做得更稳的老手。

1. 先别急着写代码：搞清楚“选中零件”到底指什么

1.1 三种容易混淆的对象

我刚接触这个需求时，第一反应是去API文档里找SelectionManager，然后赶紧写代码。但真正到现场对接时才发现，“零件”这个词在不同场景下指的东西可能完全不一样。

第一种是装配体环境里的组件实例。用户在总装里点了一个螺栓，这个螺栓可能已经装了12次，API返回的是“螺栓-3@总装”这种带实例号的字符串。这个字符串才是SolidWorks里每个组件的唯一标识，不同实例互相区分。

第二种是零件文档本身。如果用户打开的是一个单独的SLDPRT文件，那Document是零件环境，没有装配组件这个概念，只有文档标题和文件路径。

第三种是源文件路径。有些业务需要知道这个零件在磁盘上的位置，比如要把模型文件拷贝到PDM系统里，那就不能只拿名称，还得调用方法拿完整路径。

这三者不区分清楚，后面所有代码都是白写。

1.2 业务场景决定返回内容

拿一个我处理过的MES对接项目来举例。现场工艺人员要在SolidWorks里选中一个零件，然后让插件把零件名称、图号、材料信息同步到MES系统。这时插件需要的是组件实例名称吗？不对，MES里存的是图号和物料编码，组件实例名称带“-3@总装”这种后缀，数据库里根本没这个字段。

所以当时我们的做法是：先从组件对象反向拿到它引用的文档对象，再从文档对象读取自定义属性里的图号字段。组件名称只是中间跳板，不是最终答案。

反过来，如果是做装配体爆炸图的自动化，或者做装配体的子装配替换功能，那组件名称反而最关键，因为需要精确定位到某个实例。所以动笔之前，一定先问一遍：你拿这个名称去干什么？答案不同，代码路径完全不同。

2. 开发环境与前置知识准备

2.1 技术栈选型

C#开发SolidWorks插件，主流组合是Visual Studio加上.NET Framework。虽然现在.NET Core和.NET 8很普及，但SolidWorks的COM接口对跨平台不友好，我实际经验是老老实实用.NET Framework 4.7.2或4.8最稳妥。

SolidWorks本身是64位进程，所以C#项目的目标平台必须设置为x64。很多新手在这里踩坑：项目默认AnyCPU，编译没问题，一注册进SolidWorks就崩溃或提示“无法创建对象”。原因就是32位和64位进程不能直接互通COM。我处理过的案例里，大概有三成最终都是这个原因。

版本方面，SolidWorks从某个版本之后开始提供.NET互操作程序集，不同版本的API在细微方法上有差异。如果项目只部署在内部几台固定版本的SolidWorks上，那就直接用对应版本的Interop DLL；如果项目要给不同版本的用户用，尽量只调用那些多年未变的基础接口——“SelectionManager”这条链路的接口这么多年一直很稳定，放心用。

2.2 引用配置

创建好WinForms项目或类库项目后，需要在“添加引用”里找到SolidWorks的Interop程序集。主要用两个命名空间：SolidWorks.Interop.sldworks和SolidWorks.Interop.swconst。

有一个关键设置必须检查：选中Interop引用后，在属性面板里把“嵌入互操作类型”设为False。如果不改，运行时偶尔会出现类型转换的诡异错误，尤其是当你把对象传给自定义类库时。这个坑我记忆犹新，当时排查了一整天，最后发现就是嵌入互操作类型的默认值在作怪。

2.3 调试环境搭建

插件调试和普通程序不一样，你没法直接按F5启动SolidWorks，需要在项目中配置启动外部程序。把“调试”选项卡里的“启动外部程序”指向SolidWorks的EXE路径。这样按F5时，Visual Studio会自动启动SolidWorks并挂上调试器。

如果做的是插件注册，那还需要在Visual Studio的开发命令行里用工具注册程序集。注册完在SolidWorks的“插件”对话框里勾选启用。我习惯把注册命令写成一个批处理脚本，每次重编译后一键执行，省得手动敲命令。

3. 绕不开的API对象关系与核心思路

3.1 SelectionManager是选择的唯一入口

SolidWorks API里的选择管理核心是ISelectionMgr。它的获取方式很简单：先拿到当前激活文档对象IModelDoc2，然后通过doc.SelectionManager属性获取。

不要把IModelDoc2和ISldWorks搞混。ISldWorks是SolidWorks应用对象本身，相当于整个进程的根节点；IModelDoc2才是当前打开的那个模型文件。要获取用户选中的对象，必须从文档对象往下走。

ISldWorks swApp = (ISldWorks)Marshal.GetActiveObject("SldWorks.Application"); IModelDoc2 doc = swApp.ActiveDoc; if (doc == null) { // 没有打开任何文档，直接提示返回 return; } ISelectionMgr selMgr = doc.SelectionManager;

这段代码里我用了Marshal.GetActiveObject，是因为某些调试场景下需要直接连上已经运行的SolidWorks实例。正式插件里通常是从ISwAddin.ConnectToSW拿到的实例，不用这个方法。

3.2 类型判断与反向定位组件

拿到ISelectionMgr之后，第一步是统计当前选了几个对象。这里的重点在于GetSelectedObjectCount2支持传一个类型过滤参数，但如果不确定用户选的是什么类型，直接传-1表示统计所有类型。

int total = selMgr.GetSelectedObjectCount2(-1); if (total <= 0) { return; } for (int i = 1; i <= total; i++) { int selType = selMgr.GetSelectedObjectType3(i, -1); // selType 是 swSelectType_e 枚举的整数值 }

大家可能注意到索引从1开始而不是从0开始，这是SolidWorks API的老毛病，从COM时代沿用至今。我见过有同事按数组习惯从0遍历，结果第一个对象永远是null或者类型不对，排查半天才发现是这里的问题。

GetSelectedObjectType3返回的整数值，对应swSelectType_e枚举。像swSelCOMPONENTS表示选中了组件，swSelFACES表示选中了面，swSelEDGES表示选中了边。这里有个很容易让人困惑的点：如果你在装配体里选中某个零件的面，选择类型是“面”，不是“组件”。但业务上用户认为自己选中的是一个零件。

要解决这个问题，核心方法叫GetSelectedObjectsComponent4。它能把任何选择对象反查回它所属的组件实例。无论用户选中面、边还是特征，只要它在某个装配组件内部，这个方法就能返回那个组件对象。

Component2 comp = selMgr.GetSelectedObjectsComponent4(i, -1); if (comp != null) { string componentName = comp.Name; }

这是这个需求中最有价值的API。知道这条路径后，哪怕用户选中非常复杂的曲面特征，也能快速定位到它的实际零件归属。

3.3 组件名称与文档名称的区别

Component2.Name返回的字符串类似于“Part101-2@总装配”，其中Part101是零件原名，2是实例号，总装配是父装配的名称。这个名称适合用来定位组件实例，但不适合直接当文件名用。

如果要把名称用于文件管理，应当调用Component2.GetPathName()获取完整路径，或者先通过comp.GetModelDoc2()拿到组件引用的文档对象，再调用doc.GetTitle()获取文件名。

我见过不少项目直接用comp.Name去匹配物料库，结果发现实例号后缀每次都不同，数据库永远匹配不上。正确做法是提取出“@”之前的第一段，再结合自定义属性里的图号字段去匹配。

4. 实操：在C#插件中获取选中零件的名称

4.1 插件入口与命令注册

C#插件的标准做法是实现ISwAddin接口，注册命令按钮。为了不让篇幅过分堆在插件框架上，我把通讯和回调逻辑做了简化，重点保留获取名称的功能部分。

[ComVisible(true)] [Guid("A1B2C3D4-1234-5678-9ABC-DEF012345678")] [ProgId("MyDemo.GetNameAddIn")] public class GetNameAddIn : ISwAddin { private ISldWorks _swApp; private int _cmdGroupId; private ICommandManager _cmdMgr; public bool ConnectToSW(object ThisSw, int cookie) { _swApp = (ISldWorks)ThisSw; _cmdMgr = _swApp.CommandManager; _cmdGroupId = _cmdMgr.CreateCommandGroup2( 0, "GetNameGroup", "获取零件名", "获取零件名", "GetNameGroup", true, "获取选中零件名称", "获取选中零件名称", -1); // 不同SolidWorks版本的AddCommandItem参数略有差异 // 实际开发时以当前版本API签名提示为准 _cmdMgr.AddCommandItem( _cmdGroupId, "获取零件名", "获取当前选中零件的名称", "GetName", "GetName", "GetName", 0, "GetNameAddIn.OnGetNameClicked", "GetNameAddIn.OnGetNameEnable"); return true; } public bool DisconnectFromSW() { _cmdMgr.RemoveCommandGroup(_cmdGroupId); return true; } public void OnGetNameClicked() { // 在这里调用核心方法，见下文 } public int OnGetNameEnable() { return 1; } }

这段代码里的Guid是插件在COM世界里的身份标识，每次创建一个新插件都必须重新生成，不能复制别人的GUID，否则两个插件会冲突。命令组ID如果是0，系统会自动分配，不用自己纠结编号。

4.2 核心工具类实现

把获取选中零件名的逻辑单独封装成一个静态方法，好处是以后无论做宏、做按钮还是做自动化批处理，都能复用这一段。

public static class SelectionHelper { /// <summary> /// 获取当前选中对象的组件名称，如果当前是零件文档则返回文档标题 /// </summary> public static string GetSelectedPartName(IModelDoc2 doc) { if (doc == null) { return string.Empty; } ISelectionMgr selMgr = doc.SelectionManager; int total = selMgr.GetSelectedObjectCount2(-1); if (total <= 0) { return string.Empty; } for (int i = 1; i <= total; i++) { Component2 comp = selMgr.GetSelectedObjectsComponent4(i, -1); if (comp != null) { // 返回“零件名-实例号@装配体名” return comp.Name; } } // 如果不在装配体环境，直接返回当前文档的文件名 return doc.GetTitle(); } }

这个方法看起来短，但它解决了刚才说的三类场景。在装配体里，无论你选的是整个组件还是组件上的面，GetSelectedObjectsComponent4都能反查出组件对象；在零件环境里，没有组件，则妥妥地回退到GetTitle。

注意我用的是comp.Name，而不是comp.GetModelDoc2().GetTitle()。“组件名”和“文档标题”看着像一回事，其实不一样。组件名包含实例号，告诉你在装配体里是哪一份；文档标题只是零件文件自身的名字。具体用哪个，取决于你的业务需要。

4.3 处理批量选中多个零件的情况

实际业务中经常会出现多选。比如用户一次框选20个零件，要把它们的名称全部列出来。这时候循环里就不能return了，得改成收集到集合里。

public static List<string> GetSelectedPartNames(IModelDoc2 doc) { List<string> names = new List<string>(); HashSet<string> uniqueNames = new HashSet<string>(); if (doc == null) { return names; } ISelectionMgr selMgr = doc.SelectionManager; int total = selMgr.GetSelectedObjectCount2(-1); for (int i = 1; i <= total; i++) { Component2 comp = selMgr.GetSelectedObjectsComponent4(i, -1); if (comp != null && uniqueNames.Add(comp.Name)) { names.Add(comp.Name); } } // 如果装配体里什么组件都没选，则把文档自身加进去 if (names.Count == 0) { names.Add(doc.GetTitle()); } return names; }

这里用HashSet去重，是因为当用户选中一个零件的多个面时，GetSelectedObjectsComponent4对每个面都会返回同一个组件，不处理就会出现重复名称。有人可能会想，那我直接按选择项的数量来统计，结果当然是错的。

4.4 在界面层展示结果

拿到名称列表后，最简单的展示方式就是弹一个消息框，但我在生产工具里往往不这么干。因为消息框会阻塞用户操作，而且一旦列表很长，屏幕上全是文本，用户体验很差。

我通常的做法是把名称推送到自定义窗体里的ListBox或者DataGridView中，让用户可以继续在SolidWorks里操作界面，而插件的结果面板独立显示。如果只是验证逻辑，消息框倒也够用：

List<string> result = SelectionHelper.GetSelectedPartNames(swApp.ActiveDoc); if (result.Count == 0) { MessageBox.Show("没有选中的零件"); return; } MessageBox.Show(string.Join(Environment.NewLine, result));

5. 高频问题与排查技巧实录

5.1 现场问题对照表

第一列表格里的问题大多数我都在现场遇到过。尤其是“选择的时机”，这是新手最容易忽视的。如果你在窗口选择事件还没有完成之前就去读SelectionManager，拿到的往往是上一次的选择状态，甚至什么也没有。

5.2 一个典型案例的排查过程

有次现场反馈说，插件点按钮后总是提示没有选中零件，但用户明明已经选中了。我远程看了一遍，代码逻辑没问题，后来发现用户用的是框选方式，而且在框选后马上点了按钮，SolidWorks内部的选择更新事件还没走完。

当时我给的方案不是让用户重试，而是在按钮回调里加了一个小的选择延时重试机制：如果第一次统计为0，就等待300毫秒后再试一次。这个改动看起来有点土，但实际效果很稳定。后面才意识到，这其实涉及SolidWorks的事件循环和COM调用线程的问题，简单粗暴地重试往往比复杂的线程同步更有效。

不过要注意，这种延时重试只在按钮触发场景里适用，如果在事件回调里无脑延时，可能会把SolidWorks主线程卡住，界面直接假死。

5.3 调试中的关键工具与习惯

我做这类插件调试时，最喜欢用的工具就是SolidWorks自带的“宏录制”。先用宏录制用户的选择过程，然后回放宏，在宏代码里加上Debug.Print输出关键变量。宏可以访问和C#几乎相同的API对象模型，等于用一个轻量级原型验证了API调用链路，然后再把验证过的逻辑搬到C#工程里。

另外强烈建议在C#代码里接入文件日志。插件跑在SolidWorks进程内，如果用MessageBox弹窗调试，每次都会阻塞模型操作，体验非常差。日志方式就好得多，尤其是没法现场调试的那种环境，把日志文件收回来一看，问题基本能定位。

6. 工程化扩展与我的个人体会

6.1 从“获取名称”升级为“获取完整信息”

一旦名称获取这个基础能力跑通，后面几乎必然要扩展出更多能力。零件名称本身很少直接满足业务，业务要的往往是图号、材料、重量、版本号这些属性。

要从组件对象拿到这些信息，就用comp.GetModelDoc2()拿到文档，然后通过doc.Extension.GetCustomPropertyManager读取属性。这段链路不算复杂，但必须在名称获取这一层就设计好返回结构，不要在后面拼接一堆条件判断。

6.2 代码组织上的建议

工具类要独立，不要和插件界面代码混在一起。我经手的项目里，凡是把SelectionManager的调用直接写在窗体按钮事件里的，后面都很难维护。因为第二个人接手时，不知道这里牵涉装配体与零件环境的差异，往往会把逻辑改坏。

正确的做法是把“取选择”和“取属性”放到独立的服务类里，界面只负责调用和展示。以后要做批处理、要接命令行参数、要做自动化测试，都不用动界面层。

6.3 扩展的几种实用方向

名称获取能力往后延伸，可以做装配体零件重命名工具，也可以做选中零件批量导出STEP/STL，甚至做GD&T标注检查。这些功能归根结底都需要先确定用户选中了哪些零件。所以把这一层做好，整个插件的底座就稳了一半。

它的下一步自然延伸，是结合自定义属性和装配体树结构，做更智能的零件分级管理。比如按名称前缀自动分组、自动生成外购件清单。我能看到的方向至少还有三四个，但这个需求本身已经足够支撑一个成熟的内部工具。

最后再分享一个小技巧：如果拿到的是组件名称里的零件原名，想去掉实例号部分，不要用正则硬解析，直接找“-”和“@”的位置来截取就行。但更稳妥的是通过comp.GetModelDoc2().GetTitle()拿文档标题，这个名称和文件系统完全一致，几乎没有歧义。这个坑我踩过一次，之后凡是涉及文件名匹配的逻辑，都会下意识地检查是否用了正确的获取路径。