Pregunta

Actualmente estoy pensando en lanzar el argumento para la migración de nosotros desde vs 2005 (winforms) a vs 2008 (wpf). Mi punto principal son las nuevas características de diseño de la interfaz de usuario.

¿Me preocupa un poco que pongamos mucho trabajo en actualizar todo solo para que tengamos que hacer lo mismo cuando llegue el 2010? Así que esto lleva a considerar también saltarse el 2008 y simplemente adoptar el 2010 tan pronto como se publique.

¿Alguien ha estado en una situación similar?

También cualquier argumento a favor y en contra de bienvenido.

Saludos.

¿Fue útil?

Solución

Personalmente, creo que será bastante seguro llegar al 2008, ya que el 2010 es solo una extensión y mejoras para el soporte de tiempo de diseño de Visual Studio para WPF. Por lo tanto, la transición no debería ser tan complicada. Más como una actualización de 2005-2008 de un proyecto de Win Forms o ASP.NET, que es un juego de niños.

Encuentro que es mejor actualizar más temprano que tarde, para que no quedes atascado " con el marco / sistema existente. Si continúa construyendo sobre algo que finalmente reemplazará, se hace cada vez más difícil justificar que la administración se mude.

Otros consejos

Estaba en la misma situación y opté por seguir la ruta de suscripción de MSDN, donde obtengo todas las nuevas herramientas de desarrollo a medida que salen. Tengo una máquina de repuesto que utilizo para "la próxima versión" del compilador, que utilizo para las pruebas de migración, por lo que al menos sé qué esperar cuando se debe tomar una decisión. Esto funciona bien para mí, y supongo que si tienes una configuración de virtualización decente, mucho mejor.

Las nuevas versiones del compilador no rompieron mi compilación, pero sí afectaron muchas de mis pruebas automatizadas y herramientas de productividad adicionales. Básicamente. necesita pruebas de regresión de algún tipo para determinar si es probable que el daño al mudarse a una nueva versión.

Tu pregunta no tiene mucho sentido para mí. ¿Está preguntando si debería migrar las aplicaciones existentes de Winforms a WPF? ¿O simplemente desea comenzar a crear nuevas aplicaciones WPF pero seguir trabajando con proyectos Winform existentes?

De cualquier manera, la migración de Visual Studio 2005 a 2008 es extremadamente simple. Los proyectos existentes de Winform solicitan una conversión que tarda unos segundos y nunca me ha fallado (docenas de soluciones y cientos de proyectos convertidos en los últimos dos meses).

Sin embargo, esto no tiene nada que ver con Winforms y WPF.

Si desea comenzar a crear aplicaciones WPF, no hay razón para esperar a VS 2010. VS 2008 tiene un excelente soporte para ambos tipos de aplicaciones.

Estoy de acuerdo con aquellos que sugieren adoptar VS 2008 ahora. Una cosa a considerar es que WPF viene con una curva de aprendizaje bastante alta. He tenido una exposición limitada a WPF y Silverlight y me parece que son un "cambio de mente" completo. del modelo WinForms. Buena suerte.

Daría el salto ahora si estuviera en tus zapatos. Minimizará el impacto del salto 2010 en la línea al acostumbrarte a las muchas características nuevas a las que ya tendrás que acostumbrarte. Además, podrá disfrutar de muchos meses de mejor rendimiento y características antes de que esté disponible el año 2010.

Winforms vs WPF es un mundo de diferencia. Es un cambio mucho más grande que mirar la migración de 2005 a 2008. No tendría eso como la razón principal para actualizar a 2008. Tampoco tengo idea del alcance de su proyecto y si WPF es realmente la mejor dirección para tomar su producto. O si la combinación de expresiones es todo el conjunto de herramientas que necesita para poner en marcha estas interfaces de usuario.

