views:

397

answers:

3

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)]. 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.

+4  A: 

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.

Josh Einstein
+2  A: 

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.

Hans Passant
Don't forget that you can set ComVisible to "false" at assembly level and set it to "true" for classes/interfaces/methods inside the assembly and the latter will override the former. See http://stackoverflow.com/questions/1649752/how-to-elegantly-prevent-a-webservice-proxy-from-being-exposed-to-com for how it can be used. So actually flipping it "on" on the assembly level is not needed.
sharptooth
Having a consistent GUID only really matters if your type library needs to be exposed to COM clients that are expecting a particular interface. You can still expose objects to COM via IDispatch without a permanent GUID.
Josh Einstein
Hmm, late binding requires a consistent ProgID. Same problem.
Hans Passant
+1  A: 

Having [assembly: ComVisible(false)] and [assembly: Guid("...")] at the same time makes perfect sence 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.

Surely you don't care if you really don't want to expose anything from your assembly to COM and have the "Register for COM interop" option unchecked in the project settings.

sharptooth