Sarebbe accettabile l'aggiunta di alcune utility o classi molto generiche nello spazio dei nomi System ?
Sto pensando a cose davvero semplici come un generico EventArgs ( EventArgs<T> ),
Caso d'uso: sarebbe condiviso nella libreria principale di una società (in modo che possa essere ricompilato in un nuovo progetto così com'è, senza cambiare lo spazio dei nomi);
Non accettabile.
Potresti? Sì, ma lo spazio dei nomi di sistema è per materiale di base framework. Persino Microsoft non inserisce le proprie cose nello spazio dei nomi di sistema (ad esempio: API del compilatore C # o Registro di sistema ).
Lo spazio dei nomi di sistema è condiviso tra Microsoft .NET , Mono e DotGNU .
Suggerirei di usare il nome della tua azienda, quindi inserire le cose di base in quello spazio dei nomi.
No, no, no. Cosa faresti se la prossima versione .NET contenga una classe con lo stesso nome? Sei fregato come dovresti passare attraverso tutti i tuoi file che includono quella classe e rinominare tutte le istanze. Non aggiungi mai una libreria alla quale non hai alcun controllo. La soluzione più semplice è quella di invertire l'URL dell'azienda. Ad esempio, se il sito della tua azienda è fred.com, crea le tue classi in com.fred. È piuttosto comune seguire questa convenzione di denominazione.
Microsoft ha creato una serie di linee guida per le convenzioni dello spazio dei nomi.
Questo link è qui: Norme per la denominazione dei nomi dei siti Microsoft .
Risposte completamente corrette qui, ma nessuna regola senza eccezioni: se crei qualcosa come LinqBridge (che è un Sostituzione .NET Framework 2.0 per .NET fw 3.5 classi in modo compatibile al 100%), quindi l'utilizzo dello spazio dei nomi System è obbligatorio. O per rispondere a questo in un modo più generale: il proprio uso dello spazio dei nomi System è solo una buona idea se si devono portare alcune classi del framework di versione superiore a una versione più bassa, perché non è possibile aggiornare la versione di produzione al framework superiore ( e immagino che questa sia la unica ragione valida per l'utilizzo di questo spazio dei nomi).
Sì, puoi farlo. VS potrebbe riportare vari errori falsi, come le classi che non trova, ma una volta compilato tutto funzionerà bene. Generalmente non è consigliato per motivi già menzionati MA, penso che tu possa farlo in alcune situazioni.
Nel mio caso l'ho fatto per un codice base condiviso che è compilato come librerie per 6 diverse piattaforme basate su .net (.NET basic, Xamarin, Windows 8.1, Mac ecc., ciascuna API con le sue piccole differenze). La lib compilata viene quindi utilizzata dai progetti che prendono di mira ciascuna piattaforma. Per le piattaforme Windows Store 8.1 Apps e Windows Phone 8.1 il System.Collections aveva un sacco di classi mancanti: ArrayList, Hashtable, SortedList ecc., Tutti i tipi di comparatori, enumerabili ecc. Benché io sia consapevole del fatto che questi le classi non sono raccomandate e si dovrebbero usare alternative generiche (che sono disponibili per le piattaforme Win 8.1), è un compito ENORME nel nostro caso apportare tali modifiche sul codice condiviso, PLUS sul codice dei progetti consumer delle librerie risultanti . Le classi non generiche sono usate dappertutto, lo sviluppo è iniziato nel 2002. E parliamo di decine di migliaia di linee di codice ora ... Quindi, in questo caso, penso che sia giusto iniettare alcune classi mancanti nel namespace System.
Molte risposte corrette già. Ma voglio aggiungere un'altra prospettiva:
L'uso dello spazio dei nomi di Sistema dice allo sviluppatore di guardare MSDN, utilizzando lo spazio dei nomi della società dice allo sviluppatore di esaminare le risorse interne per la documentazione.
Inoltre rende chiara la dipendenza dalla libreria dell'azienda, che potrebbe essere rilevante quando si sposta il codice tra diversi moduli.