> 各アプリケーションのプロジェクトにコピーして使いまわしていましたが
コピーせず、1つの *.vb ファイルを複数のプロジェクトで共有することもできますよ。
既存の*.vb をプロジェクトに追加する際、ダイアログの追加ボタン横の▼から
「リンクとして追加」を選ぶという手法です。


> 他のアプリケーションの共通クラスを修正し忘れることがあり
それはソース管理／リリース管理上の問題であって)、
設計手法とは別の問題のようにも思えます。


> 名前空間の先頭がアプリケーションで変わってしまうため
C# とは違って、VB はプロジェクトごとに名前空間を設定できてしまいますからね…。


> プロジェクト参照することで対応可能と思いますが
プロジェクト参照を使った場合、ソリューションが大きくなるにつれ、ビルドしにくくなります。
(コンパイルに時間がかかる、ビルド時のメモリ消費量が跳ね上がるなど)

一方、DLL をバイナリ参照した場合は、EXE コンパイル時のリソース消費は減りますが、
DLL を更新した結果を反映させるための手間が生じるため、開発段階の初期では
使いにくい場合もありますね。


> どのようにクラスを管理すればよいか、わけが分からなくなってしまいました。
アセンブリ バージョンの参照に関する問題であれば、このあたり。
http://www.atmarkit.co.jp/fdotnet/technology/idnfw11_04/idnfw11_04_01.html


> ２．アプリケーション１はライブラリAを参照しています。
> ３．アプリケーション２はライブラリA・Bを参照しています。
> ４．ライブラリBはライブラリAを参照しています。

これはよくあるパターンですね。たとえば、.NET Framework 自体のライブラリでいえば

４．System.Windows.Forms.DLL は内部で Accessibility.DLL を参照しています。
３．WindowsApplication1.exe は前者を参照していますが、後者は参照していません。
２．WindowsApplication2.exe は前者も後者も参照しています。

のようなケースです。

Public Class Form1

    Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load

        Dim a As Object = Me.AccessibilityObject

    End Sub

End Class

上記のようなコードを書いた場合、AccessibilityObject プロパティの下に波線が
表示され、コンパイルエラーとなります。その波線部には、Accessibility.DLL を
参照設定するようにとの修正候補が記載されており、Accessibility.DLL を
追加で参照することで、エラーが解消されます。


> ライブラリの内容をアプリケーションのexeの中に含めたいのですが
DLL にしたうえで、それを埋め込む方法でも良ければ。
http://research.microsoft.com/en-us/people/mbarnett/ILMerge.aspx
http://www.atmarkit.co.jp/fdotnet/dotnettips/426ilmerge/ilmerge.html