Perché è visibile COM System.IO.Path (una classe con solo membri statici)?

Question

Perché è visibile la COM System.IO.Path quando contiene solo membri e campi statici?

[ComVisibleAttribute(true)] 
public static class Path 

ho avuto l'impressione che non si può chiamare funzioni membro statiche di un oggetto COM (e, inoltre, che la classe avrebbe bisogno di un costruttore di default, che Path non ha).

noti inoltre SO utente sharptooth commento:

È anche interessante notare che non ha attributo GUID che molto probabilmente significa che la classe id verrà rigenerato ogni volta che viene compilato.

Perché è visibile il PATH COM e cosa si può fare con esso?

Answer 1

Certo, questo è un errore. È in buona compagnia, molte altre classi di mscorlib hanno lo stesso problema. Ad esempio Registro, Directory, File, Buffer, Ambiente, Nullable, Monitor, Timeout. Ma non coerentemente, l'attributo è stato correttamente omesso per BitConverter, Console, Convert, GC, Math, eccetera.

L'attributo è altrimenti importante per molte classi in mscorlib, gli host CLR personalizzati e i linguaggi di script dipendono da questo. Sembra che i programmatori Microsoft che hanno applicato l'attributo stessero semplicemente operando su pilota automatico. L'errore è irrilevante, Tlbexp sa come gestirlo. La coclasse ottiene l'attributo [noncreabile] in modo che i programmi client non possano creare un'istanza della classe. E le interfacce generate automaticamente sono vuote. Quindi il tipo non è semplicemente utilizzabile e non è possibile utilizzarlo accidentalmente.

Se in realtà desidera utilizzare System.IO.Path da un programma client COM, è necessario scrivere una classe wrapper [ComVisible] per esso. Naturalmente, non statico, ogni metodo che scrivi può semplicemente delegare direttamente a uno dei metodi Path. Vorresti l'attributo [appobject] sulla coclasse in modo che si comporti staticamente in un programma client che supporta l'attributo, purtroppo .NET non ha un attributo per questo.