Se puede hacer lo siguiente (System.Reflection.Assembly)

Para esto no hace falta cargar el ensamblado con Reflection. Los ensamblados
que estan referenciados en el proyecto se cargan recien cuando se necesitan.
Si agregas el ensamblado como referencia en el proyecto y lo programas con
el normalmente (no a traves de Reflection) el ensamblado no se cargara sino
hasta que intentes usar alguna clase de ese ensamblado.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo

Bueno, estoy completamente de acuerdo con Eduardo. Si tus razones para hacer
eso son simplemente reducir la ocupación en memoria, no tiene sentido
cargarlos dinámicamente, puesto que eso mismo hace el framework.

Ahora bien, siempre hay razones para cargar en tiempo de ejecución un
ensamblado, por ejemplo un PlugIn.

En efeccto. si defines tu instancia como Form, no podrás acceder a los
elementos de tus clases específicas, no al menos sin utilizar reflection.

Para acceder a los elementos específicos hay varias formas.

1) Polimorfismo: Es la mejor forma con mucha diferencia, y debe utilizarse
siempre que sea posible

Crea una Interface. Esta incluiría la interfaz de acceso a todos tus
formularios. En todos ellos deberás implementar esta interface. La interface
deberá estar en un ensamblado separado, al que referencien tanto tus clases
dinámicas como el proyecto que las usa. El código quedaría así:

Dim Libreria As [Assembly]
Dim Formulario As ITuInterface
.
.
Libreria = System.Reflection.Assembly.LoadFrom("MiLibreria.dll")
Formulario = Libreria.CreateInstance("MiLibreria.Form1")
Formulario.Show()

También puedes hacer lo mismo mediante herencia. Defines una clase base
común a todas tus clases dinámicas. El proceso es el mismo que con
interfaces. Esta clase debe ir también en un ensamblado separado.


2) Late binding implícito: Lamentablemente es la forma a la que están
acostumbrados muchos de los programadores de versiones anteriores de VB.
Habrá que contarla :-(

Define Formulario como tipo Object. La clase Object admite en vb.net,
siempre que Strict esté desactivado, llamadas a miembros desconocidos en
tiempo de compilación, lo que se llama LateBinding.

Dim Libreria As [Assembly]
.
.
Libreria = System.Reflection.Assembly.LoadFrom("MiLibreria.dll")
Dim Formulario as Object = Libreria.CreateInstance("MiLibreria.Form1")
Formulario.Show()
Dim TextBox tb = Formulario.TextBox1
...

Puedes crear dos referencias que apunten a la misma instancia. Una de tipo
Object, y otra de tipo Form. Así podrás utilizar late binding solo cuando
sea imprescindible.


3) Late binding explícito; Reflection: Mediante reflection puedes acceder en
tiempo de ejecución a cualquier miembro necesario. Como ventaja frente al
anterior, que no requiere Strict Off. Como desventaja que es bastante más
complicado.

La razones por las que es preferible la primera son muchas: Control de
errores, ayuda de reflection, y una enorme diferencia en eficiencia.

Juan Carlos Badiola
MVP - C#

Por cierto, por si has aguantado todo el rollo :D

Donde digo:

La razones por las que es preferible la primera son muchas: Control de
errores, ayuda de reflection, y una enorme diferencia en eficiencia.

Quiero decir:

La razones por las que es preferible la primera son muchas: Control de
errores, ayuda de INTELLISENSE, y una enorme diferencia en eficiencia.

Juan Carlos Badiola
MVP - C#

2) Late binding implícito: Lamentablemente es la forma a la que están
acostumbrados muchos de los programadores de versiones anteriores de
VB. Habrá que contarla :-(

¿Era necesario contarlo? Mejor no decirlo y terminar con esa mala forma de
trabajo :)

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo

jejeje, pues si, en realidad si.

Pero no me gusta que alguno piense que las cosas son ahora más complicadas
de lo que lo son realmente. Se sigue pudiendo trabajar como antes. Otra cosa
es que yo lo recomiende :-)

Es curioso. Pese a que las versiones anteriores se basan en COM, y por lo
tanto en interfaces, muy pocos programadores las utilizan. No acabo de
entender por qué.

Juan Carlos Badiola
MVP - C#