企业官网建设流程全解析

简介：UG二次开发依赖NXOpen与GRIP两套工具链，而环境配置的核心在于版本配对与注册表管理。NX通过注册表定位组件路径、类型库和许可证服务，一旦残留旧版本信息或误用清理工具，便会出现VS2015创建项目失败、编译报错、GRIP提交闪退等连锁问题。理解NXOpen程序集加载顺序、GRIP依赖的环境变量以及VS项目模板的注册机制，是从“能装软件”迈到“能写代码”的关键门槛。在工业插件开发、自动化建模及企业工具集成等场景中，稳定可复现的开发环境直接决定交付效率。本文结合“梅雷”2016版资源包的使用经验，系统梳理NX版本与VS版本对应关系、注册表残留排查链路、工具箱加载失败成因，并给出经过验证的手动配置方案，帮助开发者在UG二次开发起步阶段跳过最常见的环境深坑。 拿到这份《UG二次开发帮助文档【梅雷】2016版》资源包的人，大多是想从GRIP或者NXOpen入手，做点自己的工具、插件，甚至搞一套类似“梅雷工具箱”的集成界面。但现实很骨感：资源包解压出来、VS2015装好、NX也装好，新建NXOpen C#项目的时候，报错一个接一个；好不容易项目建出来了，编译又提示找不到类型；折腾半天，最后发现是注册表里残留了旧版本NX的组件信息。这套流程我前前后后帮同事和自己排过不少次，今天就把这些坑一次性讲清楚。

1. 梅雷2016版资源包到底值不值得花时间——先搞清楚你手里有什么

先说结论：这个资源包的核心价值不是“现成工具”，而是“学习路径”。它把UG二次开发的入门材料、GRIP帮助文档、部分工具源码、以及一些环境配置说明整合到了一起，省去了到处找资料的功夫。但正因为它是2016年的打包，里面的软件版本、API接口、VS版本对应关系，和现在的NX版本差距很大，所以用之前得做一次“版本翻译”。

1.1 资源包里的标准内容拆解

以这类资源包的常见构成来看，解压后一般包含这几个部分：

• GRIP语言帮助文档和示例程序（.grs/.grx文件），适合想走传统宏语言路线的开发者；
• NXOpen相关说明文档，涵盖C#和C++接口的基础调用方式；
• 一些二次开发工具集源码或编译好的DLL，也就是“梅雷工具箱”这类东西；
• VS2015环境配置说明，包括如何设置NXOpen引用路径、如何配置项目模板等。

这里提醒一句：如果资源包里的“工具箱”是编译好的DLL而不是源码，别急着直接用。2016年编译的DLL大概率是面向NX 10或NX 11的，放到NX 12、NX 2212这些版本上，轻则加载失败，重则导致NX启动异常。反而是里面的GRIP示例和帮助文档，跨版本使用问题不大，学习价值也更高。

1.2 下载之后先别急着解压运行，先做版本匹配判断

我在帮别人排查时发现，大部分人拿到资源包后的第一反应是“解压、打开说明文档、照着做”，结果按文档里写的路径去配置NXOpen引用时，发现NX安装目录里根本没有那些DLL或文件夹。原因很简单：文档写的是当年那个NX版本，而你装的NX版本变了目录结构。

所以正确的第一步是：

1. 确认自己NX主版本号（比如NX 11、NX 12、NX 2212等），在NX帮助菜单的“About”里能看到准确版本；
2. 根据主版本号，对照VS版本要求；
3. 再去资源包里找对应版本的说明文档，而不是拿2016版文档直接套用。

这一步看起来不起眼，但它能帮你省下后面至少两小时的排错时间。

2. VS2015与NXOpen的版本配对工程：不是你装好VS就能写代码

热词里大量出现“nxopen vs2015”“ug二次开发c#创建项目失败”，说明很多人卡在了VS2015和NXOpen的对接上。这里我直接把版本对应关系讲透。

2.1 NX版本、VS版本、.NET Framework版本怎么对应

不同NX主版本对其二次开发工具链有严格的要求：

如果你的NX是11或12，用VS2015是正好匹配的；但如果你的NX是2007系列或更高，VS2015编译出来的程序集在加载时大概率会出问题。这个配对关系是硬性的，不是“能用就行”的宽松关系。NX通过程序集元数据判断扩展是否兼容，版本差了直接拒绝加载。

