Pergunta

Atualmente pensando em comercializar o argumento para nós Migração do vs 2005 (winforms) para vs 2008 (WPF). Meu ponto principal é o novo design da interface do usuário apresenta.

Estou um pouco preocupado que vamos colocar cargas de trabalho na modernização tudo só para nós ter que fazer o mesmo quando 2010 vem junto? Então, isso leva a considerar também pular de 2008 e apenas adotando 2010, logo que a sua liberado.

Qualquer um estado em situação semelhante?

Além disso, quaisquer argumentos a favor e contra a bem-vindas.

Felicidades.

Foi útil?

Solução

Pessoalmente, eu acho que vai ser bastante seguro para ir para 2008 como 2010 é apenas extensões em cima dela e melhorias para Studio suporte Visual tempo de design para WPF. Portanto, a transição não deve ser tão complicado. Mais como um 2005-2008 atualização de uma vitória Formas ou projeto ASP.NET, que é uma moleza.

Eu acho que é melhor para atualizar mais cedo ou mais tarde, de modo que você não fique "atolados" com a estrutura / sistema existente. Se você continuar a construir em algo que você acabará por substituir, torna-se mais difícil e mais difícil de justificar para a gerência de se mover.

Outras dicas

Eu estava na mesma situação e optou por ir abaixo da rota de assinatura MSDN, onde eu recebo todas as novas ferramentas de desenvolvimento que eles saem. Eu tenho uma máquina de reposição do uso I para 'a próxima versão' do compilador, que eu uso para testes de migração, assim que eu pelo menos saber o que esperar quando a decisão tem que ser feita. Isso funciona bem para mim, e eu acho que se você tem um set-up decente virtualização tanto melhor.

Novas versões do compilador não quebrou meu construir, mas doeu muitos dos meus testes automatizados, e adicione-in ferramentas de produtividade. Basicamente. você precisa testes de regressão de algum tipo para averiguar os danos de se mudar para uma nova versão é provável causa.

Sua pergunta não muito sentido para mim. Você está perguntando se você deve migrar aplicações existentes de WinForms para WPF? Ou você só quer começar a fazer novas aplicações WPF, mas ainda trabalho com projetos Winform existentes?

De qualquer maneira, a migração do Visual Studio 2005 para 2008 é extremamente simples. projetos Winform existentes solicitar uma conversão que leva alguns segundos e nunca falhou para mim (dezenas de soluções e 100s de projetos convertido ao longo dos últimos dois meses).

No entanto, isso não tem nada a ver com WinForms e WPF.

Se você quer começar a construir WPF aplicativos, não há razão para esperar VS 2010. VS 2008 tem um excelente suporte para ambos os tipos de aplicação.

Concordo com aqueles sugerindo a adoção VS 2008 agora. Uma coisa a considerar é que embora WPF vem com uma curva de aprendizado bastante elevado. Eu tive alguma exposição limitada a WPF e Silverlight e estou achando que eles sejam uma completa "mudança de mente" a partir do modelo WinForms. Boa sorte.

Eu faria o salto agora, se eu estivesse no seu lugar. Ele vai minimizar o impacto do 2010 salto para baixo da linha, obtendo você usou para os muitos novos recursos que você já vai ter que se acostumar. Além disso, você vai começar a desfrutar de muitos meses de melhor desempenho e características antes de 2010 está disponível.

WinForms vs WPF é um mundo de diferença. É uma mudança muito maior do que olhar para a migração de 2005 a 2008. Eu não teria que, como a razão de condução para atualizar para 2008. Eu também não tenho idéia do alcance do seu projeto e se WPF é realmente a melhor direção a tomar o seu produtos. Ou se mistura expressão é todo o ferramental que você precisa para obter esses UIs vão.

