c# - valid - El caso a favor o en contra de.NET(la bestia)
comentarios c# documentacion (7)
Cualquier aplicación de Visual C ++ también tiene requisitos previos / dependencias externas: runtime 6.0, 2003, 2005, 2008 o 2010? no SP, SP1 o SP2? x86 o x64? ¿Qué versión de Windows Installer requiere el SP2 2005? ¿Y qué 2008 SP1? Y así sucesivamente, etc.
¡Así que eso es argumentos extravagantes! Como las grumblings de Joel sobre .NET. Y mira lo que es now !
La empresa para la que trabajo utiliza C ++ Builder 6. Hemos estado desarrollando código nativo desde la concepción. Nuestro producto insignia está escrito completamente en código nativo.
Ingresa al .NET Framework con sus campanas y silbatos. Me caigo, gancho, línea y plomada. Convenzo a la gerencia de que .NET debe ser absolutamente nuestro nuevo marco para todo el desarrollo de software nuevo y que debemos comenzar a migrar nuestra línea de código existente lo antes posible. Con todos los beneficios, no es muy convincente. Ellos aceptan mi propuesta como de costumbre.
En este punto, empiezo a desarrollar mi primera aplicación .NET. Todo va según lo planeado. El proyecto es solo un componente de nuestro producto. Y así llego al punto de crear un instalador para este nuevo componente. Como empresa, nos enorgullecemos de hacer que las cosas para el usuario sean lo más sencillas posible. Incluso Microsoft con miles de desarrolladores no crea instaladores como nosotros. Cuando instale Microsoft CRM, por ejemplo, solo obtendrá una lista de fallas y requisitos previos que debe instalar antes de poder continuar. Nosotros no. Nunca. Si necesita algo, lo instalaremos por usted.
Esto hace que nuestras instalaciones se sientan tan fáciles. .NET Framework no está instalado? ¡No hay problema! Lo haremos por ti. ¿Necesita un cliente SQL nativo? ¡Multa!
El problema es este, ahora que un solo componente de nuestra solución está escrito en .NET, complica el proceso de instalación increíblemente. Antes de poder instalar nuestro producto, necesito hacer lo siguiente:
Detecta si el prerrequisito está instalado
Instálalo si no es
Verifique que se haya instalado correctamente
Siguiente prerrequisito
Para instalar .NET Framework, primero necesito Windows Installer 4.5. Pero existen diferentes versiones para los diferentes sistemas operativos, por lo que agrego detección de sistema operativo y ejecuto el EXE correcto. Ah, .NET Framework ya viene empaquetado con 2k8 y el instalador exe no puede ejecutarse en él, debe ejecutar OCSetup.exe con parámetros para instalarlo.
Y así continúa. Entonces SQL Express 2005 necesita ser instalado. Las dependencias aumentan una vez más.
Argumento con la dirección que incluso Microsoft no lo hace tan fácil para el usuario. Su respuesta es que no hay razón para que nosotros no seamos mejores que ellos de esta manera. No puedo discutir con eso, excepto que siento que hay muy buenas razones por las que se han ido con su enfoque.
De repente, nuestro instalador es masivo. Todos los requisitos previos para .NET, ni siquiera hablan de soporte de 64 bits que tiene un rango completo de EXEs para instalar. Ahora llega al punto en que queremos que los usuarios puedan descargar una evaluación "rápida". Que broma. Necesita descargar 500MB para ejecutar una aplicación de 30MB. La mayoría del paquete de instalación es un requisito previo.
La gerencia considera que tenemos demasiadas dependencias / requisitos previos. Lo entiendo completamente. Sugieren que nos alejemos del framework .NET, de vuelta a la tierra nativa donde las cosas todavía eran "fáciles" en términos de instalación. Aquí es donde una parte de mí quiere defender .NET explicando los beneficios en el panorama general, la experiencia de desarrollo mejorada, el mantenimiento más sencillo y la calidad general del código. ¡La otra parte de mí está de acuerdo con ellos de todo corazón! El desarrollo en .NET simplemente requiere que instale demasiados requisitos previos que compliquen la instalación.
Sí, algunos de los defensores de .NET afirmarán que todo debería instalarse en un sistema operativo parcheado y actualizado. Esto es cierto, pero no todos los clientes tienen esto, y simplemente decir "Lo siento, actualizar primero" simplemente no lo cortará. Recuerde, nos enorgullecemos de la experiencia general del usuario.
Ahora estamos considerando escribir código nativo de nuevo y sé que estamos perdiendo en términos de velocidad de desarrollo y todos los beneficios de .NET. Pero estamos ganando en esta área, ya sea pequeña si nos fijamos en el panorama general o no. Como tenemos habilidades de desarrollo de código nativo y .NET es en realidad un terreno nuevo para nosotros, incluso tiene sentido retroceder.
Mi pregunta es esta: ¿cuál es la opinión de su empresa sobre este tema si incluso es un problema y cuál será el caso de negocios que propongo a la gerencia suponiendo que deseo continuar migrando todos nuestros productos a .NET?
Esta es la razón por la cual muchas empresas han cambiado a instaladores web que descargan todos los requisitos previos sobre la marcha desde su página de inicio. Dado que en la mayoría de los casos, el sistema operativo tiene el 99% de lo que se necesita (si se han actualizado con Windows Update).
No pondría todo para x64 y x32 en el mismo instalador. Crea dos instaladores, uno para cada arquitectura.
No veo cómo hay requisitos previos significativamente más para .net que C ++ Builder. Se queja de SQL Server, pero ignora el hecho de que también debe instalar alguna base de datos con el generador de C ++. Se queja de x64 frente a x32, pero .NET no requiere ningún cambio. El mismo exe se ejecuta en ambos (y se compila de manera óptima para cualquier entorno). No se puede decir lo mismo sobre C ++ Builder. Es posible que necesite versiones separadas de SQL Server, pero una vez más eso se aplicaría al generador de C ++ (a menos que simplemente instale x32 en todo).
Sí, están los nuevos problemas de la versión del instalador, pero esos componentes no son muy grandes. Y realmente puede hacer que los instaladores descarguen e instalen solo los aprts que sean necesarios.
El generador de C ++ es probablemente más fácil para usted porque ya ha invertido el tiempo en crear un buen instalador. Debe hacer lo mismo para .NET, y luego puede elegir en función de problemas reales ... y no esto.
Por cierto, la razón por la que Microsoft elige hacer las cosas de la manera en que lo hacen es que muchos usuarios, especialmente los corporativos, no aprecian que se les instalen cosas automáticamente (quizás porque tienen una aplicación que depende de una versión específica de una biblioteca, y usted viene y lo elimina con una nueva versión que no puede desinstalar fácilmente).
Lo que usted ve como "hacerlo más fácil" para las personas con menos conocimientos es en realidad hacer las cosas MUCHO más difíciles para aquellos que saben lo que están haciendo.
Aquí hay un buen ejemplo. Una cosa que desprecio es cuando instalo una aplicación que necesita SQL Server, e instala su propia instancia de SQL Server, aunque es posible que ya tenga varias instancias que pueda usar. Fácil para los novatos, un dolor en el culo para que intente hacer que tu aplicación funcione con mi única instancia.
Paint.NET completa muy bien la instalación de requisitos previos sin combinar el .NET framework con él de forma predeterminada. El resultado final es un ejecutable de shim no administrado que busca el .NET framework y algunas otras cosas y mantiene su mano mientras se instala; todos descargados sobre la marcha, ya que son necesarios. A continuación, ejecutan una aplicación WinForms que invierte en MSI para envolver la instalación con algodón.
Vale la pena un Google.
También es probable que muchas máquinas cliente ya tengan instalada alguna versión de .NET Framework, ya que es parte de Microsoft Update, lo que hace que sea más fácil de consumir en el mundo de los negocios.
Publicaciones del blog de Paint.NET sobre la instalación:
http://blog.getpaint.net/2008/08/24/the-paintnet-install-experience-part-1-version-3xx/
http://blog.getpaint.net/2008/08/25/the-paintnet-install-experience-part-2-version-40/ (¡gracias Rup!)
Al leer la historia un poco más, presumiblemente la administración tuvo que pasar por el dolor de la implementación con la aplicación C ++ al menos una vez, pero ahora está hecha y clasificada como "fácil". Ponga algo de tiempo contra el despliegue y presente esto a la gerencia y, ocultando el dolor, demuéstreles lo fácil que es instalar :)
Si su aplicación se ejecuta en Mono, entonces enviar su aplicación con el tiempo de ejecución Mono puede ser menos doloroso.
Siento que necesito responder a esta afirmación:
Sí, algunos de los defensores de .NET afirmarán que todo debería instalarse en un sistema operativo parcheado y actualizado. Esto es cierto, pero no todos los clientes tienen esto, y simplemente decir "Lo siento, actualizar primero" simplemente no lo cortará. Recuerde, nos enorgullecemos de la experiencia general del usuario.
Si su usuario insiste en dispararse en el pie al operar un sistema que el vendedor le ha informado que ya no es apto para su propósito , entonces no hay mucho que pueda hacer para ''ayudarlo''. Soy consciente de que esto me hace ver como un activista odioso, pero lo veo de la misma manera que un comerciante manual: depende del cliente asegurarse de que el entorno en el que quieren que trabaje sea sonido y apropiado para el producto. Si no es así, aceptaré más renumeración para hacer ese trabajo también, pero aún podría causarles trabajo extra porque no han tenido la previsión de asegurarse de que entendieran lo que estaban comprando.
Creo que a los clientes de software se les ha permitido permanecer ignorantes durante el tiempo suficiente, y que ahora se les debería exigir que comprendan qué es lo que están comprando. Operar un entorno de TI corporativo que no está correctamente parcheado es lo mismo que continuar ejecutando un vehículo que ha estado sujeto a la retirada del fabricante: un paquete de servicio de Windows es equivalente a un retiro en muchos aspectos. No está legalmente obligado a someterse a un retiro del mercado, pero es en su mejor interés como empresa y puede ser responsable por los daños causados por su elusión de responsabilidad.
Volvamos a por qué quería cambiar de código nativo a código .NET en primer lugar: es más eficiente para usted, como programador. Muchas cosas son más fáciles en .NET que en C ++ (o en cualquier otro idioma nativo que esté usando), por lo que puede desarrollar sus aplicaciones mucho más rápido.
Entonces, ¿cómo se compara el tiempo que dedicas a desarrollar la aplicación con el tiempo que dedicas a desarrollar el instalador? Incluso si tiene que pasar un par de semanas clavando el instalador (específicamente la parte de configuración del marco), esa debería ser más o menos la única vez que tiene que pasar por eso.
Para todas las aplicaciones futuras, estarías usando un instalador casi idéntico; usted todavía haría todas las comprobaciones de requisitos previos, pero en lugar de copiar archivos a C: / Foo, está copiando algunos archivos diferentes en C: / bar.
En mi opinión, esta es una simple cuestión de economía. Sí, es más costoso desarrollar un instalador (bueno / completo) para una aplicación .NET, pero si ese es el paso que necesita tomar una vez para mejorar dramáticamente su tiempo de desarrollo, es una obviedad. Su retorno de la inversión probablemente sea del orden de semanas.