Manual Del Generador Punto Net

Manual del Generador .
NET
GeneXus 9.0
Enero 2007
Introducción
Objetos
Ambientes
Requerimientos
Requerimiento software
Plataforma .NET
GeneXus
Manejador de base de datos
Servidor Web
Requerimientos de hardware
Modelo Web
Configuración de un modelo
Propiedades específicas
General section
.Net Specific Section
ADO .NET Specific Section
Client Server specific Section
Opciones de ejecución
Generación de objetos
Compilación
Avanzados
Generación de trace
Archivo de configuración
Puesta en producción
Instalación en el servidor
Requerimientos
Instalación en el Cliente
Modelo GUI
General
.NET Specific Section
ADO.NET Specific Section
Transaction configuration Section
Client Server
Compilación
Avanzados
Archivos específicos
Instalación en el servidor
Instalación en el Cliente
Modelo GUI – Aplicaciones Distribuídas
Arquitectura
Propiedades Específicas
Model Properties
Procedure Properties
Transaction Properties
Work Panel Properties
Servidores de aplicaciones
IIS como servidor de aplicaciones
Servidor de aplicaciones GeneXus
Ventajas y desventajas
Avanzados
Pool de conexiones
Archivos de configuración
Requerimientos
Generalidades
Acceso a la base de datos
Cache de sentencias
Tipos de datos
Generación de programas de reorganización
Transactional Integrity
Transacciones de más de un nivel (GUI)
Smart Static Panels (Web)
Llamadas a Stored Procedures
Comando Submit
Submits queued components (COM+)

Requerimientos
Generación
Configuración, ejecución
Consideraciones
Publication assistant (GUI)
Descripción
Requerimientos
Comando Csharp
Permisos .NET
Permisos para ejecución de assemby remoto
Autorizacion por Web Panel
Apéndice
Tips
¿Como incluir una dll COM ?
¿Como generar código de maquina a partir de código IL ?
Glosario
.Net remoting
.NET Channel Services
ADO.NET
ASP .NET Configuration Section
Assembly
Code Access Security
COM+
Common Type System - CTS
GeneXus .NET Generator

Global Assembly Cache (GAC)
Log4net
Managed Code
Managed Data
ODBC
Session state
Strong Name
WMI (Windows Management Instrumentation)
FAQ: Errores comunes
Problemas en ejecución
Problema en compilación
Problemas en reorganización
Introducción
El generador .NET, permite el diseño de “Aplicaciones Web y GUI”, a través de la
plataforma .NET, asi como aplicaciones GUI distribuidas (3 capas)
El generador aprovecha todas las cualidades de .NET, brindando las ventajas que este
tiene (reutilización de classes, seguridad, deployment, etc)
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, procedimientos, web services y reportes con salida PDF.
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).
Objetos
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.
Ambientes
Las aplicaciones se comunican con la base de datos a través de ADO.NET u ODBC,
siendo el primero el método nativo de acceso (y el recomendado). Los posibles DBMS a
utilizar con el generador .NET, son todos los DBMS soportados por GeneXus: DB2
UDB for iSeries, DB2 Universal Database, Informix,MySQL, Oracle, PostgreSQL y
SQL Server. En el caso de optar por ADO.NET tener en cuenta que no es soportado por
todos los DBMS (ver más en Requerimientos).
El generador también nos brinda la posibilidad de realizar “Mantenimiento de la base de

datos”, es decir crearla y reorganizarla.
Requerimientos
Requerimiento software
PLATAFORMA .NET
Para el desarrollo de aplicaciones es necesario instalar:
Release del Framework Redistributable 1.1 y J# Version 1.1 Redistributable Package o
Release del Framework Redistributable 2.0 y J# Version 2.0 Redistributable Package
Para ver los requerimientos y descargarlos de forma gratuita dirigirse a:
.NET
.NET Framework http://msdn.microsoft.com/netframework
J# distribution
http://msdn.microsoft.com/vjsharp/downloads/howtoget.asp
package
El Visual J# es requerimiento para las aplicación GUI y para los reportes PDF de las
aplicaciones Web.
GENEXUS
- Development environment GeneXus 9.0
- Generador .NET 9.0
MANEJADOR DE BASE DE DATOS

SQL Server
ADO.NET utiliza el Data Provider de Microsoft para SQL Server (el cual se
instala con el framework). No se requiere el cliente SQL Server
Oracle
Se debe tener el Cliente de Oracle versión 8.1.7.5 o superior, de esta forma se
instala el Data Provider correspondiente. El valor “Server Name” de las Dbms
option hace referencia al Service Name definido en la instancia del Oracle.
La implementación utiliza el Data provider de Microsoft para Oracle
(System.Data.OracleClient), el cual requiere el cliente.
DB2 UDB for iSeries

Se necesita la V5R3 del iSeries Client Access con un service level igual o
superior a SI20055. La menor versión testeada del server es la V5 R1
Se puede obtener desde:http://www-03.ibm.com/servers/eserver/iseries/access/casp.html
Al crear 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.
DB2 Universal Database
Se necesita tener instalada la versión 8.1.3 o superior.
La dll es IBM.Data.DB2.dll, se debe copiar a los directorios gxnet/bin si la
aplicación es web o gxnetwin/bin win.
MySQL
MySQL soporta diferentes motores, GeneXus utiliza el InnoDB
(http://dev.mysql.com/doc/mysql/en/InnoDB.html).
La menor versión soportada del server es 3.23.58.
El driver cliente para .Net se puede obtener desde:
http://sourceforge.net/projects/mysqldrivercs. Luego de instalado se debe tener los archivos:
mysql.dll – Biblioteca .Net de acceso a MySQL
MySQLDriverCS.dll – se debe copiar bajo el directorio gxnet/bin si la

aplicación es web o gxnetwin/bin win
Informix
El acceso ADO.NET, es soportado a partir del Upgrade 2 del generador
El Data Provider (que viene con el IBM Informix Client SDK V2.90.TC4) se
puede obtener desde:
http://www14.software.ibm.com/webapp/download/preconfig.jsp?id=2005-08-
15+14%3A41%3A25.229714R&S_TACT=104CBW71&S_CMP=&s=
Luego de instalado, para crear un modelo se debe copiar la dll

IBM.Data.Informix.dll al directorio gxnet/bin si la aplicación es web o
gxnetwin/bin win.
Dicha dll se encuentra en el directorio: <Program Files>\IBM\Informix\Client-
SDK\bin
Las posibles keys del connection string que se pueden setear en las DBMS
Properties “Additional connection string Attributes” están en:
http://publib.boulder.ibm.com/infocenter/idshelp/v10/index.jsp?
topic=/com.ibm.netpr.doc/netprmst76.htm
Se debe configurar en las DBMS options del modelo
Server Name = El Host name del servidor
Informix server instance = El nombre de la instancia del server
Previo al upgrade 2 es necesario acceder con ODBC, la versión del DBMS

puede ser 7.0 o Informix Foundation 2000. En el cliente debe estar instalado el
cliente con la versión correspondiente. Se recomiendan los drivers de Intersolv o
Informix.
PostgreSQL
El acceso ADO.NET, es soportado a partir del Upgrade 2 del generador
El data provider es distribuido por el generador y consiste en dos dlls:
-Npgsql.dll y
-Mono.Security.dll,
es open source (LGPL) y se pueden obtener, junto con la documentación desde:

http://pgfoundry.org/projects/npgsql (Npgsql 1.0RC1: Npgsql1.0RC1-bin-
ms1.1.zip)
Npgsql is a .Net data provider for Postgresql. It allows any program developed
for .Net framework to access database server. It is implemented in 100% C#
code. Works with Postgresql 7.x and 8.x. Y no requiere instalar ningun cliente.
Las posibles keys del connection string que se pueden setear en las DBMS
Properties “Additional connection string Attributes” estan en:
http://npgsql.projects.postgresql.org/docs/manual/UserManual.htm
SERVIDOR WEB
En el caso de implementar una aplicación Web deberá contar con el servidor

web Internet Information Server 5.0 o superior (Por más información ver
requerimientos de ASP.NET del .net framework 1.1 o 2.0).
IMPORTANTE: El mismo debe ser instalado antes del .NET Framework. Si no

fuera así ocurrira el error 404 (resource cannot be found), ver solución aquí.
Los requerimientos en el servidor de producción son similares, por mas detalles ver las
secciones de “puesta en producción”
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.
Modelo Web
1. Crear un modelo de prototipo o producción con el generador .NET
 Language = .NET
 User Interface = Web
2. Configurar la Model Property Access Method en ADO.NET|ODBC
3. Configurar las Dbms Options del modelo:
 Access technology to set: ADO.NET|ODBC
 Database name: <Nombre de la base de datos>

 Server name: <nombre de servidor o IP>[,<Puerto>]
 Use trusted connection: No
 User id: <usuario>
 User password: <password>
4. Configurar las propiedades de ejecución :
 Compilador (csc.exe, se encuentra bajo directorio de instalación del

framework)
 Nombre del directorio virtual (services por defecto)
5. Ejecutar la creación de la base de datos.
6. Generar programas
7. Compilar y Ejecutar
Al compilar Webxxx se genera el assembly Hwebxxx.dll (código IL) bajo el directorio

bin y se agrega una entrada en el web.config o no (dependiendo de la propiedad
HttpHandlerFactory )
La salida de la compilación se envia al archivo Runout.log.
En ejecución se invoca al Hwebxxx.aspx

Notas:
 En el caso de configurar trusted connection (paso 3) es necesario configurar

permisos de ASP.NET
 En el caso de utilizar acceso ODBC es necesario configurar en las DBMS
Options la Access technology to set: ODBC (Paso 3 ) y la Model Property
Access Method en ODBC también. Si se desea conectarse a travez de un data
source ODBC, el mismo debe ser de sistema.
 Luego de compilar, GeneXus creará un directorio virtual con el nombre
especificado en el IIS local apuntando al <directorio físico de la
KB>\<dataxxx>\web.
 En caso de ejecutar desde un directorio de la red interna, para los pasos 5 y 7,
tener en consideración la configuración de: Permisos .NET y Permisos del
servidor de Web para ejecutar una aplicación.
Propiedades específicas del Generador .NET
Para ingresar a estas propiedades debe ir a: “File/Edit Model/ Botón Properties”.
GENERAL SECTION
Generate developer menu makefile
Indica si se generarán los archivos necesarios para compilar el “developer menu”.
El valor en NO es útil para evitar el armado del “makefile” del “developer menu”, este
es muy costoso ya que debe generar todos los response file (*.rsp) cada vez que se
compila un objeto.
Valor predeterminado: Yes
.NET SPECIFIC SECTION
.Net Application Namespace
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
propiedad.
Es útil para usuarios avanzados que quieran algún tipo de deployment en el GAC
(Global Assembly Cache).
Valor predeterminado = GeneXus.Programs
Generate strong named assemblies
Determina que los objetos main y/o dlls (assemblies) generados tengan un nombre
único o no. Esto permite acceder a un conjunto de ventajas importantes que provee el
.Net Framework, como deployment en el GAC o configuración de seguridad para el
assembly
Valores
Yes: El programa generado tiene un “Strong Name”.
No: El programa generado no tiene un “Strong Name”.
Valor predeterminado: NO
Para generar el “Key” que identifica al objeto, el generador al momento de compilar

busca un key.snk en el directorio dataxxx, si no hay: genera uno. (se requiere el SDK
en el ambiente de desarrollo para ejecutar el sn.exe y generar el archivo con la Key).
Además se debe configurar en la variable de ambiente “path” el camino a sn.exe para

que la encuentre el compilador ( "C:\PROGRAM
FILES\MICROSOFT.NET\SDK\V1.1\bin" ), de lo contrario da el error "Before
compile error: The system cannot find the file specified"
Los programas estándar provistos por el generador tienen strong names independiente
del valor de la propiedad.
Assemblie versión number
Determina el numero de versión a asignar a los assemblies que tienen strong name. La
propiedad solo aplica cuando Generate strong named Assemblies esta en Yes
Valor predeterminado: 1.0.0.0
Esta información de versión se almacena en generación en el archivo

GxAssemblyInfo.cs
Compiler Flag
La información de esta propiedad se incluirá en el .rsp que se usa para compilar los
assemblies.
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 ).
Config HttpHandlers Section
La información de esta propiedad determina cómo se mapean los assemblies en

ejecución.
Valores
HttpHandler for each object: Una entrada en el web.config por cada assembly.
Aquí se mapea el request del aspx con el assembly GeneXus.Programs.object
(bin\object.dll)
HttpHandlerFactory: Hay una sola entrada para todos los objetos en el

web.config, en donde se indica un objeto al que pedirle el mapeo
ASHX: No hay mapeos en el web.config, se genera un archivo ashx por cada

