与 64 位 Sharepoint 和 TFS 2008 持续集成?

发布于 2024-08-05 06:35:54 字数 1012 浏览 3 评论 0 原文

我已经使用 Sharepoint、持续集成和开箱即用的 MSTest 设置了一个 64 位 TFS 2008 构建服务器。普通业务逻辑类的单元测试运行良好,并且测试结果会发布到 TFS 中。然而,任何使用 Sharepoint 的 API 的测试都会严重失败,SPFarm.Local 返回 null 等等。有办法解决这个问题吗?

这些测试在 Visual Studio 和命令行中在其他相同的 32 位开发环境(Hyper-V 下的 Windows Server 2008,Sharepoint 修补至 2009 年 6 月累积更新)中运行良好,因此问题不在于 SPContext.Current 或需要在 Web 服务器上下文中运行的 API 的任何其他部分。我已经排除了权限问题,因为构建代理帐户可以使用 stsadm 部署解决方案并创建网站集。下一个罪魁祸首可能是单元测试正在运行 32 位进程,无法正确访问 64 位 Sharepoint API。我尝试了 一种解决方法,但它具有在 MSTest 中禁用 TFS 支持的副作用。

我是否必须等待 2010 版的 MS 工具(并希望得到最好的结果),或者是否有可用的第三方测试框架,可以在 64 位中本机运行并可以将测试结果发布到 TFS 2008 中?

I've set up a 64-bit TFS 2008 build server with Sharepoint, continuous integration and out-of-the-box MSTest. Unit tests for plain business logic classes run just fine and test results are published into TFS. However, any test that uses Sharepoint's API fails horribly, SPFarm.Local returning null and so on. Is there a way to fix this?

The tests run fine in an otherwise identical 32-bit development environment (Windows Server 2008 under Hyper-V, Sharepoint patched up to June 2009 cumulative update) from both Visual Studio and command line, so the problem is not about improper use of SPContext.Current or any other part of the API that needs to be run in a web server context. I've ruled out permissions issues, because the build agent account can deploy the solution and create site collections just fine with stsadm. The next culprit could be that the unit tests were being run with a 32-bit process, which couldn't access the 64-bit Sharepoint API properly. I tried a workaround, but it has the side effect of disabling TFS support in MSTest.

Do I have to wait for 2010 versions of MS tools (and hope for the best) or is there a third-party test framework available that runs natively in 64 bit and can publish test results into TFS 2008?

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

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

发布评论

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

评论(2

柳絮泡泡 2024-08-12 06:35:54

发生这种情况是因为 SharePoint 在正在执行的测试中没有上下文。 SharePoint 的上下文(特别是考虑 SPContext.Current 对象)仅当它作为 HTTP 请求的一部分在 ASP.NET 页面内运行时才会填充。 MSTest 不这样做。

如果您需要针对 SharePoint API 执行集成测试(与单元测试不同),您可以使用 用于 SharePoint 的 Typemock 隔离器。这将模拟这些 SharePoint 对象,使它们不再为空。请参阅 Francis Cheung 的博客举个例子。

评论后编辑:我没有这方面的直接经验,但想不出 32 位和 64 位之间会出现问题的任何原因。请仔细查看环境和配置上的任何差异。

This is occurring because SharePoint has no context in the tests that are being executed. SharePoint's context (particularly thinking of the SPContext.Current object here) is only populated when it is run inside an ASP.NET page as part of an HTTP request. MSTest isn't doing this.

If you need to perform integration tests (distinct from unit tests) against the SharePoint API, you could use Typemock Isolator for SharePoint. This will mock these SharePoint objects so they are no longer null. See Francis Cheung's blog for an example.

Edit after comment: I don't have direct experience with this but can't think of any reason there would be a problem between 32-bit and 64-bit. Please look closely at any differences in environment and configuration.

简单 2024-08-12 06:35:54

我自己也刚刚遇到这个问题。在网上搜索后,我终于找到了这篇文章:http://fastrup.net/post/Visual-Studio-Unit-Tests-and-64-bit-SharePoint-does-not-play.aspx

我已经在倾斜了朝着 NUnit 的方向看看它是否会有所作为,现在我将探索这条途径,如果它有效,这将是我的方法。当您想做正确的事情并对所做的一切进行单元测试但工具不支持您需要工作的环境时,这是令人沮丧的。

I've just run into this issue myself as well. After hunting around on the net, I finally found this article: http://fastrup.net/post/Visual-Studio-Unit-Tests-and-64-bit-SharePoint-does-not-play.aspx

I was already leaning in the direction of NUnit to see if it would make a difference, and now I'm going to explore that avenue and if it works that will be my approach. It's frustrating when you want to do the right thing and unit test everything that you do but the tools don't support the environment that you need to work in.

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