Domanda

Attualmente sto pensando di presentare l'argomento per la migrazione da vs 2005 (winforms) a vs 2008 (wpf). Il mio punto principale sono le nuove funzionalità di progettazione dell'interfaccia utente.

Sono un po 'preoccupato che faremo un sacco di lavoro per aggiornare tutto, solo per noi che dobbiamo fare lo stesso quando arriva il 2010? Quindi questo porta a considerare anche di saltare il 2008 e di adottare il 2010 non appena è stato rilasciato.

Qualcuno si è trovato in una situazione simile?

Anche qualsiasi argomento a favore e contro per il benvenuto.

Saluti.

È stato utile?

Soluzione

Personalmente penso che sarà abbastanza sicuro andare al 2008 in quanto il 2010 è solo estensioni e miglioramenti per il supporto dei tempi di progettazione di Visual Studio per WPF. Pertanto, la transizione non dovrebbe essere così complicata. Più come un aggiornamento 2005-2008 di un progetto Win Forms o ASP.NET, che è un gioco da ragazzi.

Trovo che sia meglio eseguire l'upgrade prima o poi, in modo da non impantanarti " con il framework / sistema esistente. Se continui a basarti su qualcosa che alla fine sostituirai, diventa sempre più difficile giustificare il trasferimento da parte della direzione.

Altri suggerimenti

Ero nella stessa situazione e ho optato per seguire la strada dell'abbonamento MSDN, dove ottengo tutti i nuovi strumenti di sviluppo appena escono. Ho una macchina di riserva che utilizzo per "la prossima versione" del compilatore, che utilizzo per i test di migrazione, quindi so almeno cosa aspettarmi quando deve essere presa la decisione. Questo funziona bene per me e immagino che tu abbia una decente configurazione della virtualizzazione tanto meglio.

Le nuove versioni del compilatore non hanno infranto la mia build, ma hanno danneggiato molti dei miei test automatici e strumenti di produttività aggiuntivi. Fondamentalmente. hai bisogno di test di regressione di qualche tipo per accertare che il danno che potrebbe essere causato dal passaggio a una nuova versione.

La tua domanda non ha molto senso per me. Stai chiedendo se è necessario migrare le applicazioni esistenti da Winforms a WPF? Oppure vuoi solo iniziare a creare nuove applicazioni WPF ma lavorare ancora con progetti Winform esistenti?

Ad ogni modo, la migrazione da Visual Studio 2005 al 2008 è estremamente semplice. I progetti Winform esistenti richiedono una conversione che richiede pochi secondi e non ha mai fallito per me (decine di soluzioni e centinaia di progetti convertiti negli ultimi due mesi).

Tuttavia, questo non ha nulla a che fare con Winforms e WPF.

Se vuoi iniziare a creare app WPF non c'è motivo di aspettare VS 2010. VS 2008 ha un eccellente supporto per entrambi i tipi di applicazione.

Sono d'accordo con quelli che suggeriscono di adottare VS 2008 ora. Una cosa da considerare è che WPF ha una curva di apprendimento abbastanza alta. Ho avuto un'esposizione limitata a WPF e Silverlight e sto trovando che sono un completo "cambiamento di mente" dal modello WinForms. Buona fortuna.

Ora farei il salto se fossi nei tuoi panni. Ridurrà al minimo l'impatto del salto nel 2010, abituandoti alle molte nuove funzionalità a cui dovrai già abituarti. Inoltre potrai godere di molti mesi di prestazioni e funzionalità migliori prima che il 2010 sia disponibile.

Winforms vs WPF è un mondo di differenza. È un cambiamento molto più grande rispetto alla migrazione dal 2005 al 2008. Non lo avrei considerato come motivo trainante per l'aggiornamento al 2008. Inoltre, non ho idea dell'ambito del tuo progetto e se WPF è davvero la direzione migliore per prendere il tuo Prodotto. O se la fusione delle espressioni è tutto lo strumento necessario per far funzionare queste interfacce utente.