objeto que realiza el mapeo con el assembly GeneXus.Programs.object
El valor HttpHandler for each object es más rápida en ejecución pero mas lento en la
carga inicial. Además permite tener objetos (*.aspx) no generados con GeneXus, con
HttpHandlerFactory esto no es así.
HttpHandlerFactory es mas rápido para prototipar pero mas lento en cada llamada
porque el mapeo se resuelve en cada requerimiento. Esta opción puede enviar
mensajes de error poco descriptivos, lo que dificulta la prototipación.
El valor ASHX, es similar a Handler Factory, crea un archivo físico con el nombre del
objeto y extensión ashx, el cual es invocado en ejecución.
Valor predeterminado = HttpHandler for each object
Access Method
Determina qué tipo de acceso se va a utilizar para acceder a la base de datos. El
método de acceso especificado será utilizado para acceder a cada uno de los data
stores.
Valores
ODBC: Acceso vía ODBC
ADO.NET: Acceso vía ADO.NET
Valor predeterminado = Depende del Dbms asociado al data store Default.
ADO .NET SPECIFIC SECTION
Propiedad Enable Caching
Esta propiedad permite definir si se habilita el “cache” de sentencias.
Valores
Yes: Hablita el caching
No: Deshabilita el caching
Valor predeterminado = No
Caching Section
Las siguientes tres propiedades aplican cuando la propiedad Enabled Caching esta en
Yes
Propiedad Hardly Ever TTL (mins)
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)

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
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
Log Level
Esta propiedad permite configurar el nivel de trace de acceso a la base de datos con
conexión ADO.NET.
Valores
0. Off
1. Fatal
2. Error
3. Warn
4. Info
5. Debug
6. All
Valor predeterminado: Off
Esta propiedad escribe el tag <log4net threshold=...> del archivo web.config y

client.exe.config (para modelos Web y Gui respectivamente). En el caso de modelos
web tambien se escribe el tag <trace enabled=true />
CLIENT SERVER SPECIFIC SECTION
Propiedad Maximum Cached cursors per connection
Uno de los costos más importantes en las operaciones ODBC/ ADO.NET 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.
Valor predeterminado: 100
Para ingresar a estas propiedades debe ir a: “File/Edit Model/ Botón Execution”.

Compiler path
Determina el path del compilador (csc.exe), este lo provee el framework SDK y se

encuentra bajo el directorio de instalación del mismo en <NET
frameworkpath>\csc.exe, siendo el < NET frameworkpath> =
WINNT\microsoft.net\vx.x.xxxx
Virtual directory
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.
El proceso de generación de un objeto consta de dos etapas:
GENERACIÓN
Luego de especificar un objeto al generarlo el generador crea por cada objeto:
- un archivo con el código fuente en lenguaje c# (.cs),

- Si es un web panel o un objeto main, se crea archivo con el mismo nombre
del objeto y con extensión '.rsp'. Este archivo contiene la información
necesaria para compilarlo (fuentes que se incluyen, referencias, etc).
- Si es main además se crea un archivo bld<nombre_del_objeto>.cs que

ejecuta el armado del objeto y los relacionados (llamados desde este). Dentro
de los relacionados no son incluidos los otros objetos que son main ya que se
arman compilándolos específicamente.
- Si referencia SDTs, collections o Business Components, se crea un

type_<nombre_del_sdt>.cs con la definición del tipo estructurado
referenciado.
- Tambien se crea el archivo gxcommon.rsp cuyo objetivo es armar un

assembly (con el mismo nombre) que incluye los objetos comunes a todos
los assemblies (SDTs, collections).
COMPILACIÓN
El código se compila (desde el dialogo F5 del generador) y el log con el resultado de la

compilación se despliega en la pantalla y se graba en el archivo RunOut.log
Como resultado de la compilación se genera una dll con el código común de .NET (IL),
este es supervisado, en tiempo de ejecución, por un intérprete (CLR) que permite
ejecutarlo convirtiéndolo a código de maquina.
El archivo Web.config o el cabezal del objeto (dependiendo de la property config

httphandler section) contienen la información de configuración de la aplicación web, en
este se asocia cada dll con una página virtual con extensión ASPX. No existe un
archivo físico aspx. Únicamente con el valor Ashx de dicha property se genera un
archivo físico por cada objeto.
El archivo Web.config se genera a partir del GXCFG.Web, el cual tiene una entrada
para cada objeto y es el UpdateConfigWeb quien ingresa la información al Web.Config
luego de la compilación. El archivo web.config define un conjunto de tags no
propietarios dentro de la sección system.web.
Al igual que el resto de los generadores, el generador .NET se apoya en un conjunto de

programas estándar. Estos programas tienen StrongName, lo que significa que son
identificables, con un nombre único en el universo .NET.
Los programas generados también tiene la posibilidad de configurar strong name (no así
los assemblies de la reorganización). Esto es útil para hacer deployment automático en
el Global Assembly Cache (GAC)
Avanzados
GENERACIÓN DE TRACE
Para habilitar la generación de trace (archivo de log) de la aplicación, se deben

configurar la propiedad Log level del modelo. Esta agrega dos configuraciones en el
archivo web.config luego de la compilación
1. Habilita la configuración del trace con el tag “threshold”
<log4net threshold="<Value>">
2.Habilita el archivo de log
<system.web>
<trace enabled="true" />
Con el paso 1 si el <Value> es diferente de OFF se generan los mensajes de log, pero se
envían al trace de ASP.NET y no es posible acceder al archivo de log, para esto se
configura el paso 2
Por defecto los modelos Web tiene como “root appender” el ASPNetTraceAppender,
eso significa que no genera un archivo como log, si no que manda los mensajes de log
al trace de ASP.NET.
Luego de generado el log de las aplicaciones Web, para poder visualizarlo se puede
acceder a la URL: http://servername/dirvirtual/Trace.axd
Cuando se ejecuta una aplicación Web remota, se debe incluir la opción localOnly
="false" si se desea visualizar el trace desde la máquina de los clientes.
Sino, solo se podrá visualizar el trace desde el propio servidor web. Para visualizar el
trace desde los clientes, se debe incluir la entrada:
<system.web>
<trace localOnly="false" enabled="true" />
Notas:
- La generación de archivos de log puede degradar la performance de la aplicación

por lo cual se recomienda en producción tener apagada la misma.
- Si se tiene <log4net threshold="OFF"> el log no se genera (no se generan mensajes

desde la gxclasses.dll), y no se toma en cuenta ninguna otra configuración (por ejemplo
trace o root).
- Desde aplicaciones web es posible generar trace a archivo.
- Por más información acerca del log4net se puede acceder a la URL:

http://log4net.sourceforge.net/
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”.
web.config
Se crea cuando se genera aplicaciones web y es utilizado cuando corremos las

aplicaciones bajo 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” y su estructura es algo similar a:
<configuration>
<appSettings>
<add key="EVENT_AFTER_COMMIT" value="" />
<add key="Connection-Default-DataSource" value="mydatasource" />
….
</appSettings>
<log4net threshold="OFF">
<appender name="ASPNetTraceAppender"
….
</layout>
</appender>
<root>
</root>
</log4net>
<system.web>
<trace enabled="false" />
<httpRuntime …
< identity impersonate …
<sessionState …
<httpHandlers>
</httpHandlers>
</system.web>
</configuration>
La sección System Web no es rescrita por el generador, la sección Appsetting si lo es
luego de cada compilación (aquí se almacenan propiedades del modelo y
configuraciones del generador).
Nota: Este web.config también se utiliza en aplicaciones distribuidas, cuando el servidor

de aplicaciones corre bajo el IIS, más información en sección Aplicaciones distribuídas
Conexión a la base de datos
La información de conexión a la base de datos queda almacenada en el archivo

web.config con el formato
<appSettings>
<add key="Connection-Default-DataSource" value="mydatasource" />
<add key="Connection-Default-User" value="Elj20MqY44RPdvT8FEpDD0==" />
Estos tags no son propietarios del framework, son definidos por el generador. El
contenido de los mismos, en algunos casos sí requieren un formato estándar predefinido
por la plataforma. Por ejemplo el string de conexión a la base de datos en modelos
ADO.NET con SqlServer podría ser:
<add key="Connection-Default-Opts" value=";Integrated Security =No; Max Pool

Size = 50; Min Pool Size=10" />
Identity impersonate
Esto permite que los objetos web corran con el usuario que el IIS le pasa a la plataforma
.net, de lo contrario, los procesos corren con la cuenta “machine” (usuario ASP.NET).
Se especifica dentro de la sección System.Web con el tag
<identity impersonate="true" />
Consideraciones:
- Es necesario si se quiere utilizar trusted connection para la conexión a la base

de datos (Sql Server), de lo contrario ejecuta con el usuario ASPNET.
- Reportes PDF: En caso de tener identity impersonate="true" el usuario que

ejecuta en el IIS de la página debe tener derecho de escritura sobre el
"C:\Documents and Settings\<nombre del webserver>\<ASPNET\Local
Settings\Temp" con IIS 5 o superior. Si se esta con IIS 6.0 o superior (windows
2003) se deben dar permisos sobre el directorio
C:\Windows\Temp\...\iTextdotNET. (pero el mismo es configurable) .
De lo contrario da un error Access to the path "C:\DOCUME~1\ARMIN-
NB\ASPNET\LOCALS~1\Temp\e8ebd99f-17de-4447-83f8-
35769f67bd23\iTextdotNET”
SessionState
Para implementar el manejo de sesiones (Tipo de dato Websession) el generador utiliza

el HttpSessionState provisto por el framework.
Existen tres modos de almacenar la session state:
1 - Inproc que usa el aspnet_wp.exe.
2 - Stateserver para cuando se tiene más de un servidor
3 - Sqlserver que en lugar de utilizar la memoria del servidor web para almacenar
información grabada en las sesiones, utiliza tablas de SQL Server.
Inproc es el mecanismo default que implementa el generador. Cuando se recicla el

aspnet se pierden las variables de session.
StateServer Se puede almacenar la websession dentro del espacio de memoria de un

proceso llamado aspnet_state.exe.
Esto es útil en prototipación para mantener la websession ya que luego de reciclar el

aspnet_wp o compilar los objetos y subirlos nuevamente se pierde la Websession.
Para implementarla hay que primero levantar el servicio ASP.NET State Service
(aspnet_state.exe) en el equipo que vaya a ser el que mantenga la sesión. Luego, en el
web.config, hay que agregar la siguiente línea:
<system.web>
<sessionState
mode="StateServer"
stateConnectionString="tcpip=name_pc:42424" />
....
....
</system.web>
El atributo stateConnectionString contiene la IP y el puerto del equipo utilizado para
mantener la sesión. El puerto default es 42424.
Sqlserver, para esto se debería:
1 - cambiar el web.config con el string de conexión
<system.web>
<sessionState mode="SQLServer"
sqlConnectionString=" Integrated Security=SSPI;data source=dataserver;"
2 - agregar al machine.config la linea
<httpmodules>
<add name="sessionState" type="System.Web.State.SessionStateModule" />
</httpmodules>
Es posible configurar el tiempo que viven las variables de sesión. Por defecto caducan,
las variables websession pierden su valor, con un timeout de 20 minutos.
Es posible configurar dicho tiempo desde
<sessionState mode="InProc"
cookieless="false"
timeout="20"/>
Por mas información: http://msdn.microsoft.com/library/default.asp?url=/library/en-

us/cpguide/html/cpconsessionstate.asp
En w2003 Server es posible configurar el timeout por directorio virtual. Para ello en las
propiedades del directorio virtual, configurar el valor desde
Virtualdirectory\Configuration\options\Enabled Session State
Http Execution Timeout
Existe una forma de configurar el timeout de los requests en aplicaciones .Net (tanto
aplicaciones Web como aplicaciones tres capas hosteadas en el IIS)
En aplicaciones Web si el request de una página demora más de 90 segundos se enviará

un mensaje de Request Timeout al browser.
Para que no den timeout se deberá crear en la seccion System.Web del archivo
web.config lo siguiente:
<httpRuntime executionTimeout="<segs>"/>
Siendo <segs> la cantidad de segundos que se desea esperar, por ejemplo 3600.
Por mas información de la sección HttpRuntime
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/cpgenref/html/gngrfhttpruntimesection.asp
Generación trace a archivo – Rolling file
Es posible configurar un modelo Web para que también genere un archivo de texto,
agregando las siguientes entradas en el archivo web.config:
1.
<appender name="RollingFile" type="log4net.Appender.RollingFileAppender">
<file value="C:/<directorio del modelo>/web/log/client.log"/>
<appendToFile value="true"/>
<maximumFileSize value="9000KB"/>
<maxSizeRollBackups value="4"/>
<layout type="log4net.Layout.PatternLayout">
<conversionPattern value="%d{HH:mm:ss,fff} [%t] %-5p %c{1} [%x] - %m%n"/>
</layout>
</appender>
Se deben utilizar las barras “/” para indicar el directorio de la aplicación.
2. Incluir la entrada <appender-ref ref="RollingFile"/>
Entrada dentro del Tag root, por ejemplo:
<root>
<level value="DEBUG"/>
<appender-ref ref="RollingFile"/>
<appender-ref ref="ASPNetTraceAppender" />
</root>
Es importante diferenciar los “appenders” que estén como “root”, que son los appender
que va a tomar en cuenta log4net cuando vaya a imprimir los mensajes de log. En este
caso, por tener configurado los valores "RollingFile" y “ASPNetTraceAppender",
generará el archivo client.log en el directorio web/log debajo del directorio del modelo
y también se podrá acceder al trace a través de la URL:
http://servername/dirvirtual/Trace.axd
En caso de tener solo un appender:
<root>
<level value="DEBUG" />
</root>
No se generará el archivo client.log, solamente se podrá acceder al trace a través de la

