Does it make sense to specify Guid when using ComVisible (false)?

Question

When you create a new C # project in Visual Studio, the generated AssemblyInfo.cs file contains an attribute indicating the GUID of the assembly. The comment above the attribute states that it is used "if this project is open to COM."

None of my assemblies contain types that should be visible to COM, so I marked my assembly with [assembly: ComVisible(false)] . So does it make sense to specify a GUID?

It seems to me that the answer is no - so why does the AssemblyInfo.cs file by default contain both [assembly: ComVisible(false)] and [assembly: Guid("...")] [assembly: ComVisible(false)] [assembly: Guid("...")] ?

---

Edit:

To summarize the answers:

Between them, the answers explain that GUID is required if and only if COM interoperability is used. So in my situation, a GUID is not needed.

In addition, sharptooth explains that [assembly: ComVisible(false)] does not mean that COM interaction is not used, since you can override ComVisible for individual types. For this reason, the AssembyInfo.cs file by default contains both [assembly: ComVisible(false)] and a GUID.

Answer 1

The presence of [assembly: ComVisible(false)] and [assembly: Guid("...")] at the same time makes sense in some cases . You start with an empty assembly and you might want to open something from it for COM. Thus, you mark the assembly as not ComVisible and later mark the entities to be provided as ComVisible . This is why a GUID exists by default.

In any case, if you really do not want to open COM for your assembly, leave the "Register for COM interaction" checkbox in the project settings.

Answer 2

Consistent GUIDs are absolutely essential in COM. The [assembly: Guid] attribute generates the LIBID of a type library. Of course, the project template automatically generates it to make sure that the programmer does not forget to provide it when he / she translates ComVisible to true.

If the assembly [Guid] is not specified, then Tlbexp.exe synthesizes one of the name, version, and public key of the assembly. This is not very good, type libraries already have a version. Changing [AssemblyVersion] would create another LIBID. It is especially bad if you use the automatic increment option for the version (for example, 1.0. *), You can quickly fill the registry with the mountain dead registry keys of TypeLib.

In short, this avoids many unpleasant failures.

Answer 3

No, there is no real reason to turn it on. This is really quite unnecessary, except for very specific COM interaction scenarios. Although I suppose there might be something useful in that you have a GUID with which you can access with reflection. But since he was not guaranteed to be there, his is not the way you could rely on him.