Spostamento di vecchi progetti su IDE e librerie più recenti [chiuso]

Abbiamo circa 30 progetti di piccole e medie dimensioni e generalmente adottiamo l'approccio secondo il quale eseguiamo la migrazione dei progetti quando eseguiamo lavori non banali su di loro . Occasionalmente, ci impegniamo a un esercizio di consolidamento per spostare i progetti più vecchi alle ultime versioni.

Ovviamente, questo significa che i nostri ambienti di sviluppo hanno più versioni di Visual Studio, il framework .Net, SQL Server, IIS, Source Control, browser, ecc.

Pur avendo mantenuto tutti questi diversi strumenti aggiornati, questo approccio ad hoc funziona in modo abbastanza efficace.

Migrazioni che di solito vanno molto bene:

• Versioni di Visual Studio (ma vedi sotto)
• Funzioni principali di SQL Server
• . Versioni nette
• Controllo del codice sorgente (da VSS a Vault)

Di solito non migriamo tra le lingue a meno che l'applicazione non sia banale.

Migrazioni che sono state problematiche:

• DTS a SSIS
• Reporting Servives. Diverse versioni di SSRS sono supportate da diverse versioni di Visual Studio.

Ci sono due tipi di upgrade da considerare qui:

• Aggiornamento della soluzione a una versione diversa di studio
• ri-factoring della soluzione per l'esecuzione su un nuovo framework

Nelle versioni successive di Visual Studio è possibile aggiornare la soluzione a VS10 e scegliere ancora un framework precedente. Lo faccio spesso perché non mi piace avere ogni singola versione dell'IDE sulla mia scatola principale. Nella maggior parte dei progetti questo aggiornamento viene eseguito correttamente attraverso la procedura guidata che si ottiene se si apre una soluzione di studio precedente nello studio più recente. Lo faccio non appena tutti gli utenti si sono installati e in genere hanno una versione superiore.

Il ri-factoring per trarre vantaggio dal nuovo framework è più complicato e non lo farei necessariamente a meno che non stia già intraprendendo un cambiamento significativo, poiché spesso ci sono molti aggiustamenti che devono essere fatti manualmente dopo il cambio di target.

Sicuramente aggiornerei un progetto ASP.NET 1.1 o 2.0 se avevo bisogno di apportare modifiche significative ad esso.

Se è solo andare avanti, non avendo bisogno di lavorare se non il cambio di copia, lascia che sia. Ma devi aggiungere qualsiasi nuova funzionalità reale, vale la pena fare l'aggiornamento.

Non ho riscontrato problemi che richiedessero più di un piccolo sforzo per risolvere il problema. Ora, ammetto che non ho aggiornato nessun progetto dal complesso molto complesso a partire da 1.1, solo quelli semplici. Ma ho aggiornato i grandi siti da 2.0 a 3.5 (ovviamente non un enorme cambiamento tra queste due versioni) senza problemi. E ho trovato che vale la pena farlo, se non altro per accedere a LINQ quando si scrivono nuove funzionalità.

Non considererei l'aggiornamento di un progetto 3.5 a 4.0 solo per il gusto di farlo. Solo se hai davvero bisogno o desideri qualcosa dal framework 4.0.

Come per le versioni di Visual Studio, assolutamente. Lavoriamo in VS2010. Aggiorna qualsiasi progetto o soluzione che è stata salvata l'ultima volta in una versione precedente. Non ho mai riscontrato problemi nell'aggiornamento del file della soluzione a un nuovo Visual Studio.

Domanda spinosa, perché ci sono molti fattori in gioco.

Da un lato, mantenere la corrente renderà la tua vita molto migliore a lungo termine. Alla fine hardware e sistemi operativi supereranno le tue librerie di codici e dovrai effettuare un enorme upgrade, sotto pressione, oppure dovrai implementare un ambiente malvagio.

D'altra parte, passare molto tempo ad aggiornare il codice esistente renderà i risultati finali come una schifezza. Nel mondo degli affari, raramente ottieni credito per le cose che non infrangono, e, ironia della sorte, spesso ricevi credito per aggiustare le cose che si sono rotte solo perché le hai trascurate.

Dico usa il tuo giudizio. Tieni aggiornati i contenuti mission-critical e lascia che il codice meno recente e meno rilevante cada per strada.