URL: http://servername/dirvirtual/Trace.axd
Si en el archivo web.config de una aplicación Web se configura:
<log4net threshold="ALL">
y en el Tag root:
<root>
<appender-ref ref=" RollingFile" />
</root>
no se tomarán en cuenta las configuraciones:
<trace enabled="true" />
<trace localOnly="false" enabled="false" />
porque estas configuraciones son válidas únicamente para el appender:
INSTALACIÓN EN EL SERVIDOR
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, htmls, *.css y cualquier contenido estático deseado
- El archivo Web.config
- Si se usan tipos de datos de Office, es necesario registrar la gxoffice2.dll

REQUERIMIENTOS
Los requerimientos son similares al ambiente de desarrollo.
• Servidor Web
- Internet Information Server 5.0 o superior
- .Net Framework Redistributable 1.1 o 2.0 (recomendable: Realizar la

instalación del mismo a partir del Windows component update provisto por el
setup de Visual Studio .NET)
- Cliente de Base de datos (no requerido en sql server)
• Servidor de Base de Datos
INSTALACIÓN EN EL CLIENTE
Cliente Web: Solamente alcanza con un browser.
Para el caso de Internet Explorer la mínima versión soportada es I.E. 6.0.
Modelo GUI
 Language = .NET
 User Interface = Win
2. Configurar la propiedad del modelo Access Method en ADO.NET|ODBC

3. Configurar las Dbms Options del modelo:
 Access technology to set: ADO.NET|ODBC

 Server name: <Nombre del servidor>,[<Puerto>]
4. Configurar las propiedades de ejecución:

 Compilador: csc.exe (bajo directorio de instalación del framework)
5. Ejecutar la creación de la base de datos.
 Build / Create (se asume que existe la base de datos)
 Build / Build All
Ejecutar el diálogo de ejecución (F5). Compilar los objetos main o el

“Developer Menu”
 Ejecutar el objeto
Al compilar por ejemplo un Work Panel Main Wkp01 se genera bajo el directorio
bin
- el objeto Uwkp01.exe y
- el assembly uWkp01.dll o Fld01.dll, siendo Fld01 el nombre del fólder

GeneXus donde se encuentra el objeto. Esto depende de la propiedad del modelo
Assemblies structure
La salida de la compilación se envía al archivo Runout.log.
En caso de ejecutar desde una red tener consideraciones en la configuración de

Permisos .NET para los pasos 5 y 7
GENERAL
Generate developer Menu makefile
.NET SPECIFIC SECTION
Application Namespace
StrongName
Version Number
Compiler Flag
Access Method
ADO.NET SPECIFIC SECTION
Assemblies Structure
Esta propiedad determina el mecanismo de armado de los assemblies en un modelo .Net

Win con acceso a la base de datos ADO.NET
Valores
By folder: se crea un assembly por cada objeto folder del modelo
By Main: se crea un assembly por cada objeto main del modelo
By folder es la forma en que se generan los assemblies (las dlls), esto implica que al
mover un objeto de folder, se deben regenerar y compilar todos los objetos
involucrados.
By Main - crea una dll por el objeto y otra por el stub. Este método de armado de
assemblies es más natural y similar al comportamiento de los otros generadores Gui.
Valor predeterminado: By Folder
Enabled Caching
Caching Section
Log level
TRANSACTION CONFIGURATION SECTION
Add/Update/Confirm/Delete Button Bitmaps
Permite cambiar el bitmap asociado al botón “Confirm” en vez del caption

correspondiente a cada caso.
Valores
Los bitmaps predeterminados son:
Agregar (gxconfirm_add.gif)
Confirmar (gxconfirm_cnf.gif)
Borrar (gxconfirm_dlt.gif)
Modificar (gxconfirm_upd.gif)
CLIENT SERVER
Maximum cached cursor
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”.

Compiler path
Determina el path del compilador (csc.exe), este lo provee el framework SDK y se

encuentra bajo el directorio de instalación del mismo en <NET
frameworkpath>\csc.exe, siendo el < NET frameworkpath> =
WINNT\microsoft.net\vx.x.xxxx
El proceso de generación de un objeto consta de dos etapas:
GENERACIÓN
Luego de especificar un objeto al generarlo el generador crea por cada objeto:
- un archivo <nombre_del_objeto>.cs con el código fuente en lenguaje C#.
- un archivo <nombre_del_assembly>.rsp con las referencias que permiten

armar el assembly que incluye el objeto. Dependiendo de la propiedad del
modelo Build Assemblies, el assembly se compone de todos los elementos
del folder que contiene al objeto (en caso de estar configurado “By Folder”),
o de todo el arbol de calls si es un objeto main (en caso de estar configurado
“By Main”).
- Si es main se genera un archivo call_<nombre_del_objeto>.cs con el codigo

necesario para instanciar el objeto dentro del assembly correspondiente, y un
archivo bld<nombre_del_objeto>.cs que se encarga de compilarlo a un exe.
- Se crea el archivo gxcommon.rsp cuyo objetivo es armar un assembly (con

el mismo nombre) que incluye los objetos comunes a todos los assemblies
(SDTs, collections).
- En el caso de estar configurado el armado de assemblies con la opción By

Fólder, se crea un gxobjects.rsp cuyo objetivo es armar un assembly (con el
mismo nombre) que incluye los objetos que se encuentran en el fólder
principal.
COMPILACIÓN
El código se compila (desde el dialogo F5 del generador) y el log con el resultado de la

compilación se despliega en la pantalla y se graba en el archivo RunOut.log
Se genera, dependiendo de la propiedad Assemblies structure:
- con el valor By folder una dll (assembly) por cada Objeto folder definido en el
modelo y un objeto gxobjects.dll para el folder root,
- con el valor By Main se genera una dll (assembly) por cada Objeto Main
Además se genera un exe por cada objeto main que invoca a dicho assembly.
El código es generado en un lenguaje común de .NET (IL), el cual supervisado, en

tiempo de ejecución, por un intérprete (CLR) que permite ejecutarlo convirtiendolo a
código de maquina
Avanzados
Para habilitar la generación de trace (archivo de log) de la aplicación, se debe agregar

una entrada en el archivo client.exe.config:.
<log4net threshold="Value">
donde “Value” puede tener alguno de los siguientes valores:
• ALL
• DEBUG
• INFO
• WARN
• OFF
La elección de cada valor depende del nivel de detalle que se desee visualizar en el
archivo de log.
El archivo client.exe.config se encuentra en el directorio del modelo (DataXXX).
El valor por defecto de la salida (“root appender”) es “RollingFile”, esto significa que
se generará un archivo.
El archivo generado será por defecto client.log y se generará en el directorio

DataXXX\bin.
Si se desea ejecutar la aplicación por fuera de GeneXus, por ejemplo ejecutando el exe
del objeto directamente desde el directorio DataXXX\bin, se debe configurar el
client.exe.config de ese directorio.
Es posible configurar un conjuno de propiedades del appender Rolling File como la

cantidad de archivo particionados de log (maxSizeRollBackups) y el tamaño de cada
archivo (maximumFileSize).
Por ejemplo:
<appender name="RollingFileAppender" … >
<file value="server.log"/>
</appender>
ARCHIVOS ESPECÍFICOS
Archivo Client.exe.config
Este archivo contiene básicamente la información para la conexión a la base de datos, la

información de propiedades del modelo 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.
Tiene una estructura:
<configuration>
<configSections>
<sectionGroup name="datastores">
</sectionGroup>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net"/>
</configSections>
<datastores>
<Default>
<add key="Connection-Default-TrnInt" value="1"/>
</Default>
</datastores>
<appSettings>
<add key="MODEL_NUM" value="2"/>
</appSettings>
<appender name="ConsoleAppender" type="log4net.Appender.ConsoleAppender">
….
</appender>
<appender name="RollingFile" type="log4net.Appender.RollingFileAppender">
</appender>
<root>
<appender-ref ref="RollingFile"/>
</root>
</log4net>
</configuration>
Archivos GXResources.dll y Messages.<lenguaje>.dll
El GXResources.dll guarda imágenes. El messages.<lenguaje>.dll contiene la

información de textos por lenguaje
Éstos se generan en momento de compilación.
INSTALACIÓN EN EL SERVIDOR
La plataforma .Net no utiliza el registry y permite configurar las versiones dlls a

utilizar, por lo que instalar en el servidor es simplemente hacer un xcopy del directorio
bin. El generador provee una herramienta, Publication Assistant, para hacer el Deploy
automático de la aplicación.
Requerimientos
Los requerimientos son similares al ambiente de desarrollo.
• Servidor GUI
- Visual J#
- .Net Framework
• Servidor de Base de Datos
INSTALACIÓN EN EL CLIENTE
- Tener en cuenta permisos .Net para aplicación en Red
- Conectividad a la base de datos
Modelo GUI – Aplicaciones Distribuidas

Es posible generar aplicaciones distribuidas, que se ejecuten en diferentes capas,
utilizando el protocolo de comunicación .Net remoting entre ellas, optimizando así los
recursos y ampliando la escalabilidad.
Se creará una aplicación distribuida donde:
Ejecutando en el cliente tendremos un Work Panel main (Wkp01) que invoca a un

procedimiento (Prc01) para dar de alta registros en una tabla, pasándole como
parámetros todos los datos para realizar el insert en la tabla.
Ejecutando en el servidor de aplicaciones tendremos el procedimiento que realiza el

insert sobre la tabla.
Nota: Se simulará el cliente y el servidor de aplicaciones en la máquina de desarrollo.

Se ejecutará la aplicación tres capas utilizando IIS.
 Language: .NET
 User interface: Win
9. Setear las Dbms Options del modelo:

 Access technology to set: ADO.NET
 Server name: localhost
 Use trusted connection: No
 User id: user
 User password: password
10. Configurar las propiedades de ejecución :
 Compilador = csc.exe (bajo directorio de instalación del framework)
11. Ejecutar la creación de tablas de la base de datos (se supone que existe la base de
datos creada en el SQL Server):
 Build / Create Database
12. Configurar propiedades del modelo
En la sección “General/.NET specific/ADO.NET specific” configurar:
 Protocol: Using .Net remoting
 Application Server host: http://localhost/3tierNET (“3tierNET” es el

nombre del directorio virtual que debe ser creado en el IIS y que apunte a
<Directorio de la aplicación>\DATAXXX\srv )
 Multi tier location: appserver
13. Configurar los programas que se ejecutaran en el servidor
Setear en las las propiedades del procedimiento:
 Main program = True
 Location = appserver (debe ser el mismo valor que la propiedad del

modelo “Multi tier location”)
 Generar los programas: Build / Build All
 Ejecutar el diálogo de ejecución (F5). Compilar el Work Panel y el

procedmiento definido como main
 Crear el directorio virtual 3tierNET, que apunte a <Directorio de la

aplicación>\Dataxxx\srv )
 Ejecutar el Work Panel (F5). Para ejecutar el Workpanel fuera de

GeneXus basta con dar clic en el archivo ejecutable que se crea en el
directorio del modelos “dataxxx/bin”. )
Tener en cuenta que todo lo que se genere en el directorio:
<Directorio de la aplicación>\DATAXXX\bin – es todo lo que corresponde con lo que

se ejecuta en el cliente
<Directorio de la aplicación>\DATAXXX\srv – es todo lo que corresponde con lo que

se ejecuta en el servidor
Arquitectura
Un sistema distribuido se basa en el concepto de distribuir lógicamente la ejecución de

una aplicación, que también puede estar distribuida físicamente o puede estar corriendo
en una misma computadora.
La idea principal de un sistema distribuido, es la división lógica de la aplicación en

varias capas, de forma de repartir las responsabilidades de realizar tareas específicas en
cada una de ellas. En nuestro caso las aplicaciones distribuidas van a estar basadas en
una arquitectura de 3 capas, es decir, que cada una de las capas se va a especializar en
realizar determinadas tareas.
En la primer capa se encuentran los componentes de la aplicación que implementan la

interfaz de la misma con el cliente (Capa de Presentación), en la segunda se hayan los
componentes que se ocupan de ejecutar la lógica del negocio de la aplicación, es decir
todo lo que es comportamiento del sistema (Servidor de Aplicaciones) y en la tercer
capa están los componentes encargados de realizar toda la manipulación y persistencia
de los datos (Servidor de Base de Datos).
A diferencia de las aplicaciones Cliente/Servidor tradicionales (2 capas), donde la