Em vez de lançar o tom WPF gostaria de focar os benefícios reais que você pode começar imediatamente. Com 2008 você tem multi-alvo para que você pode construir todos os aplicativos que você usado para construir em 2005 e tê-los como alvo o quadro 2.0. Na minha experiência, eu acho 2.008 mais rápido e as melhorias refatoração são uma grande adição. Há uma tonelada de outras novas melhorias em 2008, que você começa out-of-the-box e pode começar a utilizar a partir de dia 1.

De acordo com Rico o arquiteto chefe de 2010, você vai ficar ainda mais rico multi-targetting com 2010, o que lhe permitirá adotar 2010 mais cedo e não forçá-lo a usar CLR versão 4 de ir buscar.

No momento eu fiz isso uma prática para atualizar para a versão mais recente o mais rápido possível. Embora para um desenvolvedor de aplicativos que tem suas próprias armadilhas, Ex. .Net Framework 3.5 não é encontrado na maioria dos computadores, e se eu enviar o instalador de inicialização que é de 20 MB que insiste em uma ligação activa à Internet para baixar os arquivos necessários. O instalador completo é de 198 MBs e embora eu não gosto disso, eu tenho que enviá-lo juntamente com o software.

Para um desenvolvedor web que o problema é mais fácil de resolver, você só tem que se preocupar em fazer isso funcionar no servidor e as coisas funcionam automaticamente para os usuários. Então, se você está fazendo uma solução web Acho migração é mais fácil.

Se você estiver fazendo um software de aplicação, eu acho que você deve pesar as vantagens que a migração ofertas com as mudanças que fará para o seu esquema de implantação. Eu não sei quantas pessoas vão concordar com isso, mas eu acredito que os desenvolvedores de aplicativos deve ser uma atualização para trás.

Não é uma questão em processo subjacente aqui que eu acho que não deve ser negligenciado:

Quando é o momento adequado para atualizar ferramentas de desenvolvimento e ambientes de produção?

Por outro lado que você poderia ignorar 2008, embora isso leva à questão de quando iria 2010 seja adotada: Ao primeiro lançamento, o primeiro lançamento do service pack, ou algum outro marco? Isso pode levar à criação de mais código legado se você ficar trancado dentro em 2005, usando o framework 2.0 e outros avançar para outras estruturas. Mesmo se você mudar para 2008, ele ainda pode atingir o quadro 2.0 para que que a atualização do framework .Net pode acontecer separadamente que alguns podem gostar. Outro ponto-chave neste campo é que faz a pesquisa para avaliar as diferenças entre as versões para ver que vale a pena a mudança.

Por outro lado, você poderia sugerir que haja uma estratégia contínua de preparar para atualizar a cada 3 anos ou assim como as versões do Visual Studio da década passada eram mais ou menos 2002, 2003, 2005 e 2008 até agora. Isto parece-me ser a melhor abordagem como há mais de uma constante evolução acontecendo em vez de ficar trancado em nada. Neste caso, pode haver novos recursos que se acostumar já que as novas ferramentas vêm rapidamente em comparação com o primeiro caso em que a mudança pode ser visto como um grande passo que, neste caso, não é assim tão grande desde que você está sempre olhando para mover-se 2-3 anos.

Curso como eu digo isso a minha máquina de trabalho de idade tem Visual Studio 2003, 2005 e 2008, então eu sou tipo de em que este último acampamento que faz sentido para mim. Lembro-me de há 10 anos minha máquina de trabalho teve NT 4.0, Pentium II 333 MHz, 64 MB de RAM e um disco rígido GB 4 que tinha que ser 2 partições, uma vez que não deixaria uma partição ser tão grande. Agora minha máquina de trabalho tem 4 GB de RAM por si só, um 2.66 GHz processador dual core e um disco rígido de 160 GB. I em mais 10 anos pudesse ter uma máquina com centenas de GBs de RAM? Embora isso possa parecer ridículo, se eu estivesse compartilhando uma máquina com um punhado de outros desenvolvedores, pode fazer sentido para dividir uma enorme quantidade de memória entre todos nós.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top