Curso Generador .

NET - 2 capas
Versión 8.0
Agosto 2005

www.genexus.com/training

INTRODUCCIÓN

En este capítulo daremos una orientación básica sobre el curso y su

funcionamiento.

Incluye información acerca de la estructura del curso, cómo navegar a través del
mismo, cómo comunicarse con un instructor y cómo obtener información de
interés para su correcto desarrollo.

Metas y objetivos
En este curso se presentan todos los conceptos teóricos necesarios para la
configuración y puesta a punto de aplicaciones GeneXus .NET. (tanto GUI como
WEB) en 2 capas. El curso incluye conceptos básicos de .NET, manejo del
generador, y una aplicación de ejemplo que muestra paso a paso (con explicaciones
y videos) como ir poniendo en práctica todos los conceptos.

Cada módulo del curso está dividido en capítulos, cada uno de los cuáles tiene una
introducción que establece los temas que serán abordados dentro del mismo. Para
facilitar el aprendizaje, los conceptos teóricos van acompañados de ejemplos
prácticos y de videos demostrativos, que complementan lo explicado, de manera
tal que el alumno pueda obtener una profunda comprensión de los temas
tratados.

A medida que se avanza en los capítulos se va desarrollando una aplicación que

pone en práctica los conceptos más importantes que se van estudiando y que
permite que el alumno pueda comenzar a interactuar con la herramienta
reproduciendo lo realizado en los videos primeramente, y luego realizando los
ejercicios prácticos propuestos.

Cualquier sugerencia que desee realizar, con gusto la recibiremos en la siguiente

dirección de correo electrónico training@genexus.com.

Prerrequisitos
Tener aprobado el curso de GeneXus o conocimientos sólidos de GeneXus.

En caso de que el objetivo del alumno sea desarrollar aplicaciones web con el
generador .NET, recomendamos realizar el curso no presencial "Desarrollo de
aplicaciones para Internet con GeneXus".

Requerimientos computacionales
Debe contar con GeneXus versión 8.0 o superior. Recomendamos utilizar los
últimos Upgrades.

Ponemos a su disposición una versión de prueba de GeneXus que podrá bajar

