Model Configuration
1. Create a prototype / production model by selecting:
§ Language = .NET
§ User Interface = Web
2. Setup model properties:
§ General / .NET Specific / Access Method = ADO.NET|ODBC
3. Setup DBMS options:
§ 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. Setup execution properties:
§ Compiler directory
§ Name of virtual directory (Service used by default)
- Run database creation (the database created is supposed to exist)
§ Build / Create Database
- Generate programs:
§ Build / Build All
- Run execution dialog (F5). Compile main objects that you have, otherwise compile “Developer Menu”
- Run main object compiled or “Developer Menu”
On compiling Webxxx, Hwebxxx.dll (IL code) assembly is generated under the bin directory and an entry may be added in web.config or not (depending on the property HttpHandlerFactory )
The compilation output is sent to the Runout.log file.
Hwebxxx.aspx is called in runtime.
Notes:
- In case you setup trusted connection (step 3) you must setup ASP.NET rights
- In case you use ODBC access, you must setup the Access technology in the DBMS Options to set: ODBC (Step 3) and Model Property Access Method in ODBC as well. If you want to get connected through a data source ODBC, it must belong to the system.
- After compiling, GeneXus will create a virtual directory with the name specified in the local IIS, pointing at the < KB physical directory >\<dataxxx>\web.
- In case you execute from a directory of the internal network, you must take into account the settings of Rights .NET and Web server rights to execute an application for steps 5 and 7.
To access these properties you must go to: “File/Edit Model/ Properties button”.
It indicates if the required files are generated to compile the developer menu.
The NO value is useful to avoid the developer menu makefile building. It is quite expensive since it must generate all the response file (*.rsp) each time an object is compiled.
Default value: Yes
It determines the application namespace. The programs generated by GX and compiled with C# are available under the namespace indicated by this preference. The default is GeneXus.Programs. It is useful for advanced users who want to carry out some kind of deployment in the GAC (Global Assembly Cache).
<o:p> </o:p>
Default value: GeneXus.Program.
Generate strong-named assemblies
This causes the assemblies generated and compiled with this feature to have a unique name. It allows access to a series of important advantages provided by the .Net Framework, such as:
· Deployment in the GAC (Global Assembly Cache)
· Security configuration for the assembly (it allows configuring the security to run assemblies coming from unsafe zones).
Values
Yes: The program is generated with a unique “Strong Name”.
No: The program is generated without “Strong Name”.
Default Value: No
To generate the Key identifying the object, the generator searches for a key.snk at compilation time (typically dataxxx). If it does not find the key.snk, it generates one.
Besides, in the ‘PATH’ environment variable, you must configure the path to the required tools so that the compiler finds them (the path is similar to the following one: "<Program files>\MICROSOFT.NET\SDK\V1.1\bin" ). In other cases could be occurred the "Before compile error: The system cannot find the file specified"
This is useful since if a company has a generated key, it can continue using it for all its products (for this, you must copy the file with the key as key.snk in the model directory).
All the standard programs provided by the generator are already distributed with ‘strong name’
IMPORTANT: To use this feature, you must install the .net framework SDK 1.1 (or 2.0) in the development environment (to be able to execute the sn.exe and generate the file with the Key).
Assembly versión number
It determines the number of the version to be assigned to the ‘Strong Named assemblies’. It only applies when the Generate strong-named Assemblies property is set to Yes
Default Value: 1.0.0.0
This information is stored, on generation time¸in GxAssemblyInfo.cs file.
Compiler Flag
The information of this preference will be included in the .rsp used to compile the main.
It is useful, for instance, to generate debug information (including the string “/debug”) or to include a dll within the namespace (/r:xxx.dll ).
Config HttpHandlers Section
The information of this property determines how assemblies are mapped in runtime.
Values
HttpHandler for each object: An entry in web.config for each assembly. Aspx request is mapped here with the assembly GeneXus.Programs.object (bin\object.dll)
HttpHandlerFactory: There is only one entry for all the objects in web.config, where an object to which the mapping will be requested is indicated.
ASHX: There are no mappings in web.config. An ashx file is generated for each object doing the mapping with the assembly GeneXus.Programs.object
The value HttpHandler for each object is faster in runtime but slower in the initial loading. Besides, it allows having objects (*.aspx) not generated with GeneXus, while with HttpHandlerFactory it is no so.
HttpHandlerFactory is faster to prototype but slower in each call since the mapping is solved in each requirement. This option may send poorly descriptive error messages, which makes prototyping more difficult.
The ASHX value is similar to Handler Factory. It creates a physical file with the name of the object plus ashx extension, which is called in runtime.
Default Value = HttpHandler for each object
Access Method
It determines the type of access to be used to access the database. The access method specified will be used to access each data store.
Values
ODBC: Access througth ODBC
ADO.NET: Access througth ADO.NET
Default Value = It depends on the Dbms associated to the Default data store.
ADO .NET Specific Section
Propiedad Enable Caching
This property allows you to indicate whether you want to work with caching or not (in an application generated with .NET, using ADO.NET to access the database).
Values
Yes: enabled caching
No: disabled caching
Default Value = No
Caching Section
The following properties only apply when the Enabled Caching property is set yo yes
When you read a table that has the “Hardly Ever” value in the “Change frequency” property, the caching is performed during the time defined in this property
Default Value = 600
When you read a table that has the “Time to Time” value in the “Change frequency” property, the caching is performed during the time defined in this property.
Default Value = 60
Although the “Time to Time” property works similarly to “Hardly Ever”, the existence of both properties allows defining different persistency points in the model table.
TTL means Time To Live.
To define the time while the data will remain in memory you have the “Change frequency” property at tables level, which can only be edited at the design level.
The possible values are:
Values
Almost Never: Caches data endlessly.
Pretty Often: the table is not cached. This is the default value.
Hardly Ever: Value defined at Prototype level.
Time to Time: Value defined at Prototype level.
Default Value = Pretty Often
Log Level
This property allow you enable an application trace generation (log file), when access to the database througth ADO.NET.
Values
0. Off
1. Fatal
2. Error
3. Warn
4. Info
5. Debug
6. All
Default Value: Off
This property writes the <log4net threshold=...> tag of web.config and client.exe.config files (for Web and Gui models respectively). The <trace enabled=true /> tag is also written for web models.
One of the most important costs in ODBC/ ADO.NET operations is the one arising from SQL statements preparation. The preparation includes compilation and validation of the syntax of this statement by the server.
Programs generated in .NET manage open cursors intelligently so that there is no need to prepare those cursors that were already prepared. For this, a prepared cursor pool is kept, with a default 100-cursor size. If you want to change this number you can change the value of this property.
Default value: 100
To enter these properties you must go to: “File/Edit Model/ Execution Button”.
Compiler path
It determines the compiler path (csc.exe). It is provided by the SDK framework and is located under its installation directory <NET frameworkpath>\csc.exe, being the < NET frameworkpath> = WINNT\microsoft.net\vx.x.xxxx
It determines the execution base URL. It contains the virtual directory to be created (if it does not exist) by GeneXus, in the local Internet Information Service (IIS). The creation is carried out after the compiling and reorganization processes are finished.
The objects generation process takes two stages:
Generation
After having specified an object, when generating it, the generator creates the following for each object:
- A file with the source code in C# language (.cs),
- A file with the same name as the object and with '.rsp' extension. This file contains the information required to compile it (sources included, references, etc.).
- If it is main, it also creates a bld<object name>.cs file that executes the assembly of the object and the related ones (called from it). The other main objects are not included within the related ones, since they are assembled compiling them specifically.
- If a reference is made to SDTs, collections or Business Components, a type_<nombre_del_sdt>.cs file is created with the definition of the structured type referenced.
- The gxcommon.rsp file is also created. Its objective is assembling an assembly (with the same name) that includes the objects common to all the assemblies (SDTs, collections).
The code is compiled (from the generator F5 dialog) and a dll is generated with the common .NET code (IL). This is supervised, in runtime, by an interpreter (CLR) that allows executing it, converting it into a PC code.
The log with the compilation result is displayed on the screen and stored in the RunOut.log file.
The Web.config file or the header object (depending the config httphandler section property ) contains the information on the web application configuration. There, each dll is associated to a virtual page with ASPX extension. There is no physical aspx file. The Web.config are sorted by priority in ascending order in the directory tree.
Only with the Ashx value of this property, a physical file is generated for each object.
The WebConfig file is generated from GXCFG.Web, which has an entrance for each object and is the UpdateConfigWeb that enters the information to the Web.Config after the compilation is finished.
Like the other generators, .Net is supported by a set of standard programs. These programs have StrongName which means that they are identifiable, with a unique name in the .NET universe. Generated programs also have the possibility of setting up a strong name (but reorganization assemblies don’t). This is useful to do the automatic deployment in Global Assembly Cache (GAC)
To enable application trace generation (log file), you must setup the Log level model property. This property adds two settings in the web.config file after the compilation.
1. Enables the trace setting up with the “threshold” tag
<log4net threshold="<Value>">
2. Enables the log file
<system.web>
<trace enabled="true" />
With step 1 if <Value> is different from OFF, log messages are generated, but they are sent to the ASP.NET trace and accessing the log file is not possible. Step 2 is setup with this objective.
By default the Web models have ASPNetTraceAppender as “root appender”, this means that it does not generate a file as logging file, but that it sends logging messages to the ASP.NET trace. Therefore, the above mentioned settings must exist for generating the file.
After generating a logging file from Web applications, you may see it by accessing the following URL: http://servername/dirvirtual/Trace.axd
When a remote Web application is run, it is necessary to include the localOnly ="false" option in order to visualize the trace from client PCS.
Otherwise, the trace will only be visualized from the server itself. For visualizing the trace from client PCs, the following input must be introduced:
<system.web>
<trace localOnly="false" enabled="true" />
Notes:
- Logging file generation may degrade application performance; this is why we recommend having it switched off in production.
- For <log4net threshold="OFF">, the logging file is not generated, and none of the below mentioned settings (trace and root) are taken into consideration. In this case, logging messages are simply not generated from GxClasses.dll.
- From web application, it is possible to generate a log file.
- For more information about log4net, go to the following URL: http://logging.apache.org/log4net/
When we are working with .NET applications, we have configuration files where certain application properties are defined, such as the information for the connection to the database or the settings of a “log” file.
It is created when web applications are generated and is used when we run applications under Internet Information Server.
It has the settings about the location of the applications server, the connection to the database and the generation of the “log”, among others.
It is located under the “dataxxx” model directory and its structure is similar to the following:
<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>
The System Web section is not rewritten by the generator. The Appsetting section is written by the generator after each compilation (model properties and generator settings are stored there).
Note: This web.config is also used in distributed applications when the applications Server runs under IIS. For further information please refer to Distributed applications
DataBase connection
The information of the connection to the database remains stored in the web.config file with the following format:
<appSettings>
<add key="Connection-Default-DataSource" value="mydatasource" />
<add key="Connection-Default-User" value="Elj20MqY44RPdvT8FEpDD0==" />
…
These tags are not framework proprietors; they are defined by the generator. In some casers, their content do require a standard format defined by the platform. E.g.: the database connection string in ADO.NET models with SqlServer may be:
<add key="Connection-Default-Opts" value=";Integrated Security =No; Max Pool Size = 50; Min Pool Size=10" />
Identity impersonat
This allows web objects to run with the user that IIS transfers to the .net platform. Otherwise, the processes run with the “machine” account (ASP.NET user).
It is specified within the System.Web section with the following tag
<identity impersonate="true" />
Considerations:
- It is necessary if you want to use trusted connection for the connection to the database (Sql Server); otherwise, it executes with ASPNET user.
- PDF Reports: When having identity impersonate="true", the user executing in the page IIS must have written rights over "C:\Documents and Settings\<webserver name>\<ASPNET\Local Settings\Temp" with IIS 5 or higher version. With IIS 6.0 or higher version (Windows 2003) rights must be granted over the directory C:\Windows\Temp\...\iTextdotNET. (but it is configurable) .
Otherwise, the following error occurs: Access to the path "C:\DOCUME~1\ARMIN-NB\ASPNET\LOCALS~1\Temp\e8ebd99f-17de-4447-83f8-35769f67bd23\iTextdotNET”
SessionState
To implement sessions management (Websession data type) the generator uses the HttpSessionState provided by the framework.
There are three ways to store the session state:
1 – Inproc, which uses aspnet_wp.exe.
2 - Stateserver used when there is more than one server.
3 – Sqlserver, which uses SQL Server tables instead of the web Server memory to store the information saved in the sessions.
<o:p> </o:p>
Inproc is the default mechanism implemented by the generator. When aspnet is recycled, session variables get lost.
StateServer the websession can be stored within the memory space of a process called aspnet_state.exe.
This is useful in prototyping to maintain the websession, since after recycling aspnet_wp or compiling the objects and upload them again, the Websession gets lost.
To implement it, you must first upload the ASP.NET State Service (aspnet_state.exe) service in the PC that will maintain the session. Then, you must add the following line in web.config:
<system.web>
<sessionState
mode="StateServer"
stateConnectionString="tcpip=name_pc:42424" />
....
....
</system.web>
The stateConnectionString attribute contains the IP and port of the PC used to maintain the session The default port is 42424.
Sqlserver, for this you should:
1 - change web.config with the connection string
<system.web>
<sessionState mode="SQLServer"
sqlConnectionString=" Integrated Security=SSPI;data source=dataserver;"
2 – add the following line to machine.config
<httpmodules>
<add name="sessionState" type="System.Web.State.SessionStateModule" />
</httpmodules>
You can setup the time the session variables last. By default they expire; websession variables lost their value with a 20-minute timeout.
This timeout can be setup from
<sessionState mode="InProc"
cookieless="false"
timeout="20"/>
For more information, please refer to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconsessionstate.asp
In w2003 Server, you can setup the timeout by virtual directory. For this, in the virtual directory properties, you must setup the value from: Virtualdirectory\Configuration\options\Enabled Session State
Http Execution Timeout
<o:p> </o:p>
There is a way of setting up the request's timeout in .Net applications (both in Web applications and in 3-tier applications hosted in the IIS).
In Web applications, if a page request takes more than 90 seconds, a Request Timeout message will be sent to the browser.
To avoid timeouts, you must create the following in the System.Web session of the web.config file:
<httpRuntime executionTimeout="<secs>"/>
Where <secs> is the number of seconds you want to wait; e.g.: 3600.
For more information, please refer to the HttpRuntime section:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/gngrfhttpruntimesection.asp
Generate log file – Rolling file
It is possible to setup a Web model so that it will also generate a text file by adding the following inputs in the web.config file:
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>
Please note that slashes “/” must be used for specifying an application directory.
2. The <appender-ref ref="RollingFile"/> input must also be included.
Input inside Tag root, for instance:
<root>
<level value="DEBUG"/>
<appender-ref ref="RollingFile"/>
<appender-ref ref="ASPNetTraceAppender" />
</root>
It is important to differentiate “appenders” that are working as “root”, because these appenders are going to be considered by log4net when printing logging messages. It will send log messages to all appenders inside the “root” tag.
In the previous case, since the "RollingFile" and “ASPNetTraceAppender" values are not setup, the client.log file will be generated in the web/logging directory, below the model directory and access to the trace will also be possible through the following URL: http://servername/dirvirtual/Trace.axd
In this case, there is only a single appender:
<root>
<level value="DEBUG" />
<appender-ref ref="ASPNetTraceAppender" />
</root>
Therefore, the client.log file will not be generated. There will only be access to the trace through the following URL: http://servername/dirvirtual/Trace.axd
If in a Web application web.config file the following is setup:
<log4net threshold="ALL">
and in the Tag root:
<root>
<level value="DEBUG" />
<appender-ref ref=" RollingFile" />
</root>
the following settings will not be taken into consideration:
<trace enabled="true" />
<trace localOnly="false" enabled="false" />
because these settings are only valid for the following appender:
<appender-ref ref="ASPNetTraceAppender" />
Production Cutover
The .NET platform does not use the registry and allows configuring the dll versions to be used; thus, to install in the server consists simply in making an xcopy.
The following must be copied to the server:
- The model bin directory (where each object’s dll is located)
- The javascript ( *.js)
- The images
- The Web.config file
- If we use Office data types, the gxoffice2.dll must be registered.
The requirements are similar to the developed environment ones:
· Web Server
- Internet Information Server 5.0 or higher
- .Net SDK Framework 1.1 or 2.0 (recommendable: Carry out the installation of this tool starting from the Windows component update provided by the Visual Studio .NET setup)
- Database client
· Database server
A browser is enough.
In case of Internet Explorer, the minimum supported version is I.E. 6.0