通过 CruiseControl 构建时缺少依赖项
问题是，当项目正常构建和生成且没有任何错误时，最终打包的 msi 会缺少依赖项程序集，而如果有人通过 Visual Studio 构建项目，则通常会打包这些依赖项程序集。 因此，发生的情况是应用程序正常安装，然后在运行时崩溃，并提示 xyz dll 丢失。
据我所知，它要么在构建安装项目之前不刷新依赖项，要么以某种方式无法包含所有依赖项。
我们使用 devenv 和解决方案文件进行构建（重新构建全部）
有没有人遇到过类似的情况，如果是的话，你是如何解决的？
编辑：CruiseControl 正在与开发机器不同的机器中运行。 此外，我们发现解决方案中引用的项目会发生这种情况。
IE 在包含 3 个项目的解决方案中，A 是一个库，B 是一个引用 A 的应用程序，C 是一个安装项目，然后在构建之后发生的情况是，尽管构建成功并生成了 msi，但 B 缺少 A。
The problem is that when projects are been built and produced normally without any errors the final packaged msi is missing dependency assemblies that are normally packaged if someone builds the project through visual studio for example. So what happens is that the application is getting installed normally and then crashes on run time by saying that xyz dll is missing.
From what i can tell it either doesn't refresh the dependencies before building the setup project or somehow fails to include all of them.
We build by using devenv and the solution file (Rebuild all)
Has anyone encountered something similar and if yes how did you resolved it?
edit: CruiseControl is running in a different maching that the development one. Moreover we have figured out that this happens with projects referenced within a solution.
IE in a solution with 3 projects, A a library, B an application that references A and C a setup project then after the build what happens is that B is missing A although the build is successfull and the msi produced.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
还有另一篇文章看起来有同样的问题，但我还无法检查它是否有效。 您应该能够包含一个执行任务来运行创建的宏来刷新依赖项。
https://stackoverflow.com/questions/45593?sort=votes#sort-top
There's another post with what looks like the same question, but I haven't been able to check if it works yet. You should be able to include an execution task to run the macro created to refresh the dependencies.
https://stackoverflow.com/questions/45593?sort=votes#sort-top
当您说它可以通过 Visual Studio 手动构建时，您的意思是在同一台机器上吗？ 如果是这样，那么事实可能是您的 Cruisecontrol 服务正在以不同的用户身份运行，因此具有不同的路径和环境变量集，也许它没有访问这些依赖项所在的文件系统的权限。 如果您的意思是它在不同的计算机上运行良好，那么我将确保这些依赖项确实存在，并且服务运行的用户有权访问它们。 抱歉，我们从未遇到过这些问题，所以我只是尝试猜测一些潜在的 CC.NET 设置问题。
When you say it builds fine through Visual Studio by hand, do you mean on the same machine? If so then it probably is the fact that your cruisecontrol service is running as a different user, and as such, has differnt paths and environment variables set, maybe it does not have permissions to access the file system these dependencies are on. If you mean it runs fine on a different machine, then I would make sure that those dependencies actually there and that the user the service runs as has permissions to get to them. We have never encountered these issues, sorry, so I am just trying to guess at a few potential setting up CC.NET issues.
您可以检查缺失的 dll 是否位于构建计算机上的 GAC 中。
几个月前，我遇到了一个问题，即构建服务器生成的安装所用的 dll 比任何开发人员盒子都少。 事实证明，丢失的 dll 位于构建盒上的 GAC 中。 由于某些未知的原因，VS2005 决定不需要包含该 dll，因为它位于 GAC 中 - 即使我们在项目中专门引用了该 dll 的本地副本。
You might check to see if the missing dlls are in the GAC on the build machine.
I ran into an issue a few months back where the build server was generating an install with one fewer dll than any of the developer boxes. It turns out the missing dll was in the GAC on the build box. For some unknown reason, VS2005 decided it didn't need to include the dll since it was in the GAC - even if we specifically referenced a local copy of the dll in the project.
这种情况是由于 MSBUILD 不支持安装项目造成的。 因此我们被迫使用 devenv 来构建带有 Cruise Control 的解决方案。
真正的问题是主应用程序引用了同一解决方案中的项目，虽然这在完整的 .NET 安装项目中无法重现，但在 CF 安装项目中确实重复发生。
我们解决了这个问题，方法是更改 CF 解决方案的架构，将 1 个项目中的所有相关项目作为文件夹，这样只有 1 个 exe 与安装项目一起生成和打包。
值得注意的是，我们在引用其他 dll 文件时并没有丢失程序集，但只有当我们引用同一解决方案中存在的库项目时才会丢失程序集。
在谷歌搜索这个主题后，我发现了一些关于这个主题的令人不安的细节，这让我注意到这个错误和 msbuild 无法支持安装项目自 2005 年以来就存在于 msdn 论坛报告中，而不仅仅是这样。
This situation is a result of MSBUILD not supporting setup projects. So we are forced to use devenv to build the solution with Cruise Control.
The real problem was that projects in the same solution were referenced by the main application and while this was not reproducible in full .NET setup projects it did happened repeatedly in CF setup projects.
We resolved this issue by changing the architecture of our CF solutions to have all related projects in 1 project as folders so there is only 1 exe produced and packaged with the setup project.
It's notable that we didn't had missing assemblies when referencing other dll files but only when we were referencing library projects which existed in the same solution.
After googling about this subject i found out some disturbing details about this subject, which point me to the fact that this bug and the incapability of msbuild to support setup project exist since ~2005 in msdn forum reports and not only.