2.2 NXOpen项目模板缺失或创建失败：最常见的三个原因

热词里的“ug二次开发c#创建项目失败”我见得最多，拆开看基本是这三种情况：

原因一：VS2015没有安装NX提供的项目模板插件。

安装NX时，在安装界面可以选择安装“NX Open”相关组件，如果当时没勾选，VS里就不会出现“NXOpen C#”这类项目模板。解决办法有两个：一是重新运行NX安装程序，修改安装组件，勾选NXOpen开发包；二是去资源包或Siemens官网找对应版本的“NX Open VSIX”插件，解压后手动安装到VS2015里。

原因二：VS2015未以管理员权限启动。

这个原因特别傻，但特别常见。NX的模板安装脚本默认写入C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\ProjectTemplates，这个路径受UAC保护。如果VS不是管理员权限启动，模板文件根本没有被复制进去，但安装脚本又不会报错。检查方法很简单：打开VS的“新建项目”对话框，看左侧模板树里有没有“NX Open”分类。没有的话，关掉VS，右键“以管理员身份运行”，再试一次。

原因三：注册表残留的旧版本NXOpen类型库干扰了项目模板注册。

这是最隐蔽的。如果电脑上曾经装过NX 8.5、NX 9等旧版本，卸载时没有清理干净，注册表HKEY_CLASSES_ROOT\TypeLib下会残留NXOpen的类型库GUID。VS新建项目时加载模板，读到旧GUID，就会报“值不在预期的范围内”或“创建项目失败”。这种问题的排查链路我们放到后面专门讲。

2.3 手动配置NXOpen C#项目的完整步骤

如果项目模板实在修复不了，也不用一直卡着，完全可以用一个普通的类库项目手动配置。操作如下：

1. VS2015中新建“类库(.NET Framework)”项目，目标框架选4.5.2或版本对应表中的值；
2. 在项目上右键“添加引用”->“浏览”，定位到NX安装目录下的NXBIN\managed文件夹；
3. 添加引用NXOpen.dll、NXOpen.UF.dll、NXOpenUI.dll、NXOpen.Utilities.dll等核心程序集，开发带界面的工具时还需要NXOpen.UIStyler.dll；
4. 在项目属性“生成”选项卡中，把“平台目标”设为x64。如果保留了AnyCPU，NX加载时会因位数不匹配报错；
5. 项目属性“调试”里，把“启动外部程序”设为C:\Program Files\Siemens\NX版本根目录\NXBIN\ugraf.exe。

这套手动配置和模板创建的项目效果一样，而且因为每一步都自己做了，之后出问题排查起来反而更轻松。

3. GRIP编译与注册表的关系：为什么你的GRIP程序总在“提交”时闪退

GRIP（Graphics Interactive Programming）是NX里非常老牌的二次开发语言，虽然在NXOpen面前显得有些过时，但在批量处理一些简单建模、数据提取的活儿上依然很能打。资源包里大量出现GRIP帮助文档，说明很多人还在用或者说还想学这套东西。

3.1 GRIP的运行机制和它要“碰”哪些东西

GRIP程序的编写、编译、运行流程是这样的：

• 用文本编辑器写.grs源码文件；
• 在NX的“文件->执行->GRIP”里选择编译，生成.grx文件；
• 再次通过“文件->执行->GRIP”运行.grx。

看起来和写脚本差不多，但GRIP能正常运行依赖几个前提：GRIP许可证可用、系统环境变量配置正确、NX进程能访问GRIP编译器目录。如果前置条件不满足，就会出现编译时闪退、提交程序后无响应、或者直接提示“GRIP环境错误”。

3.2 注册表、环境变量与GRIP的三角关系

很多人忽略的一点是，GRIP依赖的环境变量在安装NX时被写进注册表，而不是系统环境变量面板。具体来说，NX安装程序会在HKEY_LOCAL_MACHINE\SOFTWARE\Siemens\NX和HKEY_CURRENT_USER\Software\Unigraphics Solutions下写入一系列项，其中就包括UGII_ROOT_DIR、UGII_BASE_DIR、UGII_GRIP等关键路径。

这里就是热词里“注册表”“GRIP注册表”大量出现的原因。一旦某个“注册表清理工具”把NX相关的注册表项清理掉，或者旧版本NX卸载时把注册表键值顺带删掉了，GRIP编译器就会找不到自身路径，表现为：

