Official Content

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 related to the IDE

  • The Web Server property available at the Generator level offers different values for the .NET generator and the .NET Framework generator because the platforms are different. For example, the "Kestrel HTTP Server" value is only offered for the .NET generator because it is specific to it.
  • The output shown in GeneXus after any Build operation is similar in both cases. Both generators compile with the MSBuild mechanism.
    • The .NET generator compiles using the "dotnet build" command.
    • The .NET Framework generator compiles using the msbuild.exe command but only to avoid requiring the .NET (because both can compile with the "dotnet build" command).
  • A Visual Studio solution called LastBuild.sln is always generated in every operation, containing the list of objects generated in the last build operation. That solution can be used to rebuild assemblies outside the GeneXus IDE and also to debug the generated code.

    NET Core dotnet build command

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):

NET Core build directory

Differences in the generated configuration files

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.

NET Core appsettings.json

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.

Differences in the generated code for Main procedures

  • 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: 
    • dotnet.exe aproceduremain.dll
  • 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

Differences at runtime

- 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.

Differences in Navigation (MySQL)

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.

Differences related to troubleshooting

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):

NET Core Web Server Property IIS Trace

Last update: November 2023 | © GeneXus. All rights reserved. GeneXus Powered by Globant