在使用Visual Studio 2005(版本8.0.50727.762)进行长时间编译期间，有时在某些项目的多个文件中会出现以下错误：

fatal error C1033: cannot open program database 'v:\temp\apprtctest\win32\release\vc80.pdb'

(提到的文件在项目的临时目录中是vc80.pdb或者vc80.idb。)

相同项目的下一个版本成功。没有其他打开的Visual Studio可以访问相同的文件。

这是一个严重的问题，因为它使得夜间编译变得不可能。

解决方案

我们在我的网站上也看到了很多。根据我们的设置，来自彼得·考夫曼(Peter Kaufmann)的这种解释似乎是最合理的：

在Visual Studio 2005中构建解决方案时，会出现致命错误C1033之类的错误：无法打开程序数据库'xxx \ debug \ vc80.pdb'。但是，当第二次运行构建时，它通常会成功。

原因：解决方案中的两个项目可能会将其输出写入同一目录(例如'xxx \ debug')。如果"工具选项"，"项目和解决方案"的" Bild和运行"中的最大并行项目生成数量设置被设置为大于1的值，则意味着两个编译器线程可能试图同时访问相同的文件，从而导致文件共享冲突。
解决方案：检查项目的设置，并确保没有两个项目使用相同的目录来输出，目标或者任何类型的中间文件。或者将并行项目构建的最大数量设置为1，以快速解决。我在使用CLAPACK库随附的VS项目文件时遇到了这个问题。
更新：即使文件不受版本控制，Tortoise SVN仍有可能访问vc80.pdb，这也可能导致上述错误(感谢Liana报告此错误)。但是，我无法确认这一点，因为在确保所有项目都使用了不同的输出目录之后，我无法重现该问题。

在这种情况下，很可能怀疑防病毒软件或者类似程序在写防病毒文件时接触了pdb文件。基于我过去在我们商店中设置夜间版本的经验，恐怕我只能给我们一些一般性的建议。其中一些听起来可能微不足道，但为了完整起见，我将它们包括在内。

• 首先也是最重要的：请确保从一开始就做好准备。也就是说，在每晚开始之前，强制删除构建的输出目录。
• 如果每台夜间计算机上都有防病毒软件，反间谍软件或者其他此类程序，请考虑将其删除。如果这不是一个选择，请将obj文件夹添加到该程序的排除列表中。
• (可选)考虑在每晚使用VCBuild或者MSBuild之类的工具。我认为，如果我们在多核计算机上，最好使用MSBuild。我们在夜间使用IncrediBuild，在发行版中使用MSBuild，但从未遇到我们描述的问题。

如果没有其他效果，则可以在构建开始几个小时后安排看门狗脚本，并检查其状态。如果构建失败，则看门狗应重新启动它。这是一个丑陋的hack，但是总比没有好。

当我们先前的调试尝试没有完全杀死调试器时，通常会发生这种情况。
在任务管理器中，查找名为vcjit的进程，将其杀死，然后重试。
最糟糕的选择是重新启动Visual Studio，这应该可以解决问题。

我们是否正在使用LinqToSql？也许这与我在这个问题中偶尔遇到的奇怪错误类似：是什么导致Visual Studio无法正确加载程序集？

我今天遇到了这个问题，在导致它的pdb路径中原来是非ansi字符。

我正在通过vmware使用Windows，并且我的项目位于共享位置：\ vmware-host \ Shared Folders \ project

当我将其移动到\ Users \ julian \ project时，它解决了该问题。