【问题标题】:Should the code being tested compile to a DLL or an executable file?被测试的代码应该编译成 DLL 还是可执行文件?
【发布时间】:2010-04-14 15:01:59
【问题描述】:

我有两个项目的解决方案。一个用于生产代码的项目,另一个用于单元测试的项目。我是按照我从 SO 那里得到的建议这样做的。

我注意到在调试文件夹中,它包含可执行形式的生产代码。我在删除可执行文件后使用 NUnit 运行测试,但它们都未能尝试找到可执行文件。所以它肯定是在试图找到它。然后我快速阅读以找出哪个更好,DLL 或可执行文件。 DLL 似乎要快得多,因为它们共享内存空间,而可执行文件之间的通信速度较慢。

不幸的是,我们的生产代码需要是可执行文件。所以单元测试会稍微慢一些。我对此并不太担心。但是该项目确实依赖于另一个库中编写的代码,该库目前也是可执行格式。

是否应该将暴露某种 SDK 的项目编译为 DLL,然后将使用 SDK 的项目编译为可执行文件?

【问题讨论】:

    标签: .net performance unit-testing dll executable


    【解决方案1】:

    仅仅因为它是一个可执行文件并不意味着它被作为一个单独的进程加载。

    在 .NET 中,您可以像加载 DLL 一样轻松地将 EXE 文件加载为程序集。这就是在这种情况下发生的事情(我想,无论如何) - 没有跨进程通信,没问题。

    如果您真正测试的东西在逻辑上应该是可执行文件,那很好。

    【讨论】:

    • 谢谢。我在想也许我应该先问这个问题。 .Net 如何处理两个可执行文件之间的通信。
    • @uriDium:您的意思是“两个恰好是 EXE 文件的程序集”还是“两个进程”?它们是完全不同的东西。运行某些代码后,.NET 并不真正关心程序集是在 EXE 文件中还是在 DLL 中。
    • 两个程序集恰好是 EXE 文件。不是两个单独的过程。为此,他们需要使用我想象的远程技术形式。除非它们被写入共享内存空间。
    • @uriDium:在这种情况下,两个 EXE 文件和两个 DLL 之间确实没有显着差异。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多