.net - saber - net framework windows 10
Qué versión de.NET Framework debo enviar; 2, 3, 3.5? (14)
Mi aplicación usa 2.0. En algún momento en el futuro, es posible que desee comenzar a utilizar las funciones más nuevas agregadas en las versiones posteriores del framework. ¿Debería esperar hasta entonces? ¿O hay ventajas de actualizar a la versión más reciente de .NET 3.5 ahora?
Supongo que para cuando esté listo para el lanzamiento de la próxima primavera, 4.0 saldrá. Tal vez debería quedarme con 2.0 para mi versión de otoño y salvar a mis clientes el espacio en HD e instalar el tiempo de otra versión de framework.
3.5 Framework ha tenido su primera versión de Service Pack, por lo que es más estable de lo que era después del lanzamiento, pero tenga en cuenta que es mucho más fácil actualizar el código de 2.0 a 3.5 que volver a 3.5 si por alguna razón se encuentra con un muestra el tope.
El artículo de wiki muestra muy bien las nuevas características.
Aprecio las nuevas características del lenguaje en .NET 3.5, pero hasta que no las use, evitaría actualizar al último tiempo de ejecución ya que es un archivo / instalación más grande con el que los usuarios pueden tener que lidiar.
Debes distribuir tu aplicación con la versión de .Net con la que hayas probado más. Si ha estado haciendo todo su desarrollo y prueba en .Net 2.0, envíe con 2.0.
Pero puede que se lo deba a sus clientes para probar en contra de 3.5 y enviar con eso, en cambio, por el bien de cualquier error que se haya solucionado en el marco desde que se lanzó 2.0. El marco ya es tan grande que probablemente no haya ningún beneficio al distribuir una versión anterior, incluso si se presentó antes de WCF, WPF, etc., a menos que esté pagando costos de ancho de banda para distribuirlo, o el dispositivo de destino tiene almacenamiento limitado espacio.
En mi opinión, debes enviar lo que tu aplicación necesita. De lo contrario, harás que la instalación sea más larga sin ningún motivo y, como dijiste, utilizarás el espacio de alta definición de tu cliente de nuevo esencialmente sin ningún motivo.
Estoy de acuerdo con que debe saber qué necesita su aplicación, pero también debe prepararse para lo que necesitarán sus aplicaciones en el futuro .
Si tiene unos pocos ciclos de repuesto, puede migrar una rama separada de sus aplicaciones en su SCM que se ejecuta con el 3.5 Runtime y cuando realmente necesita actualizar, tiene una sucursal en funcionamiento (suponiendo que lo mantenga hasta -to- fecha con alguna fusión quincenal).
He encontrado que la versión 2.0 es la más fácil de dirigir e implementar, ya que mucha gente ya la tiene instalada. Si una parte considerable de su base de clientes usa Vista, podría considerar actualizarse a 3.0. Las versiones anteriores casi siempre requieren una instalación que puede ser un problema para algunos usuarios.
Editar: El argumento "versión de framework saliendo de soporte" no contiene agua ya que 3.0 es una extensión de 2.0 y 3.5 es una extensión de eso. Por definición 2.0 será compatible siempre que 3.5 sea. La versión 1.1 es la única versión que es un tiempo de ejecución completamente independiente y ya no es compatible.
Las características de Linq a SQL, y realmente las extensiones de Linq en general bien valen la pena.
En cuanto a sus preocupaciones sobre el espacio de HD y el tiempo de instalación, IMO estos no son relevantes en la mayoría de los sistemas modernos para los marcos más nuevos. Las versiones más recientes de los marcos (3.0 y 3.5) son realmente solo "refrescantes" del marco 2.0. A menos que sus clientes / mercado sean PCs anteriores, creo que obtendrán una buena compensación en funcionalidad y productividad para su equipo de desarrollo, en oposición al riesgo insignificante de perder clientes porque no pueden arriesgarse a agregar otros 20Mb en su disco duro (inventé el número de 20 mb, alguien puede llamar a BS sobre eso).
Si planea actualizar a 3.5 SP1, debe considerar usar el nuevo paquete de configuración de perfil de cliente de .NET Framework .
.NET 3.5 SP1 presenta una nueva opción de paquete de instalación para desarrolladores que crean aplicaciones de cliente .NET denominadas ".NET Framework Client Profile". Esto proporciona un nuevo instalador de configuración que permite una experiencia de instalación más pequeña, más rápida y más simple para las aplicaciones cliente .NET en máquinas que aún no tienen instalado .NET Framework.
La configuración de .NET Framework Client Profile contiene solo los ensamblados y archivos en .NET Framework que se usan generalmente para escenarios de aplicaciones cliente. Por ejemplo: incluye Windows Forms, WPF y WCF. No incluye ASP.NET y esas bibliotecas y componentes utilizados principalmente para escenarios de servidores. Esperamos que este paquete de instalación tenga un tamaño de aproximadamente 26 MB, y se puede descargar e instalar mucho más rápido que el paquete de instalación completo de .NET Framework.
Los ensamblados y las API en el paquete de instalación de .NET Framework Client son 100% idénticos a los del paquete de instalación de .NET Framework completo (literalmente son los mismos binarios). Esto significa que las aplicaciones pueden orientarse tanto al perfil del cliente como al perfil completo de .NET 3.5 SP1 (no se requiere una recompilación). Todas las aplicaciones .NET que funcionan con la configuración de .NET Client Profile funcionan automáticamente con .NET Framework completo.
Siempre uso la versión más actualizada del Framework. Esta puede ser una pequeña carga inicial para los usuarios, pero la aplicación tiene una vida mucho más larga entre actualizaciones. Eso puede o no ser importante para ti, pero considera:
Si envió una aplicación en 2005 con .NET 1.1, el marco en el que se ejecuta su aplicación ahora está fuera del soporte principal, y puede tener vulnerabilidades de seguridad no parcheadas u otros problemas serios con los que Microsoft no puede lidiar y que no puede compensar. en tu propio código Su única alternativa en 2008 es conseguir que sus usuarios actualicen su versión de marco ahora. Y, como todos sabemos, hacer que los usuarios actualicen las cosas de manera oportuna puede ser problemático.
Del mismo modo, considere su situación en 2011. Si programa para .NET 3.5 ahora, su aplicación, tal como fue enviada, será viable por más tiempo. Si realiza el envío de .NET 2.0 ahora, dentro de unos años estará en condiciones de tener que convencer a sus usuarios para que actualicen su marco (código que no tiene ningún beneficio para ellos, recuerde) para que pueda apoyar adecuadamente esta aplicación.
Además, si planea implementar características de clase 3.5 (LINQ to SQL el próximo año, por ejemplo), le convendría enviar 3.5 ahora, en lugar de 2.0, ya que la implementación más adelante será un problema menor para usted.
No olvide que .Net 4.0 será un poco diferente de las versiones anteriores del marco. .Net 4.0 se instalará lado a lado (SxS) .Net 3.5 y viceversa. Si actualiza su aplicación para usar .Net 4.0, sus usuarios a largo plazo (también conocidas como versiones anteriores) terminarán teniendo que instalar una versión completamente nueva del marco.
Si está considerando la cantidad de espacio de disco que va a utilizar en las máquinas cliente con su aplicación y el marco, entonces no se olvide de este uso "oculto" de espacio adicional. Si actualiza su aplicación ahora de 2.0 a 3.5, entonces su aplicación podría existir por más tiempo con una funcionalidad completa sin forzar al usuario a instalar un segundo marco que consuma otros 20+ MB de espacio.
Recuerde que "una pequeña carga" para los usuarios podría significar la diferencia entre la aceptación y el rechazo de su aplicación.
Administro TI para una empresa. Nuestro estándar de la compañía no es 3.5. Tendría que tener una aplicación realmente elegante para que actualice a todos a .NET 3.5 para que pueda ejecutar su aplicación. En otras palabras, probablemente no suceda. Encontraré otra aplicación que no agrega una "pequeña carga" adicional en nuestro departamento de SI ya sobrecargado.
Alguien más comentó sobre las características que realmente usarás. Si 1.1 o 2.0 tiene el conjunto de características reales, necesita seguir con él.
.net 3.5sp1 bootstrapper es demasiado lento, especialmente si está utilizando la aplicación asp.net (en comparación con los formularios de Windows), en una máquina que solo tiene .NET 2.0, carga todo el framework y eso significa que tiene aproximadamente 20-30 minutos de descarga + tiempo de instalación en una conexión a Internet moderada y velocidad de la máquina.
Una pregunta que me gustaría hacer es ¿cuáles son las características de .NET 3.5 que le gustaría usar? Muchas de las características promocionadas son en realidad funciones C # 3.0, no características específicas para .NET 3.0 / 3.5 y dado que C # 3.0 usa el mismo CLR que .NET Framework 2.0, también puede usarlas en sus aplicaciones 2.0. Esto solo requiere VS 2008.
Los ejemplos son:
- Expresiones Lambda
- Iniciales de objetos
- Tipos anónimos
- Inferencia del tipo de variable local
- Métodos de extensión
Uso muchos de estos en mis propios proyectos .NET 2.0 sin problemas.
Si hay características específicas del marco que desee (como Linq, WPF, etc.), entonces tendría que actualizar.
Estoy de acuerdo con EBGreen y Chris , pero quiero agregar que es posible que desee considerar probar su aplicación con las versiones más recientes del marco y permitir que su aplicación se ejecute en contra de las versiones que considere que funcionan bien en contra (esto se puede hacer usando algunas truco de configuración, pero desafortunadamente, no puedo encontrar referencia a él). De esta forma, su aplicación podría funcionar contra la versión que el cliente ya haya instalado.
Sugiero esto porque:
- Las nuevas versiones de frameworks pueden darle un aumento de rendimiento.
- El cliente ya puede tener otra versión instalada en su computadora y sería una pena, como usted dice, perder espacio en el disco duro.
- Es posible que desee ejecutar su aplicación en una versión de framework más nueva en el futuro y si su cliente ya tiene esa versión y está ejecutando la versión actual de la aplicación, no habrá un viejo framework en su computadora.
Aún así, me falta cierta información que pueda tener, como los medios de distribución, el perfil de las máquinas de los clientes, etc.