2008-12-29 12 views

Respuesta

5

¿Por qué quieres hacer esto? Si es para que otra aplicación pueda usarlo, es posible que desee examinar assembly binding redirection.

+4

Para el despliegue, actualizamos los archivos AssemblyInfo y hacer una reconstrucción completa, pero que se está haciendo demasiado pesada, por lo que nos estamos moviendo a una acumulación gradual. El problema es determinar qué AssemblyInfo actualizar así que ahora no estamos actualizando la versión en los incrementales. – Mike

+0

Por lo tanto, la posible solución actual que estoy buscando es actualizar la Versión de archivo de ensamblaje posterior a la compilación para que todos sepan qué compilación del código que está viendo. – Mike

+0

¿Desea utilizar una compilación incremental para * deployment *? Yikes. ¿Cuánto tiempo tarda su construcción y con qué frecuencia se despliega? Personalmente, no me sentiría cómodo con eso, querría una versión completa (y prueba) limpia para la implementación. Mucho más fácil de reproducir de esa manera. –

1

Parece que su proceso es pesado porque hay que actualizar varios archivos AssemblyInfo. ¿Has considerado compartir el mismo archivo de AssemblyInfo entre proyectos? Derik Whittaker da un buen ejemplo de cómo hacer esto.

Una vez que tenga un solo archivo, podría recorrer la distancia adicional haciendo que un proceso de compilación actualice su única versión de AssemblyInfo utilizando MSBuild o NAnt.

35

Puede utilizar ILMerge:

ILMerge.exe Foo.dll /ver:1.2.3.4 /out:Foo2.dll

una razón válida para hacerlo es incrementar la versión de montaje en una estructura en que encuentre cambios de ruptura (utilizando NDepend por ejemplo). De esta forma, si no hay cambios de última hora, la versión de ensamblaje se mantiene igual y puede aplicar parches a las versiones publicadas fácilmente.

Siempre incrementamos la versión del archivo, y eso refleja el número de compilación.

+1

¿A menos que el conjunto sea wpf o silverlight? –

+0

Otro posible escenario que tengo en mente es que construya una versión alfa y desee elevarla a versión beta, liberar candidata y luego liberarla sin una reconstrucción completa. Si la compilación y la prueba toman un poco de tiempo (20 minutos), esto ahorraría mucho tiempo en las distintas etapas y garantizaría que los archivos binarios que haya probado sean los que envíe. – jpmc26

+0

Solo necesité esto para la depuración. Tenía un dll de recursos que no coincidía con el dll correspondiente. – dudeNumber4

1

Si tiene pruebas y fuente de control formal, el proceso se vuelve bastante sencillo. Comienza con una comprensión de quién puede cambiar los diferentes segmentos de números de la versión y cuándo. Los ensamblados .net tienen 4 segmentos de número (es decir, 1.0.0.1).

El primer segmento contiene el número de versión principal. Esto es establecido por la gerencia superior e indica un cambio importante en la interfaz de usuario o en la plataforma de la aplicación. Este siempre debe ser el mismo número entre la versión del ensamblaje y la versión del archivo.

El segundo segmento contiene el número de versión secundaria, también conocido como el número de función de salida. Esto es establecido por Project Management e indica que se han agregado nuevas características a la aplicación. Este siempre debe ser el mismo número entre la versión del ensamblaje y la versión del archivo.

El tercer segmento contiene el número de compilación. Esto lo establece el grupo de prueba e indica que la aplicación está lista para implementarse. Se cambia antes de que se publiquen las correcciones de errores. Al lanzar una nueva compilación, la prueba restablece el cuarto segmento a 0. Este puede ser el mismo número entre la versión de ensamblaje y la versión de archivo, pero generalmente se deja en 0 para la versión de ensamblado para simplificar el parcheo de las implementaciones existentes.

El cuarto segmento contiene el número de revisión. Esto establecido por el grupo de desarrollo cada vez que comprueban el nuevo código en el control de fuente. Este número se incluiría en la versión del archivo de la DLL compilada, pero no en la versión del ensamblado.

he encontrado que esto ayuda a los desplegados, los probadores y desarrolladores un seguimiento de las últimas versiones sin pisar los demás dedos de los pies. Desafortunadamente, también trabajé con compañías que usaban un sistema de control de versiones estático para que nadie supiera cuál era el mejor ensamblaje.

1

VerPatch, como se indica en este answer, es simple y eficaz.

+2

Cambia la versión de Win32, no la versión de ensamblaje de .net. – deerchao

5

viejo tema, pero aquí están mis 5 monedas de diez centavos ...

  1. Desmontar

    ildasm my.exe /output:my.il /metadata

  2. Editar my.il para cambiar la información de versión. Hay varios lugares para buscar en:

    • mayor: menor: la revisión: construcción - por lo general una ocurrencia
    • major.minor.revision.build - varias ocurrencias. La cadena se encuentra en la sección de comentarios después de la línea real. La versión es un valor hexadecimal en una matriz de bytes. Ejemplo:

.custom instance void [mscorlib]System.Reflection.AssemblyFileVersionAttribute::.ctor(string) = (01 00 07 35 2E 31 2E 33 2E 30 00 00) // ...5.1.3.0..

  1. Editar my.res para cambiar la información de versión. Haz doble clic y edítalo con Visual Studio. Procedimiento bastante sencillo.

  2. Ensamble

    ilasm my.il /res:my.res

+1

Aunque ILMerge, como se menciona en la respuesta más votada en la actualidad, no funcionó para mí, ¡sí! ¡Gracias! :-) – Christian

+0

No funciona para archivos DLL.El error que obtengo en el paso 4 es Crear archivo PE Error: No se ha declarado ningún punto de entrada para el archivo ejecutable No se pudo crear el archivo de salida, código de error = 0x80004005 ***** FALLO ***** –

+0

Solo necesito agregar a/dll enciende el paso 4. ilasm my.il /res:my.res/dll –

Cuestiones relacionadas