• 打开GRIP编译菜单后，NX界面闪一下或直接崩溃；
• 提交.grs文件后，命令窗口一闪而过，没有生成.grx；
• 更严重的情况下，NX启动时因为UGII_BASE_DIR指向不存在的路径，加载GRIP模块直接报错。

检查方法也简单，在系统环境变量里加一个临时变量UGII_GRIP，值指向NX安装目录下的GRIP文件夹（通常为C:\Program Files\Siemens\NX版本\GRIP），然后重新启动NX，看编译是否恢复。如果恢复了，说明注册表里的键值确实已经损坏，需要手动修复注册表，而不是靠环境变量打补丁。

3.3 清理注册表时保护NX组件的边界线

热词里“清理注册表”“彻底清理注册表”连续出现，但我要特别泼一盆冷水：在UG二次开发环境里，宁可注册表脏一点，也不要激进清理。NX的许可服务、类型库、COM组件、环境变量散落在多个注册表分支中，彼此之间还有交叉引用。用市面上那些“一键清理”工具扫一遍，大概率会把NXOpen的COM组件注册项误判为无效项清理掉，结果就是NX能启动，但所有外部程序调用NXOpen接口时全部报错。

我做环境维护时的原则是：

• 只清理与特定软件卸载相关的残留项，且清理前先导出备份；
• 用系统自带的regedit手动删除，不使用第三方“智能清理”；
• 重点保护HKEY_CLASSES_ROOT\TypeLib、HKEY_CLASSES_ROOT\Interface、HKEY_LOCAL_MACHINE\SOFTWARE\Siemens三个分支。

4. 注册表错误和创建项目失败的完整排查链路

前面提到“注册表残留干扰了项目模板创建”，这里把整套排查过程走一遍。思路比结论重要，因为电脑环境千差万别，但排查逻辑是通用的。

4.1 从现象到假设：不要一上来就重装VS

一个典型的故障现象是：VS2015里新建NXOpen项目，点了“确定”之后，进度条转两圈，弹出对话框说“创建项目失败”，或者“调用的目标发生了异常”。

遇到这个报错，我的排查顺序是：

1. 看细节按钮里的异常信息。VS的创建项目失败对话框通常会附带“查看详细信息”的链接，点开能看到底层异常类型。如果出现System.Runtime.InteropServices.COMException，基本可以锁定是注册表类型库问题；如果出现System.IO.FileNotFoundException，则是模板文件缺失，走管理员权限重装模板。
2. 查看Windows事件查看器。在“应用程序”日志里，筛选来源为.NET Runtime或VS的错误记录，能看到更完整的堆栈。有一次我排查了一下午，最后在这里看到了加载NXOpen.Part程序集失败，原因是被旧版本程序集占用了。
3. 用进程监视器确认VS加载了哪些NX相关DLL。这一步稍微专业一点，但非常有用。运行Process Monitor，过滤“Path结尾是.dll”且“Process Name是devenv.exe”，新建项目时观察加载了哪些NXOpen相关DLL，以及它们从哪里加载的。如果看到VS往C:\Windows\System32里找NXOpen.dll，那就是COM注册表中指向的路径不对。
4. 检查注册表中NXOpen类型库的GUID和路径一致性。打开regedit，切换到HKEY_CLASSES_ROOT\TypeLib，搜索NXOpen，逐个展开GUID分支，看win32键值是否指向真实存在的DLL路径。如果该路径已不存在，删除整个GUID分支（先导出备份），再重试新建项目。

4.2 “由于其配置信息（注册表中的）不完整或已损坏”这个报错的真实成因

热词里有一条非常典型的Windows错误：“由于其配置信息（注册表中的）不完整或已损坏，Windows无法启动这个硬件设备”。这个报错在UG二次开发环境里也不少见，尤其是在安装过USB加密狗驱动、后来又卸载了旧版NX许可服务的机器上。

它的本质是：Windows设备管理器中，某个设备的驱动程序服务（Driver Service）的注册表项被破坏，系统无法启动该设备。常见的触发点是UGS License Server（UGNX许可证服务）安装时注册的驱动服务，卸载NX后服务残留但驱动文件已经被删，设备管理器里就会出现一个带黄色感叹号的未知设备。

处理办法：