ejecución de todo el código de la aplicación (lógica del negocio) se realiza en el cliente,
en una aplicación 3 capas, se distribuye el código; ejecutando parte en el cliente y parte
en el servidor de aplicaciones. De esta forma logramos ganar en escalabilidad, seguridad
y performance como veremos más adelante.
Cabe aclarar que en una arquitectura como esta, el servidor de aplicaciones puede a su
vez comunicarse con otros servidores de aplicaciones, distribuyendo de esta forma la
responsabilidad de los servicios que son provistos al cliente. Del mismo modo, el
servidor de la base de datos no tiene porque ser uno solo, sino que se puede contar con
varios.
Es este tipo de arquitectura, los clientes se comunican con el servidor de aplicaciones

mediante un protocolo de comunicación específico según el lenguaje de la aplicación y
el servidor utilizado; a su vez, el servidor de aplicaciones se comunica con la base de
datos mediante un protocolo de comunicación o driver específico según el DBMS
utilizado.
La forma de comunicación entre los componentes, del cliente y el servidor de

aplicaciones, se realiza con .Net remoting, esto implica que para el transporte de la
información se crean mensajes que viajan bajo HTTP o TCP (.Net Channel Services).
La forma de comunicación con el servidor de base de datos desde el servidor de
aplicaciones es a traves de ADO.NET
Solo es posible generar aplicaciones tres capas utilizando ADO.NET como método de
conexión a la base de datos, no es posible generar una aplicación en tres capas
utilizando ODBC
Además, las aplicaciones en tres capas solo pueden ser generadas con Interfaz Win, no
es posible generar aplicaciones tres capas con Interfaz Web.
Propiedades Específicas
MODEL PROPERTIES
Protocol
Esta propiedad permite definir si la aplicación se va a generar en 2 capas o en 3 capas, si

se opta por esté último, se debe seleccionar con qué protocolo de comunicación entre el
cliente y servidor de aplicaciones se va a trabajar.
Valores
Using.Net remoting - Se genera la aplicación en tres capas
No - El modelo se generará en dos capas.
Valor predeterminado: No
Application Server Host

Permite especificar la referencia al “host” donde está corriendo el servidor de
aplicaciones.
Valores
http://servername/virtualDir
por ejemplo: <http://localhost/remoting> para utilizar IIS como servidor de

aplicación
tcp://servername:puerto
por ejemplo: <tcp://servername:1234> para utilizar Consola o Servicio de

Windows como servidor de aplicación
Valor predeterminado: No tiene
En el caso de modificar el Channel ref ="tcp” se debe especificar el application Server

host bajo el mismo protocolo.
Multi tier location
Indica el nombre lógico (el “Location”) del servidor de aplicaciones que ejecutará el
código remoto de la aplicación.
El código remoto consiste en los accesos a la base de datos y según la configuración de

propiedades de los objetos, se ejecutará la lógica de los mismos (o parte de ellos) en el
cliente o en el servidor. En particular para ejecutar la lógica de los procedimientos y o
reportes en el servidor, se deberá configurar la propiedad ‘Location’ con el valor que se
especifique en esta propiedad del modelo.
Valores
Se puede especificar cualquier nombre lógico para el “Location”

Valor predeterminado: Appserver
PROCEDURE PROPERTIES
Location
Esta propiedad nos permite definir a nivel de procedimientos y reportes main, si el

objeto es generado para ser ejecutado íntegramente en el servidor de aplicaciones, es
decir, que no sólo los accesos a la base de datos, sino también que toda su lógica y la de
los objetos llamados por él sean ejecutados en forma remota.
Si a un objeto no se le define Location, se asume que se ejecuta en el Location del

llamador, por lo tanto no es necesario definir el Location a cada uno de los
procedimientos y reportes del árbol de llamadas del primero, ya que al haber definido el
main y location del primero, todos toman dicho valor. Por lo tanto, dado que un objeto
puede ser llamado por diferentes objetos, dicho objeto a veces puede ser ejecutado todo
en el servidor de aplicaciones (es decir, remoto) y otras veces algo en el cliente y el
acceso a la base de datos en el servidor de aplicaciones, dependiendo del Location de
quien lo llame.
En el árbol de llamadas no deben existir objetos con interfaz, por ejemplo, una llamada
(call) a un work panel o a una transacción en un procedimiento definido como remoto o
llamado por otro remoto. Prestar especial atención a esto, ya que en caso de existir, dará
error o bien se visualizará en el servidor de aplicaciones (que es donde está ejecutando
el objeto) y no en el cliente.
Valores
El valor es un nombre lógico. Si coincide con el valor de la preferencia del modelo
Multi tier location, entonces el objeto correspondiente corre íntegramente en el servidor
de aplicaciones, de lo contrario corre en el cliente.
TRANSACTION PROPERTIES
Optimize for multi tier location
Esta propiedad permite definir si las reglas de la transacción se ejecutan en el cliente y

no en el servidor de aplicaciones.
En una aplicación en 3 capas por defecto todas las reglas de las transacciones se
ejecutan en el servidor de aplicaciones. Pero las transacciones pueden tener determinada
regla que genere algún tipo de interfaz de usuario, por ejemplo una llamada a un work
panel, a un reporte o a otra transacción. En ese caso la transacción no puede ser
ejecutada en el servidor de aplicaciones y esta propiedad permite que se ejecute en el
cliente
Valores
No: Todas las reglas son ejecutadas en el cliente, inclusive el código de acceso a la base
de datos.
Yes: Todas las reglas de la transacción son ejecutadas en el servidor de aplicaciones.
Valor predeterminado = Yes

Nota: igualmente no es recomendable cambiar esta propiedad para aplicaciones en 3
capas, pues afecta la performance y la idea es que sólo desde el servidor de aplicaciones
se puede acceder a la base de datos. Para solucionar el tema de tener una regla que
invoque a algún objeto con interfaz de usuario, se recomienda encontrar la manera de
eliminar esa regla, por ejemplo pasarla a los eventos o utilizar la regla “msg” o “error.
WORK PANEL PROPERTIES
Execute load events in application server
Configurando esta propiedad en los work panels, se puede determinar si además de los
accesos a la base de datos, se ejecutará toda la lógica del evento Load en el servidor de
aplicaciones automáticamente.
Al trabajar en una aplicación distribuida, para lograr una buena performance, como
regla general hay que tratar de ejecutar la mayor cantidad de código en el servidor de
aplicaciones, básicamente ejecutar todo menos la interfaz. Es por ello que se cuenta con
esta propiedad para delegar toda la ejecución de la lógica del evento Load del work
panel al servidor de aplicaciones.
Valores
No: La lógica ejecuta en el cliente y sólo los accesos a la base de datos ejecutan
en el servidor de aplicaciones.
Yes: Ejecuta todo lo programado en el evento Load del work panel en el

servidor de aplicaciones, tanto la lógica como los accesos a la base de datos.
Valor predeterminado = No
Consideraciones
Si esta propiedad tiene el valor “Yes”, se debe tener en cuenta ciertos puntos en la
programación del evento Load.
Dado que esta propiedad indica que el evento Load se va a ejecutar en el servidor de
aplicaciones, no se puede programar en él nada que tenga que ver con interfaz, como
ser:
Llamadas a un método de un control del form del work panel
Cambio de propiedades del form del work panel
Llamadas a otros programas con interfaz, como por ejemplo un “call” a otro work panel
o transacción
Al generar el modelo se crean los objetos necesarios según el tipo de objeto
<Directorio de la aplicación>\DATAXXX\bin – es todo lo que corresponde con lo que

se ejecuta en el cliente
<Directorio de la aplicación>\DATAXXX\srv – es todo lo que corresponde con lo que

se ejecuta en el servidor
Todos los componentes generados son componentes .Net (Assemblies), que siguen el
estándar de “Factory Design Pattern”.
En el servidor de aplicaciones se publica un único objeto “Factory”, que es compartido

por todos los clientes (Singleton). Este permite al cliente, a través de dos métodos
getProcedure y getDatastore, acceder al objeto remoto y activarlo (Client Activated
Objects–CAO). El servidor de aplicaciones se encarga de mantenerlos vivos mientras
exista interacción frecuente entre el objeto y el cliente.
Al acceder dos clientes al mismo objeto se crea en el servidor de aplicaciones una nueva
instancia del objeto. No hay un criterio de re-uso como el pool de objetos de COM+, o
sea, un objeto se usa por un cliente hasta que no lo necesita más.
Servidores de aplicaciones
Los servidores de aplicaciones se encargan de ejecutar el código definido como remoto
en una aplicación distribuida, en el caso del generador .NET, tenemos dos opciones,
podemos utilizar Internet Information Server o el servidor de aplicaciones que nos
ofrece GeneXus.
Esto es determinado a través de la propiedad Application server Host
IIS COMO SERVIDOR DE APLICACIONES
Para poder ejecutar la aplicación utilizando IIS (Internet Information Server) como
servidor de aplicaciones, se debe crear un directorio virtual en el IIS apuntando al
directorio del modelo “dataxxx\srv”.
A continuación describimos las características de utilizar IIS:
• El servidor de aplicaciones es levantado automáticamente en la primera

solicitud.
• El servidor de aplicaciones se reinicia cada vez que se modifica el archivo

“web.config”, este es el archivo de configuración donde se encuentra toda la
información sobre el servidor de la aplicación, sobre la conexión a la base de
datos, entre otros. Este archivo se localiza en el directorio del modelo
“dataxxx\srv”.
• Si los procesos demoran más de 90 segundos (“timeout” predeterminado),

caen dando error de “timeout”. Para que no ocurra esto, se deberá
configurara el Http Execution timeout en el archivo “web.config”,
configurando un valor mayor.
SERVIDOR DE APLICACIONES GENEXUS
Si optamos por utilizar el servidor de aplicaciones GeneXus, entonces tenemos dos

formas de levantarlo:
Por consola
Ejecutando el archivo GxDotNetAppServer.exe que se encuentra en el directorio

del modelo “dataxxx\srv\bin”.
La salida de los mensajes se da en la consola y en el archivo client.log

Como servicio Windows
Para configurarlo como servicio Windows es preciso instalarlo la primera vez

con la siguiente sentencia:
installutil GxDotNetAppServerWinSrv.exe
Este ejecutable se encuentra en el directorio del modelo dataxxx\srv\bin
Una vez instalado, debe levantarse manualmente, y luego puede configurarse

como cualquier servicio Windows.
La salida de los mensajes de error se da por el event viewer y por el client.log
En ambos casos se debe detener el servicio al recompilar los objetos.
El servidor de aplicaciones GeneXus, lee su configuración del archivo

“server.exe.config”, en este archivo se encuentra desde la información sobre el host de
la aplicación hasta los datos de conexión a la base de datos. Este archivo está en el
directorio del modelo “dataxxx\bin”.
VENTAJAS Y DESVENTAJAS
Utilizar uno u otro servidor de aplicaciones tiene sus ventajas y desventajas, y en esta
sección mostraremos cuales son.
Ejecutar una aplicación bajo IIS seguramente sea la opción más cómoda cuando se
trabaja en prototipo, ya que es la más sencilla. Además se "hereda" la seguridad del
propio IIS.
En este caso la actualización de las versiones de las “dll” se puede hacer sin bajar el
servicio.
La desventaja se presenta en la performance, puede ser un poco más lento que utilizar el
servidor de aplicaciones de GeneXus.
La mejor performance con .NET Remoting se da con comunicación TCP y formato

binario, la más baja con HTTP y formato SOAP. Teniéndolo bajo IIS se tiene
comunicación HTTP con formato binario o con formato SOAP, el primero sería
"intermedio" en performance.
El formato predeterminado es binario, pero puede ser configurado en los

archivo.config: “server.exe.config” o “web.config”
Otro punto a tener en cuenta es que si el si el servicio se cae por alguna razón en caso
como Consola o Servicio de Windows, hay que levantarlo manualmente, lo que no es
necesario con IIS, ya que con IIS el servidor de aplicaciones se levanta automáticamente
en el próximo pedido.
Avanzados
Por defecto, en los modelos tres capas se genera un log en el cliente (client.log) y un
log en el servidor de aplicaciones (server.log).
POOL DE CONEXIONES
Una de las ventajas de implementar una aplicación en 3 capas, es la posibilidad

de tener más centralizado y controlado el manejo de las conexiones a la base de
datos, ya que el acceso a la misma no se hace desde el cliente, como en una
aplicación en 2 capas, sino que en este tipo de aplicación el acceso es realizado
por el servidor de aplicaciones. Para ello podemos utilizar un pool de conexiones
a la base de datos.
Un pool de conexiones es un conjunto limitado de conexiones a una base, que es

manejado de forma tal, que dichas conexiones pueden ser reutilizadas por los
diferentes usuarios. Este pool es administrado por un servidor de aplicaciones
que va asignando las conexiones a medida que los clientes van solicitando
consultas o actualizaciones de datos.
En aplicaciones .NET con acceso a SQL Server u Oracle, utilizando ADO.NET

