Limitazioni pratiche con assiemi non contrassegnati come conformi a CLS?

Question

Come autore di una libreria OSS, ho sempre cercato di rendere CLS compatibile. Ma MS non lo rende facile. Spesso ti mettono in situazioni di catch-22, come ad esempio:

• Non è possibile avere una variabile protetta che differisce solo nel caso della proprietà pubblica.
• Non è possibile avere variabili protette o pubbliche che iniziano con un carattere di sottolineatura o "m_".
• Se si desidera rendere una classe realmente estendibile, è spesso necessario avere variabili protette che corrispondono alle proprietà pubbliche. La tua uscita meno brutta è quella di aggiungere un suffisso alla variabile, come "Var" o "Valore". È brutto e inaccettabile per me. Mi piace il codice pulito.

Non conosco linguaggi .NET che non supportano variabili che iniziano in un carattere di sottolineatura, e li ho usati in molti posti in cui la variabile deve essere visibile alle sottoclassi.

Sono stanco degli avvertimenti e sto pianificando di disattivare la conformità CLS a livello di assembly sulle mie librerie 30+ C#.

Sono presenti problemi effettivi con la disattivazione della conformità CLS nelle librerie? Qualsiasi reale problemi con questo?

Microsoft ha rilasciato una guida unheedable sul software per decenni, con meno del 5% di esso che è valsa la pena di byte è stato codificato in. Non riesco a trovare alcuna prova che questo migliori pratiche ha alcun effetto reale su qualsiasi cosa.

Ma, per fare attenzione, sto controllando.

E no, questo non è un duplicato del inverso di questa domanda: Any reason not to mark a DLL as CLSCompliant?

Sto cercando i risultati effettivi e gli effetti qui, non il consiglio di un tirocinante MS.

Ad esempio, se IronPython, IronRuby o F # non sono in grado di leggere o scrivere una variabile che inizia con un carattere di sottolineatura, questo è un effetto, anche se causerebbe solo un problema per gli utenti che suddividono determinati oggetti.

Se un linguaggio o uno strumento non è completamente in grado di utilizzare un assembly a meno che non sia contrassegnato come conforme a CLS, ora è un grosso problema.

Answer 1

Da quello che posso dire, un vero e proprio problemareale o con la non conformità è si perde la garanzia.

http://msdn.microsoft.com/en-us/library/bhc3fa7f.aspx

E 'come overclocking tuo computer o guidare l'auto con un terzo mod parte su di esso, si perde il supporto "ufficiale" da parte dei cittadini in origine la fornitura di voi se qualcosa va storto (anche se capita di lavorare) .

Nel caso di conformità CLS, si perde il supporto da MS circa l'interoperabilità del codice contro altre lingue (mia enfasi):

Se si progetta una libreria di classi CLS-compatibile, la libreria sarà avere una garanzia di interoperabilità con una vasta gamma di programmi lingue

Come per tutti i catch-22s, non ho idea. Non posso dire che mi sia mai importato della conformità al CLS.

Answer 2

Circa il problema si è utilizzato come esempio:

• Se la proprietà pubblica ha un setter pubblico e getter, la variabile protetta non è necessario, perché le classi derivate possono impostare il valore utilizzando la proprietà pubblica.
• Se la proprietà pubblica non ha un setter pubblico, dagli un setter protetto. Ciò elimina la necessità di una variabile protetta, poiché le classi derivate possono impostare il valore utilizzando il setter protetto della proprietà pubblica.
• Le variabili pubbliche dovrebbero essere evitate completamente.

Conclusione: Normalmente è necessario no per variabili protette o anche pubbliche. Può essere modellato utilizzando le proprietà.