1. Win+R输入devmgmt.msc打开设备管理器；
2. 找到状态为“无法启动”或带感叹号的设备（名字里常含“Sentinel”“HASP”“UGS”等字样）；
3. 右键卸载设备，勾选“删除此设备的驱动程序软件”；
4. 重新安装对应版本的许可服务，或如果不再需要该设备，安装一个假驱动占位。

我经历过一次很极端的案例：某台机器上所有USB设备全部无法启动，最后发现就是许可服务注册的过滤驱动异常，清理后才恢复。

4.3 一个完整的“从零到能建项目”的修复顺序

如果以上问题你都想自己先试一遍，我建议按这个顺序来，避免重复操作：

1. 备份注册表关键分支（HKEY_LOCAL_MACHINE\SOFTWARE\Siemens、HKEY_CLASSES_ROOT\TypeLib）；
2. 确认NX安装完整性：运行安装目录下的ugraf.exe，确认NX能正常启动；
3. 以管理员身份打开VS2015，测试新建NXOpen项目；
4. 如果失败，看异常详情，对着第4.1节的顺序排查；
5. 如果确认是类型库残留，清理后重启VS；
6. 如果项目模板文件缺失，重新运行NX安装程序，勾选NXOpen组件；
7. 重新编译一个最简单的“Hello Part”程序，验证环境可用。

5. NXOpen程序集的正确引用方式——你引用的DLL可能根本没被加载

项目能创建成功，只是万里长征第一步。接下来写代码时，最常见的坑是：using NXOpen;这一行就飘红，或者编译时报“命名空间中不存在类型”。热词里“NXOpen”“无法读取”相关的报错，很大一部分出在这个环节。

5.1 NXOpen程序集搜索顺序与“双重引用”陷阱

NX在运行时会按固定顺序加载程序集：先是NX安装目录下的NXBIN\managed文件夹，然后才是系统GAC或应用程序目录。这带来一个非常隐蔽的陷阱：

如果你在项目里手动引用了NXOpen.dll，并且把“复制本地”属性设为了True，那么编译时VS会把NXOpen.dll复制到你的输出目录。NX运行你的插件时，如果输出目录的DLL和它自己版本不一致（例如你的DLL是从NX10拷贝出来的，而NX12在运行），就会加载失败或出现类型转换异常。更麻烦的是，这种错误往往只在你自己的机器上不出现，换一台NX版本不同的电脑就崩。

正确做法是：项目引用里添加NXOpen.dll后，把“复制本地”设为False，让NX在运行时使用自己安装目录下的程序集。

5.2 Session.GetSession()到底在什么时候会失效

NXOpen C#程序的标准入口通常是：

Session theSession = Session.GetSession(); Part workPart = theSession.Parts.Work;

但这段代码在两种场景下会失效：一是外部进程调用NXOpen时（比如用C#写一个独立的exe，用Session.GetSession()去连正在运行的NX），此时必须使用NXOpen.UF.UFSession.GetUFSession()里的UF方法，或者先调用NXOpen.Session.GetSession()但确保环境变量和启动参数正确；二是当你的程序集在NX内部被多次加载、且上一次异常退出导致进程状态不一致时，Session.GetSession()可能拿到一个null。

遇到后者，没有太好的程序化办法，只能重启NX，或者把程序逻辑包在try-catch里，捕获异常后提示用户重启NX。

5.3 用UF方法创建文本（Text）的一个冷门但实用的例子

热词里有一条“能不能创建模型中的text，用uf方法”——这是很具体的问题。在NXOpen里创建文本通常用的是NXOpen.Annotations命名空间下的AnnotationManager，但如果你想用底层UF方法实现，有一个经典写法：

// 创建UF会话 UF uf = UF.UFSession.GetUFSession(); // 定义文本原点 double[] origin = new double[3] { 0.0, 0.0, 0.0 }; // 定义文本方向（这里用平面X方向） double[] planeNormal = new double[3] { 0.0, 0.0, 1.0 }; // 先用UF生成一个基准平面作为文本放置平面（核心步骤） Tag planeTag = Tag.Null; uf.Plane.CreatePlane(origin, planeNormal, out planeTag); // 再在平面上创建文本 // 注意：UF方法与NXOpen对象模型不同，返回的是Tag而不是对象

