42

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.

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
user200783
  • 13,722
  • 12
  • 69
  • 135
  • Related: https://stackoverflow.com/questions/18729489/difference-between-dual-interface-and-dispatch-only-interface-for-c-sharp-com-au – StayOnTarget Jan 21 '19 at 12:41

3 Answers3

19

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.

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
sharptooth
  • 167,383
  • 100
  • 513
  • 979
9

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
  • 922,412
  • 146
  • 1,693
  • 2,536
  • 1
    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 Feb 27 '10 at 15:33
  • 1
    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 Feb 27 '10 at 23:57
  • Hmm, late binding requires a consistent ProgID. Same problem. – Hans Passant Feb 28 '10 at 00:08
4

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
  • 68,005
  • 14
  • 144
  • 156
  • It has a pretty big [use](http://stackoverflow.com/q/11403333/712526) for a stand-alone web server which needs an SSL certificate – jpaugh Nov 25 '15 at 17:21
  • @jpaugh: Not sure we're talking about the same thing. – Josh Nov 27 '15 at 15:05
  • I'm not entirely sure, myself; but, I had to use the GUID from the assembly info to get that scenario working (see the bottom of my answer on that page.) My (tentative) conclusion is that Windows uses a COM interface to make an SSL binding "stick" to a particular app. – jpaugh Nov 29 '15 at 03:47