Tengo una gran solución con muchos proyectos, usando VS2008 SP1, y al menos una vez al día me encuentro con el error LNK2022. Si realizo una reconstrucción completa de la solución, funciona bien, pero esto no es divertido.

Ocurre cuando una DLL dependiente se cambia 'insignificantemente' (es decir, sin cambiar ningún método o clase), y el proyecto de referencia se construye más tarde. Falla al fusionar los metadatos, sea lo que sea que eso signifique.

a primera cosa a tener en cuenta es que la DLL compartida está referenciada con#using de múltiples archivos .CPP.
o segundo es que si elimino el AssemblyInfo.cpp de la DLL compartida, el problema desaparece (pero soy ¿No está seguro si esta es una solución sensata?).

Lo he reducido lo más posible en la siguientesolució que contiene 2 proyectos de CLR Class Library (el xxx proyecto depende deCompartid):

Aquí están los contenidos de cada archivo:

Shared.cpp:

public ref class Shared
{
};

pulgada

#pragma once
#using "Shared.dll"
public ref class Common
{
private:
    Shared^ m_fred;
};

xxx.cpp y xxx2.cpp:

#include "inc.h"

Para reproducir, primero reconstruya la solución. Construirá OK.
Ahora guardar Shared.cpp y compile la solución, se compilará bien y mostrará:

...
2>------ Build started: Project: xxx, Configuration: Debug Win32 ------
2>Inspecting 'd:\xxx\xxx\Debug\Shared.dll' changes ...
2>No significant changes found in 'd:\xxx\xxx\Debug\Shared.dll'.
2>xxx - 0 error(s), 0 warning(s)
========== Build: 2 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Ahora guardar xxx.cpp y compila la solución, falla con el siguiente mensaje:

1>------ Build started: Project: xxx, Configuration: Debug Win32 ------
1>Compiling...
1>xxx.cpp
1>Linking...
1>xxx2.obj : error LNK2022: metadata operation failed (80131188) : Inconsistent field declarations in duplicated types (types: Common; fields: m_fred): (0x04000001).
1>LINK : fatal error LNK1255: link failed because of metadata errors
1>xxx - 2 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========

EDITA:
Las diferencias entre el IL para xxx.obj y xxx2.obj son las siguientes:

(para xxx.obj)
// AssemblyRef # 2 (23000002)
// ----------------------------------------------- --------
// Token: 0x23000002
// Clave pública o token:
// Nombre: Compartido
// Versión: 1.0.3412.16 606
// Versión principal: 0x00000001
// Versión menor: 0x00000000
// Número de compilación: 0x00000d54
// Número de revisión: 0x000040Delawar
// Configuración regional:
// HashValue Blob: 1c bb 8f 13 7e ba 0a c7 26 c6 fc cb f9 ed 71 bf 5d ab b0 c0
// Banderas: [ninguna] (00000000)

(para xxx2.obj)
// AssemblyRef # 2 (23000002)
// ----------------------------------------------- --------
// Token: 0x23000002
// Clave pública o token:
// Nombre: Compartido
// Versión: 1.0.3412.16 585
// Versión principal: 0x00000001
// Versión menor: 0x00000000
// Número de compilación: 0x00000d54
// Número de revisión: 0x000040 c9
// Configuración regional:
// HashValue Blob: 64 af d3 12 9d e3 f6 2b 59 ac ff e5 3b 38 f8 fc 6d f4 d8 b5
// Banderas: [ninguna] (00000000)

Esto implica para mí que xxx2.obj todavía está utilizando la versión anterior de Shared.dll, y que está en conflicto con xxx.obj que está utilizando el Shared.dll actualizado. Entonces, ¿cómo puedo solucionar eso?