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

01/06/2005 - 16:44 por Juande | Informe spam

Hola grupo,

Quiero desarrollar una aplicacion que vaya cargando módulos (librerías dll)
según las vaya necesitando, para ello he hecho una simple prueba con un
proyecto que contiene un formulario y que carga en tiempo de ejecución una
librería que contiene varios formularios, el código es el siguiente;

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

Hasta aquí todo bien, cargo la librería que necesito y creo una instancia a
un formulario existente en ella para luego mostrarlo, ahora viene lo que no
se hacer, dentro de las clases (formularios) de dicha librería existen
objetos como botones, grids... y funciones, ¿cómo puedo acceder a dichos
objetos desde la instancia creada 'Formulario' en el form principal?

Muchas gracias

Siga el debate

9 respuestas

Tengo una respuesta

Preguntas similare

Leer las respuestas

#6 Juande

02/06/2005 - 09:35 | Informe spam

Ok Eduardo, no sabía que el Framework cargaba en memoria un ensamblado
cuando usas alguna clase dentro de éste, gracias. Con esto, se me ocurre
otra pregunta, una vez que yo deje de utilizar esta clase, por ejemplo
cuando cierre un form, ¿seguirá el ensamblado en memoria?, ¿cuando se
libera?

Muchas gracias

"Eduardo A. Morcillo [MS MVP VB]" <emorcillo .AT. mvps.org> escribió en el
mensaje news:

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

Responder a este mensaje

#7 Juande

02/06/2005 - 09:36 | Informe spam

Gracias Tristan,

Nada de rollo, felicidades por tu explicación, me servirá de mucho.

Muchas gracias de nuevo

"Tristan" escribió en el mensaje
news:%

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#

Responder a este mensaje

#8 Eduardo A. Morcillo [MS MVP VB]

02/06/2005 - 16:00 | Informe spam

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é.

Entre otras cosas, supongo que porque VB6 las oculta bastante. En VB6
cualquier interface que este declarada como default en una coclass en una
type library automaticamente queda oculta en el object browser. Tampoco
puedes declararlas para usarlas en tu aplicacion. Cuando requieres una
interface tienes que crear una clase y VB6 te crea entonces una interface
para esa clase y al ser default te la oculta bajo el nombre de la clase. Y
ni hablar de como te oculta IUnknown e IDispatch. Si el programador no tiene
idea de como trabaja COM ni de que es una interface, con VB6 no lo va a
aprender. En cambio cualquiera que haya hecho cualquier cosa con Java (hasta
lo mas simple) sabe que es una interface.

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

Responder a este mensaje

#9 Tristan

02/06/2005 - 23:54 | Informe spam

Pues mucho me temo que no hay liberación posible. Un ensamblado permanece en
memoria hasta que se descargue todo el AppDomain. Tiene su explicación
técnica, pero vamos, no se puede. Pero ni con reflection ni sin reflection.
No se puede.

Lo único que se puede hacer si realmente es imprescindible, es utilizar
varios AppDomain en tu aplicación. Cuandono se necesiten, podrás descargar
todo el AppDomain. La dificultad es que los AppDomain, como su nombre
indica, son dominios independientes, sin posibilidad de comunicación entre
si. Para intercambiar información entre ellos tienes que utilizar remoting.
En fin, a no ser que sea imprescindible, no te recomiendo meterte en nada
parecido.

Juan Carlos Badiola
MVP - C#

Siga el debate Respuesta

Responder a este mensaje

Ads by Google

Hacer una pregunta

Tengo una respuesta

1 2

Busqueda sugerida