como protocolo de acceso a los datos, el manejo del pool lo hace el propio
framework utilizando el "Connection Pooling" de ADO.NET.
Es posible modificar los valores de las propiedades del pool de conexiones seteados
por defecto. Para esto es necesario configurara la propiedad “Additional connection
string attributes” de las DBMS dentro de “Properties/Access technology
settings/Connecction information”.
Las propiedades disponibles en el pool de conexiones que provee el ADO.NET son:
• Connection Lifetime
• Connection Reset
• Enlist
• Max Pool Size
• Min Pool Size
• Pooling
Por ejemplo podemos configurar la propiedad “Additional connection string

attributes” con:
Enlist=true;Max Pool Size=40
Las propiedades del pool de conexiones siempre van separadas por punto y coma.
Si una conexión alcanza un determinado tiempo no configurable sin actividad (30000

milisegundos), ésta es devuelta al pool de conexiones.
Por más detalles sobre esta funcionalidad y sobre cómo configurar las propiedades
puede acceder a las siguientes páginas: SqlServer y Oracle
ARCHIVOS DE CONFIGURACIÓN
Web.config
Es el archivo de configuración donde se encuentra toda la información sobre el

servidor de la aplicaciones cuando se corre bajo Internet Information Service (IIS).
Se crea bajo el directorio Dataxxx\srv\

Tiene una estructura similar a:
<configuration>
<configSections>
<datastores>
<appSettings>
<add key="NAME_HOST" value="http://jlarrosa/rotulos"/>
<add key="SPONSOR_LIFETIME" value="420"/>
<add key="SPONSOR_RENEWONCALL" value="300"/>
</appSettings>
<system.runtime.remoting>
<application>
<channels>
<channel ref="http">…
<lifetime leaseTime="5M" renewOnCallTime="2M" leaseManagerPollTime="10S"/>
<service>
<wellknown mode="Singleton" type="com.genexus.distributed. …i="factory.rem"/>
</service>
</application>
</system.runtime.remoting>
<system.web>
<trace enabled="false"/>
<httpRuntime …"/>
</system.web>
</configuration>
Formato de mensajes
<channel ref="http">
<serverProviders>
<formatter ref="binary"/>
</serverProviders>
</channel>
El “formatter ref” puede ser "SOAP" si el “channel ref” es “http”.
server.exe.config
Es el archivo de configuración donde se encuentra toda la información sobre el

servidor de la aplicaciones cuando se utiliza el servidor de aplicaciones GeneXus.
Se crea bajo el directorio Dataxxx\srv\bin
Tiene una estructura similar a:
<configuration>
<configSections> …
<datastores> …
<appSettings>
<add key="NAME_HOST" value="http://jlarrosa/rotulos"/>
<add key="SPONSOR_LIFETIME" value="420"/>
<add key="SPONSOR_RENEWONCALL" value="300"/>
</appSettings>
<application>
<channels>
<channel ref="http">…
<lifetime leaseTime="5M" renewOnCallTime="2M" leaseManagerPollTime="10S"/>
<service>
<wellknown mode="Singleton" … ="factory.rem"/>
</service>
</application>
<log4net>
</configuration>
Formato de mensajes
<channel ref="http">
<serverProviders>
</serverProviders>
</channel>
El “channel ref” puede ser "tcp"
El “formatter ref” puede ser "SOAP" si el “channel ref” es “http”.
Client.exe.config
Este archivo, como se detalla en el modelo dos capas, tiene información de las
propiedades del modelo y log. En aplicaciones distribuidas no tiene información de la
conexión a la base de datos pero se agrega la información de canales, del objeto
singleton (Factory) y formatos e información de propiedades relevantes como la
ubicación del servidor de aplicaciones y el keep alive.
La estructura es similar a:
<configuration>
<appSettings>
<add key="NAME_HOST" value="http://localhost/srv"/>
<add key="KEEP_ALIVE_INTERVAL" value="90"/>
</appSettings>
<application>
<channels>
</channels>
<client>
<wellknown type="com.genexus.distributed. … url="http://localhost/srv/factory.rem"/>
</client>
</application>
….
</log4net>
Manejo de Proxy
En el caso de que exista un Proxy entre el cliente y servidor de aplicaciones,

debemos realizar algunos cambios. Dichos cambios deben ser implementados en
el archivo de configuración del cliente “client.exe.config”, en el cual hay que
configurar que se va a utilizar el Proxy que fue establecido en las “Internet
Options” de Windows.
Tenemos dos posibles situaciones, como se muestra a continuación:
• Cliente y servidor de aplicaciones en la misma LAN:
<channel ref="http" port="0" proxyName="" >
<clientProviders>
</clientProviders>
</channel>
De esta forma no se va acceder por el Proxy.

• Cliente y servidor de aplicaciones en LAN distinta:
<channel ref="http" port="0" useDefaultCredentials="true" >
<clientProviders>
</clientProviders>
</channel>
De esta forma se accede por el Proxy configurado en las “Internet Options”.
Las etiquetas nombradas anteriormente son “Case Sensitive”, es decir se deben

escribir respetando las mayúsculas y minúsculas, por ejemplo: proxyName.
La plataforma .Net no utiliza el registry y permite configurar las versiones de dlls a

utilizar, por lo que instalar la aplicación es simplemente hacer un xcopy de:
- directorio bin para el cliente
- directorio srv para el servidor de aplicaciones
El generador provee una herramienta, Publication Assistant, para hacer el Deploy

automático de la parte del cliente.
REQUERIMIENTOS
Servidor de aplicaciones
- .Net Framework Redistributable
- Conectividad al servidor de base de datos
- IIS o servidor de aplicación GeneXus

Cliente
- Visual J#
- .Net Framework Redistributable
Generalidades
Acceso a la base de datos
Hay dos formas de conexión a la base de datos con: ADO.NET y ODBC. El primero es
un método nativo del generador y es el recomendado, ya que permite la generación de
aplicaciones Windows de múltiples capas, habilita el caching de sentencias, ofrece
herramientas de monitoreo de aplicaciones, mejoras de performance (con respecto al
acceso ODBC) e implica utilizar 100% “.NET managed code” para acceder al DBMS
Para los manejadores de base de datos que no esta liberado o no poseen un provider
ADO es necesario acceder con ODBC (PostgreSQL, Informix)
Para configurar la conexión a la base de datos se debe setear:
- Propiedad Access Method del modelo (ADO.NET/ODBC)
- Valores de conexión desde “Access technology to set” = ADO/ODBC
No es posible tener algunos objetos con conexión ADO y otros con ODBC, si un
modelo es ADO todos los objetos y todos los datastores usarán este método de conexión
Al trabajar con ADO.NET toda la lógica se encuentra en la gxclasses.dll, en cambio en

el acceso ODBC se implementa bajo la gxdata.dll, al igual que el resto de los
generadores Client Server.
En el caso de los DBMSs, cada uno utiliza un Data Provider para acceder a la base de
datos, cada DBMS tiene su propio Data Provider para acceso ADO.NET.
Cache de sentencias
La conexión ADO.NET a la base de datos 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.
Tipos de datos
La plataforma .Net es muy estricta en el chequeo de tipos, tanto en tiempo de

compilación como en tiempo de ejecución, el generador se ocupa de hacer los “casts” y
conversiones que puede, pero de todas formas pueden surgir errores causados por mala
programación (el mas común es el overflow en tipos numéricos).
Es necesario tener algunas consideraciones en el tipo de datos mail:
- Esta implementado los tipos de datos para el manejo de correo con modo “Internet”
(SMTPSession, POP3Session) y Outlook
- En ambiente web para utilizar modo Outlook es necesario configurar:
o impersonate del usuario
o configurar el directorio virtual del Internet Information Service (IIS)

para que utilice un usuario que tenga permisos sobre una cuenta de mail
en outlook (editando las propiedades\Directory Security\Edit)
- No esta implementado el modo Mapi

Implementación
GxOffice2net.dll es la que se usa desde los programas.
Interop.GxOffice2lib.dll es el wrapper de la gxoffice2, se necesita siempre.
GxOffice2.dll es la implementación cuando se usa modo Outlook
Generación de programas de reorganización
El programa que ejecuta la reorganización es el assembly reor.exe que se crea bajo el

directorio bin.
Este toma las especificaciones de la reorganization.dll y chequea la presencia de el

archivo reorgpgm.gen (una flag), esto es necesario cuando se precisan ejecutar
reorganizaciones o creaciones de la base de datos en el servidor de producción.
La información de conexión a la base de datos se encuentra en el archivo

client.exe.config, esto es válido tanto para modelos GUI como Web.
Los archivos necesarios para llevar solamente la creación/reorganización son:
GxClasses.dll, log4net.dll, Reor.exe, Reorganization.dll, reorgpgm.gen,

messages.<language>.dll
Es posible ejecutar la reorganización sin interfaz con el parámetro “nogui”. La sintaxis

del comando es: reor.exe –nogui
Transactional Integrity
La propiedad “Transactional Integrity” no es tomada en cuenta con ADO.NET. Los

objetos siempre se generan con integridad transaccional, a excepción de las
reorganizaciones de la base de datos (con Autocommit).
Transacciones de más de un nivel (GUI)
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, tampoco se soportan estructuras del
tipo:
A*
B
(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.
Smart Static Panels (Web)
No esta implementada esta funcionalidad, por lo tanto no es posible generar archivos

HTML con la información obtenida de la base de datos.
Llamadas a Stored Procedures
Al igual que en el resto de los generadores para llamar a un store procedure “sp1”, este
debe estar definido dentro de la propiedad “List of remote programs” del modelo. Para
invocarlo en el códuigo GeneXus alcanza con programar:
call('sp1', parm1, parm2)
Los parámetros deben estar definidos en el archivo extprog.ini, donde se mapea el

nombre de los parámetros definidos en la BD, por ejemplo:
[storeproc]
ProgramName=Sp1
ProgramType=StoredProcedure
ParmMode=inout,in
ParmType=Number,5,0;Number,5,0;
ParmName=parm1,parm2
En versiones previas cuando se trabajaba con ADO.NET, estaba la restricción de que

las variables se llamen igual que los parámetros del Stored Procedure que se está
invocando, y sean todos los parámetros de tipo inout.
En el caso detallado anterioirmente, en la Base de datos el Stored

Procedure sp1 debe tener dos parámetros de nombre @parm1 y
@parm2 (ambos de tipo inout).
Comando Submit
El comando submit usa un Thread pool en lugar de crear un thread nuevo siempre. Esto
limita la cantidad de threads que se pueden llegar a crear evitando un potencial
problema de sobrecarga. Se usa siempre que se haga un submit, y se tienen 25 threads
por procesador. En el ASPNET se puede configurar el numero de threads (en el
processModel del config) pero en una app win no a menos que se reescriba el host. Si el
thread muere por algun motivo deja un error en el event log.
De aquí la importancia de generar los submits como queued components:
Submits como queued components (COM+)
Funciona de forma que un proc llamado con submit, en lugar de ejecutarse en otro
thread, se pone en una cola de un servicio COM+ que se ocupa de instanciarlo y
ejecutarlo, si no puede por algun motivo (error de la app/ recursos no disponibles)
reintenta 5 veces y si falla lo manda a una cola especial de objetos “fallados”. Esto es
util cuando se quiere garantizar la ejecución de un proceso y no importa el momento en
que se ejecute, además se ejecuta en un proceso distinto al del llamador.
REQUERIMIENTOS
• Message Queuing instalado (viene con Windows pero no se instala por defecto).
Para instalarlo se debe acceer a Control Panel/Add-Remove Programs/Add-
Remove Windows Component
GENERACIÓN
Esta implementación es válida solo para procedimientos.

Para que los objetos GeneXus se generen de esta forma, deben cumplir los siguientes
requisitos:
• Deben estar definidos como objeto main (Propiedad del objeto “Main object
= true”)
• El “assembly” debe estar armado con “Strong name” (Propiedad del modelo
“Strong name = true”)
• No puede tener layout
Si no se cumple alguno de estos requisitos, el objeto se genera sin posibilidades de

llamarse como “Queued component” y el Submit se hace levantando otro Thread.
Junto con el objeto se genera información para su configuración que se incluye en la

aplicación COM+ cuando se registra.
CONFIGURACIÓN, EJECUCIÓN
Un assembly de este tipo ejecuta en una aplicación COM+, por lo tanto es necesario
configurarlo como tal, para eso es necesario:
• La configuración de seguridad, la genera el generador automáticamente;

genera un esquema sin autenticación (lo mas común para probar la
aplicación)
• Registración, se debe registrar el componente COM+ con el comando:
“regsvcs <nombre del assembly>”
Por ejemplo: regsvcs bin\aprc01.exe.
Esto crea la aplicación COM+ (con el nombre del modelo) y la configura

con seguridad y esquema transaccional generado. Regsvcs es una
herramienta del .NET Framework que sirve para registrar assemblies como
aplicaciones COM+.
Además se debe copiar el client.exe.config al directorio de sistema de

Windows (típicamente Windows\system32).
CONSIDERACIONES
• Todo lo que es COM, DCOM y COM+ se configura desde el Control
Panel/Administrative Tools/ Component Services
• Configuración de seguridad
No es necesario si la aplicación se registró como se indica en “Configuración,

ejecución”. Para probar, lo mas común, es una instalación MSMQ workgroup (que
no requiere domain controller). En este tipo de instalación no hay un “Active
directory store” contra el que autenticar los callers y por lo tanto hay que desactivar
la autenticación (sino da “Access denied” al hacer el call). Para desactivar la
autenticación desde el Component services/Computers/My Computer/COM+
Applications, presionar botón derecho en la aplicación, properties/security, apagar el
checkbox de “Enforce access checks for this application” y poner “Authentication
level for calls” en “None”. Esta configuración la genera el generador y se hace
cuando se registra el componente. La configuración para producción depende de
cada instalación, en general tiene un domain controller y hay que configurar la
seguridad.
• Configurar el soporte transaccional
Esto no es necesario si la aplicación se registró como se indica en “Configuración,

ejecución”. Dentro de la aplicación COM+ ir a Components, seleccionar el que
corresponde al objeto GeneXus, presionar botón derecho, properties/transactions,
poner “Transaction support” en “Not supported”. Esta configuración la genera el
generador y se hace cuando se registra el componente.
Publication assistant (GUI)
Esta herramienta permite hacer el deploy automático de una aplicacion .Net Win en 2 o
3 capas via HTTP.
La idea es poder realizar instalaciones de aplicaciones o realizar actualizaciones de las
mismas en las máquinas cliente de una manera sencilla y centralizada.
DESCRIPCIÓN
La herramienta nos permitirá dada una aplicación (2 o 3 capas) la posibilidad que un
cliente desde una URL y haciendo un simple click pueda instalar la aplicación o
upgrades de la misma.
Para acceder a la herramienta debemos ir a la ventana de Execution: Build -> Run (F5)
y dar click en el botón Publish.
La metodología es muy simple, luego de haber generado el exe de nuestra aplicación:
1) Estando en la ventana de Execution seleccionamos el exe correspondiente para el

