Perché i progetti scelgono di rimanere su una versione precedente di .NET Framework? [chiuso]

Per .NET può dipendere dalla destinazione di implementazione. .NET 3.5 è supportato anche nelle prime versioni di Windows XP, mentre 4.5 è supportato solo su Vista e versioni successive.

Nel mio posto di lavoro abbiamo optato per rimanere su 4.0 perché abbiamo ancora workstation in esecuzione su Windows XP Pro SP3 (che 4.0 supporta). Non possiamo considerare la migrazione fino al prossimo anno solo per quello.

Un altro motivo potrebbe essere una dipendenza da librerie di codice esterne che sono state compilate utilizzando una versione precedente del framework e per le quali non esiste una versione recente.

" Abbastanza buono è il nemico di meglio. " - Jerry Pournelle

Seriamente, ci deve essere una ragione per un aggiornamento oltre a " ooh, lucido! ". Tra le altre questioni, ogni volta che si cambia la versione di un pacchetto da cui dipende il codice, si sostituisce un set di bug che si è adattato a un altro set che potrebbe non essere. Nel processo di commutazione, è spesso necessario apportare modifiche al codice a causa di differenze API o modifiche non documentate del comportamento. E la lista continua.

C'è un'altra domanda da porre: " Perché i progetti optano per l'aggiornamento a una versione più recente del framework? " Idealmente, le risposte diranno qualcosa sul valore del progetto o sulla sua circoscrizione dell'aggiornamento . Ad esempio, con un quadro commerciale, l'incapacità di ottenere un supporto professionale per la versione precedente. Il più delle volte, la risposta è " Per sfruttare una funzionalità non presente nella versione precedente. ".

Consiglia un aggiornamento a un progetto software da un milione di dollari dalla v3.5 alla v4.0 (non sempre lo stesso che va da 0,50 a 1,0), è meglio avere una buona ragione. Ci dispiace, ma affermare che è 5-10 anni non è abbastanza buono.

Siate pronti a identificare le nuove funzionalità e in che modo beneficeranno questo progetto. Potresti obiettare che se non lo fai, fai un salto ancora più grande di 3.5 - > 6.0 sarà esponenzialmente più costoso perché il creatore del tuo codice di programmazione non fornirà alcun tipo di modo automatico di farlo come un esempio.

Quando paghi le bollette, è più comodo confortare in "Se non è rotto, non aggiustarlo."

Fornire supporto per un sistema operativo meno recente è una delle ragioni (vedere la risposta di Crono). L'altro motivo è "risparmiare denaro". Citato perché risparmia solo soldi a breve termine.

Dipende dal tipo di progetto, naturalmente, ma per le applicazioni aziendali, che di solito sopravvivono per un numero significativo di anni, ci sono buone probabilità che un aggiornamento sia necessario ad un certo punto, per qualsiasi motivo: supporto per nuove piattaforme, nuove caratteristiche, prestazioni migliori ... Quindi, posticipate l'aggiornamento fino a quando non avete altra scelta, o continuate ad aggiornare come parte della normale routine di sviluppo.

Passaggi piccoli, rapidi e poco costosi o passaggi lunghi, costosi. È esattamente lo stesso problema con il refactoring. In realtà, immagino che potresti persino dire che un aggiornamento di framework / library è una sorta di refactoring.

Nota a margine: c'è una discussione nei commenti della risposta di JeffO sull'analogia dell'automobile. Dato che il mio rappresentante è troppo basso per commentare, sto lasciando questa nota qui. Il software non invecchia come una macchina se non viene toccata, sì, ma fa invecchia se funziona. Codice è stato aggiunto Diventa gonfio. Proprio come una macchina, se non si sostituiscono continuamente parti di essa, qualcosa si rompe. Nel caso di un'auto, è ancora possibile sostituire la parte rotta, se disponibile. Con il vecchio software, trovare e risolvere il problema diventa così costoso con il tempo che alla fine dovrai rinunciare.

Targeting di una versione più recente di .NET quando l'applicazione non si basa su nulla dall'ultima versione di .NET non è necessaria, a meno che il framework di destinazione non stia raggiungendo la fine della vita. Stai introducendo ulteriore lavoro per aggiornare e testare la tua applicazione senza alcun beneficio reale.

Detto questo, nel nostro gruppo abbiamo installato alcuni software che abbiamo aggiornato in passato da .NET 2.0 o .NET 3.5 a .NET 4.0. Nella maggior parte dei casi è stato perché volevamo sfruttare la libreria Task Parallel per migliorare le prestazioni.

Non possiamo aggiornare nulla a .NET 4.5 ancora nella nostra organizzazione perché non è stato implementato in nessuno dei nostri ambienti