UF方法创建文本的难点不在“创建”本身，而在“需要先提供一个带方向的平面或坐标系”。很多教程只给前半段代码，不给平面创建部分，结果照着写就是报“找不到临时平面”。

如果你是刚入门，建议优先用NXOpen的AnnotationManager.AddText方法，代码更直观；只有当你需要在一个自定义实体的表面上批量生成文本时，才值得回头折腾UF方法。

6. 工具箱加载失败的背后：DLL、菜单脚本与NX启动加载路径

标题里的“UG梅雷工具箱”代表了另一类常见需求：不是自己写代码，而是把别人编译好的工具箱加载到NX里，然后通过菜单或工具条调用。这类操作同样有一堆隐藏的地雷。

6.1 NX外部程序集的加载机制

NX启动时会扫描一组固定路径，寻找可加载的二次开发扩展，主要包括：

• %UGII_USER_DIR%\startup（用户级目录，优先级最高）
• %UGII_SITE_DIR%\startup（企业级目录）
• %UGII_BASE_DIR%\startup（安装级目录）

每个startup目录里可以放三类东西：

• .dll文件（NXOpen程序集）；
• .men文件（菜单脚本）；
• .tbr文件（工具条定义脚本）；
• .rtb文件（功能区定义脚本）。

如果你把“梅雷工具箱”的DLL放到了某个startup目录，NX启动时却没有任何反应，最常见的排查顺序是：

1. 确认当前NX实例实际加载的目录是哪个。可以用File -> Execute -> NX Open打开一个Journal，在其中输出Session.GetSession().UserDir和SiteDir，看路径是否符合预期；
2. 确认DLL依赖的.NET Framework版本和NX内部程序集版本匹配。不匹配时，NX启动日志（在%TEMP%\nx_*.log或用户AppData目录下）里通常会记录加载异常，但界面上可能什么都不报；
3. 确认DLL是否包含正确的入口。NXOpen扩展DLL不需要写Main函数，但程序集里必须有一个类被标记为NXOpen.Utilities.NXOpenPlugin或类似特性，否则NX不会执行它。

6.2 菜单脚本（.men）的语法和坑

一个典型的.men文件长这样：

VERSION 120 EDIT UG_GATEWAY_MAIN_MENUBAR BEFORE UG_HELP BUTTON MEILE_TOOLBOX LABEL 梅雷工具箱 ACTIONS MeileToolbox.ShowDlg END_OF_BEFORE

这个脚本本身不复杂，容易出问题的是：

• ACTIONS指向的方法必须是全名（命名空间.类.方法），且该方法必须是public和static；
• 菜单脚本里的BUTTON名称如果与其他菜单脚本的按钮ID冲突，NX会注册失败，而且不给出错误提示；
• 如果你同时修改了.men文件又修改了.tbr文件，两个文件里的按钮ID必须完全一致，否则工具条上的按钮会变成灰色不可点。

6.3 “类型未注册”与注册表的隐藏连接

加载DLL时如果报“类型未注册（Class not registered）”，这时候很多人会去注册表里翻找。其实这类错误分两种：

• COM组件方式加载的DLL确实需要regasm或regsvr32注册，在注册表HKEY_CLASSES_ROOT\CLSID下生成GUID项；
• .NET程序集方式加载的DLL不需要注册，但必须先被初始化。

梅雷工具箱或类似.NET开发工具，通常不走COM注册，而是走NXOpen插件路径。如果报“类型未注册”，大概率是你把DLL放到了需要COM注册的位置，而NX没有自动初始化它。

遇到这种情况，我建议直接把DLL放到用户级startup目录里，而不是尝试用regasm注册。每次修改DLL之后，需要完全退出NX再重启，不能只关闭当前文件。

7. VS2015安装与激活的实操建议，以及许可证和密钥的“坑中坑”

热词里“vs2015安装包下载”“vs2015专业版密钥”频繁出现，说明大家卡在了VS2015这个版本本身。VS2015在2025年的今天，已经算得上“古董”，安装过程也确实更容易出问题。

7.1 安装VS2015最容易被忽略的组件项

VS2015安装器默认会安装C++和C#相关组件，但有两项经常需要手动勾选：

• Windows 10 SDK：NXOpen C++开发需要它，纯C#开发可以不装，但建议装，因为NXOpen的C++头文件编译时需要它；
• Microsoft .NET Framework 4.6 SDK：NX 11或NX 12的C#项目默认目标框架如果是4.6，缺了它会编译报错。

