"LNK2022: metadata operation failed" driving me insane

Microsoft replied to my Connect post, with a much better workaround:

It looks like the problem is caused by the mismatch in version between the two .objs. A better workaround is to replace

[assembly:AssemblyVersionAttribute("1.0.*")];

with

[assembly:AssemblyVersionAttribute("1.0.0.1")];

in AssemblyInfo.cpp. This will ensure that the version does not change between incremental builds.

This works for me and obviously this is preferable to disabling the feature.
Anyway the accepted answer has been chosen and cannot be changed now :(
Edit: I managed to unaccept my answer and mark Nick's answer as the accepted answer :)

Try this in xxx.cpp and xxx2.cpp:

#ifndef _PROTECT_MY_HEADER
#define _PROTECT_MY_HEADER
#include  "inc.h"
#endif

#pragma once isn't enough to protect the header in this case.

This problem is caused by the new Managed Incremental Build feature in Visual Studio 2008. As you spotted, the metadata did change, but not in a way that the managed incremental build feature considers signifcant. However, if you force a recompile of one of the cpp files, it grabs the new metadata, embeds it in the obj, and then the linker sees a conflict.

There are two ways to resolve this problem. A simple way that seems to work, from demoncodemonkey's answer below is to specify an explicit version number in the referenced assembly metadata to instruct the compiler that the referenced assembly is in fact at the same version:

Replace

[assembly:AssemblyVersionAttribute("1.0.*")];

with

[assembly:AssemblyVersionAttribute("1.0.0.1")];

in AssemblyInfo.cpp. This will ensure that the version does not change between incremental builds.

The alternative way to avoid this problem is by disabling the feature. We may recompile some cpp files unnecessarily, but it's better than having the linker fail.

In the project properties, under Configuration Properties > General, set "Enable Managed Incremental Build" to No.