manual del generador punto net
DESCRIPTION
Manual Del Generador Punto Net usado con GenexusTRANSCRIPT
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
Configuración de un modelo
Propiedades específicas
General
.NET Specific Section
ADO.NET Specific Section
Transaction configuration Section
Client Server
Opciones de ejecución
Generación de objetos
Compilación
Avanzados
Generación de trace
Archivos específicos
Puesta en producción
Instalación en el servidor
Instalación en el Cliente
Modelo GUI – Aplicaciones Distribuídas
Configuración de un modelo
Arquitectura
Propiedades Específicas
Model Properties
Procedure Properties
Transaction Properties
Work Panel Properties
Generación de objetos
Servidores de aplicaciones
IIS como servidor de aplicaciones
Servidor de aplicaciones GeneXus
Ventajas y desventajas
Avanzados
Generación de trace
Pool de conexiones
Archivos de configuración
Puesta en producció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/netframeworkJ# distribution package
http://msdn.microsoft.com/vjsharp/downloads/howtoget.asp
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 OracleSe 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 iSeriesSe 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 R1Se 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 DatabaseSe 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. MySQLMySQL 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
Configuración de un modelo
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|ODBC3. 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
Opciones de ejecución
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.
Generación de objetos
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" />
<appender-ref ref="ASPNetTraceAppender" />
</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>
<level value="DEBUG" />
<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:
<appender-ref ref="ASPNetTraceAppender" />
Puesta en producción
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
Configuración de un modelo
1. Crear un modelo de prototipo o producción con el generador .NET
Language = .NET User Interface = Win
2. Configurar la propiedad del modelo Access Method en ADO.NET|ODBC3. Configurar las Dbms Options del modelo:
Access technology to set: ADO.NET|ODBC Database name: <Nombre de la base de datos> 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)
6. Generar programas
Build / Build All
7. Compilar y Ejecutar
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
Propiedades específicas
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
Opciones de ejecución
Para configurar la ejecución de una aplicación GUI .NET, alcanza con definir el camino del compilador (csc.exe), este lo provee el framework SDK y se encuentra bajo el directorio de instalación del mismo en:
<NET frameworkpath>\Framework\v1.1.4322 \csc.exe
Para ingresar a esta propiedad debe ir a: “File/Edit Model/ Botón Execution”.
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
Generación de objetos
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
GENERACIÓN DE TRACE
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:
< a p p e n d e r n a m e = " R o l l i n g F i l e A p p e n d e r " … >
<file value="server.log"/>
<appendToFile value="true"/>
<maximumFileSize value="9000KB"/>
<maxSizeRollBackups value="4"/>
</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>
<log4net threshold="OFF">
<appender name="ConsoleAppender" type="log4net.Appender.ConsoleAppender">
….
</appender>
<appender name="RollingFile" type="log4net.Appender.RollingFileAppender">
</appender>
<root>
<level value="DEBUG"/>
<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.
Puesta en producció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.
Configuración de un modelo
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.
8. Crear un modelo de prototipo o producción con el generador .NET
Language: .NET User interface: Win
9. Setear las Dbms Options del modelo:
Access technology to set: ADO.NET Database name: <Nombre de la base de datos> 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”)
14. Generar programas
15. Compilar y Ejecutar
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
Generación de objetos
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
GENERACIÓN DE TRACE
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>
<log4net threshold="OFF">
<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>
<system.runtime.remoting>
<application>
<channels>
<channel ref="http">…
<lifetime leaseTime="5M" renewOnCallTime="2M" leaseManagerPollTime="10S"/>
<service>
<wellknown mode="Singleton" … ="factory.rem"/>
</service>
</application>
</system.runtime.remoting>
<log4net>
</configuration>
Formato de mensajes
<channel ref="http">
<serverProviders>
<formatter ref="binary"/>
</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>
<system.runtime.remoting>
<application>
<channels>
…
</channels>
<client>
<wellknown type="com.genexus.distributed. … url="http://localhost/srv/factory.rem"/>
</client>
</application>
</system.runtime.remoting>
<log4net threshold="OFF">
….
</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>
<formatter ref="binary"/>
</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>
<formatter ref="binary"/>
</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.
Puesta en producción
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*
D
(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ÓNLa 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 fontsLeftMargin 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: 999setLineHeight: 15GxAttris: \-> 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 assemblypublic 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 modeloD. 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:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/introremoting.asp
.NET CHANNEL SERVICES
http://msdn.microsoft.com/library/default.asp?url=/library/en-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.aspx
ASSEMBLY
Es la unidad de los objetos programados con .Net
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconassembliesoverview.asp
CODE ACCESS SECURITY
http://msdn.microsoft.com/library/default.asp?url=/library/en-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:
http://msdn.microsoft.com/library/default.asp?url=/library/en-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
http://msdn.microsoft.com/library/default.asp?url=/library/en-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:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconstrong-namedassemblies.asp
WMI (WINDOWS MANAGEMENT INSTRUMENTATION)
http://msdn.microsoft.com/library/default.asp?url=/library/en-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'.
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 codeException 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
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: 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
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.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.Description: An unhandled exception occurred during the execution of the current web request...
Motivos/Soluciones:Algún error de tipos o valores en el pasaje de parámetros . Verificar los mismos.
o Configuration Error
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: 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.
o Configuration Error
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: 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"/>
<appendToFile value="true"/>
<maximumFileSize value="9000KB"/>
<maxSizeRollBackups value="4"/>
<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.logclient2003-12-18T163751.log….
Apagar el log, ponerlo en OFF y sin appenders en el root:
<root>
<level value="DEBUG" />
</root>
Dejar el log prendido (ALL) pero con salida a consola en lugar de
archivo.
<root>
<level value="DEBUG"/>
<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/BINARYVERSIONMISMATCH.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.DistributedObjectFactory, 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.