C#二次开发SolidWorks：遍历零件与装配体所有面面积并导出

1. 从“给模型算面积”说起：需求背景与API对象结构

前一阵子在写自动化成本评估工具，产品结构里有一步要统计每个零件的表面面积——喷涂用量、电镀成本、包装膜尺寸、表面处理工时，全都指着这个数。过去靠手工在SolidWorks里一个个面点过去，选中一个看一次左下角提示，几百个特征面的复杂件弄到人眼花，数据还容易漏。后来我把目光放到C#二次开发上，直接通过SolidWorks API把当前文档所有面的面积一次性抓出来，再按条件筛选、导出表格，整个过程可以在几秒内跑完。

这篇文章就把这套思路完整讲清楚：从SolidWorks API的对象结构，到C#连接实例、遍历实体与面、读取面积，再到单位换算、性能处理、筛选导出。适合正在做CAD二次开发、自动化报价、工艺评估这类工作的工程师参考；对SolidWorks API不太熟的同学，也能通过这篇文章搞明白它的对象模型和调用逻辑，照着思路往自己的项目里移植。

1.1 并不是只有建模才需要“所有面面积”

很多人一听到“获得所有面面积”，第一反应是“这不就是看质量属性里的表面积吗”。但实际业务里，光知道一个总和远远不够。

我在实际需求里碰到过三类典型场景。第一种是表面处理报价：喷涂、电镀、阳极氧化都是按面积计费，但不同面可能对应不同工艺——比如外表面要喷漆、内腔不喷，这时候需要的是每个面的面积明细，按面归类后才能准确算价。第二种是工艺工时估算：CNC加工中某个面的加工面积大小直接影响刀具路径和铣削时长，提前统计关键面的面积可以辅助排产。第三种是质量筛查：复杂模具里容易出现极小的碎面，这类面往往是建模失误或倒角过小造成的，通过遍历所有面并筛出面积异常的项，能快速定位模型问题。

这三类需求的共同点是：都需要逐面级别的数据，而不是整体汇总数据。SolidWorks自带的质量属性只能给总面积和体积，拿不到“哪个面多大”的粒度，所以必须走API。

1.2 SolidWorks API对象模型：从文档到面的五层结构

要写面积提取代码，第一步不是急着打开Visual Studio，而是先认清SolidWorks API的对象层级。整个调用链是固定的：

• SldWorks：Application对象，对应正在运行的SolidWorks程序本身
• ModelDoc2：当前打开的文档，可以是零件、装配体或工程图
• PartDoc / AssemblyDoc：文档的具体类型接口，通过它访问实体
• Body2：实体/曲面体，一个零件可以包含多个Body
• Face2：每个Body上的面，Face2.GetArea()就是我们要调用的方法

生活化类比一下：ModelDoc2相当于一栋大楼，PartDoc是大楼的楼层平面图，Body2是某一层里的具体房间单元，Face2则是这个房间的每一面墙壁。我们要做的就是拿到“每一面墙”的尺寸数据。

这个层级关系之所以重要，是因为很多新手写代码时总想直接从ModelDoc2跳到Face2，结果发现拿不到接口。API的访问路径是单向的，必须顺着文档→体→面的阶梯一步步走，哪一层断了，后面的数据都取不到。

1.3 插件内开发还是外部程序调用：两条路线怎么选

讲实现细节之前，先聊一个方向性问题：用C#做SolidWorks API开发，有两条路线。

一条是插件（AddIn）方式：把功能编译成DLL嵌入SolidWorks进程，在软件里增加菜单或命令按钮，用户点一下就能跑。这种方案对最终使用者最友好，但开发和调试相对繁琐，要管理加载卸载、版本适配、界面事件等一堆东西。

另一条是外部程序（EXE）方式：写一个独立运行的C#控制台或WinForm程序，通过COM连接正在运行的SolidWorks实例，读取数据后直接输出结果。这种方案调试方便，适合内部工具和批量处理，也是我今天要讲的方案。

我建议做面积统计这类工具时优先考虑外部程序，原因很实际：这类需求往往是辅助计算，而不是日常高频操作，没必要做成插件塞进SolidWorks界面里。而且外部程序可以脱离SolidWorks进程单独测试，修改逻辑后重新编译运行即可，调试效率高很多。