En lugar de lanzar el tono de WPF, me concentraría en los beneficios reales que puede obtener de inmediato. Con el 2008, tiene múltiples objetivos, por lo que puede crear todas las aplicaciones que utilizó para compilar en 2005 y hacer que se orienten al marco 2.0. En mi experiencia, encuentro 2008 más rápido y las mejoras de refactorización son una gran adición. Hay un montón de otras mejoras nuevas en 2008 que se obtienen de manera inmediata y pueden comenzar a usarse desde el primer día.

Según Rico, el arquitecto principal de 2010, obtendrás un multi-targeting aún más rico con 2010, lo que te permitirá adoptar 2010 antes y no te obligará a usar CLR versión 4 desde que te vayas.

En este momento me he convertido en una práctica actualizar a la última versión lo antes posible. Aunque para un desarrollador de aplicaciones tiene sus propios escollos, Ex. .Net Framework 3.5 no se encuentra en la mayoría de las computadoras, y si envío el instalador bootstrap, que tiene 20 MB, insiste en una conexión activa a Internet para descargar los archivos necesarios. El instalador completo es de 198 MB y, aunque no me gusta, tengo que enviarlo junto con el software.

Para un desarrollador web, aunque el problema es más fácil de resolver, solo tiene que preocuparse de que funcione en el servidor y que las cosas funcionen automáticamente para los usuarios. Entonces, si estás creando una solución web, creo que la migración es más fácil.

Si está creando un software de aplicación, creo que debería sopesar las ventajas que ofrece la migración con los cambios que realizará en su esquema de implementación. No sé cuántas personas estarán de acuerdo con esto, pero creo que los desarrolladores de aplicaciones deberían estar detrás de una actualización.

Aquí hay una pregunta de proceso subyacente que creo que no se debe pasar por alto:

¿Cuándo es el momento adecuado para actualizar las herramientas de desarrollo y los entornos de producción?

Por un lado, podría omitir 2008, aunque esto lleva a la pregunta de cuándo se adoptará 2010: ¿En la primera versión, la primera versión del service pack o algún otro hito? Esto puede llevar a crear más código heredado si permanece bloqueado en 2005 con el marco 2.0 y otros se mueven a otros marcos. Incluso si se cambia a 2008, todavía puede apuntar al marco 2.0 para que la actualización del marco .Net pueda ocurrir por separado, lo que a algunos les puede gustar. Otro punto clave en este campo es quién realiza la investigación para evaluar las diferencias entre versiones para ver cuál vale la pena el cambio.

Por otro lado, podría sugerir que haya una estrategia continua de preparación para la actualización cada 3 años aproximadamente, ya que los lanzamientos de Visual Studio de la última década fueron aproximadamente 2002, 2003, 2005 y 2008 hasta el momento. Me parece que este es el mejor enfoque, ya que hay una evolución más constante en lugar de permanecer encerrado en absoluto. En este caso, es posible que haya nuevas funciones que se usen, ya que las nuevas herramientas vienen rápidamente en comparación con el primer caso en el que el cambio puede verse como un gran paso, mientras que en este caso no es tan grande, ya que siempre está buscando mudarse. 2-3 años.

Por supuesto, mientras digo esto, mi vieja máquina de trabajo tiene Visual Studio 2003, 2005 y 2008, por lo que estoy más o menos en el último campo que tiene sentido para mí. Recuerdo que hace 10 años, mi máquina de trabajo tenía un procesador NT 4.0, Pentium II 333 MHz, 64 MB de RAM y un disco duro de 4 GB que tenía que ser 2 particiones, ya que no permitiría que una partición fuera tan grande. Ahora mi máquina de trabajo tiene solo 4 GB de RAM, un procesador de doble núcleo a 2.66 GHz y un disco duro de 160 GB. ¿Podría en otros 10 años tener una máquina con cientos de GB de RAM? Si bien esto puede parecer ridículo, si compartiera una máquina con un puñado de otros desarrolladores, podría tener sentido dividir una gran cantidad de memoria entre todos nosotros.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top