被测试的代码应该编译为 DLL 还是可执行文件？
我有两个项目的解决方案。一个用于生产代码的项目，另一个用于单元测试的项目。我是按照我从 SO 那里得到的建议这样做的。
我注意到在调试文件夹中它包含可执行形式的生产代码。我在删除可执行文件后使用 NUnit 运行测试，但它们在尝试查找可执行文件时都失败了。所以它肯定是在努力寻找它。然后我快速阅读了一下，找出 DLL 和可执行文件哪个更好。 DLL 似乎要快得多，因为它们共享内存空间，而可执行文件之间的通信速度较慢。
不幸的是，我们的生产代码需要是可执行的。所以单元测试会稍微慢一些。我对此不太担心。但该项目确实依赖于另一个库中编写的代码，该库目前也是可执行格式的。
是否应该将公开某种 SDK 的项目编译为 DLL，然后将使用 SDK 的项目编译为可执行文件？
I have a solution with two projects. One for project for the production code and another project for the unit tests. I did this as per the suggestions I got here from SO.
I noticed that in the Debug Folder that it includes the production code in executable form. I used NUnit to run the tests after removing the executable and they all fail trying to find the executable. So it definitely is trying to find it. I then did a quick read to find out which is better, a DLL or an executable. It seems that an DLL is much faster as they share memory space where communication between executables is slower.
Unforunately our production code needs to be an exectuable. So the unit tests will be slightly slower. I am not too worried about that. But the project does rely on code written in another library which is also in executable format at the moment.
Should the projects that expose some sort of SDK rather be compiled to an DLL and then the projects that use the SDK be compiled to executable?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
仅仅因为它是一个可执行文件并不意味着它会作为单独的进程加载。
在 .NET 中，您可以像加载 DLL 一样轻松地将 EXE 文件作为程序集加载。这就是这种情况下发生的情况（无论如何，我想）——没有跨进程通信，没有问题。
如果您真正测试的东西在逻辑上应该是可执行文件，那么就可以了。
Just because it's an executable file doesn't mean it's being loaded as a separate process.
In .NET you can load an EXE file as an assembly just as easily as a DLL. That's what's happening in this case (I'd imagine, anyway) - no cross-process communication, no problem.
If you're genuinely testing something which should logically be an executable, then that's fine.