(http://www.genexus.com/trialversion) e instalar en su computadora para poder
desarrollar el curso satisfactoriamente. La misma incluye el generador .NET
necesario para este curso.

En el manual de instalación de GeneXus 8.0 encontrará los requerimientos de

hardware y software para generar en todas las plataformas soportadas por
GeneXus. El manual de instalación se encuentra disponible para ser bajado de
nuestro Download Center.

A medida que en el curso presentemos el software necesario para generar

aplicaciones .NET, se verá información sobre donde obtenerlo.
Para poder ver los videos incluidos en el curso, necesitará contar con algún
reproductor de archivos multimedia. El video debe reproducirse con el mismo
tamaño del original (size 100%) para obtener el mayor nivel de nitidez. Asimismo,
antes de reproducir la primera de las demos, deberá haber ejecutado en su
máquina el archivo TSCC.EXE que viene junto con el curso.

En el documento FAQ: Problemas con la reproducción de los videos tiene la

solución a algunos de los problemas que se le podrían presentar al intentar
reproducir los videos incluidos en el curso. Allí se indica también de dónde se
pueden bajar reproductores en forma gratuita.

Para ver los videos correctamente debe tener una resolución de pantalla no
inferior a 800x600, recomendándose 1024x768 o superior.

Comunicación con un docente y examen final

Eventualmente ud. necesitará consultar a un docente por dudas del curso. También puede estar interesado
en rendir un examen final, y en caso de aprobación certificar que completó este curso en modalidad no
presencial. Por esta información, diríjase a nuestro sitio de capacitación a distancia o a
training@genexus.com.

Cómo utilizar este curso

Este material tiene por objetivo ser utilizado tanto en una etapa de aprendizaje
como en una etapa de consulta posterior, a modo de libro de referencia. Para
ello, establecimos una simbología que incluimos en los documentos para orientar
visualmente al lector discriminando qué partes de la documentación pueden
excluirse en una primera lectura, qué partes son de fundamental importancia y
deben convocar toda su atención, etc. Asimismo establecimos una simbología
análoga a nivel del índice (árbol) del curso. En las tablas de más abajo listamos
estos símbolos y sus significados.

Este curso está pensado para ser seguido fundamentalmente de manera

secuencial. Algunas veces se podrán producir desviaciones a ese orden, tanto por
decisión del lector, como por alguna sugerencia explícita. Normalmente se
comienza con la introducción de un capítulo, y luego se pasa a leer el documento
que le sigue en orden dentro del índice. Sin embargo, algunos documentos o
secciones de los mismos estarán marcados con el símbolo . Esto denotará que
puede omitirse todo lo que se encuentre en esa sección en una primera lectura.
Generalmente se trata de puntos más avanzados, o de información más
específica, que no necesita ser digerida en una primera aproximación al tema.
Algunas veces se trata de información que se incorpora a los efectos de tener la
documentación completa, y se puede estudiar en alguna consulta posterior sobre
ese tema, no siendo vital para continuar con el desarrollo normal del curso.

A lo largo del curso se desarrollará una aplicación de ejemplo, como se explica en

el documento siguiente. Por ello algunos de los documentos que aparecen dentro
de un capítulo están identificados en el índice con el símbolo , que indica que se
trata de un documento práctico donde aparecerán videos demostrativos, así como
ejercicios para que realice el alumno. Generalmente ud. verá el video una vez, y
luego repetirá lo que allí vio. De todos modos, también puede pausar, volver hacia
atrás y reproducir un video a conveniencia a medida que va realizando la práctica
usted mismo.

Si bien los documentos están ordenados de modo de ser leídos secuencialmente

pueden, no obstante, contener links que los relacionen con otros documentos de
otras partes que están más adelante o más atrás en el curso. Los links “hacia
delante” se aconsejan seguir solo cuando se está haciendo una “referencia
posterior”, es decir, cuando ya se ha dado una primera lectura a todo, y se está
consultando un tema específico. Los que son “hacia atrás” sí pueden utilizarse en
la primera lectura, pues posibilitan refrescar o recordar temas, conceptos, ideas,
etc. vistos recientemente y aún no suficientemente afianzados.

Las siguientes tablas dan el significado de los símbolos que aparecerán a lo largo
del curso.

Tabla de símbolos de los documentos

Símbolo Significado

Denota que puede omitirse todo lo que se encuentre en esa sección

en una primera lectura. Generalmente se trata de puntos más
avanzados, que no necesitan ser entendidos en una primera
aproximación al tema. Si el símbolo se encuentra al principio del
documento, aplica a todo el documento. Si aparece delimitado por
líneas, aplica solo al texto delimitado.

Denota que lo que se encuentra en esa sección es de fundamental

importancia y debe prestarse especial atención a lo que allí se dice.
Generalmente se trata de conceptos de gran relevancia. Si el
símbolo se encuentra al principio del documento, aplica a todo el
 documento. Si por el contrario aparece delimitado por líneas, aplica
solo a lo delimitado.

Denota que en ese punto ud. debe implementar en su aplicación en

GeneXus lo que se explicita. Aparecerá únicamente en documentos
prácticos: aquellos que contienen demos.

Es una referencia a un pie de página. Se incorpora en la mitad de un

texto para establecer un link a dicho pie de página.

Representa una nota en alguna parte del documento.

Tabla de símbolos del índice (árbol) del curso

Símbolo Significado

Representa un capítulo o subcapítulo.

Representa un capítulo de fundamental importancia.

Representa un documento normal del curso.

Representa un documento de fundamental importancia. Equivale al

símbolo a nivel de documento.

Representa un documento que contiene conceptos avanzados o

detalles sobre el tema que se está tratando y que puede ser salteado
en una primera lectura. Equivale al símbolo a nivel de documento.

Representa un documento práctico, que contiene alguna demo donde

se va desarrollando la aplicación de ejemplo.

Sugerimos tener GeneXus abierto mientras se está siguiendo el curso, a fin de ver
los elementos que se van mencionando e ir probando en la aplicación de ejemplo.
Algunos links de interés
Con el objetivo de brindar a los desarrolladores una fuente única de información
potenciada con una “ingeniería de búsqueda” que les permita acceder rápida y
fácilmente a la información técnica sobre los diferentes productos que desarrolla
ARTech, se creó GXDL: GeneXus Developer Library, una biblioteca que centraliza
toda esta información técnica.

Puede ser consultada online (http://www.gxtechnical.com/gxdl) o puede ser

utilizada –y actualizada- en forma local mediante una sencilla instalación.

Podrá crearse un usuario en nuestro sitio web para desarrolladores

(http://www.gxtechnical.com), y bajar del Download Center diversos materiales
según los permisos de su usuario. En el Download Center encontrará productos,
cursos, ejemplos, manuales, release notes, utilitarios y technical papers.

Puede encontrar links e información útil sobre el generador el generador .NET en

www.gxtechnical.com/net.

Problemas con la reproducción de los videos

Los videos son archivos AVI. Debe configurar su máquina para que los abra
siempre con el reproductor que quiera utilizar.

¿Por qué los videos no se ven?

Los videos que se utilizan en este curso son producidos utilizando un codificador,
TSCC, que permite comprimir los archivos sin degradar la calidad de la imagen.
Este codificador debe estar instalado en toda máquina en la que se vayan a
visualizar los videos.

El archivo TSCC.EXE que incluimos junto con el curso, debe ser ejecutado en su
sistema de manera de instalar el codificador TSCC en su máquina. Esta acción
solo debe realizarse una vez.

Para Windows NT/2000/XP los usuarios deben tener permisos de administrador

para realizar la instalación.

También puede ser descargado del sitio web:

http://www.techsmith.com/download/studiodefault.asp

¿Por qué los videos se ven borrosos?

Si se escala el video en la aplicación que lo está reproduciendo el video se verá

borroso. Los videos deben reproducirse con su tamaño original, sin ser escalados.

Problemas con la reproducción con Media Player

Si el video se está reproduciendo en Media Player 7, 8 o 9 y ud. no logra ver la

imagen nítidamente, el problema probablemente sea de que el video no se está
reproduciendo al 100% del tamaño original. Es un problema que tienen estas
versiones del Media Player en sus “skins” mode predeterminados. Por defecto
escalan los videos durante la reproducción a un tamaño menor, dando como
resultado la degradación de la calidad de la imagen. Muchas veces el seleccionar
View/Video Size/100% no tiene el efecto deseado.

La solución es configurar el Media Player para que no escale las imágenes. Hay
varias formas de hacerlo:

1. Configurar Media Player para que utilice “Classic skin”. Presionar el botón
“Skin Chooser” y seleccionar “Classic”.
2. Correr el player en “Compact mode”. En Media Player seleccionar
View/Skin Mode
3. Correr Media Player en modo 6.4

Uso de Media Player 9 en modo v6.4

1. Localizar y ejecutar el archivo MPLAYER2.EXE que está ubicado en Program

Files/Windows Media Player. Esto correrá MP9 en modo v6.4.
2. Cuando v6.4 está corriendo seleccionar View/Options/Formats, presionar
Select All/Apply/OK. Esto configurará las asociaciones de Windows para
usar Media Player 6.4 cuando se hace doble clic sobre un video en
Windows Explorer, o en otras aplicaciones que usan las asociaciones del
shell de Windows para ejecutar un reproductor.
3. Seleccionar View/Options/Playback y configurar el nivel de Zoom en 100%

Si desea utilizar v6.4 puede bajarlo de:

http://www.microsoft.com/windows/windowsmedia/en/download/default.asp

Otra opción es utilizar el TechSmith Camtasia AVI Player, que puede bajarse
libremente de
http://www.techsmith.com/products/studio/player.asp. En este caso no habrán
problemas de escalado.

INTRODUCCIÓN

Este capítulo tiene como objetivo dar una breve introducción a lo que es .NET. y
presentarles algunos conceptos básicos cuando hablamos de la plataforma .NET.

Información general
.NET es una plataforma de desarrollo de software de Microsoft, llamada .NET Framework. Este
es un soporte sobre el cual corren las aplicaciones implementadas en los lenguajes que incluye
la plataforma, ya no corren directamente sobre el sistema operativo, sino que ahora existe una
capa intermedia sobre la cual se ejecutan las aplicaciones.

Los principales componentes del .NET Framework son:

CLR (Common Language Runtine)

Es el motor de ejecución de las aplicaciones .NET, encargado de ejecutar el código.NET.

El CRL se encarga de convertir el código .NET (código intermedio) a lenguaje de
máquina, esto lo hace en tiempo real el compilador JIT (Just In Time) del CRL.

Conjunto de clases del .NET Framework

Es el conjunto de clases que componen el framework y que permite el desarrollo de las

aplicaciones. Dentro de estas clases encontramos por ejemplo: manejo de datos
(ADO.NET), administración de memoria, manejo de excepciones, manejo del sistema
de ventanas, entre otros.

ASP.NET
 Es el componente que permite la ejecución de aplicaciones Web, que corren bajo el
servidor Web Internet Information Server.

.NET Remoting

Es el protocolo que utilizan las aplicaciones .NET para la comunicación entre el cliente
y el servidor de aplicaciones es .NET Remoting.

¿Como funciona .NET Framework?

Para implementar una aplicación puede utilizar cualquiera de los lenguajes que incluye la
plataforma .NET. Cuando la aplicación es compilada se crea un código intermedio llamado IL
(Intermediate Language), este código es independiente de la plataforma de hardware. Una vez
compilado, la CLR administra la ejecución de la aplicación.

La CLR utiliza un componente JIT para la compilación, el cual transforma el código intermedio
IL al código de máquina en el sistema donde la aplicación se va a ejecutar. Esta compilación a
lenguaje de máquina lo hace en el momento de ejecución del código.

Formas de ejecución: GUI y WEB

Las aplicaciones .NET pueden ejecutarse en dos modalidades diferentes: como aplicaciones
GUI y como aplicaciones WEB. A continuación describimos cada una.

Aplicaciones GUI
Se trata de aplicaciones .NET que se ejecutan interpretadas. En el cliente se instala la
aplicación GUI en su máquina, y ejecuta el archivo EXE de la aplicación.

Aplicaciones WEB
Cuando se genera una aplicación web (DLL), esta corre en el servidor web (Internet
Information Server ). El cliente ejecuta la aplicación desde un browser.
 Internet Information Services de Microsoft forma parte de la mayoría de las
versiones de Windows. Si lo tiene instalado, al navegar a http://localhost verá una
página de gestión o de ayuda de este servidor. Puede iniciarlo o detenerlo yendo
al menú Start y de ahí a Settings / Control Panel / Administrative Tools /
Internet Information Services.

En la ventana que se abrirá navegue por las carpetas que aparecen a la izquierda:
Internet Information Services / <local host> / Web Sites / Default Web
Site y presione el botón de Start

INTRODUCCIÓN

En este capítulo presentaremos los requerimientos para generar y ejecutar

aplicaciones .NET. Presentaremos las distintas herramientas y componentes
necesarios, y cómo obtenerlos.

Requerimientos de hardware
Para utilizar las aplicaciones .NET generadas, es necesario tener un mínimo de
128MB de RAM.

El procesador en principio no es tan crítico como la memoria RAM, pero se

recomienda utilizar al menos un Pentium de 133 para compilar/ejecutar las
aplicaciones.

Se sugiere ver la página de Microsoft para obtener los requerimientos del .NET
Framework y J# distribution package.

Requerimientos de software
Detallaremos a continuación los requerimientos para desarrollar y ejecutar una
aplicación 2 capas en .NET.

Para el desarrollo de las aplicaciones .NET es necesario tener:

  Development environment GeneXus 8.0
 Generador .NET 8.0

Para la compilación y ejecución de los programas es necesario tener instalado el

.NET Framework 1.1 y el J# distribution package 1.1. Estos archivos pueden
obtenerse en forma gratuita del sitio de Microsoft.

Para ver los requerimientos de software del .NET Framework y del J# distribution
package referirse a los links de los sitios de Microsoft brindados más abajo.

Los siguientes son los requerimientos para cualquier aplicación en 2 capas

.NET:

 .NET Framework
 J# distribution package
 DBMS (por ejemplo SQL Server)
 Cliente del DBMS utilizado.

En el caso de implementar una aplicación Web deberá contar con el servidor

web Internet Information Server.

¿Dónde obtener el software requerido?

.NET

.NET Framework 1.1http://msdn.microsoft.com/netframework

J# distribution http://msdn.microsoft.com/vjsharp/downloads/howtoget.asp
package 1.1

En el CD de este curso se incluye una copia del driver .NET Framework 1.1 y una
copia de J# distribution package.

A continuación detallamos cuáles son los drivers de los DMBS, necesarios

según el método de acceso a la base de datos:

En el caso de ADO.NET los requerimientos son:

  SQL Server
ADO.NET utiliza el Data Provider de Microsoft para SQL Server (el cual se
instala con el framework).

 Oracle
Se debe tener el Cliente de Oracle versión 8.1.7 o superior, de esta forma se
instala el Data Provider correspondiente.

El valor “Server Name” de las Dbms option hace referencia al nombre del
Server definido en la instancia del Oracle, no al nombre del equipo.

 DB2 UDB for iSeries

Se necesita la V5R3 del iSeries Access, que es una versión beta y está solo en
inglés. Además cuando se crea un modelo se debe copiar la dll
IBM.Data.DB2.iSeries.dll al directorio gxnet/bin si la aplicación es web o
gxnetwin/bin win. La versión V5R3 del iSeries Access se puede obtener de la
URL:http://www-
1.ibm.com/servers/eserver/iseries/access/windows/beta.html.

 DB2 Universal Database

Se necesita tener instalada la versión 8.1.3 o superior.

La dll es IBM.Data.DB2.dll, también se debe copiar a los directorios gxnet/bin

si la aplicación es web o gxnetwin/bin win.

En el caso de ODBC los requerimientos son:

 SQL Server
Si utiliza la versión de DBMS: 6.5, en el cliente debe estar instalado el cliente
de Sql Server 6.5. El driver recomendable es el provisto en la instalación de
esa versión.

Si utiliza la versión de DBMS 7.0 o 2000, entonces es driver recomendable es

el provisto en la instalación de esa versión.

Se recomienda utilizar la versión del DBMS 7.0 o 2000 SP1. Esto se debe
principalmente a que Sql Server 6.5 realizaba lockeos por página y no por
registro.

 DB2 Universal Database

Versión de DBMS: 6.10.00.50 FixPack 9 o superior. Cliente y driver
recomendable: El provisto en la instalación de la versión. A partir de la versión
GeneXus 7.5 es necesario el driver IBM Db2 7.01.00.40 o superior.
  Oracle
Si utiliza la versión de DBMS: 7.3, en el cliente debe estar instalado el cliente
de Oracle 7.3. El driver recomendable es Intersolv 3.11 o superior.

Si utiliza la versión de DBMS 8.0.X, (X>=5), en el cliente se debe tener

instalado el cliente con misma versión. El driver recomendable es Intersolv
3.11 (o superior) o driver de Oracle versión 8.0.59.0 (o superior).

No se soporta el DBMS 8.0.4 o menor, ni las versiones de clientes y drivers

correspondientes.

Si utiliza la versión de DBMS 8.01.X, en el cliente se debe tener instalado el

cliente con misma versión (aunque se recomienda cliente de Oracle 9i cuando
se trabaja con drivers de Oracle). El driver recomendable es Intersolv 3.11 (o
superior) o driver de Oracle 9.00.11.00 (o superior).

En todos los casos, si se desea usar el driver de Oracle se deberá tener

instalado el cliente de Oracle en inglés.

 Informix
Versión de DBMS: 7.0 o Informix Foundation 2000. En el cliente debe estar
instalado el cliente con la versión correspondiente. Driver recomendable: Los
drivers se encuentran en el CD de instalación de Informix. (Son de Intersolv o
Informix).

INTRODUCCIÓN

En este capítulo presentaremos las características de las aplicaciones

desarrolladas con el generador .NET, con qué criterios decidir entre una interfaz
GUI o WEB, y qué características particulares presentan los objetos GeneXus
generados con .NET, en particular las transacciones.

Información general
El generador .NET permite generar tanto aplicaciones GUI como aplicaciones WEB,
así como también permite generar tanto aplicaciones en 2 capas como
aplicaciones distribuidas.
Una aplicación GUI (Graphical User Interface) tiene interfaz gráfica Windows,
compuesta básicamente por los objetos transacciones, work panels,
procedimientos y reportes. Una aplicación WEB, por su parte, tiene interfaz html y
se ejecuta dentro de un browser. Este tipo de aplicaciones se desarrollan
básicamente con los objetos WEB de GeneXus: web panels y web components.
Además, al generar en un ambiente web, se generarán las transacciones con su
form web.

Vale aclarar que las aplicaciones GUI generadas pueden ser ejecutadas tanto en
Intranet como en Internet. Lo que diferencia a una aplicación GUI, de una
aplicación WEB, es la interfaz: las aplicaciones GUI tienen interfaz gráfica Windows
(y el cliente deberá tener instalados los archivos de clase necesarios), mientras que
las aplicaciones WEB tienen interfaz HTML (y no se requerirá bajar archivos de
clase, por tratarse de una aplicación 100% resuelta en el servidor). El único
requerimiento para ejecutar una aplicación WEB, es un browser.

Las aplicaciones GUI pueden generarse en 2 capas o distribuidas (utilizando el

protocolo .NET Remoting para la comunicación entre el cliente y el servidor de
aplicaciones).

Las aplicaciones se comunican con la base de datos a través de ODBC o ADO.NET.

Los posibles DBMS a utilizar con el generador .NET, son todos los DBMS
soportados por GenXus: DB2 UDB for iSeries, DB2 Universal Database, Informix,
Oracle, PostgreSQL y SQL Server. En el caso de optar por ADO.NET para realizar
la conexión a la base de datos, se debe tener en cuenta que no es soportado por
todos los DBMS, como veremos más adelante.

El generador también nos brinda la posibilidad de realizar “Mantenimiento de la

base de datos”, es decir crearla y reorganizarla.

Los programas generados son fuentes de código C# (.cs) y compilados a assemblies

(dlls o exe) en código común (IL Intermediate Language) las cuales en tiempo de
ejecución son interpretados por la máquina virtual de .NET

Web Services
En los últimos tiempos ha surgido con mucha fuerza el concepto de web services,
incluso afirmándose que cambiaría la forma de programar las aplicaciones
orientadas a Internet hacia una arquitectura orientada a servicios. Todo esto se ha
visto potenciado luego del anuncio de Microsoft de su nueva estrategia que se basa
en el modelo de web services.
Un web service es una aplicación que puede ser descripta, publicada, localizada e
invocada a través de una red, generalmente Internet. Los web services combinan
los mejores aspectos del desarrollo basado en componentes y la Web.

Al igual que los componentes, los web services son funcionalidades que se
encuentran dentro de una caja negra, que pueden ser reutilizados sin preocuparse
de cómo fueron implementados. A diferencia de la actual tecnología de
componentes, no son accedidos por medio de protocolos específicos del modelo de
objetos como ser RMI, DCOM o IIOP; sino que son accedidos utilizando protocolos
web como ser HTTP y XML.

La interfase de los web services esta definida en términos de los mensajes que el
mismo acepta y retorna, por lo cual los consumidores de los web services pueden
ser implementados en cualquier plataforma y en cualquier lenguaje de
programación, solo tiene que poder crear y consumir los mensajes definidos por la
interfase de los web services.

Más información en:

http://www.artech.com.uy/gxdlsp/pub/iehelp.htm?genexus/internet/technicalpaper
s/web_services.htm

¿Aplicación .NET GUI o WEB?

Anteriormente se clasificaban las soluciones en Internet según la frecuencia con la
que los usuarios las accedían. Para usuarios casuales, se recomendaba una solución
Web. Para aplicaciones con usuarios frecuentes, y más avanzados, a los cuales se
les podía capacitar en el uso de una aplicación más sofisticada, se recomendaba
una aplicación distribuida

Hoy en día las aplicaciones Web han alcanzado el mismo nivel de sofisticación de
interfaz que cualquier aplicación Win. Debido a las ventajas que presentan
(facilidad en la instalación de la aplicación, solo se requiere un browser en el
cliente; alta escalabilidad), han marcado una tendencia en soluciones de software.
Normalmente, si se crear una nueva aplicación, se recomienda es implementar una
solución Web.
Conexión a la base de datos
El generador .NET permite generar aplicaciones que se conecten con la base de
con ODBC y para algunos de los DBMS podemos utilizar el protocolo ADO.NET.

Si utilizamos ODBC nos podemos conectar a los siguientes DBMS:

DB2 UDB for iSeries

DB2 Universal Database

Informix

Oracle

PostgreSQL

SQL Server.

Mediante ADO.NET podemos conectarnos a los siguientes DBMS:

SQL Server

Oracle

DB2 Universal Database

Acceso ODBC
ODBC(Open DataBase Connectivity) es un estándar de acceso a Bases de Datos desarrollado
por Microsoft, su funcionalidad es permitir realizar la conexión de la aplicación con la base de
datos, sin necesidad de conocer el DBMS donde están almacenados los datos. ODBC es una
capa intermedia entre la aplicación y el DBMS, el propósito de esta capa es traducir las
consultas de datos de la aplicación en comandos que el DBMS entienda.

Acceso ADO.NET
ADO.NET es un conjunto de librerías utilizadas para el acceso a datos, las cuales
están contenidas dentro del .NET framework. Los cambios con respecto a la
metodología que se utilizaba anteriormente para el acceso a los datos están
relacionados con la funcionalidad, rendimiento e interoperabilidad con una forma
estándar de representación de datos a través de XML.

Es posible utilizar ADO.NET como método de acceso al DBMS tanto para

aplicaciones con Interfaz Windows (GUI) como Web.
Tenemos varias ventajas importantes a la hora de implementar aplicaciones con el
generador .NET utilizando ADO.NET para la conexión a la base de datos.

ADO.NET nos brinda una mejora significativa en la performance del acceso a la

base de datos. Además a nivel tecnológico se utiliza 100% “.NET managed
code” para el acceso a los datos y se corrigen problemas inherentes a la
tecnología ODBC.

Otras características muy importantes son las que presentamos a continuación:

Caching

Permite mantener un “cache” de consultas sobre la base de datos, de

forma que si se realizan nuevamente, no se requiera un nuevo
acceso a la base de datos, optimizando tráfico, accesibilidad a datos y
esfuerzos del DBMS.

Pool de Conexiones

A partir de la utilización de ADO.NET para el acceso a la base de

datos utilizando el generador .NET de GeneXus, es posible configurar
ciertas propiedades para manejar pool de conexiones a la base.

Puede obtener más información sobre este tema en ADO.NET.

Transacciones
El comportamiento y las facilidades de las transacciones pueden diferir según el generador
utilizado. A continuación se presentan las características de los objetos de tipo transacción
generados en .NET.

Tipo de Diálogo
Una de las principales características de una aplicación desarrollada con el
generador .NET está en la implementación del diálogo de las transacciones, el cual
llamamos diálogo a pantalla completa “Full Screen”.

Por defecto las aplicaciones .NET no cuentan con la posibilidad de realizar una
validación de los datos ingresados en las transacciones a medida que se navega por
las mismas, sino que la validación se realiza una vez ingresados todos los datos, al
presionar el botón de Confirmar.
Del mismo modo, contamos con una propiedad del modelo que permite optar por
validación del lado del cliente (“Client Side Validation”) adicionalmente a la
validación que se realiza en el servidor.

El procesamiento de los datos ingresados por el usuario final es a "pantalla

completa", esto implica que no se graba por nivel. En particular, utilizando como
ejemplo la inserción en una transacción típica de facturación de dos niveles, el
cabezal y las líneas se graban todas juntas cuando el usuario confirma toda la
transacción.

Del mismo modo, se debe tener en cuenta que si se quiere borrar una línea de la
grilla correspondiente al segundo nivel, primero se debe presionar botón “Supr” o
“Del” del teclado y luego presionar el botón de Actualizar o Confirmar de la
transacción.

Propiedad Client Side Validation

Propósito
Permite seleccionar el nivel de interacción entre el usuario y la aplicación, esta
alternativa provee más interacción con el usuario final, ya que habilita hacer las
validaciones y cálculos mientras los datos son ingresaos.

La validación a nivel de cliente es una alternativa a la validación en el servidor. Permite

incrementar sustancialmente la interacción de las transacciones con el usuario final.
Esto se logra validando los datos y calculando fórmulas a medida que el usuario se
mueve entre los campos de la pantalla y/o ingresa información en ellos.

Values
Yes: Se realizar las validaciones y cálculos mientras se están ingresando los
datos.
 No: No se realiza las validaciones y cálculos mientras se están ingresando los
datos. Todas las validaciones y cálculos se realizan una vez que el usuario
active el evento “Enter”.

Valor predeterminado = No

Consideraciones

Las aplicaciones con interfaz Win para los generadores .NET en el caso que se utilice la
validación a nivel del servidor (Propiedad “Client side validation = No”), tienen un
comportamiento particular, algunos puntos destacables son:

 Los atributos de la tabla extendida se cargan al momento de confirmar los datos y no

antes.

 Se requiere conocer en forma explícita el modo. Es decir, no ocurrirá que se infiera el

modo dependiendo del valor ingresado en la clave.

 Dado que los generadores .NET cambian la descripción del botón Confirmar, si el usuario
lo cambia manualmente no obtendrá el efecto deseado.

 Los tiempos para disparo de reglas son sólo al entrar y al confirmar la transacción. No es
posible disparar reglas entre un atributo y otro con reglas 'after(attribute)'. Si es posible
usar el evento IsValid.

 Si en una transacción de dos niveles, con cabezal y líneas, se tiene una regla condicionada
para cargar valores en las líneas, éstas se van a agregar luego de la confirmación de toda la
transacción, no al pasar del cabezal a la grilla.

 Cuando en algunos casos, en Visual Basic y Visual FoxPro después de un atributo se

dispara una lectura que obtiene un atributo de la extendida que luego se usa como filtro
de un prompt, como en .NET esa lectura se hace al final, el prompt quedará sin filtro.

 Si hay dos prompts, no es posible filtrar en el segundo por un atributo de la extendida del
primero.

De esa forma se tendrá una validación a nivel del cliente, adicionalmente a la que se realiza a
nivel del servidor.
 Disparo de reglas
La validación a nivel de cliente no evita que se realice la validación a nivel del servidor. Esta
última siempre se realiza para asegurar la integridad de los datos y evitar realizar bloqueos de
registros mientras el usuario final está ingresando datos.

Por esta razón, las reglas de una transacción pueden ejecutarse más de una vez. Es necesario
entonces tener esto en cuenta, si las reglas invocan programas que actualizan la base de datos.

Específicamente, las reglas condicionadas a atributos (no a eventos) se ejecutarán cuando se

pase por el atributo y nuevamente al confirmar la transacción.

Por lo tanto, para que los diferentes disparos de las reglas no afecten el comportamiento de la
aplicación, se recomienda que las reglas sean idempotentes. Eso significa que no importa
cuántas veces se dispare una regla siempre debe producir el mismo resultado.

Por ejemplo, la siguiente regla:

error("Debe ingresar el nombre") if null(CliNom);

se disparará al pasar por el atributo CliNom y nuevamente cuando se confirme la

transacción.Pero ambas ejecuciones producen el mismo resultado, por lo tanto esta es una
regla idempotente.

De igual forma, si desde las reglas de una transacción, se invoca a un procedimiento que
devuelve un valor, esa regla también será idempotente ya que no importa cuántas veces se
ejecute el procedimiento, siempre devolverá el mismo resultado.

En cambio, si se invoca a un procedimiento desde las reglas de una Transacción, para numerar
automáticamente un atributo, ese procedimiento se ejecutará al pasar por el atributo y
nuevamente al confirmar la Transacción, pero el resultado en ambas ejecuciones será
diferente, ya que la primera vez retornará un valor X, y la próxima vez que se ejecute
devolverá el valor X+1, por lo tanto esta regla no es idempotente.

Propiedad Confirmation
Una propiedad a nivel del modelo y de cada transacción, es trabajar con y sin
confirmación. Si se opta por trabajar “con” confirmación, al momento de confirmar
se disparan las reglas, se efectúan las validaciones de integridad referencial, se
cargan los atributos de la tabla extendida, pero no se graban directamente los
datos. En vez de esto, se le solicita al usuario confirmación para hacerlo. Para
entonces, el botón Add habrá cambiado su caption a Confirm, y en la barra de
estado se solicitará ‘Please confirm the data’.

Si se presiona Confirm se agregará el registro, y en la barra de estado aparecerá

el mensaje: “Data has been successfully added”.

Si se hace cualquier modificación, el botón pasará a decir Add nuevamente, y se

volverá el comienzo del ciclo. El funcionamiento para modificaciones y bajas es
análogo.

Si se trabaja sin confirmación, al dar de alta en una transacción, si no hay errores,

se insertarán los datos sin previa consulta al usuario. Análogamente si se hace
una modificación o una baja.

Por defecto, un modelo .NET tiene la propiedad Confirmation en “sí” (Always

Prompt), y puede deshabilitarse cambiándola a Never Prompt. Muchos usuarios
prefieren deshabilitarla y trabajar con validación del lado del cliente. Esta
propiedad puede resultar útil cuando no se desea utilizar Client Side Validation,
pero se desea verificar las descripciones que se cargan de la tabla extendida,
para luego poder decidir si efectuar la grabación, o no.

Manejo de bitmaps
Si se utiliza la propiedad Confirmation, el código .NET generado irá cambiando el
caption del botón ‘Confirmar’. Por ello, si el usuario lo cambia manualmente no
obtendrá el efecto deseado.

Se puede optar por utilizar un bitmap para el botón Confirm en lugar del Caption.

En las propiedades del botón Confirmar, lo único que debe seleccionarse es que se
manejará Bitmap en vez de Caption, sin embargo no se debe indicar un path
específico, sino que el generador .NET utiliza un conjunto de Bitmaps por defecto.

Los bitmaps por defecto son:

 Add

Confirm

Delete

Update

Estos bitmaps pueden cambiarse con las propiedades:

Add Button Bitmap

Update Button Bitmap

Confirm Button Bitmap

Delete Button Bitmap

Transacciones de más de un nivel

El generador .NET soporta transacciones de más de un nivel, pero toda transacción
.NET debe tener no más de un nivel plano, y al menos uno. No se soportan
transacciones de un nivel con subfile. Por ejemplo, no se soportan estructura del
tipo:

A*

(C*

(E*

F)
Vale aclarar que lo que no se soporta es la generación del programa
correspondiente a la transacción para la ejecución de la misma; pero si, se
soportan estas transacciones en lo referente al diseño de las estructuras de la base
de datos que éstas determinan. Es decir, no se pueden ejecutar transacciones en
.NET con estas estructuras, pero sí son tenidas en cuenta al crear y reorganizar la
base de datos.

¿Por qué elegir el generador .NET?

El generador .NET de GeneXus aprovecha en todo sentido las ventajas de la
tecnología .NET, y acompañará en todo momento la evolución de la misma.

El generador .NET permite que las aplicaciones de los usuarios GeneXus continúen
evolucionando tecnológicamente sin necesidad de reescribirlas. Es decir, del mismo
modo en que pudieron ser migradas de un entorno de sólo texto a un entorno
Windows, ahora pueden ser migradas automáticamente para ejecutar en Internet y
ambientes distribuidos.

A modo de resumen, a continuación se enumeran algunas razones por las cuales

optar por el generador .NET:

 Migración de una aplicación ya desarrollada con algún generador visual,

para ponerla rápidamente en Internet.

 Desarrollo de aplicaciones de interfaz GUI y HTML para Intranet e Internet.

Aplicaciones 2 en dos capas y aplicaciones distribuidas (utilizando .NET
Remoting como protocolo de comunicación).

 Cantidad grande de usuarios y/o usuarios frecuentes.

 Fácil instalación de la aplicación y sus diferentes versiones.

 Acceso a la base de datos mediante ADO.NET, protocolo que permite el

manejo de un pool de conexiones y caché de sentencias, además de la
mejora en la performance del acceso a la base de datos frente a las
tecnologías utilizadas anteriormente.
INTRODUCCIÓN

En este capítulo presentaremos las propiedades y opciones de ejecución para un

modelo desarrollado utilizando el generador .NET, describiremos desde la
configuración de las propiedades del modelo hasta las propiedades para la
conexión a la base de datos. También ejemplificaremos estos puntos viendo un
ejemplo desde la creación hasta su ejecución.

Edición del modelo

Al seleccionar “File/Edit Model…” aparece el siguiente diálogo para definir las
propiedades del mismo.

Cada Modelo tiene un ambiente principal que se utiliza para la creación y

reorganización de la base de datos, y como ambiente por defecto para la
generación de la aplicación. Además puede tener varios ambientes secundarios
que se definen en el tab de Environments.
El ambiente principal es el que se define en esta pantalla (en el tab General,
sección Environment) e incluye los siguientes campos para su definición:
Language, User Interface y DBMS.

Language proporciona un combo con todos los lenguajes soportados por

GeneXus. En este caso evidentemente se debe elegir: .NET.

User interface ofrece 2 valores posibles: Win Form y Web Form. Aquí se debe
seleccionar el tipo de interfaz que se desee utilizar para el ambiente principal. El
valor Web Form permite generar todos los objetos GeneXus salvo work panels,
menu y menu bars.
El valor Win Form, por su parte, permite generar todos los objetos GeneXus,
excepto los web panels y themes.

En el caso que la mayoría de los objetos “main” de la aplicación correspondan a

interfaz windows (GUI), se debe seleccionar User interface: Win Form en el
ambiente principal y de ser necesario se debe crear un ambiente secundario con
User interface: Web Form.

Por el contrario, si la interfaz de la mayoría de los objetos “main” es web, se debe

seleccionar User interface: Web Form en el ambiente principal y de ser
necesario se debe crear un ambiente secundario con User interface: Win Form.

Definición de ambientes secundarios

En el tab Environments existen tres columnas que corresponden a: ambiente,
lenguaje e interfaz de usuario. Hay dos tipos de ambientes definidos Default y
Reorg que heredan por defecto la información del ambiente principal, siendo
posible cambiar el lenguaje y form del ambiente Default, así como agregar
nuevos tipos de ambientes.

La siguiente figura muestra el tab Environments de un modelo .NET Win al que

se le agrega un nuevo tipo de ambiente web.
¿En qué ambiente se generan los objetos?
Por defecto los objetos se generan en el ambiente Default (que en principio se
hereda del ambiente principal, y puede modificarse). Sin embargo, a los objetos
main, se les puede asociar cierto ambiente secundario. Por ejemplo, si el
ambiente Default de una Base de Conocimiento fue definido como Win Form,
dado que los web panels no pueden ser generados con interfaz windows, a los
web panels (que son objetos main) se les asocia un generador secundario de
interfaz Web Form.

Cada objeto main se genera en el ambiente asociado a dicho objeto. Y cada objeto
no main, se genera en los ambientes de los mains que lo llamen. A modo de
ejemplo, una transacción con form Win y form Web será generada en ambiente
Web si es llamada por un Web Panel y a su vez en ambiente Win si es llamada por
un Work Panel.

Si el objeto no se corresponde con el ambiente, por ejemplo si se tienen Web

Panels en un ambiente Full Win, el objeto no se especifica y en la navegación se
muestra la siguiente advertencia: This object cannot be generated on this
environment.
En lo que se refiere al ambiente principal, además de Language (.NET) y de User
interface (Win Form / Web Form), solo resta entonces, seleccionar el DBMS.

Botones: Properties, DBMS Options, Execution

A continuación veremos todas las propiedades correspondientes a un modelo
.NET, las DBMS Options que se deben configurar con la información de conexión a
la base de datos y las opciones de ejecución.

Al igual que con otros generadores, al momento de crear un nuevo modelo no

se abre este diálogo, sino el GeneXus Create Model Wizard, que presenta solo
algunas de las opciones de configuración. Haciendo click en Manual Creation, es
posible pasar al diálogo de edición de las Model Properties.

Propiedades del modelo

Veremos las propiedades correspondientes a un modelo .NET básico. Observar
que las propiedades se agrupan por áreas. Algunas son comunes a otros
generadores. Otras son específicas del generador .NET, como muestra la figura
siguiente.
A continuación se explican las siguientes propiedades.

General
Application namespace

Generate strong named assemblies

Assembly version number

Compiler Flag

Access Method

Client server information

Maximum open cursos per connection

List of remote programs

User interface
Use .NET controls

Propiedades Add/Update/Confirm/Delete Button Bitmaps

Propiedad Application namespace

Propósito
Determina el namespace de la aplicación. Los programas generados por
GeneXus y compilados con C# se encuentran disponibles bajo el namespace
indicado por esta preference.

Valores
El nombre del namespace.

Valor predeterminado = GeneXus.Program

Propiedad Generated Strong Named Assemblies

Propósito
Determina si los exe y dll generados tienen un “Strong Name”, es decir un
nombre único.

Permite acceder a una serie de ventajas que provee el .NET Framework, como
por ejemplo, Depoyment en el GAC (Global Assembly Cache), configuración de
la seguridad para el assembly (permite configurar la seguridad para correr un
assembly que viene de una zona no segura).

Valores
Yes: El programa generado tiene un “Strong Name.

No: El programa generado no tiene un “Strong Name.

Valor predeterminado = No

Propiedad Assemblies Version Number

Propósito
Determina el número de versión a ser asignado al “Strong Name assemblies”.

Valor predeterminado = 1.0.0.0

Propiedad Generated Strong Named Assemblies

Propósito
La información de esta propiedad se utiliza para la compilación del main. Es
útil por ejemplo para generar información de debug (incluyendo el string
“/debug”) o para incluir una dll dentro del namespace (/r:xxx.dll ).

Propiedad Access Method

Propósito
Determina que tipo de acceso se va a realizar a la base de datos.

Valores
ODBC: Acceso vía ODBC

ADO.NET: Con este valor se determina que el acceso a la base de

datos se realizará con este protocolo y se conectará con los valores
definidos en DBMS Option\Access technolgy setting\access technolgy
to set\ADO.NET. Si se selecciona este valor se habilita la propiedad
“Enable Caching”.

Valor predeterminado = ODBC

Cache de sentencias
ADO.NET nos brinda la posibilidad de mantener un “cache” de sentencias con sus resultados,
de forma tal de realizar una primera consulta sobre la base de datos y las siguientes sobre una
memoria “cache”, lo cual acarrea un aumento en la performance de la aplicación ya que se
reduce el costo de acceso al servidor de base de datos.

Es común, que en la mayoría de los sistemas, accedamos a datos que no cambian con mucha
frecuencia, con lo cual estamos realizando recorridas sobre la base de datos para obtener la
misma información en muchas ocasiones, esto originó que en ADO.NET se implementara un
mecanismo de “cache” en memoria, de rápido acceso, con los resultados de las sentencias más
frecuentes.

El “cache” de sentencias funciona de la siguiente manera:

  Al realizar una consulta por primera vez sobre una tabla, el resultado queda
guardado en memoria.
 Cuando se realiza nuevamente la consulta no se realiza comunicación alguna con el
servidor de base de datos, sino que se obtienen los datos del “cache” de memoria,
siempre y cuando no haya expirado el tiempo configurado para mantener los datos
en dicho “cache”.
 Si el tiempo expiró se accede a la base de datos para obtener nuevamente los datos y
almacenarlos en el “cache”.

Para habilitar el “cache” de sentencias de ADO.NET y configurar las propiedades

correspondientes, debemos ir a la sección “General/.NET specific/ADO.NET specific” de las
propiedades del modelo.

Propiedad Enable Caching

Propósito

Esta propiedad permite definir si se habilita el “cache” de sentencias.

Valores

Yes: Hablita el caching

No: Deshabilita el caching

Valor predeterminado = No
Propiedad Hardley Ever TTL (mins)
Propósito

Cuando se lee una tabla que tiene en la “Propiedad Change frequency” el valor “Hardly
Ever”, se mantiene en el “cache” durante el tiempo en minutos definido en esta
propiedad.

Valor predeterminado = 600

Propiedad Time to Time TTL (mins)

Propósito

Cuando se lee una tabla que tiene en la “Propiedad Change frequency” el

valor “Time to Time”, se mantiene en el “cache” durante el tiempo en
minutos definido en esta propiedad.

Valor predeterminado = 60

La diferencia entre la propiedad “Time to Time” y la propiedad “Hardly Ever”,

es permitir definir distintos puntos de persistencia en las tablas del modelo.

Propiedad Change frequency

Propósito

Si bien el “cache” se realiza a nivel de sentencia, es a nivel de tabla que se configura,

permitiendo seleccionar el tiempo en que los datos van a persistir en memoria antes
de ir a buscarlos nuevamente a la base de datos. Para poder configurar este tiempo se
utiliza esta propiedad, que se configura a nivel de tablas, en modo de diseño.

Valores

Almost Never: Se mantienen los datos en “cache” indefinidamente

Pretty Often: No se realiza “cache”
Hardly Ever: Valor que se define a nivel de modelo
prototipo/producción
Time to Time: Valor que se define a nivel de modelo
prototipo/producción

Valor predeterminado = Pretty Often

Por información más detallada sobre este tema ir al documento Caching.

Propiedad Maximum open cursors per connection

Propósito
Uno de los costos más importantes en las operaciones ODBC/JDBC es el de
preparar las sentencias SQL. La preparación incluye la compilación y
validación de la sintaxis de dicha sentencia por parte del servidor.

Los programas generados en .NET realizan un manejo inteligente de los

cursores abiertos, de modo que no haya que volver a preparar cursores que
ya fueron preparados. Para eso se mantiene un pool de cursores
preparados, cuyo tamaño por defecto es de 100 cursores. Si se desea
cambiar este número, se puede cambiar el valor de esta propiedad.

Propiedad List of Remote Programs

Propósito
Permite especificar una lista de programas almacenados en la base de datos
(procedimientos almacenados). Los nombres de los programas deben estar
separados por espacios.

Nota:
En .NET, cuando el generador encuentra un “call” a un programa incluido en
la lista, hace una llamada vía ODBC, en vez de una llamada normal.

Propiedad Use .NET Controls

Propósito
Determina la forma de hacer el “rendering” de los controles HTML (para
EditBox, CheckBox, RadioButtons, ListBox y Buttons), en web panels y web
transactions. Por defecto esta en "Yes" lo que indica que el “rendering” se
hace utilizando controles .Net para generar el HTML necesario, este
aprovecha ciertas características del Internet Explorer para representar
mejor los controles. Estando en "No" indica que use el “rendering Standard”
generado por GeneXus en todas sus plataformas, este último garantiza
compatibilidad en el “look and feel” entre las distintas plataformas Web
generadas por GeneXus.

Valores
Yes: Utiliza “rendering” que se hace utilizando controles .Net para
generar el HTML necesario
 No: Utiliza el “rendering Standard” generado por GeneXus en todas
sus plataformas

Valor predeterminado = Yes

Propiedades Add/Update/Confirm/Delete Button Bitmaps

Propósito
Permite cambiar el bitmap asociado al boton “Confirm” en vez del caption
correspondiente a cada caso.

Valores
Los bitmaps por defecto son:

Agregar (gxconfirm_add.gif)

Confirmar (gxconfirm_cnf.gif)

Borrar (gxconfirm_dlt.gif)

Modificar (gxconfirm_upd.gif)

Opciones de ejecución
Para configurar la ejecución de una aplicación GUI .NET, alcanza con definir el
camino del compilador (csc.exe), este lo provee el framework SDK y se encuentra
bajo el directorio de instalación del mismo en:

<NET frameworkpath>\Framework\v1.1.4322 \csc.exe

Para ingresar a esta propiedad debe ir a: “File/Edit Model/ Botón Execution”.

Archivo de configuración
Cuando estamos trabajando con aplicaciones .NET, tenemos archivos de
configuración donde se definen determinados propiedades de las aplicaciones,
como por ejemplo la información para la conexión a la base de datos o la
configuración de un archivo de “log”.

A continuación detallamos cual es ese archivo en el caso de una aplicación en 2

capas .NET.

client.exe.config

Se crea cuando se genera aplicaciones en 2 capas o aplicaciones distribuidas.

En el caso de aplicaciones en 2 capas contiene básicamente la información para

la conexión a la base de datos y la generación del “log”.

Se encuentra en el directorio del modelo “dataxxx” y en “dataxxx\bin”. Cuando

la aplicación corre desde Genexus, se utiliza este archivo de configuración; si
se corre directamente desde el “exe” de la aplicación del directorio
“dataxxx\bin”, entonces se utiliza la que está en este directorio, es decir que
toma el archivo que se encuentre en el mismo directorio de la aplicación.
web.config
Se crea cuando se genera aplicaciones web y es utilizado cuando corremos las
aplicaciones baja Internet Information Server.

Contiene la configuración sobre la ubicación del servidor de aplicaciones, la

conexión a la base de datos y la generación del “log”, entre otros.

Se encuentra en el directorio del modelo “dataxxx”.

Permisos .NET
Permisos para ejecución de objetos remotos
El esquema de seguridad para los Assemblies (dlls y exes) de .NET es un esquema bastante
complejo y seguro a la vez. Para configurar el ambiente de desarrollo es necesario tener
algunas consideraciones.

Para poder trabajar con modelos remotos, es necesario deshabilitar el control de seguridad de
.NET. En otro caso no es posible ejecutar localmente los objetos web que se encuentran en
otra máquina a través de la red, o sea, ejecutar en el servidor web objetos que no están
físicamente en la misma máquina que este. Esta es una restricción de seguridad del framework
.NET.Esto involucra únicamente el ambiente de desarrollo, en la instalación final (donde el
server y las DLLs están en la misma máquina) no es necesario y no se recomienda deshabilitar
la seguridad.

Para inhibir la seguridad es necesario ejecutar el comando "caspol -security off", en la

máquina donde se ejecutarán los objetos. Este comando se setea por equipo, no afecta la
generación de los objetos, sólo la ejecución en el ambiente de desarrollo. Si los objetos a
ejecutar se encuentran en la misma máquina no es necesario hacer esto.

Permisos para ejecución de reorganización remota

Para ejecutar la reorganización, que es un assembly (reor.exe), si es corrido desde alguna
máquina de la intranet no contará con todos los recursos necesarios. El assembly cuenta con
diferentes niveles de seguridad según en el sitio en el cuál se encuentre:

 My Computer: “Full Trust” ( los programas son totalmente confiables y pueden

acceder a todos los recursos necesarios).

 Local Intranet: Tienen un nivel diferente, más bajo que el “Full Trust”, por tanto
no pueden acceder a un conjunto de recursos, como ser el “file system”.
  Internet: Tienen el nivel de confiabilidad más bajo y en general no pueden realizar
tareas sin la aprobación del usuario.

Para solucionar este problema:

1) Moverse al directorio:

<SYSTEM DRIVE>:\<WINDOWS FOLDER>\Microsoft.NET\Framework\<Version

Number>\

2) Ejecutar el comando:

mmc mscorcfg.msc

Esto lo que hace es abrir la consola ".Net Admin Tool".

Entre otras cosas hay una entrada para "Runtime Security Policy".

Luego ir al link “Adjust Zone Security”

Seleccionar la zona Intranet y aumentar el nivel de seguridad a “Full Trust“

Otra posible solución es darle permisos en este caso solo al exe de la reorganización (reor.exe).
Para ello ir al link "Increase Assembly Trust" y aumentar el nivel a “full trust” solo a ese
assembly.

Autorizacion por Web Panel

En caso de que sea necesario asignar diferentes niveles de autorización a diferentes objetos
web dentro de un mismo directorio virtual debe procederse como se describe a continuación:

 Crear un archivo .aspx por cada web panel, web procedure, etc., en el directorio
virtual. No interesa el contenido del archivo, lo único que interesa es que el
archivo exista para que el IIS pueda checkear los permisos.

 Luego, en el IIS, dar botón derecho sobre el directorio virtual / propiedades. En la

parte de “application settings”, ir al botón “Configuration”. En la hoja “App
mappings”, elegir la extensión aspx e ir al botón “Edit”. Luego activar el “check
box” que dice "check that file exists”.
Práctica 1 - Creación del primer modelo .NET
Vamos a crear el primer modelo 2 capas .NET, para poner en práctica todos los conceptos
vistos hasta el momento.

La forma de trabajo que vamos a tener a lo largo del curso es mostrarles primero
cómo realizar cada paso, e inmediatamente después de terminar de definirlo, Ud.
deberá hacer lo mismo por sí solo, siguiendo las instrucciones indicadas.

En primer lugar, debe crearse la Base de Conocimiento (en GeneXus 8.0 o superior)
y consolidar el archivo NETCourse.xpz, que contiene algunas transacciones, work
panels, reportes, procedimientos y web panels.

Una vez realizada la consolidación, vamos entonces a crear un modelo de prototipo

para realizar la definición del primer modelo .NET.

Como el generador .NET genera aplicaciones Cliente/Servidor, es necesario contar

con alguno de los DBMS soportados por GeneXus. El DBMS que utilizaremos aquí
será SQL Server 2000. Una alternativa es utilizar MSDE, una versión libre y
reducida de SQL Server 2000.

En este ejemplo utilizaremos el protocolo ADO.NET para realizar ala conexión a al

base de datos.

Comencemos por ponerle un nombre al prototipo (por ejemplo: First .NET Model).
Luego, pasaremos a ingresar los valores solicitados en cada unos de los pasos
para configurar el modelo.

Las propiedades que no se especifiquen a continuación, las dejaremos con los

valores por defecto.

Paso1 – General Information:

 Language: .NET

 User interface: Win

 DBMS: SQLServer
Paso 2 – Model & DBMS Properties (Part 1)

 Access Method: ADO.NET

 Database name: dataBase (es una base de ejemplo)

 Server name: localhost (en este caso el servidor de la base de datos es

la misma máquina, sino se debe poner el nombre externo de la
máquina donde esté instalado SQL Server)

Paso 3 y 4 - Model & DBMS Properties (Part 2 – Part 3)

 Use trusted connection: No

 User id: user (usuario ejemplo con acceso a la base de datos)

 User password: password (o la password que ud. haya especificado en

la instalación, si utiliza el administrador, o la que corresponda al
usuario que esté usando ahora)

Paso 5 – Compile & execution properties

 Directorio del compilador.

Paso 6 – Compile & execution properties

Vamos a marcar la opción “Edit advanced properties ...” para configurar el

modelo. Para ello, presionamos el botón “Finalizar”, y desde ahí vamos a la
edición de las propiedades del modelo, una vez ahí, accedemos a la sección
“General/.NET specific” y allí configuramos la siguiente propiedad:

 Access Method: ADO.NET

Tenga en cuenta que es fundamental configurar correctamente la información

referente a la conexión a la base de datos, así como las opciones de ejecución.

Haga clic aquí para ver la demostración

Ahora puede realizarla usted.
 Cabe destacar que en el caso de .NET es en el momento de la compilación
donde se detectan la mayoría de los errores, ya que éstos generadores realizan
controles estrictos al momento de compilar los objetos. Fundamentalmente estos
controles se realizan en la definición de los tipos de datos utilizados en los
programas, lo que hace que sean exigentes en la definición de los mismos.

Por ejemplo, no es posible realizar una compilación cuando un objeto llama a otro
y el llamador utiliza un tipo de datos numérico en un parámetro y el llamado lo
recibe en un campo de tipo carácter.

No es necesario instalar el cliente del DBMS, ya que en el caso de SQLServer,

ADO.NET utiliza el Data Provider de Microsoft para SQL Server (el cual se instala
con el framework).

Introducción
En este capítulo presentaremos las opciones de ejecución para un modelo Web,
desarrollado utilizando el generador .NET. También mostraremos paso a paso la
configuración y ejecución de una aplicación Web.

Opciones de ejecución
Para configurar la ejecución de una aplicación WEB en .NET, debemos configurar
dos propiedades, por un lado tenemos que definir el camino del compilador
(csc.exe), este lo provee el framework SDK y se encuentra bajo el directorio de
instalación del mismo en:

<NET frameworkpath>\Framework\v1.1.4322 \csc.exe

Y por otro lado debemos especificar el “directorio virtual”, el cual determina la URL
base de ejecución, esta contiene el directorio virtual a ser creado (si no existe), por
GeneXus en el Internet Information Service (IIS) local. El momento de la creación
es luego de la compilación y reorganización
Para ingresar a estas propiedades debe ir a: “File/Edit Model/ Botón Execution”.

Práctica 2 - Creación y ejecución de una aplicación

web
Vamos a crear el primer modelo .NET, para poner en práctica todos los conceptos vistos
hasta el momento.

La forma de trabajo que vamos a tener a lo largo del curso es irles mostrando
primero cómo realizar cada paso, e inmediatamente después de terminar de
definirlo, Ud. deberá hacer lo mismo por sí solo, siguiendo las instrucciones
indicadas.

En primer lugar, debemos asegurarnos de que esté instalado y levantado el

servidor web Internet Information Server.

Seguidamente, vamos a crear la Base de Conocimiento (en GeneXus 8.0 o superior)

y consolidar el archivo NETCourse.xpz, que contiene algunas transacciones, work
panels, reportes, procedimientos y web panels.
Una vez realizada la consolidación, vamos entonces a crear un modelo de prototipo
para realizar la definición del primer modelo .NET.

Como el generador .NET genera aplicaciones Cliente/Servidor, es necesario contar

con alguno de los DBMS soportados por GeneXus. El DBMS que utilizaremos aquí
será SQL Server 2000. Una alternativa es utilizar MSDE, una versión libre y
reducida de SQL Server 2000.

En este ejemplo utilizaremos el protocolo ADO.NET para realizar ala conexión a al

base de datos.

Comencemos por ponerle un nombre al prototipo (por ejemplo: .NET Web Model).
Luego, pasaremos a ingresar los valores solicitados en cada unos de los pasos
para configurar el modelo.

Las propiedades que no se especifiquen a continuación, las dejaremos con los

valores por defecto.

Paso1 – General Information:

 Language: .NET

 User interface: Web

 DBMS: SQLServer

Paso 2 – Model & DBMS Properties (Part 1)

 Access Method: ADO.NET

 Database name: dataBase (es una base de ejemplo)

 Server name: localhost (en este caso el servidor de la base de datos es

la misma máquina, sino se debe poner el nombre externo de la
máquina donde esté instalado SQL Server)

Paso 3 y 4 - Model & DBMS Properties (Part 2 – Part 3)

 Use trusted connection: No

 User id: user (usuario ejemplo con acceso a la base de datos)

  User password: password (o la password que ud. haya especificado en
la instalación, si utiliza el administrador, o la que corresponda al
usuario que esté usando ahora)

Paso 5 – Compile & execution properties

 Directorio del compilador

 Nombre del directorio virtual: http://localhost/services

Paso 6 – Compile & execution properties

Vamos a marcar la opción “Edit advanced properties ...” para configurar el

modelo. Para ello, presionamos el botón “Finalizar”, y desde ahí vamos a la
edición de las propiedades del modelo, una vez ahí, accedemos a la sección
“General/.NET specific” y allí configuramos la siguiente propiedad:

 Access Method: ADO.NET

Tenga en cuenta que es fundamental configurar correctamente la información

referente a la conexión a la base de datos, así como las opciones de ejecución.

Haga clic aquí para ver la demostración

Ahora puede realizarla usted.

No es necesario instalar el cliente del DBMS, ya que en el caso de SQLServer,

ADO.NET utiliza el Data Provider de Microsoft para SQL Server (el cual se instala
con el framework).

Internet Information Services de Microsoft forma parte de la mayoría de las

versiones de Windows. Si lo tiene instalado, al navegar a http://localhost verá una
página de gestión o de ayuda de este servidor. Puede iniciarlo o detenerlo yendo
al menú Start y de ahí a Settings / Control Panel / Administrative Tools /
Internet Information Services.
En la ventana que se abrirá navegue por las carpetas que aparecen a la izquierda:
Internet Information Services / <local host> / Web Sites / Default Web
Site y presione el botón de Start

Distribución
Detallaremos a continuación los pasos necesarios para realizar la distribución de
una aplicación .NET 2 capas.

Para ejecutar las aplicaciones .NET, tanto en el cliente como en el servidor de

aplicaciones, es necesario tener instalado el .NET Framework 1.1, que puede
obtenerse del sitio de Microsoft:

http://msdn.microsoft.com/netframework

En el cliente debe estar instalado además el J# distribution package 1.1, que puede
obtenerse de:

http://msdn.microsoft.com/vjsharp/downloads/howtoget.asp

Para ver los requerimientos de software del .NET Framework y del J# distribution
package referirse a los links de los sitios de Microsoft brindados arriba.

Además debemos tener instalado el cliente del DBMS que se utilice, por más
información ver Requerimientos de software.

Para realizar la instalación de la aplicación en el cliente basta con armar un

paquete de instalación con MSI o CAB , incluyendo los archivos que se
encuentran en el directorio del modelo “/dataxxx/bin”. Una vez armado este
paquete, debe ser instalado en el cliente.

Otra opción es simplemente copiar los archivos del directorio al cliente .

Por más información sobre la forma de armar el paquete de instalación ir a la

siguiente dirección:

http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpguide/html/cpcondeploymentscenarios.asp
 Si se utiliza tipos de datos ExcelDocument, WordDocument o MailMessage, será
necesario registrar la ‘gxoffice2.dll’, de la siguiente forma: regsvr32.exe <Ruta a
gxoffice2.dll>\gxoffice2.dll. Esto es válido tanto para el cliente como para el
servidor de aplicaciones.

Reorganización:
Seguidamente se detallan los pasos necesarios para realizar la reorganización de
la base de datos:

1) Si es la primera instalación y el método de acceso al DBMS es vía Data

Source, entonces se debe crear el data source correspondiente.

2) Si se desea crear la base de datos:

3) Crear en el directorio padre al de producción un archivo

‘reorgpgm.gen’.

4) Ejecutar el ‘reor.exe’. El mismo solamente permitirá ejecutar la

creación si existe el ‘reorgpgm.gen’ y lo borrará luego de ejecutarse
la misma.

Instalación en el servidor web

En una aplicación web es necesario copiar al servidor:

 El directorio bin del modelo (donde se encuentran las dlls de cada

objeto)

 Los java script (*.js)

 Las imágenes

 El archivo Web.config

 Si se usan tipos de datos de Office, es necesario registrar la

gxoffice2.dll
Anexo – Terminología .NET
Managed Code

Es el código que apunta a .NET y que contiene cierta información extra metadata para
describirse a sí mismo. Si bien tanto el “managed code” como el que no lo es, pueden correrse
en una máquina de ejecución, sólo el “managed code” contiene la información que permite
que la máquina de ejecución garantice, por ejemplo, seguridad en la ejecución e
interoperabilidad.

Managed Data

CLR proporciona facilidades de asignación y des-asignación de memoria, y eliminación de

información superflua o basura. Algunos lenguajes de .NET usan “managed data” por defecto
(.NET, Visual Basic.NET, JScript.NET), mientras que otros (C++) no lo hacen.

Dependiendo del lenguaje que se esté usando, el apuntar a CLR puede imponer ciertas
restricciones respecto a las funcionalidades disponibles. Por ejemplo, C++ pierde la herencia
múltiple. Tal como ocurre con el “managed code” y el que no lo es, se pueden tener “managed
data” y no, en las aplicaciones .NET (datos a quienes no se eliminan los datos superfluos o
basura pero que en cambio son controlados por el “managed code”).

