El caso a favor o en contra de .NET (la bestia) [cerrado]

La empresa para la que trabajo utiliza C ++ Builder 6. Hemos estado desarrollando código nativo desde su concepción. Nuestro producto estrella está escrito completamente en código nativo.

Entra en .NET Framework con sus campanas y silbidos. Caigo, gancho, línea y plomada. Convenzo a la gerencia de que .NET debería ser absolutamente nuestro nuevo marco para todo el desarrollo de software nuevo y que deberíamos comenzar a migrar nuestra línea de código existente lo antes posible. Con todos los beneficios, no hace falta mucho para convencer. 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 fáciles 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 necesita 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 Native? ¡Multa!

El problema es este, ahora que un solo componente de nuestra solución está escrito en .NET, complica increíblemente el proceso de instalación. Antes de que pueda instalar nuestro producto, debo hacer lo siguiente:

• Detectar si el requisito previo está instalado

• Instálelo si no lo es

• Verifique que se instaló correctamente

• Siguiente prerrequisito

Para instalar .NET Framework, primero necesito Windows Installer 4.5. Pero hay diferentes versiones para los diferentes sistemas operativos, así que agrego la detección del sistema operativo y ejecuto el EXE correcto. Oh, .NET Framework ya está empaquetado con 2k8 y el instalador exe no se puede ejecutar en él, debe ejecutar OCSetup.exe con parámetros para instalarlo.

Y así continúa. Entonces es necesario instalar SQL Express 2005. Las dependencias aumentan una vez más.

Argumento con la dirección de que ni siquiera Microsoft se lo pone tan fácil al usuario. Su respuesta es que no hay ninguna razón para que no seamos mejores que ellos de esta manera. No puedo discutir con eso, excepto que siento que hay muy buenas razones por las que han optado por su enfoque.

De repente, nuestro instalador es enorme. Todos los requisitos previos para .NET, ni siquiera hablar del soporte de 64 bits que tiene toda una gama separada de EXE para instalar. Así que ahora llegamos al punto en el que queremos que los usuarios puedan descargar una evaluación "rápida". Que broma. Debe descargar 500 MB para ejecutar una aplicación de 30 MB. La mayor parte del paquete de instalación es un requisito previo.

La gerencia siente que tenemos demasiadas dependencias / requisitos previos. Lo entiendo completamente. Sugieren que nos alejemos del marco .NET y regresemos a la tierra nativa donde las cosas aún 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 fácil y la calidad general del código. ¡La otra parte de mí está de acuerdo con ellos de todo corazón! Desarrollar en .NET simplemente requiere que instale muchos otros requisitos previos que complican la instalación.

Sí, algunos de los defensores de .NET afirmarán que todo debe instalarse en un sistema operativo parcheado y actualizado. Esto es cierto, pero no todos los clientes lo tienen, y simplemente decir "Lo siento, actualice primero" no es suficiente. Recuerde, nos enorgullecemos de la experiencia general del usuario.

Ahora estamos considerando escribir código nativo nuevamente y sé que estamos perdiendo en términos de velocidad de desarrollo y todas las ventajas de .NET. Pero estamos ganando en esta área, ya sea pequeña si se mira el panorama general o no. Como tenemos habilidades de desarrollo de código nativo y .NET es realmente un terreno nuevo para nosotros, incluso tiene sentido retroceder.

Mi pregunta es la siguiente: ¿cuál es la opinión de su empresa sobre este tema, si es que es un problema y cómo será el caso de negocio que propongo a la gerencia asumiendo que quiero continuar migrando todos nuestros productos a .NET?

Esta es la razón por la que 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. Cree dos instaladores, uno para cada arquitectura.

Paint.NET envuelve muy bien la instalación de los requisitos previos sin incluir el marco .NET de forma predeterminada. El resultado final es un ejecutable shim no administrado que busca el marco .NET y algunas otras cosas y sostiene su mano mientras se instala; todos descargados sobre la marcha según se necesiten. Luego ejecutan una aplicación WinForms que pInvoca en MSI para envolver aún más la instalación en algodón.

Vale la pena Google.

También es probable que muchas máquinas cliente ya tengan alguna versión de .NET Framework instalada, ya que es parte de Microsoft Update, lo que lo hace más fácil de consumir en el mundo empresarial.

