非常奇怪的构建问题

发布于 2024-08-26 22:15:17 字数 643 浏览 6 评论 0原文

这个问题困扰了我一年多,看起来真的很奇怪而且很晦涩。当我构建解决方案时,它抱怨缺少引用的 DLL。当我重建它时,问题就消失了。每当我进行清理时都会返回,即必须尝试构建两次才能成功。

这是模糊的,但如果有必要,我可以对解决方案结构给出更好的解释。由于解决方法只是构建两次,所以我从来没有费心去给予它更多的关注,但它非常烦人。

此外,构建失败是因为 DLL 似乎不存在,因此引用它的代码会因为 DLL 中缺少类型而失败。下次我启动构建时,它工作正常。

更新:

  • 引用的 DLL 是外部的(来自 CodePlex 的 ValidationFramework),位于源代码树中。
  • 我的项目都没有复制 DLL,只是其中一些项目引用了它。
  • 这种情况在调试和发布版本中都会发生。

刚刚发现它还与项目 A 引用 ValidationFramework.dll 相关,项目 B 也是如此,但项目 B 引用项目 A。 现在,当发生构建错误时,它总是在编译器转到项目 B 时,即项目 A 总是构建第一次和第二次构建尝试均成功。

另外,当项目 B 失败时,我可以一遍又一遍地单击“构建”,但没有效果,它确实需要“重建”,因此无论“修复”发生的问题,都会在构建项目 B 之前发生(因为问题本身可能会以及)。

This one has had me stumped for over a year and seems really odd and really obscure. When I build my solution, it complains about a missing referenced DLL. When I rebuild it, the problem goes away. Whenever I do a clean this returns, i.e. have to attempt a build twice before it succeeds.

This is vague, but if warranted I can give a better explanation of solution structure. Since the workaround is simply to build twice, I've never bothered to give it more attention, buts its extremely annoying.

Also, the build fails because it seems the DLL is just absent, so code that references it after fails because of missing types from the DLL. The next time I initiate the build, it works fine.

Update:

  • The referenced DLL is external (ValidationFramework from CodePlex), located in the source tree.
  • None of my projects are copying the DLL, just some of them reference it.
  • This happens in both Debug and Release builds.

Just found it relevant to also add that project A references the ValidationFramework.dll, as does project B, but project B references project A. Now when the build error occurs, its always when the compiler goes to project B, i.e. project A always builds successfully on both first and second build attempts.

Also, when project B fails, I can click "Build" over and over to no effect, it does require a "Rebuild", so whatever "fixes" the problem that is occurring happens prior to building project B (as the problem itself might as well).

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

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

发布评论

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

评论(2

疯狂的代价 2024-09-02 22:15:17

丢失的 DLL 是您工作区中正在构建的项目之一吗?您是否设置了项目依赖项,以便必须在构建利用项目之前构建 DLL 项目?

Is the missing DLL one of the projects being built in your workspace? Do you have the project dependencies set up so that the DLL project has to be built before the utilizing project is built?

吹梦到西洲 2024-09-02 22:15:17

这听起来有些耳熟。我可能在 vs.net 2003 或 2005 中经历过这种情况,我不记得了。但它的表现是这样的:

在调试版本中,引用的 C++/CLI 将被正确复制到使用程序集文件夹,但当我发布版本时,它会突然中断,因为引用项目找不到它们。事实证明这是一个 VS.NET 错误,我认为已在服务中修复,但在此期间我添加了一些构建后步骤,通过强力将程序集移动到需要的位置。

您的调试版本似乎每次都有效吗?

This sounds vaguely familiar. I may have experienced this with vs.net 2003 or 2005 I don't recall. But it exhibited itself like this:

In debug builds the referenced C++/CLI would be copied to consuming assembly folders correctly but when I did release builds it would suddenly break because the referencing projects couldn't find them. It turned out to be a VS.NET bug that I thought was fixed in a service back but in the interim I added some post build steps to move the assembly by brute force to where it need to be.

Do your debug builds seem to work every time?

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