Common Type System - CTS

El CLR usa algo llamado CTS para una seguridad de tipo estrictamente reforzada. Esto asegura
que todas las clases sean compatibles entre sí, describiendo los tipos de un modo común. CTS
define como trabajan los tipos en la máquina de ejecución (sus declaraciones y usos), lo que
habilita a los tipos en un lenguaje a operar con tipos en otro lenguaje, incluyendo el manejo
entre distintos lenguajes por excepción.

Además de asegurar que los tipos sean usados adecuadamente, la máquina de ejecución
también asegura que el código no intente acceder la memoria que no le ha sido asignada (es
decir que es un código con seguridad de tipo).
Assemblies

Los programas .NET son construidos a partir de "Assemblies" (Ensamblados). Un Assembly es

un grupo de código y metadata compilados y presentados en una versión, que forman una
unidad funcional atómica.

Todos los Assemblies, contienen un Manifiesto que contiene el nombre, versión y ubicación
del Assembly, además de una lista de los archivos que forman el Assembly, las dependencias
que tiene el Assembly, y las funcionalidades que son exportadas por el Assembly.

Cuando se apunta a .NET con su compilador, lo que se genera no es un código nativo. Es un

pequeño envoltorio PE (Ejecutable Portátil), en torno a tres bloques de datos. El PE es un
formato binario usado para contener programas Win32. Los archivos PE contienen un
programa ‘stub’ MS DOS (si usted ha intentado correr un ejecutable Win32 desde DOS y ha
visto el mensaje “Este programa requiere Microsoft Windows", lo que usted ha visto es el
‘stub’ en acción).