2. 开发前准备：引用SDK、连接实例，先让程序“看到”SolidWorks

2.1 引用SDK DLL最容易错的两个细节

用C#调用SolidWorks API，需要先引用官方互操作程序集，通常是SolidWorks.Interop.sldworks.dll。这个DLL一般位于SolidWorks安装目录下，不同版本路径会有些差异，不熟悉的话直接在安装目录搜文件名就行，很快能找到。

引用之后有两个细节容易被忽视，我在这里单独拎出来讲。

第一个细节是“嵌入互操作类型”这个选项。在Visual Studio里选中引用后，属性面板里有个Embed Interop Types，默认可能是True，但建议改成False。原因是用True模式时，编译器会把互操作类型内嵌到你的程序集里，一旦SolidWorks版本升级，接口签名稍有变化，旧程序可能直接抛异常；改成False后，程序运行时动态解析COM接口，兼容性会好很多。

第二个细节是目标框架的选择。SolidWorks COM互操作在.NET Framework 4.x下最稳，如果你是.NET Core或.NET 8这类现代框架，调用COM虽然也能跑，但要处理STA线程模型、依赖包缺失等问题，坑比想象中多。我的建议很简单：老老实实建一个.NET Framework控制台项目，省心。

2.2 两种连接SolidWorks实例的方式

外部程序连接SolidWorks有两条路径：一种是附加到已经打开的程序窗口上，另一种是启动一个全新的SolidWorks进程。

附加到已打开的实例，代码是这样：

using System; using System.Runtime.InteropServices; using SolidWorks.Interop.sldworks; static SldWorks ConnectToRunningInstance() { try { object obj = Marshal.GetActiveObject("SldWorks.Application"); return (SldWorks)obj; } catch (COMException) { return null; } }

Marshal.GetActiveObject会去系统运行对象表里找“SldWorks.Application”这个COM标识，如果SolidWorks已经打开就能拿到实例。这种方式适合“先让用户打开模型，再点我的工具读取数据”的使用场景。

第二种方式是后台启动新进程，适合无人值守的批量处理：

static SldWorks StartNewInstance() { Type swType = Type.GetTypeFromProgID("SldWorks.Application"); SldWorks swApp = (SldWorks)Activator.CreateInstance(swType); swApp.Visible = true; return swApp; }

这段代码会根据ProgID创建一个新的SolidWorks COM实例。实际开发中通常两种方式组合使用：优先尝试附加到已打开实例，找不到再启动新进程。注意启动新实例后要设置Visible = true，否则程序可能以不可见模式运行，用户还以为没反应。

2.3 验证连接：读取当前文档的基本信息

连接成功后，下一步是验证是否拿到了正确的文档。写代码前想清楚一点：ActiveDoc可能为空，比如用户只开了SolidWorks但没打开任何模型，这时强行往下走会直接空引用崩溃。

验证文档的代码很简单：

ModelDoc2 doc = swApp.ActiveDoc; if (doc == null) { Console.WriteLine("当前没有打开的模型文档，请先打开零件或装配体。"); return; } if (doc is PartDoc) Console.WriteLine($"当前文档：{doc.GetTitle()}（零件）"); else if (doc is AssemblyDoc) Console.WriteLine($"当前文档：{doc.GetTitle()}（装配体）"); else Console.WriteLine($"当前文档：{doc.GetTitle()}（其他类型）");

这里判断文档类型时，我推荐用is PartDoc/is AssemblyDoc这种C#类型判断，而不是调用GetType()去读类型枚举。原因很隐蔽但很实际：COM对象在C#里会被包装成RCW，直接调用GetType()很可能返回的是运行时类型对象，而不是SolidWorks的文档类型常量，容易踩坑。用is判断最直观，也不容易出错。

3. 核心实现：从零件到装配体，遍历所有面并提取面积

3.1 零件场景：Body2.GetFaces()的遍历主循环

拿到文档对象后，零件和装配体的处理方式不同，先讲零件。

