如果编译器自动处理这个问题，那么您最终会遇到两种情况之一。

• 每次编译时生成一个新的GUID--因为GUID应该是发布的，所以这会失败。
• 冲突-如果GUID每次都是相同的，基于（比如说）名称的哈希，多个项目最终将使用相同的GUID用于不同的目的。

现有的方法--显式GUID使开发人员能够根据需要控制这些。
实际上，只有在有限的情况下才需要添加GUID属性-主要的情况是用于COM互操作，如果您使用.NET编写COM对象供另一个系统使用。根据您的项目类型，这可能是每天的事件-也可能是每年的事件。

这些属性对于COM来说非常重要。COM是.NET的前身，在Java抢尽风头之前的90年代达到了全盛时期。.NET需要与COM兼容才有成功的机会。或者换句话说，你需要能够用大型遗留程序可以使用的.NET语言编写COM服务器。
[ComVisible]属性确保COM客户端程序可以看到并使用IEnumerable接口。这是允许客户端程序枚举.NET集合所必需的。
[Guid]属性在COM中是至关重要的，它标识接口。这是通过guid而不是名称来完成的，以确保它在不同程序员编写的多个应用程序中是唯一的。.NET也有这个属性，但使用名称使其更易于使用。“System.Collections.IEnumerable，mscorlib，Version=2.0.0.0，Culture=neutral，PublicKeyToken=b77a5c561934e089”。
IEnumerable〈〉，泛型版本，没有[Guid]。泛型与COM不兼容。这在当今已经不重要了，没有太多可见的COM了，大部分COM都被友好的.NET类 Package 了。但在Windows中仍然是非常核心的，特别是在全新的WinRT中（又名Metro，又名Modern UI，又名UWP）。你也不能直接使用它，这使得COM有点像Windows编程中的汇编语言。

你可以这样做（只需要省略属性），但是即使接口没有改变，编译器也会在每次重新编译时生成一个新的GUID。这是很不幸的，因为接口的用户不知道这个改变，并且会用它的旧GUID来检索接口，因此检索失败。

有时候，您希望为某些类或模块提供一个唯一的标识符，该标识符是常量，并且在源代码中硬编码。

要阅读这个定义，你需要查找每个属性的含义，第一个属性ComVisibleAttribute的描述如下：
控制单个托管类型或成员或程序集中所有类型对COM的可访问性。
这告诉我们ComVisible与COM有关，并允许我们指定特定类型是否对COM程序可见。页面的更下方是一个链接，指向有关该属性的用途以及类型库导出器如何使用它的更多细节。
第二个是GuidAttribute，一开始帮助不大：
在不需要自动GUID时提供显式System.Guid
但是同样，您必须阅读下面剩下的部分，您将看到另一个提到类型库导出器的地方。
将这两个属性放在一起，就可以清楚地看到，这两个属性控制IEnumerator在导出到类型库时的处理方式。如果您不知道类型库是什么，这可能对您没有多大意义。如果您没有使用COM互操作，则可以安全地忽略这些属性。如果您正在使用COM互操作，您需要知道Guid才能从非托管COM代码正确访问该接口。
微软把这些放在每一个接口定义中，以备您需要;阅读MSDN页面的部分技巧是识别这类信息，并知道什么时候它对您没有任何用处。既然您知道了这两个属性的作用，您应该能够弄清楚它们是否与您相关，否则就忽略它们。