¿Por qué se produce una dll diferente después de una compilación limpia, sin cambios de código?

Question

Cuando hago una construcción limpia de mi proyecto C#, el dll producido es diferente al construido previamente (que guardé por separado). No se hicieron cambios en el código, solo limpiar y reconstruir.

Diff muestra que algunos bytes en la DLL tienen cambios, algunos cerca del final y pocos cerca del final, pero no puedo entender lo que representan. ¿Alguien tiene ideas sobre por qué está sucediendo esto y cómo prevenirlo?

Esto está utilizando Visual Studio 2005/WinForms.

Actualización: No se usa el incremento automático de la versión ni se firma el ensamblaje. Si se trata de una marca de tiempo de algún tipo, ¿cómo puedo evitar que VS lo escriba?

Actualización: Después de mirar en Ildasm/diff, parece que los siguientes puntos son diferentes:

• Dos bytes de cabecera PE en el inicio del archivo.
• <PrivateImplementationDetails> {GUID} sección
• parte críptica de la tabla de cadenas cerca del final (se pregunta por qué, no cambié las cuerdas)
• piezas de ensamblaje información al final del archivo.

Ni idea de cómo eliminar cualquiera de estos, si es posible ...

Answer 1

Mi mejor estimación sería que los bytes modificados que está viendo son las columnas de metadatos utilizados internamente que se generan automáticamente en tiempo de compilación.

Algunas de las columnas de ECMA-335 Partición II (CLI especificación de metadatos Definición) que pueden cambiar por-construcción, aunque el código fuente no cambia en absoluto:

• Module.Mvid: Una acumulación tiempo-generado GUID. Siempre cambia, cada construcción.
• AssemblyRef.HashValue: podría cambiar si está haciendo referencia a otro ensamblado que también se ha reconstruido desde la compilación anterior.

Si esto realmente, realmente le molesta, mi mejor consejo sobre cómo encontrar exactamente lo que está cambiando sería diff las tablas de metadatos reales. La manera de obtener estos es el uso de la ventana metainfo ildasm:

View > MetaInfo > Raw:Header,Schema,Rows // important, otherwise you get very basic info from the next step 

View > MetaInfo > Show! 

Answer 2

podría ser que los números de compilación o de revisión han cambiado.

Answer 3

Creo que sería el campo TimeDateStamp en el encabezado IMAGE_FILE_HEADER del PE32 specifications.