安装顺序上，一定要先装Windows SDK，再装VS2015。反过来装的话，VS的项目模板可能不注册SDK的引用，后续写代码时提示找不到Windows头文件。

7.2 密钥与环境变量：VS2015专业版“到期”的伪问题

大多数“VS2015专业版密钥”相关的热词，其实指向的不是VS本身到期，而是VS的登录态、许可证缓存与系统注册表之间断了。VS2015会在注册表里写许可证状态，如果系统时间被改过，或者用户配置文件夹被迁移过，VS可能反复提示“许可证过期”。这时候不用急着换密钥，先把HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0\Licenses备份后删除，重新打开VS并登录账号，通常能恢复。

7.3 安装VS2015时“无法写入注册表值，请检查权限”的解法

这个报错是因为VS安装器在写入系统级注册表项时权限不足，常见于系统开启了“受控文件夹访问”或安装器没有以管理员身份运行。解法如下：

1. 右键VS安装包，选“以管理员身份运行”；
2. 暂时关闭Windows Defender的“受控文件夹访问”（装完后记得开回来）；
3. 如果还是不行，用Process Monitor看安装器具体卡在哪个注册表路径，手动给该路径加写权限。

8. 你一定会遇到的“系统卡死”与注册表清理谣言——我的保命经验

最后这章，我想认真聊聊“注册表清理”这件事。热词里“彻底清理注册表”“注册表清理”“pdf默认打开方式被篡改 注册表”“一点击文件windows资源管理器就卡死”这些词挤在一起，本身就是个信号——很多人在UG二次开发环境的折腾过程中，顺手把系统弄出了问题。

8.1 “清理注册表让电脑变快”是最大的伪命题

注册表本身不会让电脑变慢。Windows的性能瓶颈从来不是注册表项数量，而是开机启动项、服务状态、磁盘IO这几个方面。所谓的“注册表清理后变快了”，更多是心理作用，或者是因为清理工具顺带删掉了一些无效的临时文件。

但在UG二次开发语境下，注册表清理的危害是实打实的：NXOpen组件、GRIP环境变量、许可服务、VS项目模板，全都依赖注册表。清理工具一跑，轻则VS新建项目失败，重则NX直接无法启动。

我的建议是：不要在装有NX和VS2015的机器上使用任何第三方注册表清理工具。如果你觉得启动慢，用msconfig看启动项，用services.msc看服务。完全不动注册表，是环境维稳的最高原则。

8.2 如果注册表已经被误清理，如何恢复到可用的NX环境

万一你已经跑了清理工具，NX或VS已经出现异常，按优先级做这几件事：

1. 如果之前在系统还原点里创建过还原点，直接用系统还原（最彻底）；
2. 没有还原点的话，导出HKEY_LOCAL_MACHINE\SOFTWARE\Siemens保存好，然后完全卸载NX，删除C:\Program Files\Siemens残留目录，删除HKEY_CURRENT_USER\Software\Unigraphics Solutions，重新安装NX；
3. 对于VS2015，同样卸载后删除HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\14.0和HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0，重新安装；
4. 重装后先验证NX能启动，再验证VS能新建NXOpen项目，最后才去加载工具箱。

这条链路我走过好几次，每一次都是因为图省事用清理工具。后来我学乖了：备一块移动硬盘或者一个虚拟机，专门用来做UG二次开发环境，把主系统当成“干净控制组”，所有骚操作都在虚拟机里试，试通了再往主机上同步。

8.3 最后分享一个保存环境的实用技巧

装好一套能正常工作的NX+VS2015+GRIP环境后，别急着开始写代码。先把这几个东西备份出来：

• 系统还原点（如果系统盘空间够）；
• NX安装目录\NXBIN\managed\*.dll（备份一份到你自己的工具盘）；
• 注册表分支HKEY_LOCAL_MACHINE\SOFTWARE\Siemens的导出文件；
• VS2015的“导出环境设置”；

这四样东西，能帮你在未来任何一次环境崩溃后，用最短时间回到“能干活”的状态。我自己的习惯是每换一台新电脑，第一件事就是把NX环境按模板装好并备份，后面再也不会因为环境问题浪费整整一天。

本文还有配套的精品资源，点击获取