The .NET Generator is the evolution of the .NET Framework generator.
Both generate C# code and share the same repository of GeneXus Standard Classes.
There are some differences between the .NET generator and the .NET Framework generator because of underlying differences in the platforms (Check .NET Platform restrictions).
Also, the .NET generator is similar in several aspects to the Java generator because the generated code runs on Linux.
Differences in the generated code
The code generated by the .NET generator is practically the same as that generated by the .NET Framework generator, except that the .NET generator creates fewer sources.
For REST services, sources with suffix _services.cs (*_services.cs) are not generated (but *.svc are still generated).
Also, *.rsp bld * .cs are not generated in any case.
The generated code remains in the build directory (parallel to the web directory):
When generating for .NET Framework, the web.config file contains the environment properties settings. The equivalent in .NET is called appsettings.json. The format is JSON (property-value list) and it is generated with a structure that is very similar to the web.config file.
The appsettings.json file has less information than the web.config file because the sections that are specific to ASPNET aren't in the appsettings.json file but they are directly programmed into the GeneXus Standard Classes code.
The .NET generator only creates a small web.config file when configuring the Web Server property = Internet Information Server. It is very small and contains the settings to connect the IIS with the Kestrel web server.
Note: .NET provides a standard mechanism to override the appsettings.json file. Read more at
SAC #54342.
- In .NET Framework, command line main procedures have a .exe extension, and in .NET they have a .dll extension. They are executed with a command like this:
- To execute main procedures, the corresponding .deps.json—which contains the dependencies and their paths—must exist in the same path as the executable.
- For example, to run amainprocedure.dll, amainprocedure.deps.json must be in the same directory as amainprocedure.dll
- At runtime, when running the application in a browser and comparing an application generated for .NET with another generated for .NET Framework, you will see only a few differences:
- The headers show that for .NET Framework the server is Microsoft-IIS, and for .NET, the server is Kestrel.
- You will also see differences in compression:
- .NET Framework always compresses with gzip.
- .NET has multiple compressors and uses the first one in the list supported by the client (Example: 'br' corresponds to Brotli compressor).
- The URL is the same (and can be customized with URL Rewrite object)
- Performance & multithreading: .NET supports concurrency in requests in the same session by default, while.NET Framework queues them, unless you change the configuration (.NET framework 4.7 supports that). The behavior of .NET is similar to Java in this aspect. (ref. https://stackoverflow.com/questions/44527292/enabling-concurrent-requests-from-same-session-in-asp-net-core)
The MySQL driver for .NET does not support multiple data readers. This implies the following:
If you have nested loops on the database tables (e.g., nested For each commands or a For each command with a nested new), and the recordset that is returned by the outer For each has a high cardinality, memory consumption can be very high.
When the Web Server property is set to Kestrel HTTP Server, while the server is running an open console shows information about the runtime execution, including unmanaged exceptions and errors.
When the Web Server property is set to Internet Information Server, a trace containing the internal Kestrel server output can be activated through the web.config (by setting the "sdtoutLogEnabled" as shown):