Deployment y damos click en el boton Publish.
2) Luego en el GeneXus .NET Publication Assistant editamos las preferences del

Deployment:
Application name: nombre que se le dará a la aplicación, por default es la descripción

del main que se selecciono.
Client installation folder: folder donde se instalará la aplicación en el cliente, por

default se agregará al final del folder seleccionado GxPrograms\Application name.
Shortcut Icon: icono que tendrá el exe, por default será

ModelPath\GXPUB\gxappstart\net.ico que es un icono que se distribuye por default (*).
Shortcut for unistall: especificamos si queremos agregar un acceso directo al Unistall
de la aplicación.
Publication URL: URL desde la cual se podrá realizar el Deployment, por default será
http://server/app donde server es el nombre de la máquina donde se está haciendo el
Deployment y app es el nombre del exe.
Physical path: directorio donde se encuentra la aplicación en el server, por default es

ModelPath\Publication.
Application files: archivos que conforman a la aplicación, por defualt son cargados del
directorio bin del modelo.
(*): el GXPUB se crea por debajo del directorio del modelo al hacer Publish.
Al momento de hacer Publish se crea el directorio GXPUB bajo el directorio del

modelo en el cual se almacenan todos los archivos necesarios para llevar el control de
las nuevas versiones de la aplicación.
3) Una vez que se establecieron las preferences del Deployment damos Publish.
En este punto:
- se crea el directorio GXPUB debajo del directorio del modelo donde se guardan todas
las preferences ingresadas y donde se copian todos los archivos necesarios para armar el
deployment.
- se copian los archivos de la aplicación que se encuentran en el bin del modelo al

Physical path, también se copia un appname_manifest.xml el cual será utilizado para
saber si hay nuevas versiones de la aplicación para instalar.
- se crea un directorio virtual con el mismo nombre que la aplicación apuntando al

Physical path.
- se arma el aplicativo que se utilizará en el cliente para realizar las instalaciones y
actualizaciones de la aplicación, los fuentes de la misma quedan en
\GXPUB\gxappstart.
- en caso de no presentarse ningún error en el Output del GeneXus .NET Publication

Assistant quedará la URL a la cual acceder para realizar la instalación, la cual se arma
en base a la Publication URL que se especifico antes.
4) Colocar la URL en un browser de la máquina cliente.

5) Instalar la aplicación
6) La aplicación está felizmente instalada en el cliente lista para ejecutar.
Cada vez que se ejecute la aplicación en el cliente se comparará el

appname_manifest.xml que se tiene en el cliente con el appname_manifest.xml que está
en el server de haber diferencias se preguntará si desea bajar la actualización:
Para aplicaciones distribuídas (tres capas) es análogo
REQUERIMIENTOS
- Microsoft Windows® 2000, Windows XP Professional or Microsoft Windows Server

2003
- .NET Framework 1.1
- Setear seguridad para poder ejecutar

http://server/App/Setup/NoTouchDeploymentStub.exe.
Observación: los requerimientos pueden ser vistos en el archivo install.html que es

accedido al momento de realizar la instalación.
ADVANCED
La publicación de una aplicación, crea por defecto en el folder “Publication” (o

dependiendo del valor ingresado en la opción “Physical Path”), un conjunto de archivos
similares al bin del modelo. A este se le adicionan:
-Object_manifest.xml: existe un archivo xml por cada main que se publique. En este
archivo se tiene la información del manifestId (este es un autonumerado), y el hashcode
de cada archivo, ambos se chequean para verificar si la aplicación precisa un update o
no.
-Folder Setup: Aquí se encuentra los archivo para instalar la aplicación que son:
- Install.html es una interfase que simplemente llama al

NoTouchDeploymentStub.exe
-NoTouchDeploymentStub.exe: Tiene embebido las dlls standares de microsoft e

información del manifiesto que instala en el cliente.
-NoTouchDeploymentStub.exe.config: Permite modificar la Url del manifiesto,

esto es útil cuando no se conoce el nombre del server al momento de hacer la
publicación.
La estructura de este archivo, que debe ser creado por el usuario es la siguiente:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="manifestUri" value="http://myserver/uMnuPpal/uMnuPpal_manifest.xml" />
</appSettings>
</configuration>
Esta funcionalidad esta disponible a aprtir del upgrade 2 del generador
Cuando el cliente instala una aplicación, esta reside en el folder seteado en la propiedad
“Client installation folder” (por defecto Application Data). Alli se instala:
- Folder APP: tiene la instalación propiamente de la aplicación (Client.exe.config y

dlls)
- Updaterconfiguration.config: este archivo es creado la primera vez que se instala

la aplicación y extrae la información del NotouchdeploymentStub.exe. Este por ejemplo
tiene la información de donde se encuentra el manifiesto en el server.
- Microsoft.Application.xxx.dll: estos archivos standares del Application block de

Microsoft son instalados desde el NotouchDeploymentStub.Exe
- GxAppStart.exe: Es el ejecutable que se encarga de disparar el proceso de chequeo

de una nueva versión, es llamado por el ejecutable de la aplicación.
El mecanismo de verificación de un update de la aplicación es disparado por el

gxAppStart.Exe del cliente, el cual es invocado al levantar el exe de la aplicación. Este
compara el ManifiestId, que se encuentra en el Object_manifest.xml del lado del server,
y si es distinto activa el update. Si el manifiest Id no cambio, comienza a comparar los
hashcode de cada uno de los archivos (que se encuentran en el Object_manifest.xml
también) si alguno cambio activa el update. La activación del update consiste en
invocar al NoTouchDeploymentStub.Exe el cual transfiere los archivos necesarios al
cliente.
Reportes PDF
Existen algunos seteos especificos para el caso de reportes PDF que son configurables a
traves de un archivo de configuración PDFReport.INI
SETEO DE MÁRGENES
Editando el archivo PDFReport.INI. es posible setear los márgenes izquierdo y superior

en las propiedades ‘LeftMargin’ y ‘TopMargin’ respectivamente. Por ejemplo:
LeftMargin=3.5
TopMargin=2
Los valores default de ambos es 1.
El separador de decimales debe ser el punto y no la coma, por ejemplo: LeftMargin=3.5
FONTS EMBEBIDOS
Puede darse que en el reporte GX se incluyan determinados fonts que el usuario final no
cuente con ellos al ejecutar este reporte. La forma de evitar esto es embeber en los
reportes generados los fonts deseados.
La forma de incluir esta lista es a través del archivo PDFReport.INI especificando la

font y la ubicación de la misma en la sección Embebed Fonts. Por ejemplo en muchos
casos es necesario para visualizar los código de barra, para ese caso alcanzaría con
configurar en el archivo:
[Embeed Fonts]
3 of 9 Barcode= true
[Fonts Location (MS)]
3 of 9 Barcode= C:\WINDOWS\Fonts\3of9.TTF
El path debe ser el absoluto del servidoro Web y podria variar según el sistema
operativo, por ejemplo C:\WINNT\Fonts\3of9.TTF
ARCHIVO DE CONFIGURACION – PDFREPORT.INI
Este archivo se encuentra en el directorio donde se ejecuta el reporte, y es

automáticamente generado al ejecutar un reporte en caso de que no esté presente.
Embeed Fonts booleano que indica si embeber los fonts o no (ver Seccion
'Embeed Fonts')
SearchNewFonts booleano que indica si se deben buscar los fonts si no están en el
INI al embeberlos
SearchNewFontsOnce booleano que indica buscar por única vez los fonts si no se
encuentran
Version Indica la versión del PDFReport (formato a.b.c.d) // actualmente
genera siempre 1.0.0.0
FontsLocation Indica la ubicación de los fonts
LeftMargin Indica el margen izquierdo asociado al documento (en
centímetros)
TopMargin Indica el margen arriba asociado al documento (en centímetros)
OutputFileDirectory Si en la output_File del reporte GeneXus no se especifica path se
toma en cuenta la outputDirectory sino se toma el path que se
especifica en GeneXus
OutputFileDirectory Si en la output_File del reporte GeneXus no se especifica path se
toma en cuenta la outputDirectory sino se toma el path que se
especifica en GeneXus
DEBUG Indica que se quiere mostrar DEBUG por la stdout. Muestra
información como la siguiente:
GxSetDocName: 'reporte.pdf'
setPageLines: 999
setLineHeight: 15
GxAttris:
\-> Font: Helvetica (8) BOLD
\-> Fore (0, 0, 0)
\-> Back (255, 255, 255)
GxEndDocument!
Sección 'Embeed Fonts':
Para cada nombre de font se le asocia un booleano que indica si embeber el font o no
(para granularidad más fina de la GeneralProperty). Para embeber un font, debe estar en
'true' la generalProperty y la property de esta sección. Para setear qué fonts embeber, se
puede ejecutar el 'com.genexus.reports.PDFReportConfig' *
Sección 'Fonts Location (MS)' y 'Fonts Location (Sun)'
Se almacenan los mappings 'FontName= ubicación del .ttf asociado'. Estos mappings
son distintos para MS y Sun. Estos mappings son creados automáticamente
Sección 'Fonts Substitutions'
Se almacenan pares 'Font= Font' que mapean un font en otro. Por ejemplo, se puede
poner 'Impact= Courier', para mapear un TrueTypeFont en otro. También se puede
mapear un font en un Type1, por ej: 'Impact= Helvetica'. Estos mappings los puede
realizar el usuario.
Incluir código nativo
COMANDO CSHARP
Asi como en el resto de los generadores es posible incluir código nativo del lenguaje en
los programas generados, para esto existe el comando CSHARP
La sintaxis es anteponer la palabra CSHARP en el código
PROGRAMAS EXTERNOS .NET
Otra opcion para incluir código nativo .Net de usuario es llamar a una funcion externa,
para esto se debe definir un programa csharp (.cs) e invocarla con:
call('FuncExt', par1, par2)
Esto se traduce a codigo C#:
new funcext(ref _Context).execute(ref AV8par1, ref AV9par2)
Consideraciones:
- Se debe tener una clase con el nombre de la función

