Advice on assembly version conflicts

I have a situation that's really starting to annoy me and I'm looking
for some advice on the best way to resolve it. I have a few .NET
assemblies that are commonly referenced in most of my projects
(assemblies of common library classes). However, since they are so
commonly-used, they also tend to form the building blocks of other
assemblies that get reused, and I'm starting to see some problems that
seem to relate to version conflicts.

For example, in a recent project (let's call it assembly "C"), I have
references to assemblies "A" and "B." Assembly "B" also references
assembly "A." Now, if I modify assembly "A" and compile my project
"C," it will see the updated assembly "A" but since assembly "B" was
previously compiled against the old version of "A" I get a compilation
error that my assembly "A" must be strongly-typed.

BTW I'm not currently signing any of my assemblies, so the error
message isn't due to the current project being strongly-typed, thus
requiring any referenced assemblies to be strongly-typed. It appears
to be related to the fact that the assembly "B" is expecting a
different version of assembly "A" than what's been compiled into the
bin directory by compiling project "C." At least when I go back and
to project "B," remove and re-add the reference to assembly "A,"
recompile "B," and then go back to "C" and remove and re-add the
references there and recompile, the problem goes away.

And as more developers get involved in these projects, I only see the
problem getting worse.

I'm currently using an AssemblyVersion like "1.0.*" to auto-increment
the last two parts of the build number. I wanted to do that to help
automate the build number versioning for bug-fixes and minor
revisions, saving larger revisions to a manual renumbering of the
major/minor version components. However, this policy is also
responsible for the problem I'm currently experiencing! If I go back
to manually specifying the full version number, I'm afraid that people
will forget to increment version numbers properly, and even with
manually incrementing version numbers, I'll have this problem whenever
an assembly version changes (which at the moment is happening fairly
frequently as some new features are being added to the shared
components).

What are some of the techniques that others out there have employed to
help resolve this problem? Ideally, I'd like to be able to tell my
apps to accept ANY version of their dependent referenced assemblies
that match a certain pattern (say "1.0.*") instead of having to match
the exact versions that were referenced when the assembly was
compiled. I can see the referenced assembly versions in the manifest
file, but can I modify that version to do this, and if so how do I do
this since the manifest is being created when I compile (I don't see a
corresponding .manifest file in my project folder with the source
code)?

My other thought was that I might want to start putting these shared
assemblies in the GAC since then each component could reference the
version of the assembly that it was compiled against, but that raises
a other questions. I'm currently sharing these assemblies among
developers through a shared network folder (the Release builds of each
assembly copy the .dll to that share to keep it updated). If I use
the GAC, what's the best way to keep all the developers in synch with
the latest versions of each assembly? What NEW issues might I
encounter if I start using the GAC instead of using "Local Copy" for
each referenced assembly in a project?

Thanks!

Keven