Comparing the .NET Core generator with the .NET generator

The GeneXus .NET Core Generator is very similar to the .NET generator because they share most of the code. 

Both generate C# code and share the same repository of GeneXus Standard Classes.

Some differences between the .NET Core generator and the .NET generator are only because the .NET Core generator is still in the development stage, while other differences are due to differences between platforms.

Also, the .NET Core 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 Generator level, offers different values for the .NET Core generator and the .NET generator because the platforms are different. For example, the "Kestrel HTTP Server" value is only offered for the .NET Core generator because it is specific for it.
   
• The output shown in GeneXus after any Build operation is similar in both cases. Both generators compile with the MSBuild mechanism.
  • The .NET Core generator compiles using the "dotnet build" command.
  • The .NET generator compiles using the msbuild.exe command but only to avoid requiring the .NET Core (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 GeneXus IDE and also to debug the generated code.
  
  

The generated code remains in the build directory (parallel to the web directory):

Differences related to the generated code

The code generated by the .NET Core generator is practically the same as the generated by the .NET generator, with the exception that the .NET Core 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.

Differences related to the generated configuration files

When generating in .NET, the web.config file contains the environment properties settings. The equivalent in .NET Core 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 Core 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 related to the generated code for Main procedures

The command line main procedures that in .NET have a .exe extension, in .NET Core have a .dll extension.

They are executed with a command like this: dotnet.exe aproceduremain.dll

Also, each main procedure requires a corresponding .deps.json that contains the dependencies and their paths.

Sample:

.NET -  amainprocedure.exe
.NET Core - amainprocedure.dll + amainprocedure.deps.json

Differences at runtime

At runtime, when running the application in a browser and comparing an application generated with .NET and another generated with .NET Core you will see only a few differences.

• You can see in the headers that for .NET the server is: Microsoft-IIS, and for .NET Core, the server is Kestrel.
• You will also see differences in compression:
  • .NET always compresses with gzip.
  • .NET Core 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.

Differences in Navigation (MySQL)

The MySQL driver for .NET Core does not support multiple data readers. This implies the following:

If you have nested loops on tables of the database (eg, 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 there is an opened console where the information about the runtime execution is displayed as well as unmanaged exceptions and errors.

When the Web Server property is set to Internet Information Server, there is a trace containing the internal Kestrel server output that can be activated through the web.config (by setting the "sdtoutLogEnabled" as shown):