当我打开我的项目并双击项目管理器中的特定pas文件时，bds.exe会冻结并继续使用25％的cpu。我必须通过Windows任务管理器终止进程。 （1）
当我打开我的项目并在同一个文件上按F12时，我看到了我之前希望看到的内容，即pas文件的内容。
当我打开我的项目并首先编译它，然后双击该文件，一切都很好。
我正在试图找出如何，我认为是一个不匹配的DCU文件，悄悄进入我的项目，以及最好的方法是防止将来出现类似的问题。我可以强制重建所有DCU文件吗？我可以简单地删除所有dcu文件并重新编译，或者这是一件危险的事情吗？我的DCU文件当前也存储在我保存pas和dfm文件的同一目录中，这有点乱。
（1）我们的应用程序还显示了生产中的行为，它有时会崩溃，同时它继续使用稳定的CPU使用或者只是继续按预期工作，但在后台显示稳定的CPU使用率。我们无法在编译版本中触发它，但看到它不时弹出。我们假设dcu不匹配是这个问题的根源。
答案 0 :(得分：3)
你的问题中存在很多问题，有些问题完全不相关，但假设问题是“不匹配的”问题。 DCU不太可能是正确的（我认为你的意思是指旧的＆＃34;或过去编译过的不正确的DCU或不同的源）。
首先是你的问题。
双击项目管理器中的单元时IDE锁定的问题不太可能与“不匹配的”＃34; DCU。
您是否有源文件位于网络驱动器上？这个单位是这样的文件吗？该网络位置是否可用/有效？ ie是使用不再映射或不可用的网络驱动器号的文件路径？
如果DPR中的单位参考中没有显式路径，您的系统，IDE或项目路径中是否列出了网络位置？
访问文件位置的困难是最有可能解释IDE在尝试简单地打开文件时出现锁定。
至于为什么在使用F12而不是项目管理器时它应该有不同的行为，不幸的是Delphi IDE因使用不同的机制在不同的地方实现相同的东西而臭名昭着，所以有时候当其中一个这些机制打破了其他机制仍然有效（即使两者都有效，也会产生不同的结果）。
如果我们的工作基础确实你确实有一个＆＃34;不匹配的＆＃34;然后DCU执行项目的完整版本将解决这种不匹配问题，只要您拥有所有必需DCU的来源并且正确和适当每个DCU的来源都可用。
但是，即使可能解决了不匹配问题，重建可能会也可能不会解决问题，具体取决于重新编译时该问题是否仍然存在于该单元的源代码中。
DCU的简单事实是＆＃34;不匹配＆＃34;不能引起异常的应用行为。除OS或RTL错误等外，如果应用程序的行为存在错误，那么这些错误将是源代码中错误的结果。
只需重新编译包含错误的源代码，就不会删除该错误。
因此，如果 这样的错误，那么如果有人能够在该分数上提供任何帮助，则需要更多的信息（这应该是一个单独的问题，一旦你自己做了一些初步的调试和诊断。）
如果您正在使用运行时包，那么事情会变得更复杂，因为使用运行时包时，用于任何特定单元的DCU可能是包文件的一部分。在这种情况下，磁盘上的DCU文件是在编译软件包本身时生成的，但使用 软件包的任何项目都将 在磁盘上使用DCU，但改为使用已编译到软件包中的版本。
因此，如果您正在使用运行时包以及重建项目，则还需要重建可能已更改的任何和所有运行时包。
现在，针对您的实际问题。
是的，当然。但请参阅上文w.r.t 运行时软件包，如果您的项目使用它们。
我强烈建议您更改项目设置，将DCU文件输出到特定位置，与源文件分开。
例如，您可以使用相对路径创建项目特定的DCU文件夹。即将您的DCU输出文件夹设置为＆＃34;。\ dcu＆＃34;并在DPR所在的文件夹中创建一个dcu文件夹。
对于支持多个平台和配置的Delphi版本，最好在该路径中包含平台和配置的环境变量，这样您就不会在RELEASE版本中使用为DEBUG编译的单元。
e.g。
.\dcu\$(Platform)\$(Config)
或
.\$(Platform)\$(Config)\dcu
什么是在构建中编译？
当您对项目执行构建时（与＆＃34; Compile＆＃34;不同），将重新编译该项目引用的所有单元，但任何VCL /除外RTL单元（即随Delphi提供的单元）。那些得到特殊待遇。
至少，重建项目将强制重新编译DPR中明确列出的所有单位，但也将重新编译所有这些单位使用的其他单位（或他们使用的单位等）
注意：DCU缺少来源
如果 可以找到来源，则 仅重新编译 。
如果您有DCU并且源文件丢失或无法在项目，IDE或系统路径中找到，那么编译器将简单地假设您要使用现有的DCU。
即使使用完整的＆＃34; Build＆＃34;
也是如此这看似显而易见，但您也应该小心，不要删除DCU，这可能是您可能正在使用的没有源代码的任何第三方库的唯一副本。
这是非常不明智的，但我想我们不能排除你可能处于这种情况的可能性。
总的来说，是的。如上所述，如果缺少引用单元的源代码，即使存在可以找到的DCU（或必需包，如果使用运行时包），即使完整构建也会成功。
因此，确保您拥有所有 DCU的当前来源的唯一方法是首先删除以前任何版本可能已使用过的DCU。
当您拥有一个特定的显式位置，输出所有项目DCU时，这当然要容易得多。
如果您使用运行时软件包， 稍微更多一些，但如果您正在合理地组织DCU，那么唯一真正的复杂因素是您需要为所涉及的所有项目重复相同的练习，通过启动每个使用的运行时包并完成项目，然后使用它们。
答案 1 :(得分：1)
是的，您可以重建项目中的所有DCU文件;
在项目组窗口中，右键单击项目并选择Build。
删除项目中的所有DCU是可以的，但不是必需的（或者在你犯错误的情况下是可取的......）。
请注意，这仅在您的项目中显式构建DCU（如项目树中所示），而不是由于您的uses子句导入的任何隐式DCU。
答案 2 :(得分：0)
在其他答案中没有得到解决的三件事可能会发生 请注意，我只有Delphi XE2和Seattle 10的经验，但它们可能适用于您的版本。
从表单切换到源视图时，Delphi可能会很慢，特别是如果表单上有许多组件。在从XE2迁移到10时，我们注意到了这方面的改进。我们在这里说几秒钟，这似乎不是你的问题。
在项目之间切换时，Delphi的速度非常慢。切换后，IDE可能需要很长时间（20-30秒）才能响应。你不能输入任何东西;代码完成需要很长时间;使用Alt-S-D启动项目搜索等待很长时间，然后失败。在从XE2迁移到10时，我们发现这里有很大的恶化。
条件编译。如果你的代码中有IFDEFs为一个项目而不是另一个项目编译东西，那么你的IDE可以完全挂起，除了杀死BDS.EXE之外别无他法。如果您切换项目并且意外地编译而不是构建，则会在Delphi Seattle 10中发生这种情况。
您可能会遇到这些变体。