对于我的两个VS 2005 C ++项目，VS在构建项目时想要写入.sln文件。我有许多其他的VS 2005 C ++项目，但事实并非如此。这是一个问题，因为我们将ClearCase源代码控制与VS 2005安装集成，当我们尝试通过批处理文件运行隔夜构建时，构建会在显示ClearCase签出对话框时暂停。
查看VS在.sln文件中的变化，它是项目行中的第二个GUID。
建造之前：
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "InterCommClientB", "InterCommClientB.vcproj", "{A2AF232A-7F27-4340-81D5-8ABFD10994D2}"
建成后：
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "InterCommClientB", "InterCommClientB.vcproj", "{67BE85B7-3234-484E-88FB-4F0E42096583}"
感激不尽的任何帮助。我是VS 2005的新手，因为我们最近刚从VC ++ 6.0迁移过来，所以如果我错过了一些明显的东西，我会道歉。
我们正在运行安装了SP1的VS 2005 Professional Edition。
此致
格雷格。
答案 0 :(得分：3)
我有类似的问题。似乎从旧版本的VS（如6或2003）转换项目时，VS 2010不会将Project GUID添加到.vcxproj文件中。因此，当您打开包含此类项目的解决方案时，VS将为此类项目重新创建GUID，并将更改.sln文件，但不会更改.vcxproj文件。因此，另一次打开此类解决方案时情况将相同，.sln文件可能会再次更改。
答案 1 :(得分：1)
我在这里猜测，但看起来对InterCommClientB项目（项目，而不是项目中的文件）进行了一些更改。发生这种情况时，sln会更新，在这种情况下只会更新项目GUID。
解决此问题的最佳猜测是手动构建解决方案，然后检查更改。这样sln文件在构建时不会改变。
我的第二个最好的猜测是你已经在你的计算机上进行了这项更改并且工作正常，但你没有在你进行夜间构建的电脑上获得最新版本。
答案 2 :(得分：0)
这可能完全在那里 - 但有时Visual Studio在修改解决方案文件并且在Visual Studio中打开解决方案时无法签入解决方案文件。尝试关闭Visual Studio，然后再提交解决方案文件。
如果不是这样，可能会有其他代理商导致解决方案文件需要更改其使用的GUID。在一个例子中，我使用的是National Instruments的.NET工具，他们有一个许可方案，当我去重建时，它会触发那种行为（无理由地修改无关文件）。
请仔细查看构建的输出（在日志或输出窗口中） - 您可能会在那里找到更多线索！