- Esta debe tener un constructor que recibe un parámetro de tipo IGxContext (se
debe incluir el namespace GeneXus.Application
- Se debe tener un método execute que recibe los parámetros por referencia.
- Todos los nombres son siempre en minúscula.
Por más información vea el apéndice y/o este ejemplo completo en:
http://www.gxopen.com/gxopen/servlet/hproject?395
Permisos .NET
PERMISOS PARA EJECUCIÓN DE ASSEMBLY REMOTO
Para ejecutar la reorganización (reor.exe) o el virtualdir.exe o cualquier

assembly 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) Administrative Tool/Microsoft .NET Framework Configuration/
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.
También puede configurarse (Framework 2.0) por línea de comando
caspol -m ag All_Code url file:// W:\LibraryPro\ * FullTrust n RemoteKB.LibraryPro
Esto setea la seguridad a nivel de la maquina (-m) para todos los archivos en
W:\LibraryPro con nivel FullTrust y llama a ese grupo RemoteKB.LibraryPro
(aca puede ir el nombre que se desee). -ag especifíca que se está agregando un
grupo (addgroup).
caspol m cg LocalIntranet_Zone FullTrust
Aca se está seteando FullTrust para la Zona LocalIntranet_Zone. -cg indica que
se estea cambiando el nivel de seguridad a nivel del grupo LocalIntranet_Zone
(chggroup).
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 proc, 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”.
Apéndice
Tips
¿COMO INCLUIR UNA DLL EXTERNA?
Se distinguen tres casos:
1- Llamar a una dll o componente .NET
Por ejemplo se tiene un assembly .NET que suma uno a un número, Sum.dll por
ejemplo. Para invocarla desde GeneXus se debe:
A. crear un SUMGX.cs con la definición de la función. Este debe tener un
constructor execute para llamarlo, por ejemplo el código del CS sería:
Using classSum; //Namespace del assembly

public void SUMGX(int YYYY ... );
public void execute(ref int YYYY )
{
/// llamar a la función sum del assembly
B. Incluir en la preference Compiler Flag la referencia a Sum.dll

C. Copiar Sum.dll al directorio bin del modelo
D. Desde el código GeneXus programar
Call('SUMGX', &num)
Se puede obener un ejemplo en http://www.gxopen.com/main/hproject.aspx?395

2 - Llamar a una dll COM
Para poder invocar una dll Com desde una aplicacion .NET, existe un utilitario,
"tlbimp", que genera una dll .NET que funciona como puente sobre la dll com.
Por ejemplo
tlbimp /out:GXNET.dll GXCOM.dll
La dll que genera (GXNET.dll) es una dll .net a partir de la COM (GXCOM.dll)
Seria similar al caso anterioir pero en C copiar la dll creada con tlbimp y la dll com.
Hay un ejemplo en http://www.gxopen.com/main/hproject.aspx?8 version 1.4.2)
3- Llamar a una dll No COM desde .NET
Crear un CS con la definición de la función, similar al caso 1 pero usando el comando

Dllimport de .NET, sería:
[DllImport("XXXXX.dll")]
public static extern bool funcion(string YYYY ... );

public void execute(ref string YYYY )
{
/// llamar a las funciones de la dll No COM
Notar que también debe tener el constructor execute que es el código que traduce el
generador en el fuente al hacer un call.
Importante En la versión 80 hay un cambio en la generación interna de los llamados:

En la versión 7.5 al hacer call a un procedimiento cualquiera genera
new FUNCTION (ref _Context).execute(ref parm1 ...);
En la versión 80 al hacer call a un procedimiento cualquiera genera

new FUNCTION(context ).execute( ref parm1 ... );
Esto implica que al migrar de versión de GeneXus hay que modificar el constructor (los
parámetros del mismo ya no son por referencia)
Hay un ejemplo en http://www.gxopen.com/main/hproject.aspx?395
¿COMO GENERAR CÓDIGO DE MAQUINA A PARTIR DE CÓDIGO IL ?

Existe un utilitario, "ngen", que compila el codigo intermedio de la plataforma .NET
(codigo IL) en código de máquina. Esto podría mejorar la performance de ejecución,
ngen hgxtech.dll - esto compila la dll a codigo de maquina y la instala
ngen /show - muestra las dlls instaladas
ngen hgxtech /delete - lo desinstala (vuelve a andar con el Just in Time como antes)
1.Debuger se puede debugear con el dbgclr.exe que se encuentra en

<ProgramFiles>\Microsoft.Net\Frameworksdk\guidebug o con el que tiene el visual
studio, también puede hacerlo desde allí.
¿COMO DEBUGEAR EL CÓDIGO DE UNA APLICACION WEB?
1) Compilar con /debug:full los fuentes (propiedad del modelo Compiler Flag = /debug)
2) Abrir el debuger (VStudio o dbgclr.exe)
3) Ir a "Tools/Debug Processes..." ( Ctrl + Alt + P)
4) Clickear en el check "Show system processes"
5) Ordenar por tipo dando click en la columna que dice "Type"
6) Seleccionar el Proceso "aspnet_wp" y dar "Attach..."
7) Si aparece un diálogo con título "Attach to Process" seleccionar el check
"Common Language Runtime" y dar OK
8) Abrir el documento que se quiere debugear e insertar break point en donde

corresponda. (El método webexecute() es el primero que se llama en los
webobjects)
9) Navegar a la página.
¿COMO DEBUGEAR EL CÓDIGO DE UNA APLICACION WIN?
Se puede debugear con Vstudio o con el dbgclr.exe:

1) Compilar con /debug (propiedad del modelo Compiler Flag = /debug)
2) Seleccionar el exe a debugear
a) Vstudio: crear un project y en las Configuration properties de este

poner:debug mode=Program; exe y working directory
b) Dbgclr: en Debug\Program to debug… poner exe y working directory
3) Insertar los breackpoint que sean necesarios
4) Run
¿COMO MODIFICAR EL RECICLADO DEL PROCESO QUE SIRVE LAS APLICACIONES

WEB?
• En windows Xp, w2000
El proceso aspnet_wp.exe, se configura en el Machine.config ( aplica a todo el

webserver) en la sección Process Model, existe un valor “MemoryLimit” que por
defecto esta seteado en 60. Esto significa que al proceso consumir un valor igual al 60%
de la memoria virtual de equipo este se recicla.
• En windows W2003
El proceso w3wp.exe, se configura desde el mismo IIS (version 6.0) en la seccion

Application Pool. Este ofrece mas posibilidades que el de la version IiIS 5.0 ( Windows
2000 y Xp). Es posible configurarlo por tiempo, cantidad de request, memoria virtual
virtual. El dialogo de configuración es similar al siguiente:
Glosario
.NET REMOTING
Es un protocolo de comunicaciones para objetos distribuidos. Puede correr sobre HTTP

o TCP, si corre sobre HTTP puede realizar la comunicación en forma binaria o
utilizando el protocolo SOAP. Por mas información:
us/dndotnet/html/introremoting.asp
.NET CHANNEL SERVICES
us/dndotnet/html/introremoting.asp
ADO.NET
ADO.NET es el método nativo de acceso a la base de datos en la plataforma .Net. Este

conjunto de librerías utilizadas para el acceso a datos, están contenidas dentro del .NET
framework. Proveen una mejora significativa en la performance del acceso a la base de
datos con el generador .Net. Además a nivel tecnológico se utiliza 100% “.NET
managed code” .
ASP .NET CONFIGURATION SECTION
http://authors.aspalliance.com/aspxtreme/aspnet/syntax/aspnetconfigurationsections.asp
x
ASSEMBLY
Es la unidad de los objetos programados con .Net
us/cpguide/html/cpconassembliesoverview.asp
CODE ACCESS SECURITY
us/spptsdk/html/SPCodeAccessSec.asp
COM+
COM+ es una infraestructura de servicios que soporta la ejecución de componentes.
Entre esos servicios están: transacciones automáticas, queued components, object

pooling y otros. En .NET se pueden implementar componentes COM+.
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).
GENEXUS .NET GENERATOR
http://www.gxtechnical.com/net
GLOBAL ASSEMBLY CACHE (GAC)
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:
us/cpguide/html/cpconglobalassemblycache.asp
LOG4NET
http://logging.apache.org/log4net/
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”).
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.
Con el generador .Net es posible acceder con este método, pero es solo recomendable
para aquellos manejadores de base de datos que no provean un provider Ado.Net.
SESSION STATE
us/cpguide/html/cpconsessionstate.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:
us/cpguide/html/cpconstrong-namedassemblies.asp
WMI (WINDOWS MANAGEMENT INSTRUMENTATION)
us/wmisdk/wmi/wmi_start_page.asp
FAQ: Errores comunes

PROBLEMAS EN EJECUCIÓN
Modelos WEB
o Server Error in '/services' Application:
System.BadImageFormatException: The format of the file 'HXXXX' is invalid.
File name: "reorganization"
Motivos/Soluciones:
o Se esta compilando con framework 2.0 y ejecutando con framework 1.1

o inferior
o Se esta generando con la versión 8.0 de GeneXus o inferior y ejecutando

con framework 2.0.
o Server Error in '/services' Application.
Access to the path

"C:\DOCUME~1\PC\ASPNET\LOCALS~1\Temp\e8ebd99f-17de-4447-83f8-
35769f67bd23\iTextdotNET, Version=1.4.1964.2760, Culture=neutral,
PublicKeyToken=bd3736a929f259c3" is denied.
Description: An unhandled exception occurred during the execution of the

current web request. Please review the stack trace for more information about
the error and where it originated in the code.
Exception Details: System.UnauthorizedAccessException: Access to the path

"C:\DOCUME~1\PC\ASPNET\LOCALS~1\Temp\e8ebd99f-17de-4447-83f8-
35769f67bd23\iTextdotNET, Version=1.4.1964.2760, Culture=neutral,
PublicKeyToken=bd3736a929f259c3" is denied.
Motivos/Soluciones:
- Se da al ejecutar un reporte PDF y se restringen los permisos.
Las solución es dar derechos de escritura en C:\Documents and

Settings\<nombre del webserver>\<ASPNET\Local Settings\Temp
o Server Error in '/services' Application.
Access is denied.
Description: An unhandled exception occurred during the execution of the current web request.
Please review the stack trace for more information about the error and where it originated in the
code.
Exception Details: System.UnauthorizedAccessException: Access is denied.
Motivos/Soluciones:
- En el caso de trabajar en ambiente web con .Net y estar con NTFS, la misma además
debe tener derechos de Read & Execute, por defecto con el usuario ASPNET, en caso contrario
ocurre un error al desplegar la pagina.
- También ocurre si un objeto usa algún tipo de datos de mail (Outlook), excel o word, eso
involucra el uso de la gxoffice2.dll y la misma no esta registrada en el servidor web. O puede ocurrir por
que la dll quedo corrupta o esta siendo usada por otro objeto.
o Configuration Error
Could not load file or assembly …
Description: An error occurred during the processing of a configuration file

required to service this request. Please review the specific error details below
and modify your configuration file appropriately.
Parser Error Message: Could not load file or assembly 'gxclasses' or one of its
dependencies. The system cannot find the file specified.
Motivos/Soluciones:
- El caso ocurria en un w2003, alli el directorio virtual, con un icono verde, no estaba creado
correctamente. El Application name era default application, al presionar el boton create se
resuelve
- También podría dar si no se tienen los permisos de Full Trust en la seguridad
o Access is denied: 'GxOffice2Net'.

the error and where it originated in the code
Exception Details: System.IO.FileLoadException: Access is denied:
'GxOffice2Net'
Motivos/Soluciones: Si se trabaja con <identity impersonate="true" /> y el usuario que

ejecuta en el IIS la página no tiene derecho de escritura en el
C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET
Files\<nombre_directorio_virtual>, da este error al ejecutar un web panel que use una
variable de tipo smtpsession, o sea trate de mandar un mail via smtp.
La solución es darle derechos de escritura al usuario en esa carpeta.
o GeneXus Fast Access Exception or message

Exception Details: GeneXus.DataAccess.GxFATDataException: GeneXus Fast

Access Exception
Motivos/Soluciones:
- No se puede conectar al servidor de Base de datos
a. Verificar las Dbms Option
b. Dependencias de la gxdata
c. No se definió datasource de sistema
d. Permisos en thrusted conection en datasource de Sqlserver
e. El usuario que corre los webpanels (host\ASPNET o

IUSR_MASTER) no tiene los permisos necesarios sobre la base
de datos)
- Algún problema de índices o registros duplicados en la base de datos

o The resource cannot be found.
Description: HTTP 404. The resource you are looking for (or one of its
dependencies) could have been removed, had its name changed, or is
temporarily unavailable. Please review the following URL and make sure that it
is spelled correctly.
Motivos/Soluciones:
No encuentra la página, puede no tener el mapeo a la dll en el archivo

web.config del directorio bin o no haberse compilado.
El Web config lo genera el UpdateWebconfig a partir de las entradas del

archivo GXCFG.web. En este caso compilar nuevamente el objeto y/o ejecutar
el UpdateWebconfig
- Otro motivo es que no este levantado el IIS, es útil verificar si en la misma Url
es posible ejecutar un HTML. En este caso levantar el servidor Web
- Otro motivo puede ser un problema de instalación del framework y el IIS no

reconozca los .aspx. Esto ocurre si se instala primero el framework y luego el
IIS, ya que el usuario ASPNET que corre el servicio ASpnet_Wp (que sirve los
webpanels) no tiene los permisos suficientes en el servidor Web. En ese caso
ejecutar el comando aspnet_regiis –i (este se encuentra bajo el direcotrio de
instalación del framework)
- Otra posibilidades en ambiente Windows 2003 donde hay mas restricciones de

seguridad, es necesario habilitar la extensión de los archivos aspx desde:
Computer Managment/ serices And applications/Webservice Extensions/AspNet

