Based on your description I've come up with the following.  First, each
of the external classes is actually in their own individual assembly
file (e.g. DLL).  Second, what you want to do is somehow wrap all of
these individual assembly files up into a single distributable DLL file
that can be accessed by consuming applications without having to
distribute each of the smaller files individually.  If that is the case
I don't believe you can do this in VB.Net.  If this is not the case you
need not read any further because I'm about to explain something you
aren't asking about.

When you reference an external assembly you get just that, a reference
to it; you do not get it's code wrapped up into your own assembly. This
is true whether the external assembly is yours or a third party.  What
sometimes gets confusing here is that you see that you can reference
Microsoft assemblies (like System.Data) and don't have to distribute
them to get the application to work, this is because they have been
installed in the Global Assembly Cache (GAC) of every .Net installed
machine; what you don't see is that the real DLL for these referenced
assemblies are on the machine, they are just in the GAC install
location.  You could do this same thing with your assemblies but it
would mean a whole lot more work (check MSDN about strong named
components and the GAC).

What you basically get stuck with is creating a facade (it's a design
pattern) assembly that consumers can reference to have a single location
to call for functionality without having to know the details of all the
"rolled up" classes and assemblies.  However you still need to deliver
all the assemblies (your "rolled up" one and the ones that were "rolled
up" to the consumers of the application.

Have A Better One!

John M Deal, MCP
Necessity Software

check this (http://www.remotesoft.com/linker/) maybe is the solution.