我们有一个VS2008解决方案,我发现了一些奇怪的事情:
某些项目引用在同一解决方案中定义的其他项目(添加为项目引用)。这是在不久前完成的。
直接从VS建立工作正常。
从MSBUILD构建失败。
我删除了项目引用并重新添加它,我注意到项目的GUID已更改。从MSBUILD开始构建。
问题是,我现在必须检查所有项目并验证这一点。
此外,我不知道为什么会发生这种情况(为什么项目GUID与以前不同,并且不确定是否会再次发生这种情况。)
这可能是什么原因?
答案 0 :(得分:33)
我也在Visual Studio 2013中看到此问题,并且不需要进行源代码管理集成。
当我在多个解决方案中拥有相同项目时,偶尔会遇到这种情况,每个解决方案都为该项目使用不同的GUID,并相应地更新项目。解决方案是手动修改.sln文件以使它们同步。这个答案归功于春生堂。
首先用记事本打开解决方案文件(.sln)并检查那里的项目引用。格式如下:
# Visual Studio 2005
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "WindowsApplication1", "WindowsApplication1\WindowsApplication1.csproj", "{9378D255-CE38-45CD-82FA-A1EBFB86FD6C}"
EndProject
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "ClassLibrary1", "ClassLibrary1\ClassLibrary1.csproj", "{DE374096-FF44-4FDF-B248-C767039B4175}"
EndProject
每个项目的第二个GUID是对共享项目的引用。
要解决此问题,请为共享项目选择一个GUID;确保打开它的所有解决方案都在其解决方案文件中具有相同的GUID。 (请在进行这些更改之前备份您的文件)
答案 1 :(得分:13)
由于与源控制系统(如TFS)集成,ProjectGuid发生了变化。例如,如果其他人打开文件,则会发生。
此处描述了解决方法:
http://social.msdn.microsoft.com/Forums/en-US/csharpide/thread/1d632940-cc1d-49d5-a64c-d3e999216cbd
答案 2 :(得分:4)
对我来说问题是其中一个解决方案文件中的重复GUID。在我的安装程序的.sln中,我发现Config项目GUID(在整个地方使用)和安装程序项目GUID(特定于解决方案)是相同的。打开解决方案导致VS更改项目文件中其中一个的GUID,尽管在解决方案文件中并不明显。碰巧它总是选择共享的一个导致最大的悲伤。修复方法是为安装程序项目创建新的GUID,并手动将所有其他解决方案文件编辑回Config项目的正确GUID。
我不知道这是怎么发生的,因为我没有复制项目来创建它们。
答案 3 :(得分:3)
解决方案文件从项目文件中获取项目guid。您是否从早期版本的VS升级了解决方案/项目?如果解决方案文件中的guid不断变化,可能是因为项目文件根本没有guid,因此每次打开解决方案时VS都会组成一个新文件。我称之为VS升级机制中的一个错误,但没有人问我。通过在项目文件中添加一个guid解决问题,如下所示:
<PropertyGroup>
<ProjectGuid>{FB0F4A2A-1F78-42BF-8E31-E4FEFDC5565F}</ProjectGuid>
</PropertyGroup>
再次打开解决方案,让项目guid最后一次更改为新的guid。指导永远不会再改变。
答案 4 :(得分:0)
关于变通方法:可以在解决方案文件(.sln)中的几个位置引用GUID。请记住替换对此GUID的所有引用,而不仅仅是变通方法中提到的引用(变通方法已锁定 - 无法在那里留下评论,因此我不得不回答此帖子。)
答案 5 :(得分:0)
如果在同一个解决方案中有两个项目的GUID相同,则会发生这种情况,VS将为其中一个分配新的GUID。 这可能在构建带有新项目的新解决方案时发生,并且如果您插入共享项目,则它们的向导可能与新项目相同。 问题是所有其他已经插入了共享项目的解决方案都不得不再次更改GUID,这很烦人。
一个简单的解决方案,而不是手动编辑solution- / project-files: 只需删除项目,然后先插入共享项目,然后再插入新项目。因此,VS为新项目提供了新的-而不是重复的-Guid,并且没有被迫更改共享项目的Guid。
...关于“全球唯一标识符”;-)