SolidWorks的零件文档里，几何体是分组在Body2对象中的。一个简单的拉伸零件通常只有一个Body，但实际工程中多实体零件非常常见——比如阵列壳体、焊接件拆成的多个实体，都可能包含多个Body。所以要遍历所有面，思路是先取到该零件文档下的所有Body，再逐个Body取Faces，最后对每个Face调用GetArea()。

核心代码块如下：

using System.Collections.Generic; using SolidWorks.Interop.sldworks; class FaceAreaItem { public string ComponentName { get; set; } public double AreaM2 { get; set; } } static void ExtractFacesFromPart(PartDoc part, string componentName, List<FaceAreaItem> results) { // 获取所有实体body和曲面body object[] solidBodies = (object[])part.GetBodies((int)swBodyType_e.swSolidBody); object[] sheetBodies = (object[])part.GetBodies((int)swBodyType_e.swSheetBody); ProcessBodies(solidBodies, componentName, results); ProcessBodies(sheetBodies, componentName, results); } static void ProcessBodies(object[] bodies, string componentName, List<FaceAreaItem> results) { if (bodies == null) return; foreach (object bodyObj in bodies) { Body2 body = (Body2)bodyObj; object[] faces = (object[])body.GetFaces(); if (faces == null) continue; foreach (object faceObj in faces) { Face2 face = (Face2)faceObj; double area = face.GetArea(); // 单位：平方米 results.Add(new FaceAreaItem { ComponentName = componentName, AreaM2 = area }); } } }

这里有个细节值得注意：GetBodies按类型区分，swSolidBody对应实体体，swSheetBody对应曲面体。为什么两种都要取？因为实际模型中可能存在曲面补面、钣金展开特征，这些几何可能不是封闭实体而是曲面体。如果只取实体body，统计结果就会漏掉一部分面。把两种类型都遍历一遍，才能保证“所有面”这个需求的完整性。

3.2 装配体场景：递归遍历所有组件

装配体的处理比零件复杂一个层级。装配体文档本身没有直接的面，它的所有几何都来自下面的一个个零部件——零件组件也好，子装配体组件也好，都需要逐层往下找。

这里我用递归方式实现：拿到装配体的所有顶层组件（Component2对象），每个组件再取其模型文档，如果模型文档是零件就调用上面写好的ExtractFacesFromPart，如果是子装配体就继续递归。

static void ExtractFacesFromAssembly(AssemblyDoc assembly, string parentPath, List<FaceAreaItem> results) { object[] comps = (object[])assembly.GetComponents(false); if (comps == null) return; foreach (object compObj in comps) { Component2 comp = (Component2)compObj; string compPath = string.IsNullOrEmpty(parentPath) ? comp.Name2 : parentPath + "/" + comp.Name2; ModelDoc2 compDoc = comp.GetModelDoc2(); if (compDoc == null) continue; if (compDoc is PartDoc) { ExtractFacesFromPart((PartDoc)compDoc, compPath, results); } else if (compDoc is AssemblyDoc) { ExtractFacesFromAssembly((AssemblyDoc)compDoc, compPath, results); } } }

这样处理的好处是：最终统计结果的ComponentName字段会带着完整的装配路径，比如总装/电机座/壳体，后面做筛选、定位问题面时非常有用。否则几百个面混在一起，面积数据拿到手也分不清是哪个零件上的。

3.3 汇总统一入口：零件和装配体共用一套调用

有了零件处理和装配体递归，接下来可以在入口处统一调度：

static List<FaceAreaItem> GetAllFaceAreas(ModelDoc2 doc) { var results = new List<FaceAreaItem>(); if (doc is PartDoc part) { ExtractFacesFromPart(part, doc.GetTitle(), results); } else if (doc is AssemblyDoc assy) { ExtractFacesFromAssembly(assy, doc.GetTitle(), results); } else { throw new NotSupportedException("只支持零件和装配体文档"); } return results; }

调用方只需要关心传一个ModelDoc2进去，就能拿到全模型所有面的面积明细。这个统一入口的设计让后续扩展变得容易，比如以后想支持多文档批量处理，只要循环调用它就行。

4. 实测踩坑：单位换算、隐藏面与性能优化

4.1 最大的坑：GetArea()返回的是平方米，不是毫米

第一次跑通遍历逻辑时，我盯着控制台输出的面积数字愣了好半天——一个100mm×50mm×20mm的长方体，程序输出的总面积明明是0.016，可这个数怎么看都不像能直接用于报价。

原因要从SolidWorks API的底层设计说起。它的几何内核在计算物理量时默认采用国际单位制，GetArea()返回值的单位是平方米。但对绝大多数国内制造企业来说，图纸单位是毫米，我们期望的面积单位是平方毫米。1平方米等于10的6次方平方毫米，如果忘记换算，报价单上的数据会直接差六个数量级。

换算逻辑本身不复杂，关键是要让程序具备“根据文档单位动态换算”的能力，而不是写死乘一个系数。最简单的稳妥方案是提供一个换算辅助函数：

/// <summary> /// 根据当前文档长度单位和目标面积单位，计算面积缩放系数 /// </summary> static double GetAreaScale(ModelDoc2 doc, string targetUnit = "mm2") { // 先获取文档长度单位，再按长度单位换算面积的平方关系 object[] unitInfo = (object[])doc.GetUnits((int)swUserUnitsType_e.swLengthUnits); // 简化处理：读取长度单位枚举 int lengthUnit = Convert.ToInt32(((IUnitSystem)doc.GetUnits((int)swUserUnitsType_e.swLengthUnits)).GetLengthUnit()); double lengthScale = lengthUnit switch { 0 => 1000.0, // 毫米 -> 米 1 => 100.0, // 厘米 -> 米 2 => 1.0, // 米 3 => 39.3701, // 英寸 -> 米 _ => 1.0 }; double areaScale = lengthScale * lengthScale; if (targetUnit == "mm2") return areaScale / (1000.0 * 1000.0) * 1000000.0; return areaScale; }

其实更省心的做法是：只在程序里约定统一输出平方毫米，然后根据文档长度单位换算一次系数，把所有面积结果统一转成平方毫米，后续的排序、筛选都以这个为准。无论当前图纸是毫米、厘米还是英寸制，都不影响结果口径。

4.2 隐藏与非激活状态的数据要不要统计

“所有面”这个表述在实际业务里是有歧义的。设计状态下的隐藏特征、压缩特征，要不要统计？

先说结论：被压缩的特征不会生成几何体，所以GetBodies拿到的Body里天然不包含它们，这部分不用额外处理。但“隐藏”状态的Body就不一样了——隐藏只是不在界面上显示，几何体仍然存在，GetBodies依旧会把它们返回给你。

我推荐在ProcessBodies里加一个过滤条件，是否包含由调用方决定：

static void ProcessBodies(object[] bodies, string componentName, List<FaceAreaItem> results, bool includeHidden = true) { if (bodies == null) return; foreach (object bodyObj in bodies) { Body2 body = (Body2)bodyObj; if (!includeHidden && !body.Visible) continue; object[] faces = (object[])body.GetFaces(); if (faces == null) continue; // ... 后续取面逻辑不变 } }

这里要结合业务需求判断。如果是喷涂报价，隐藏面不该计入成本；如果是全量模型数据备份，则建议保留全部隐藏面。给自己留一个开关，比到时候再改代码灵活得多。

4.3 大装配体的性能优化：一次循环能做的别做两次

实测下来，面数量在几千个以内的普通零件，整个遍历过程都是毫秒级，不需要任何优化。但碰到大型装配体——几十个零件、数万张面——COM调用的累积开销就会体现出来。

我处理过一个整机模型，包含约200个零件，总面数大概3万。第一次跑遍历程序花了将近40秒，后来排查发现瓶颈不在GetArea()本身，而是我在循环里反复做了两件“小事”：一是每个面都拼接了包含组件名称的字符串，非常耗时；二是频繁访问comp.GetModelDoc2()来获取同一个文档对象。优化方式很简单：先把组装路径拼好放入FaceAreaItem的ComponentName，面积只追加到List里，所有字符串格式化放到遍历完成之后统一处理。

另一个明显优化是只在必要时访问COM对象。每个COM互操作调用都有一次进程边界开销，虽然单次很小，但几万次累加起来就很明显。能缓存的对象就缓存，能少调就少调，这是所有COM二次开发共通的性能准则。

4.4 用长方体做一次手工验算

写面积提取工具，最怕程序跑通了但数据错了，而且错得看不出异常。我强烈建议在写完后用标准几何体做一次验算。

以100mm×50mm×20mm的长方体为例，手工计算六个面的面积：

总面积 = 10000 + 4000 + 2000 = 16000mm²，也就是0.016m²。如果程序输出的面积列表正好是6条记录，且总和等于16000mm²（或换算成对应的m²），说明遍历逻辑和单位换算都没问题。

这组验算值我写成了固定的自检用例，每次改完代码都会跑一遍。它挡掉的低级错误远比想象中多——单位系数写错、遗漏曲面体、数组转换失败，都能在这几分钟内暴露出来。

5. 结果应用：筛选异常面、导出表格、对接后续流程

5.1 按面积阈值筛选异常面

拿到了所有面的面积明细，下一步就是按业务规则处理。我遇到最多的筛选需求是“找出面积过小的碎面”。

碎面对加工没什么影响，但会影响后续的网格划分和渲染性能。用LINQ一行就能搞定：

double threshold = 50.0; // 单位：平方毫米 var smallFaces = results .Where(item => item.AreaM2 * 1000000.0 < threshold) .ToList(); Console.WriteLine($"面积小于 {threshold}mm² 的面共有 {smallFaces.Count} 个"); foreach (var item in smallFaces.Take(10)) { Console.WriteLine($"{item.ComponentName}: {item.AreaM2 * 1000000.0:F3} mm²"); }

筛选逻辑按需组合即可。比如按组件名搜某个零件下的所有面、按面积范围统计分布区间、找出最大的5个面，这些都是很常用的分析视角。

5.2 导出CSV：注意编码问题

数据要给别人看或者存档，导出CSV是最通用的方案。这里有个容易被坑的点：CSV文件如果用默认的Encoding.Default写中文，到了别人电脑上打开Excel很容易乱码。

推荐用带BOM的UTF-8编码写入：

using System.IO; using System.Text; static void ExportToCsv(List<FaceAreaItem> results, string filePath) { using (var writer = new StreamWriter(filePath, false, new UTF8Encoding(true))) { writer.WriteLine("组件路径,面积(mm²)"); foreach (var item in results) { writer.WriteLine($"{item.ComponentName},{item.AreaM2 * 1000000.0:F3}"); } } Console.WriteLine($"已导出 {results.Count} 条面面积记录到：{filePath}"); }

我自己做过一次对比测试，同样的数据用普通File.WriteAllText默认编码写出来，Excel打开直接乱码；加上new UTF8Encoding(true)后，无论是Excel还是记事本打开都正常。这个细节看起来小，但实际项目交付时很容易因为乱码被返工。

5.3 与总面积、质量属性互相印证

最后说一个我常用的校验套路：把逐面面积累加得到的“总面积”，和SolidWorks自带的质量属性里的“表面积”做对照。

double totalAreaFromFaces = results.Sum(item => item.AreaM2); // 调用质量属性接口获取表面积，做对照 ModelDocExtension ext = doc.Extension;

两者理论上应该完全一致或只差浮点尾差。如果偏差超过0.1%，说明遍历过程漏了面——大概率是某类Body没取到。这个对照组可以作为程序运行的自动校验项，每次跑完都输出一条对照结果，多少能防住漏面这类问题。

顺着这个思路往下扩展，其实可以把“所有面的面积”继续细化成更多的面属性：面的类型（平面、圆柱面、圆锥面、样条曲面）、面的周长、最小曲率半径等等。有了这些数据，后面做工艺评估、成本估算就能从一个“黑盒总表面积”升级成可以逐面分析的结构化数据集，这正是C# + SolidWorks二次开发的价值所在。

我在实际项目中感触最深的一点是：这类工具真正难的不是API调用本身，而是所有数据口径都要建立在“业务定义清晰”之上——包括单位口径、隐藏面口径、曲面体口径。把这些定义钉死，代码就会非常稳定；定义含糊，再漂亮的遍历逻辑都可能在交付现场翻车。