El .NET equivalente de bibliotecas estáticas?

Question

Estoy construyendo una herramienta en código administrado (principalmente C ++ / CLI) en dos versiones, una versión de 'usuario normal' y una versión 'pro'.

El hecho de que el código del núcleo es idéntico entre las dos versiones me ha causado un pequeño problema ya que quiero para empaquetar la herramienta resultante como un solo conjunto (DLL) y no quieren tener que incluir los archivos .cpp para el código común en los proyectos de las dos versiones de las herramientas. Yo prefiero tener un proyecto para el código común y un proyecto para cada versión de la herramienta y hacer que cada versión del proyecto de herramientas dependerá del código común y vincularlo en lo deseas.

En C ++ no administrado que me gustaría hacer esto colocando el código común en una biblioteca estática y la vinculación de las dos versiones de la herramienta a la misma. No parecen ser capaces de conseguir que esto funcione en C ++ / CLI. Parece que estoy obligado a construir el código común en un conjunto de DLL y que se traduce en más de DLL de lo que me gustaría.

Así, en resumen, no puedo encontrar la manera de construir el código común en un proyecto y vincularlo con cada uno de los proyectos de productos finales para producir dos conjuntos DLL individuales que ambos incluyen el código común.

Probablemente estoy haciendo algo mal pero tratado de encontrar la manera de hacer esto utilizando netmodules y lo que sea y no pude conseguir que funcione. Al final, la única manera que tengo trabajo era contar la enlazador para enlazar los productos de construcción del conjunto del código común en lugar de los resultados que funciona, pero es un poco de un truco en mi humilde opinión.

De todos modos, ¿alguien tiene alguna sugerencia de cómo debería ser la solución de este problema?

Editado: Creo que debería haber mencionado el hecho de que los conjuntos generados no son 100% código administrado, que contienen una mezcla de código administrado y no administrado como es, probablemente, bastante común con los conjuntos producidos con C ++ / CLI ...

Answer 1

Si usted está molesto por todas las DLL, descarga ILMerge . Lo utilizo para agrupar juntos múltiples DLL en un .EXE y fácil de usar para mis clientes.

Answer 2

Como dijo ILMerge es una manera, personalmente si su bundeling algunos exe con una gran cantidad de DLL estoy a favor Netz .

Answer 3

Se puede usar módulos . Puede vincularlos en un conjunto utilizando el enlazador montaje, al.exe.

Answer 4

Si yo estoy entendiendo esto correctamente, usted tiene una solución que contiene dos proyectos. Uno de los proyectos para el usuario "normal" y un proyecto para el usuario "pro". Visual Studio le permite añadir un "link" a otra fuente de archivo de otro proyecto. Si su versión "pro" tiene el archivo de código del núcleo real, y en su versión "normal" que añadir existente -> encontrar el archivo en el proyecto "pro" y haga clic en la flecha hacia abajo por el botón Agregar y seleccione "Agregar Enlace ". Ahora usted tiene una sola fila que es literalmente la misma entre dos proyectos.

Answer 5

Esa es la desventaja del proceso de compilación .Net, no se puede tener cosas como bibliotecas estáticas y los ficheros de cabecera que los mantienen unidos, todo se lleva a cabo en un solo archivo DLL grande y la única manera de compartir información es ya sea para construir un DLL común y referencia de otras asambleas o para duplicar el código en cada DLL (posiblemente mediante la copia / Cs vincular archivos entre proyectos).

Tenga en cuenta que la segunda forma declarará diferentes tipos, a pesar de que tienen el mismo nombre. Esto le muerde en el culo con cosas como comunicación remota (o cualquier cosa que requiere la fundición a interfaces específicas compartidas entre procesos).

Answer 6

Remotesoft Salamandra le liarte. Se trata básicamente de un compilador nativo y enlazador.

Answer 7

Cuando se utiliza mono (o cygwin es una opción) mkbundle también puede ser una opción válida.