Invece di lanciare il pitch di WPF mi concentrerei sui reali benefici che puoi ottenere immediatamente. Con il 2008 hai multi-targeting in modo da poter costruire tutte le applicazioni che hai usato per costruire nel 2005 e farle indirizzare al framework 2.0. Nella mia esperienza trovo il 2008 più veloce e i miglioramenti del refactoring sono un'ottima aggiunta. Ci sono un sacco di altri nuovi miglioramenti nel 2008 che puoi ottenere immediatamente dal primo giorno.

Secondo Rico, l'architetto capo del 2010, con il 2010 otterrai un multi-targeting ancora più ricco, che ti consentirà di adottare il 2010 prima e di non costringerti a utilizzare CLR versione 4 fin dall'inizio.

Al momento ho reso pratica l'aggiornamento al più presto possibile alla versione più recente. Anche se per uno sviluppatore di applicazioni ha le sue insidie, Ex. .Net Framework 3.5 non si trova sulla maggior parte dei computer e se invio il programma di installazione bootstrap che è 20 MB, insiste su una connessione Internet attiva per scaricare i file necessari. Il programma di installazione completo è di 198 MB e sebbene non mi piaccia, devo spedirlo insieme al software.

Per uno sviluppatore web sebbene il problema sia più facile da risolvere, devi solo preoccuparti di farlo funzionare sul server e le cose funzionano automaticamente per gli utenti. Quindi, se stai realizzando una soluzione web, penso che la migrazione sia più semplice.

Se stai realizzando un software applicativo, penso che dovresti soppesare i vantaggi offerti dalla migrazione con le modifiche che apporterà al tuo schema di distribuzione. Non so quante persone saranno d'accordo con questo, ma credo che gli sviluppatori di applicazioni dovrebbero essere un aggiornamento dietro.

C'è una domanda di processo sottostante che penso non debba essere trascurata:

Quando è il momento giusto per aggiornare gli strumenti di sviluppo e gli ambienti di produzione?

Da un lato potresti saltare il 2008, anche se questo porta alla domanda su quando verrà adottato il 2010: al primo rilascio, primo rilascio del service pack o qualche altra pietra miliare? Questo può portare alla creazione di più codice legacy se rimani bloccato nel 2005 utilizzando il framework 2.0 e altri passano ad altri framework. Anche se passi al 2008, può comunque scegliere come target il framework 2.0 in modo che l'aggiornamento del framework .Net possa avvenire separatamente, cosa che potrebbe piacere ad alcuni. Un altro punto chiave in questo campo è chi fa la ricerca per valutare le differenze tra le versioni per vedere quale valga la pena cambiare.

Dall'altro, potresti suggerire che ci sia una strategia continua di preparazione per l'aggiornamento ogni 3 anni circa, dato che le versioni di Visual Studio dell'ultimo decennio erano circa 2002, 2003, 2005 e 2008 finora. Questo mi sembra essere l'approccio migliore in quanto vi è più di un'evoluzione costante in atto piuttosto che rimanere bloccati a tutti. In questo caso potrebbero esserci nuove funzionalità che vengono utilizzate poiché i nuovi strumenti arrivano rapidamente rispetto al primo caso in cui lo spostamento può essere visto come un grande passo mentre in questo caso non è così grande poiché stai sempre cercando di spostarti 2-3 anni.

Ovviamente, come ho detto, la mia vecchia macchina da lavoro ha Visual Studio 2003, 2005 e 2008, quindi sono un po 'in quest'ultimo campo che per me ha senso. Ricordo che 10 anni fa la mia macchina da lavoro aveva NT 4.0, processore Pentium II a 333 MHz, 64 MB di RAM e un disco rigido da 4 GB che doveva essere 2 partizioni in quanto non avrebbe lasciato una partizione così grande. Ora la mia macchina da lavoro ha solo 4 GB di RAM, un processore dual core da 2,66 GHz e un disco rigido da 160 GB. Potrei in altri 10 anni avere una macchina con centinaia di GB di RAM? Sebbene ciò possa sembrare ridicolo, se condividessi una macchina con una manciata di altri sviluppatori, potrebbe avere senso dividere un'enorme quantità di memoria tra tutti noi.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top