I have a solution with many projects, of which several have COM
references to a third-party DLL.  At initialization, our application
performs reflection searches through the assemblies in its start
directory to discover its functionality.  In other words, most of the
projects know very little about each other.

A few of these projects -- mostly C#, but some managed C++ -- depend on
the same COM server, and the generated interop assembly causes
occasional trouble.

After a build, we run a postbuild step that searches for *.dll and
*.exe and for each hit, if its modification time is more recent than
that of the file by the same name in the staging area, we update the
staging area accordingly.

This heuristic works fine in from-scratch builds, but if we modify one
of the projects that talk to the (in-process) COM server, perform an
incremental build, and then run the postbuild again, we get a
TypeLoadException from any method that tries to instantiate the
coclass.

As I wrote above, the underlying DLL is from a third party and does not
change.  The MVID changes of course, but no other changes are obvious
when examining with ildasm.  Looking at hex dumps shows some pretty
extensive differences, but they must only be shuffling because all the
copies of the interop assembly have the same length.

We can work around the issue by going back and copying the interop
assembly from the build directory of the project we updated, but it'd
be nice to be able to either fix whatever the underlying problem is or
at least be able to automate the workaround.

Why is the most-recent-wins heuristic inadequate?  Note that when our
postbuild copies a file to the staging area, it updates the
modification time to mirror that of its source's so files other than
the first one found have a shot at making it.

What significant differences (i.e., other than commentary metadata) are
there between interop assemblies generated for different projects but
for the identical underlying DLL?  Why aren't they interchangeable?

Thanks for any help,
Greg