最近写了一点 UG NX 的二次开发。二次开发这事儿的特点是“磨”，一个一个坑往往是长久的走投无路之后才柳暗花明。
今天碰上的问题是，之前在 Win 10 下调好了的代码，拿到 Win 11 下无法运行；报错信息大概是：
onecore\net\netprofiles\service\src\nsp\dll\namespaceserviceprovider
此服务不存在，在指定的命名空间中找不这个服务
这是调试控制台抓出来的信息。正常运行的话，最多只有一个自己编的意外弹窗，写的是更为模糊的信息。搜了一番，原因大概是：
When running on windows 11. The GetHostByName is deprecated. Only GetHostName is supported as far as I can tell.
—— 来自：https://github.com/Nethereum/Nethereum/issues/973
于是找了 Win 10 机器测试，发现原生在 Win 10 上面编译出来的可执行文件在 Win 10 上运行是正常的，但只要编译环境或者运行环境二者之一是 Win 11，都会出这个问题。
细节就不用继续追究了，无论微软还是西门子都不是自己能撼动的。幸好甲方大爷们倒是不要求 Win 11 运行。
用的是 NX 12 的某个版本，考虑到这玩意儿是 2017 发布的，不兼容 Win 11 倒是情有可原。也许更新的版本会支持？
这段写于上一段三周之后。
就是，今天发现了另外一个问题，是调用了 C++ NXOpen 的程序会从 exe 所在目录加载一些 dll，而其中一个 dll 恰好与 UG 自己的一个 dll 重名，最终造成冲突。
但是！我发现这个问题之后去看 Win11 的那一台机器，发现也有这个 dll 文件。然后我把他删掉，Win11 上就能运行了！
所以，上面一段问题有可能是假的。即使有报错信息，但在指针乱飞的前提下，报错信息也不能 100% 相信。
但目前也只能说有可能是假的。二次开发的事儿，谁能肯定呢？
为了验证，重新编译了若干依赖库（因为不可能动UG嘛），从我能控制的方向改掉了冲突库的名字，问题解决。
因为两个库是完全重名并且需要出现在同一个进程中，这基本上是手动加载DLL之外唯一办法了。更改加载路径之类的方法是没有用的，因为一旦加载了任何一个，动态库自动加载机制就不会再去搜索第二个文件而是直接使用。
也幸好这俩库至少有一个是我能掌控的，否则就只能做双进程模式了。
其实不见得都是你的问题。
今天一次现场调试的时候，发现NXOpen不能加载装配体了，加载零件是正常的，匪夷所思。
经历了包括重启在内的一系列办法后，发现……是那个装配体文件因为某种原因有损坏……