并行执行和 MS 单元测试

发布于 2024-10-04 11:05:06 字数 620 浏览 4 评论 0原文

这里的环境是 C#/.Net 4。

在我的 MS Unit Test 单元测试项目中,我正在测试一段代码,该代码使用 COM dll 进行一些日期转换计算(这又使用一些其他 COM DLL,因此在所有三个 COM DLL 中)参与)。

当在正常的应用程序/服务设置中运行时,通过使用链接到 COM dll 程序集标识的清单,我可以毫无问题地进行并行执行,但是当尝试在单元测试中执行相同操作时项目中,我总是因为“类未注册”异常而失败。

现在,我已经尝试过:

  • 嵌入测试 DLL 清单
  • 嵌入测试 DLL 清单、COM DLL 清单 + COM DLL 本身

但无济于事。所以我想知道:如何使单元测试环境知道通过清单进行的 COM 链接?对我来说,似乎 DLL 清单链接不太工作(EXE 清单工作正常),但通常这些想法等于做错了什么......

我通常在搜索这样的东西方面非常成功,但在这一点上,我的点击量很少,也没有类似的内容,所以如果您有任何想法或意见,请分享:)如果需要详细说明,请告诉我。

(我知道,可以通过在正确的位置进行一些依赖项注入来避免使用 COM dll,但现在我想探讨一下有关并行设置的单元测试的案例)。

亲切的问候

杰斯珀

Environment here is C#/.Net 4.

In my MS Unit Test unit test project I'm testing a piece of code which uses a COM dll for some date conversion calculations (this in turn uses some other COM DLLs so in all three COM DLLs are involved).

When running in a normal application/service set-up, I have no problem getting the side-by-side execution to work through use of manifests linking to the COM dlls' assembly identities, but when trying to do the same from my unit test project, I always get failure due to 'class not registered' exceptions.

Now, I've tried this already:

  • Embedding the test DLL manifest
  • Embedding both the test DLL manifest, the COM dlls manifests + the COM DLLs themselves

But to no avail. So I'm wondering: how could I make the unit test environment aware of the COM linking through the manifests? To me, it seems like the DLL manifest linking isn't quite working (the EXE manifests are working fine), but usually those kinds of thoughts equals doing something wrong ...

I'm usually pretty successful in searching for stuff like this, but on this one, I've had very few hits, and nothing which resembles this, so please, if you have any thoughts or input, do share :) And if elaboration is needed, please let me know.

(I know, that the use of the COM dlls could probably be avoided by some dependency injection the right place, but for now I'd like to explore this case regarding unit testing a side-by-side setup).

Kind Regards

Jesper

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

梦毁影碎の 2024-10-11 11:05:06

我不熟悉 MS 单元测试,所以这只是猜测。

在正常的应用程序设置中,您已通过应用程序清单引用了 COM 服务器清单,因此常规“进程激活上下文”包含正确的引用。

在单元测试场景中,您无法控制应用程序,因此流程激活上下文没有正确的引用。
您已将测试 DLL 清单嵌入到 DLL 中,但除非您做额外的工作,否则所做的只是允许根据清单解析静态 DLL 依赖项。只要您的 dll 代码处于活动状态,清单激活上下文就不会处于“活动”状态;您必须自己管理此上下文,方法是手动创建并激活对 COM 服务器的调用周围的上下文。

例如,请查看 CodePlex 上 OneCode 项目的 CSRegFreeCOMClient

I'm not familiar with MS Unit test, so this is just guesswork.

In your normal application setup, you've referred to the COM server manifests through your app manifest, so the general "process activation context" includes the proper references.

In the unit test scenario, you don't control the application, so the process activation context doesn't have the proper references.
You've embedded the test dll manifest in your DLL, but all that does, unless you do extra work, is allow static DLL dependencies to be resolved against the manifest. The manifest activation context isn't "active" whenever your dll code is active; you have to manage this context yourself, by manually creating and activating the context around your calls into the COM server.

For an example, take a look at CSRegFreeCOMClient from the OneCode project on CodePlex.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文