Is there any point in specifying a Guid when using ComVisible(false)?

Question

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

None of my assemblies contain types which need to be visible to COM, so I have marked my assembly with [assembly: ComVisible(false)]. So is there any point in specifying a GUID?

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

---

Edit:

To summarize the responses:

Between them, the answers explain that specifying a GUID is required if and only if COM interop is being used. So, in my situation, a GUID is not necessary.

sharptooth further explains that [assembly: ComVisible(false)] does not imply not using COM interop, since it is possible to override ComVisible for individual types. It is for this reason that the default AssembyInfo.cs contains both [assembly: ComVisible(false)] and a GUID.

Answer 1

Having [assembly: ComVisible(false)] and [assembly: Guid("...")] at the same time makes perfect sense in certain cases. You start with an empty assembly and will perhaps want to expose something from it to COM. So you mark the assembly as not ComVisible and later mark the entities to expose as ComVisible. That is why the GUID exists by default.

Regardless, if you really don't want to expose anything from your assembly to COM leave the "Register for COM interop" option unchecked in the project settings.

Answer 2

Consistent GUIDs are absolutely essential in COM. The [assembly:Guid] attribute generates the type library LIBID. Surely the project template auto-generates one to make sure that the programmer doesn't forget to provide one when s/he flips ComVisible to true.

If an assembly [Guid] isn't provided then Tlbexp.exe synthesizes one from the assembly name, version and public key. That's not really good enough, type libraries already have a version. Changing [AssemblyVersion] would generate a different LIBID. Especially bad when you use the auto-increment option for the version (like 1.0.*), you could quickly fill the registry with a mountain of dead TypeLib registry keys.

Long story short, it avoids a lot of nasty mishaps.

Answer 3

Nope, no real reason to include it. It's really pretty unnecessary except in very specific COM interop scenarios. Though I suppose there could be something useful about having a GUID that you can access with reflection. But since it's not guaranteed to be there, its not like you could rely on it.