2012-07-04 8 views
8

Ho derivato diverse classi da varie eccezioni. Ora vs dà l'avvertimento come nel titolo di questa domanda.Derivante dalle avvertenze delle classi di eccezioni: CA2237: Contrassegna i tipi ISerializable con SerializableAttribute

1. Qualcuno potrebbe spiegare le implicazioni della soppressione di questa regola?

2. Si può spiegare la regola da here dicendo "Non sopprimere un avviso da questa regola per le classi di eccezioni perché devono essere serializzabili per funzionare correttamente tra domini dell'applicazione".?

Grazie.

P.S. Beh, ho una risposta anch'io. In effetti devi contrassegnare le eccezioni come serializzabili. Funzionano bene senza questo attributo nello stesso AppDomain. Tuttavia, se provi a prenderlo da qualche altro dominio, dovrà essere serializzato per superare i limiti dell'app. E questa è la ragione principale per cui ho trovato questo.

risposta

12

Questo non è esattamente un avviso di Visual Studio, è un avviso prodotto dallo strumento FxCop. Quale è possibile eseguire dal menu Analisi VS. FxCop è un analizzatore statico che cerca trucchi comuni in un programma .NET che un compilatore non contrassegna. La maggior parte dei suoi avvertimenti sono piuttosto oscuri e raramente sono problemi veramente gravi, è necessario trattarlo come un "hai pensato a questo?" tipo di strumento.

Il piccolo fatto che sta cercando di ricordarvi è che la classe Exception implementa ISerializable e ha l'attributo [Serializable]. Che è un requisito piuttosto difficile, rende l'oggetto Exception di base serializzabile tra domini app. Necessario perché Exception non deriva da MarshalByRefObject. E necessario per consentire il codice che si esegue in un altro dominio app per generare eccezioni che è possibile rilevare.

Così FxCop rileva che non hai fatto lo stesso per la tua classe derivata Exception. Il che è davvero solo un problema se hai intenzione di avere un codice che lancia la tua eccezione in un altro dominio dell'app. FxCop non è abbastanza intelligente per sapere se lo fai, ma può solo ricordarti che va male quando lo fai. È abbastanza raro quindi sentirsi libero di ignorare l'avviso quando non si sa ancora se lo farai o meno o se tutto ti sembrerà cinese.

+0

Dopo aver letto e giocato con i confini di AppDomain, .NET ha infatti iniziato a dare le proprie eccezioni dicendo che queste classi non hanno [Serializable]. Un aspetto interessante di appDomain.CreateInstance (..., classNameForThisDomain, ...) è che crea ed esegue classNameForThisDomain in un dominio app distinto da quello in cui stiamo eseguendo solo quando questa classe deriva da MarshalByRefObject. Ma se così non fosse, classNameForThisDomain verrà caricato nello stesso appdomain! – Nickolodeon

0

Se non si utilizzerà più AppDomain nell'applicazione, penso che si possa ignorarlo o sopprimerlo.

+0

Non tutti i programmi utilizzano AppDOMain? Da [documentazione MSDN per 'System.AppDomain'] (https://msdn.microsoft.com/en-us/library/system.appdomain.aspx): *" Le istanze di AppDomain vengono utilizzate per caricare ed eseguire assembly. La classe AppDomain implementa una serie di eventi che consentono alle applicazioni di rispondere quando viene caricato un assembly "*. Sembra che qualsiasi applicazione che carica un assembly utilizzi AppDomain. E poiché ogni programma probabilmente caricherà 'System.dll', la documentazione MSDN implicherebbe che tutto usi domini app. –

+0

@IanBoyd: Penso che il mio punto fosse utilizzare più di un dominio app, cioè crearne uno proprio. – abatishchev

Problemi correlati