Compartir Libreria

Hola Rogelio,

las librerías, salvo que cometa algún error, deben de estar en la máquina en
la cuál se desarrolla o en la cuál se ejecuta la aplicación.

El uso de Web Services, permite solventar de alguna manera esto que
comentas, pero para añadir una referencia a una librería y trabajar con todos
sus métodos, propiedades, etc., debería de estar en local.

Espero no haberme equivocado.

Un saludo,

Jorge Serrano Pérez
MVP VB.NET


"Rogelio Chacon R." wrote:

Hola a todos.

Espero que me puedan ayudar, alguno de ustedes sabe como hacer para
compartir librerias o hacer referencia a librerias de otra maquina.

Digamos tengo un cliente este cliente hace referencia a las librerias que se
encuentran fisicamente en otra maquina. Se puede? que no sea con el IIS.

Ok

Gracias Jorge.

"Jorge Serrano [MVP VB]" escribió:

Hola Rogelio,

las librerías, salvo que cometa algún error, deben de estar en la máquina en
la cuál se desarrolla o en la cuál se ejecuta la aplicación.

El uso de Web Services, permite solventar de alguna manera esto que
comentas, pero para añadir una referencia a una librería y trabajar con todos
sus métodos, propiedades, etc., debería de estar en local.

Espero no haberme equivocado.

Un saludo,

Jorge Serrano Pérez
MVP VB.NET


"Rogelio Chacon R." wrote:

> Hola a todos.
>
> Espero que me puedan ayudar, alguno de ustedes sabe como hacer para
> compartir librerias o hacer referencia a librerias de otra maquina.
>
> Digamos tengo un cliente este cliente hace referencia a las librerias que se
> encuentran fisicamente en otra maquina. Se puede? que no sea con el IIS.

las librerías, salvo que cometa algún error, deben de estar en la
máquina en la cuál se desarrolla o en la cuál se ejecuta la
aplicación.

Se puede usar el app.config para especificar la ubicacion de un ensamblado
que no este en la maquina usando el elemento CODEBASE.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
https://mvp.support.microsoft.com/p...4EF5A4191C

Gracias Eduardo,

es que tenía dudas y no estaba seguro de responder correctamente la duda,
porque creía recordar que había un método para hacerlo.

De todos los modos, ¿esa forma de trabajar sería óptima?.
Me explico:
En tiempo de desarrollo y ejecución, el hecho de añadir ensamblados en otra
máquina, supone que la aplicación cada vez que se ejecute o utilice el
ensamblado, vaya a la máquina en la que está el ensamblado, valide que es el
ensamblado que espera, lo recoja y lo cargue en memoria para poder ejecutar
la aplicación..., entiendo que esto consume más recursos y tiempo que si
estuviera el ensamblado en local, aunque por otro lado, se evita el riesgo de
usar diferentes versiones del ensamblado, y en caso de error veo que la forma
de solucionar un determinado error podría llevar algún quebradero de cabeza.

Vamos, que es una solución, pero no se si es que es muy pronto por la mañana
(casi las 8 ahora mismo) o es que no lo termino de ver del todo claro... ¿que
inconvenientes y ventajas ves a todo esto?.

Un abrazo, :-)

Jorge Serrano Pérez
MVP VB.NET


"Eduardo A. Morcillo [MS MVP VB]" wrote:

> las librerías, salvo que cometa algún error, deben de estar en la
> máquina en la cuál se desarrolla o en la cuál se ejecuta la
> aplicación.

Se puede usar el app.config para especificar la ubicacion de un ensamblado
que no este en la maquina usando el elemento CODEBASE.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
https://mvp.support.microsoft.com/p...4EF5A4191C

De todos los modos, ¿esa forma de trabajar sería óptima?.

Seguramente que no. Pero como con todas las cosas hay que analizar si la
ventaja sobre tenerlo en otra maquina (puedes actualizarlo sin necesidad de
instalarlo en todos los clientes) conviene sobre la copia a cada cliente (y
la carga de red) cuando los clientes usan la aplicacion.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
https://mvp.support.microsoft.com/p...4EF5A4191C