¿Hay alguna razón para crear una DLL .NET en lugar de EXE si el archivo se usa como un ensamblado al que se hace referencia?

Me di cuenta de que puedo agregar una referencia no solo a una DLL sino también a un EXE en Visual Studio y acceder a todas las clases en el EXE como si fuera una DLL.¿Hay alguna razón para crear una DLL .NET en lugar de EXE si el archivo se usa como un ensamblado al que se hace referencia?

¿Hay alguna razón para crear una DLL o puedo hacer referencia al EXE?

Pregunto porque a menudo escribo programas .net que ejecuto tanto en Windows como bajo Mac OS y mi solución habitual es crear una DLL con la funcionalidad y luego dos GUI, una para cada objetivo.

Sin embargo, ahora me parece que podría simplemente escribir una versión de Windows de mi aplicación y luego agregar esa versión de Windows (el archivo EXE) a mi proyecto Mac y hacer referencia al EXE de Windows en lugar de una DLL. También tiene la ventaja adicional de que puedo ejecutar la versión de Windows desde la carpeta Mac sin agregar otro archivo.

¿Hay alguna buena razón para no hacerlo de esa manera?

Fuente

2011-08-24 Andrew J. Brehm

En este caso, ¿su EXE de Windows incluiría las partes de UI que anteriormente habría separado (si fuera una DLL)? –

Sí. Se podría ejecutar por separado y creo que eso es una ventaja. –

Si lo desea, puede compilar todos sus ensamblajes como ejecutables (.exe) y hacer referencia a ellos. No hay diferencia para .NET si un ensamblado se compila como ejecutable (.exe) o biblioteca de clases (.dll).

La única diferencia es que un ejecutable tiene un formato y encabezado adicional Portable Executable (PE), por lo que se pueden ejecutar en sistemas Windows. Principalmente es este encabezado utilizado para iniciar CLR Runtime.

Nota: También es posible construir .dll asambleas como Portable Class Libraries

Fuente

2011-08-26 07:36:15 Jehof

.NET DLL no funcionan en Windows Phone? Nunca lo supo. –

Entonces, en mi caso, cuando es una ventaja hacer referencia a un archivo EXE en lugar de un archivo DLL (es decir, que un programa de Windows que funcione completamente viaja con la versión de Mac) no tiene inconvenientes, excepto los inconvenientes habituales de no haber dividido el EXE en una DLL y un EXE? –

Depende de la cantidad de mantenimiento/actualización que terminaría haciendo a las aplicaciones. Me gusta la limpieza del modelo original, donde la interfaz de usuario se separa en función de la plataforma, y los archivos DLL contienen las clases que se comparten. Lo encontraría menos confuso para mantenimiento/refactorización.

Fuente

2011-08-24 13:11:53

Quizás. Pero incluso dentro de la GUI de un proyecto y la lógica de negocios todavía están en clases y archivos separados. Y tiene la ventaja de que la versión simple .NET (que usa Windows Forms) es un único archivo EXE sin archivos de soporte necesarios. La versión de Mac necesita muchos archivos de soporte, pero viene en un bundle.app. –

veo al menos dos razones por las que todavía se debe dividir/

de versiones - que es bueno tener números de versión para los independientes dlls y exse - es especialmente bueno cambiar el número de versión cuando la interfaz cambia
responsabilidad única y prueba

Fuente

2011-08-26 07:44:13 weismat

Esos son argumentos para dividir una aplicación en archivos EXE y DLL separados, no necesariamente motivos para no hacer referencia a un archivo EXE. Necesito saber si hay razones para no hacer referencia a un archivo EXE, obviamente además de las razones generales para dividir una aplicación en GUI y archivos de lógica de negocios. –

¿Hay alguna razón para crear una DLL .NET en lugar de EXE si el archivo se usa como un ensamblado al que se hace referencia?

Respuesta

Cuestiones relacionadas