v1.14322 = allowed
Tambié se puede habilitar una extensión particular editando el en IIS las

propiedades de dirvir y en la sección Http Header agregar el Myme type de la
extensión, por ejemplo para txt:
Extension = .txt
Myme Type = application/octet-stream

o Object reference not set to an instance of an object

Exception Details: System.NullReferenceException: Object reference not set to

an …
Motivos/Soluciones: Es un error general, después que da con un objeto puede

dar con cualquier otro.
Puede ocurrir con Web transaction sin boton confirmar, o con algun control sin
inicializar (por ejemplo un webcomponent).
Otro caso puede ocurrir por algún problema de conección a la base de datos. Por
ejemplo trabajando con el manejador SQLServer, si se tiene configurado el
acceso de usuario por Windows (“Use Windows Authentication” ) y no se tiene
los permisos necesarios da el error .En este caso se resuelve agregando el
usuario ASPNET al grupo de usuarios o cambiando el acceso a “SQL
Authentication”.
Si el error especifica la línea del programa donde cae editar el CS en esa línea y
verificar la operación.
--------------------------------------------------------------------------------------------
o Specified cast is not valid.

current web request...
Motivos/Soluciones:Algún error de tipos o valores en el pasaje de parámetros .

Verificar los mismos.

Parser Error Message: File or assembly name GXData, or one of its

dependencies, was not found
Motivos/Soluciones: Falta una dependencia de la gxdata o no esta la gxdata en
el bin del modelo. Borrar *.ver del directorio del modelo y regenerar un objeto.

Parser Error Message: Method XXXX in Type GeneXus.Programs.XXXX

form Assembly … does not have an implementation
Motivos/Soluciones: El objeto mencionado (XXXX) no fue generado o fue

generado con otra versión. Verificar que dicho objeto especifica, genera y
compila y que las clases Standard son las correspondientes (para forzar la copia
de las clases se puede borrar el *.ver y generar un objeto).
También podría ocurrir este error si el objeto alguna ves existio en el modelo y
fue eliminado, pero la dll se mantiene en el directorio bin.
El error solo da con la propiedad Config http Handler Section con su valor por
defecto (for each object), si se modifica a Handler Factory (o ashx) no dará el
error al levantar la aplicación pero si dará un error al intentar acceder a dicho
objeto (XXXX)
o Application has generated an exception that could not be handled
Description: Application has generated an exception that could not be handled
Process id=0x67c (1660), Thread id=0x6c4(1732)"
Motivos/Soluciones: Para darle permisos ejecutar "Control

panel\Administrative Tools\Microsoft .NET Framework 1.1 Wizards\Adjust
.Net security\Make changes to this computer\Local intranet", alli se debe setear
el valor Full trust
Modelos GUI
o System.IO.IOException: The process cannot access the file client.log"

because it is being used by another process.
Esto ocurre por ejecutar dos objetos a la vez en el cliente que escriben log.
Ambos leen el mismo client.exe.config y tienen el log en ALL al mismo
archivo.
Motivos/Soluciones:
• Que cada uno genere un archivo distinto de log, en lugar de

client.log que sean por ejemplo client1.log y client2.log (para eso
cada uno tiene que leer un client.exe.config diferente => ejecutar en
directorios diferentes).
• Correr dos clientes con el mismo client.exe.config y con el log
prendido y el nombre del log se genera cada vez, por ejemplo:
<appender name="RollingFile"
type="log4net.Appender.RollingFileAppender">
<file value="client"/>
<staticLogFileName value="false" />
<datePattern value="yyyy-MM-
ddTHHmmss'.log'"/>
<layout type="log4net.Layout.PatternLayout">
<conversionPattern
value="%d{HH:mm:ss,fff} [%t] %-5p
%c{1} [%x] - %m%n"/>
</layout>
</appender>
Con esa configuración se generan, por ejemplo, los siguientes logs:

client2003-12-18T163808.log
client2003-12-18T163751.log
….
• Apagar el log, ponerlo en OFF y sin appenders en el root:
<root>
</root>
• Dejar el log prendido (ALL) pero con salida a consola en lugar de

archivo.
<root>
<appender-ref ref="ConsoleAppender"/>
</root>
------------------------------------------------------------------------------------------
o Exception: System.Runtime.Serialization.SerializationException
Message: BinaryFormatter Version incompatibility. Expected Version 1.0.

Received Version 1835627630.1699884645.
Motivos/Soluciones: Esta excepción tiene un mensaje que no tiene nada que

ver con 'version incompatibility', lo que pasa es que se retorno una excepcion
desde el server y no es bien interpretada por el cliente.
Esto ocurre en aplicaciones distribuidas, una posible explicacion sobre eso:
http://www.ingorammer.com/RemotingFAQ/BINARYVERSIONMISMAT
CH.html
En este caso ver el log del server, generalmente es porque esta dando un
error en el server, de conexion a la BD o de algun procesamiento en la BD.
Si mirando el log aun no se ve nada raro, probar de configurar el
client.exe.config y server.exe.config con formato soap:
cambiar <formatter ref="binary"/> por <formatter ref="soap"/> en los dos

config, con ese formato en el cliente se va a ver la excepcion con un mensaje
mas entendible (!= 'version incompatibility').
------------------------------------------------------------------------------------------
o Exception: System.Net.WebException
Message: The underlying connection was closed: Unable to connect to the

remote server.
Motivos/Soluciones: No esta encontrando el servidor de remoting:
Si esta corriendo en IIS (en la property del modelo ADO.NET Only,

Application server host se tiene algo asi: http://servername/dirvirtual),
chequear que:
• Existe el directorio virtual <dirvirtual> apuntando al srv de ese

modelo
• Probar de acceder a http://servername/dirvirtual en un browser. Si da

"not found" puede ser que no este registrado el aspnet_wp.
• Si se esta corriendo como consola o servicio de windows (en la

property del modelo ADO.NET Only, Application server host se
tiene algo asi: http://servername:port), chequear que:
o Esta levantado el servicio, y en el mismo puerto. Por

ejemplo: si port=1234 en el client.exe.config debe estar la
línea:
<wellknown
type="com.genexus.distributed.DistributedObjec
tFactory, GxClasses"
url="http://servername:1234/factory.rem"/>
y en el server.exe.config debe estar:
<channel ref="http" port="1234">
o También puede dar un mensaje de ese tipo si se está

corriendo un programa con remoting en IIS y se modifica
algo en el web.config, (por que en ese caso se reinicia el
aspnet_wp automáticamente).
------------------------------------------------------------------------------------------
APLICACIONES CON PUBLISH
o The underlying connection was closed: The remote name could not be
resolved.
at
Microsoft.ApplicationBlocks.Updater.Logger.LogAndThrowException(
String message, Exception ex )
Se instala una aplicación mediante publish, al levantar la misma desde el

cliente da el error descrito
Motivos/Soluciones:
• Al levantar el exe en el cliente , lo primero acción es ir a chequear el

manifiest.xml del server, para saber si es necesario instalar una
actualización de la aplicación o no. Si la Url del manifiesto no esta
accesible da este error. La url se extrae del archivo
updaterconfiguration.config que se encuentra en el directorio de
instalación de la aplicación ( por defecto Document and
Setting\User\Application Data\GxPrograms\Objetname)
• También podría ocurrir el error si la Url dentro del manifiesto , en el
server, es errónea. El manifiesto se encuentra bajo el folder donde se
publica y tiene el nombre object_Manifiest.xml.
PROBLEMA EN COMPILACIÓN
• Fatal error U1077: 'UpdateConfigWeb.exe' : return code '0xe0434f4d'
Motivos/Soluciones: Compilación de objeto o reorganización remota, por falta

de permisos (verificar en permisos .NET para modelos remotos )
---------------------------------------------------------------------------------------------
• Identifier expected : fatal error U1077:
The system cannot find the file specified.
Motivos/Soluciones: Puede ocurrir cuando no se tiene especificado un valor en

la preference “Application namespace”
---------------------------------------------------------------------------------------------
• gxexec "C:\Usuarios\ealmeida\mdlCR\NetOracle\blduXCEMant.cs"
-r:GxBaseBuilder.dll -
arg:csc="C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\csc.exe"
-arg:mdlpath= "C:\Usuarios\ealmeida\mdlCR\NetOracle\"
Before compile error: El sistema no puede hallar el archivo especificado
Motivos/Soluciones: se estan generando strong names y no esta seteada la

variable path con el directorio del sn.exe
Nota: El lenguaje es muy estricto en el chequeo de tipos, por lo que pueden

surgir problemas de compilación que deberán ser corregidos en el código
GeneXus.
---------------------------------------------------------------------------------------------
PROBLEMAS EN REORGANIZACIÓN
• Unhandled exception: System.BadImageFormatException: The format of the

file 'reorganization' is invalid.
File name: "reorganization"
Motivos/Soluciones: Se tiene instalado el framework 2.0 y se esta generando

con la versión 8.0 de GeneXus o inferior.
---------------------------------------------------------------------------------------------
• Unhandled exception
Motivos/Soluciones: El reor.exe no esta pudiendo ser levantada,verificar
- tener instalado el framework release o la versión de framework compatible

con el generador que armo el reor.exe
- Propiedades del modelo, en particular Edit model\Dbms, ya que si se
especifica un dbms distinto al del datasource da el error
- verificar la conexión a la base de datos
- tener la reorganization.dll donde se especifica la reorganización a ejecutar
---------------------------------------------------------------------------------------------
• Unhandled exception: System.Security.SecurityException: Request failed.
Description: The granted set of the failing assembly was:

<PermissionSet class="System.Security.PermissionSet" version="1">
Motivos/Soluciones:
- Permisos de seguridad en una reorganización de modelo Web en la red.

Revisar sección de Permisos .Net.
---------------------------------------------------------------------------------------------
• Unhandled exception: System.IO.FileLoadException: Could not load file or

assembly 'GxClasses
Description: Unhandled Exception: System.IO.FileLoadException: Could not

load file or assembly 'GxClasses, Version=1.0.0.1, Culture=neutral,
PublicKeyToken=74ebdef9af814246' or one of its dependencies. Failed to grant
minimum permission requests.
Motivos/Soluciones:
- Permisos de seguridad en una reorganización de modelo Win en la red.

Revisar sección de Permisos .Net.

Manual Del Generador Punto Net

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Manual Del Generador Punto Net

Cargado por

Copyright:

Formatos disponibles

Manual del Generador .

Manejador de base de datos

.Net Specific Section

ADO .NET Specific Section

Client Server specific Section

.NET Specific Section

ADO.NET Specific Section

Transaction configuration Section

Modelo GUI – Aplicaciones Distribuídas

Work Panel Properties

IIS como servidor de aplicaciones

Servidor de aplicaciones GeneXus

Acceso a la base de datos

Generación de programas de reorganización

Transacciones de más de un nivel (GUI)

Smart Static Panels (Web)

Llamadas a Stored Procedures

Submits queued components (COM+)

Publication assistant (GUI)

Permisos para ejecución de assemby remoto

Autorizacion por Web Panel

¿Como incluir una dll COM ?

¿Como generar código de maquina a partir de código IL ?

.NET Channel Services

ASP .NET Configuration Section

Code Access Security

Common Type System - CTS

GeneXus .NET Generator

WMI (Windows Management Instrumentation)

FAQ: Errores comunes

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

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

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

Para el desarrollo de aplicaciones es necesario instalar:

Release del Framework Redistributable 1.1 y J# Version 1.1 Redistributable Package o

Release del Framework Redistributable 2.0 y J# Version 2.0 Redistributable Package

Para ver los requerimientos y descargarlos de forma gratuita dirigirse a:

- Development environment GeneXus 9.0

- Generador .NET 9.0

MANEJADOR DE BASE DE DATOS

DB2 UDB for iSeries

mysql.dll – Biblioteca .Net de acceso a MySQL

MySQLDriverCS.dll – se debe copiar bajo el directorio gxnet/bin si la

El acceso ADO.NET, es soportado a partir del Upgrade 2 del generador

Luego de instalado, para crear un modelo se debe copiar la dll

Se debe configurar en las DBMS options del modelo

Server Name = El Host name del servidor

Informix server instance = El nombre de la instancia del server

Previo al upgrade 2 es necesario acceder con ODBC, la versión del DBMS

El acceso ADO.NET, es soportado a partir del Upgrade 2 del generador

El data provider es distribuido por el generador y consiste en dos dlls:

es open source (LGPL) y se pueden obtener, junto con la documentación desde:

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

IMPORTANTE: El mismo debe ser instalado antes del .NET Framework. Si no

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

1. Crear un modelo de prototipo o producción con el generador .NET

 Access technology to set: ADO.NET|ODBC

 Database name: <Nombre de la base de datos>

 Use trusted connection: No

 User id: <usuario>

 User password: <password>

4. Configurar las propiedades de ejecución :

 Compilador (csc.exe, se encuentra bajo directorio de instalación del

 Nombre del directorio virtual (services por defecto)