Publicaciones de 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 un poco más la historia, 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á hecho y clasificado como "fácil". Dedique algo de tiempo a la implementación y preséntelo a la gerencia y, ocultando el dolor, muéstreles lo fácil que es instalar :)

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 cualquier idioma nativo que esté usando), por lo que puede desarrollar sus aplicaciones mucho más rápidamente.

Entonces, ¿cómo se compara el tiempo que dedica a desarrollar la aplicación con el tiempo que dedica a desarrollar el instalador? Incluso si tiene que pasar un par de semanas definiendo 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, utilizaría un instalador casi idéntico; todavía haría todas las comprobaciones de requisitos previos, pero en lugar de copiar archivos en 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 caro desarrollar un instalador (bueno / completo) para una aplicación .NET, pero si ese es el paso que debe realizar una vez para mejorar drásticamente su tiempo de desarrollo, es una obviedad. Su retorno de la inversión probablemente sería del orden de semanas.

Siento que necesito responder a esta declaración:

Sí, algunos de los defensores de .NET afirmarán que todo debe instalarse en un sistema operativo parcheado y actualizado. Esto es cierto, pero no todos los clientes lo tienen, y simplemente decir "Lo siento, actualice primero" no es suficiente. Recuerde, nos enorgullecemos de la experiencia general del usuario.

Si su usuario insiste en dispararse a sí mismo en el pie operando un sistema que el proveedor le ha informado que ya no es adecuado para su propósito , entonces no hay mucho que pueda hacer para 'ayudarlo'. Soy consciente de que esto me hace parecer una especie de activista desagradable, pero lo veo de la misma manera que lo haría un comerciante manual: depende del cliente asegurarse de que el entorno en el que quiere que trabaje sea sonido y apropiado para el producto. Si no es así, aceptaré una remuneración adicional para hacer ese trabajo también, pero aún podría causarles trabajo adicional porque no han tenido la previsión necesaria para asegurarse de que entendieron lo que estaban comprando.

Creo que a los clientes de software se les ha permitido permanecer en la ignorancia 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á debidamente parcheado es lo mismo que continuar ejecutando un vehículo que ha estado sujeto al retiro del mercado de un fabricante: un paquete de servicio de Windows es equivalente a un retiro del mercado en muchos aspectos. No está legalmente obligado a someterse a una retirada, pero es lo mejor para su empresa y es posible que sea responsable de los daños causados ​​por eludir su responsabilidad.

Cualquier aplicación de Visual C ++ también tiene requisitos previos / dependencias externas: tiempo de ejecución 6.0, 2003, 2005, 2008 o 2010? sin SP, SP1 o SP2? x86 o x64? ¿Qué versión de Windows Installer requiere 2005 SP2? ¿Y qué 2008 SP1? Y así sucesivamente.

¡Así que son argumentos inverosímiles! Como las quejas de Joel sobre .NET. ¡Y mira lo que es ahora !

No veo cómo hay muchos más requisitos previos para .net sobre C ++ Builder. Usted se queja de SQL Server, pero ignora el hecho de que también tiene que instalar alguna base de datos con el constructor C ++. Usted se queja de x64 vs 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 de C ++ Builder. Es posible que necesite versiones separadas del servidor SQL, pero nuevamente, eso se aplicaría al constructor C ++ (a menos que solo instale x32 en todo).

Sí, existen problemas con la nueva 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 constructor de C ++ probablemente sea más fácil para usted porque ya ha invertido tiempo en crear un buen instalador. Debe hacer lo mismo para .NET, y luego puede elegir basándose en problemas reales ... y no en esto.

Por cierto, la razón por la que Microsoft elige hacer las cosas de la forma en que lo hacen es que muchos usuarios, especialmente los usuarios 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 vienes y lo borras con una nueva versión que no pueden desinstalar fácilmente).

Lo que usted ve como "facilitar las cosas" a las personas con menos conocimientos es en realidad hacer las cosas MUCHO más difíciles para quienes saben lo que están haciendo.

He aquí un buen ejemplo. Una cosa que desprecio absolutamente es cuando instalo una aplicación que necesita SQL Server, y esta instala su propia instancia de SQL Server, aunque es posible que ya tenga varias instancias que podría usar. Fácil para el novato, un dolor en el trasero para mí intentar que tu aplicación funcione con mi única instancia.

Si su aplicación se ejecuta en Mono, entonces enviar su aplicación con el tiempo de ejecución Mono podría ser menos doloroso.