Por que al ejecutar un EXE hecho en VB .Net me pide registro un co

Los componentes COM siguen requiriendo el mismo registro que era necesario
en VB 6.0. La dll que crea VS cuando añades una referencia al componente COM
no es más que un wrapper que hace de intermediario entre el mundo .NET y el
mundo COM. Los archivos que forman el componente COM deben instalarse
también en la máquina del usuario y registrarse con COM además de cualquier
otro tipo de registro que requiera el fabricante en cuanto a licencias se
refiere.

Saludos:

Jesús López



"Ernesto Lara" <Ernesto escribió en el
mensaje news:

Mi problema es el siguiente:

En la empresa compramos un componente el cual contiene una clase que
utilizamos para nuestras aplicaciones en VB6 ahora en VB .Net la volví a
utilizar agregándola como referencia COM y funciona excelente. El problema
viene cuando ejecuto la aplicación en la computadora de un usuario que no
sea
desarrollador ya que aparece la pantalla de licenciamiento del
componente(esta pantalla es la que aparece al utilizar el componente y no
tener licencia), obviamente nosotros tenemos registrado el componente con
las
licencias que adquirimos, en cambio el usuario ejecuta un EXE que se
supone
contiene esta misma clase creada en una carpeta como un archivo Dll por el
.Net. En VB6 no sucedía esto creo yo por el hecho de que el usuario corría
un
EXE el cual era instalado con un package que contenía dicho componente. Mi
pregunta es ¿hay forma de que no me aparezca esa pantalla en mis
aplicaciones
cuando use este componente? o ¿hay alguna forma de indicarle al programa
que
registre dicho componente?

Jesús actualmente existen aplicaciones en las maquinas de los usuario que
están usando esa clase y tienen instalado un Package con dicha clase, por que
con las aplicaciones de VB6 no me pide ese registro y con VB .Net si? no se
supone que ya esta registrado en la maquina del desarrollador y al crear el
EXE el componente va liberado? por que no pasa lo mismo con .Net? por que no
creo que sea correcto instalarle el componente a 100 usuarios ya que
necesitaría 100 licencias del mismo siendo que ellos no desarrollan
simplemente usan nuestras aplicaciones. Aun sigo confundido con si pudieras
explicarme un poco mas te lo agradecería :)

Saludos
"Jesús López" escribió:

Los componentes COM siguen requiriendo el mismo registro que era necesario
en VB 6.0. La dll que crea VS cuando añades una referencia al componente COM
no es más que un wrapper que hace de intermediario entre el mundo .NET y el
mundo COM. Los archivos que forman el componente COM deben instalarse
también en la máquina del usuario y registrarse con COM además de cualquier
otro tipo de registro que requiera el fabricante en cuanto a licencias se
refiere.

Saludos:

Jesús López

"Ernesto Lara" escribió en el
mensaje news:

Jesús actualmente existen aplicaciones en las maquinas de los usuario que
están usando esa clase y tienen instalado un Package con dicha clase, por
que
con las aplicaciones de VB6 no me pide ese registro y con VB .Net si? no
se
supone que ya esta registrado en la maquina del desarrollador y al crear
el
EXE el componente va liberado? por que no pasa lo mismo con .Net? por que
no
creo que sea correcto instalarle el componente a 100 usuarios ya que
necesitaría 100 licencias del mismo siendo que ellos no desarrollan
simplemente usan nuestras aplicaciones. Aun sigo confundido con si
pudieras
explicarme un poco mas te lo agradecería :)

Hola.

Imagino que la manera en que .Net instancia los componentes visuales (OCX)
COM es diferente de la manera en que los instancia VB6. Se me ocurre que el
runtime de VB6 es capaz de informarle al componente COM (mediante el mismo
envoltorio que crea VB6, a una parte del cual accedes mediante la propiedad
Ambient del control) si está en modo de diseño o en modo de ejecución. Si
.NET no lo provee, o bien si provee su versión más amplia, el componente
"cree" que está en modo de diseño y emite el mensaje. Para los controles de
Windows Forms no hay diferencia entre modo de diseño y modo de ejecución.

No creo que sea necesario adquirir licencias adicionales para cada estación
de trabajo, pero sería buena idea consultar con el fabricante. Igual la
licencia se restringe a aplicaciones desarrolladas con VB6, o tal vez exista
una versión .NET de ese mismo componente - que seguramente te romperá todo
el código :-)

En cualquier caso, lo que restringen los acuerdos de licencia es el uso del
componente en aplicaciones desarrolladas por terceros: mientras tus usuarios
no incorporen ese componente en sus propias aplicaciones, puedes hacer todo
lo que sea necesario para que tus aplicaciones corran debidamente, incluso
registrar la licencia del OCX.

Instalar el paquete de desarrollo en un equipo limpio, monitoreando los
cambios con RegistryMonitor y FileMonitor, ambos de SysInternals, puede
darte una idea de lo que debes hacer.

Salud!