Los binarios .NET contendrán entonces un ‘stub’ Win32 – para usar .NET para correr el
programa o para decir algo como: “Este programa requiere .NET para ejecutarse” si no está
disponible.

El primer bloque de datos dentro del envoltorio PE es el mismo IL. El IL luce aproximadamente
como un assembler. Este es el bit que realmente se compila y ejecuta.

El segundo se llama metadata. Describe el contenido del archivo, por ejemplo, qué métodos
proporciona, qué parámetros toma y cuáles retorna. También contiene claves públicas de
componentes externos.

El tercero es el manifiesto. Describe qué otros componentes necesita el ejecutable para poder
asegurar que los componentes externos son los que el ejecutable piensa que son. Al correr el
ejecutable, el CLR usa compilación Just-In-Time. A medida que cada método es invocado en el
ejecutable, se le compila al código nativo; las siguientes llamadas al mismo método no deben
someterse a la misma compilación; de esta forma, la demora solo tiene lugar en una ocasión.
La compilación JIT trae a colación algunos temas. Uno es que requiere recursos, en particular
memoria y tiempo del procesador. Para resolver esto, MS tiene dos compiladores JIT: uno
normal, que optimiza el código compilado bastante bien pero puede consumir mucho tiempo
del procesador y/o memoria, y un "EconoJIT". EconoJIT puede no optimizar tanto los códigos,
pero consume menos memoria y tiempo del procesador al ejecutarse. También permitirá que
su programa de ejecución descarte la forma compilada de un método, liberando así la
memoria, a cambio de tener que compilarlo nuevamente.

GAC (Global Assembly Cache)

Es un área de memoria reservada que utiliza .NET para almacenar los assemblies de las
aplicaciones que corren en una máquina. Para que un assembly sea almacenado en la GAC,
debe tener un "Strong Name".

Por más información ir a:

http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpguide/html/cpconglobalassemblycache.asp

Strong Name

Un "Strong Name" determina la identidad de un assembly, compuesta por su nombre y

versión, más una clave pública y una firma digital. El framework .NET ofrecen la posibilidad de
asignar un "Strong Name" a un assembly.

Por más información ir a:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconstrong-
namedassemblies.asp