XSharp builds on .Net Core

[robert]

I would like to share some progress that I made today.
I have changed the X# build system to support building for .Net Core. Consider an app that has one PRG file and a XSPROJ file.
The contents of the XSProj file looks like this:

Code: Select all

<Project Sdk="Microsoft.NET.Sdk">
  <Import Project="$(XSharpMsBuildDir)XSharp.NET.Sdk.props" />
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp5.0</TargetFramework>
    <ins>true</ins>
    <dialect>vo</dialect>
  </PropertyGroup>
<ItemGroup>
    <Reference Include="XSharp.Core" />
    <Reference Include="XSharp.RT" />
    <Reference Include="XSharp.RDD" />
    <Reference Include="XSharp.MacroCompiler" />
</ItemGroup>
<Import Project="$(XSharpMsBuildDir)XSharp.NET.Sdk.targets" />
<ItemGroup>
  <PackageReference Include="System.Text.Encoding.CodePages" Version="4.7.1" />
</ItemGroup>
</Project>

As you can see we are compiling for .Net Core 5.0 and for the VO dialect. I have included the XSharp assemblies needed to open a DBF file. The only "strange" thing in here is the package references to the System.Text.Encoding.CodePages package, because by default .Net Core does not have support for Codepage 1252 which I am using.
Unlike traditional project files there are no items included. By default .Net Core includes all source code items in the folder.

The code looks like this:

Code: Select all

USING System.Text

FUNCTION Start() AS VOID
FIELD CUSTNUM, LASTNAME, FIRSTNAME
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance)
? "Hello from X#"
? "OS       :",OS(TRUE)
? "Framework:", System.Environment.Version:ToString()
? "Xsharp   : version", Version(), "dialect", RuntimeState.Dialect:ToString()
? "Datetime :", DateTime()
? "Program  :", ExecName(TRUE)
? "Workdir  :", WorkDir()
? "Curdir   :", System.IO.Directory.GetCurrentDirectory()

? "Opening, Indexing and listing a DBF with .Net Core"
?
USE Customer
INDEX ON LASTNAME TO LASTNAME
DO WHILE ! EOF()
	? Str(CUSTNUM,2) , LASTNAME, FIRSTNAME
	SKIP
ENDDO
? "Press any key"
Console.ReadLine()
RETURN

As you can see I am calling a function in the Encoding class to link the package that has the codepage support.
The rest is a normal mixture of Xbase code and .Net code.
To compile and run the program I type

Code: Select all

dotnet run

on the command line.
The result is this:

Code: Select all

Hello from X#
OS       : Windows 10 Enterprise (x64) ( Version 10.0, Build 18363 )
Framework: 5.0.0
Xsharp   : version XSharp 2.5.2.0 dialect VO
Datetime : 29-07-2020 16:10:58
Program  : C:testbinDebugnetcoreapp5.0test.dll
Workdir  : C:testbinDebugnetcoreapp5.0
Curdir   : C:test
Opening, Indexing and listing a DBF with .Net Core

 6 Baker      James
 2 Borne      Maria
15 Chandler   Walter
 3 Cooper     Elizabeth
12 Cusumano   Karen
 5 Dougherty  Janet
 .
.
14 Walsh      Gloria
19 Zimmerman  Carla
Press any key

As you can see the runtime, RDD system and Macro compiler all work on .Net Core 5.0 !
You can deploy this app with all support DLLs in one single Exe and 2 small DLLs by calling:

Code: Select all

dotnet publish --self-contained true -r win-x64 -p:PublishSingleFile=true -p:PublishTrimmed=true 

This creates the following files, which make up the whole program:

Code: Select all

29-07-2020  16:13        28.955.153 test.exe
28-05-2020  08:26           500.608 hostfxr.dll
28-05-2020  08:26           506.248 hostpolicy.dll

Even the XSharp DLLs are included in test,exe. The total size is 29 Mb.

You can also prepare an image for Linux by replacing win-x64 with linux-x64 and then the output is:

Code: Select all

29-07-2020  16:16        44.552.454 test
28-05-2020  07:54           563.728 libhostfxr.so
28-05-2020  07:54           532.408 libhostpolicy.so

A self contained .Net app for Linux in 44 Mb !

I hope you find this interesting.

Robert

And yes this will be included in the next build. Not with the VS project system, that will take a bit longer.

[wriedmann]

Hi Robert,
that is really great, thank you very much!
@Chris: It would be a cool thing to have this supported also in XIDE as it is my favourite development environment.
Wolfgang

[Chris]

Hi Wolfgang,

I wouldn't be surprised if there are absolutely zero changes needed in XIDE to support compiling for .Net Core. But will check when I get the new compiler from Robert!

[robert]

Chris,
I did not make changes to the compiler for this. You can use the 2.5b compiler (actually all the 2.x compilers) for this.
The changes are in the build system because:
- you do not need to include the reference assemblies (except for some special references).
- MsBuild automatically includes all relevant reference assemblies from the folder in"c:Program FilesdotnetpacksMicrosoft.NETCore.App.Ref5.0.0-preview.5.20278.1ref" . The exact folder name depends on the framework chosen of course.
For the test that I did with "netcoreapp5.0" that resulted in a list of over 150 assemblies. From what I see MsBuild simply includes all DLLs from that folder.
- Of course we also need to use these assemblies inside the intellisense for type and member lookup.

Robert

[Chris]

Robert: Thanks, that's what I expected!

Wolfgang: Have you tried compiling against the .Net code reference assemblies with the existing XIDE and compiler? I would not be surprised if that works already out of the box...

[Meinhard]

That sounds great Robert!

Regards
Meinhard

[wriedmann]

Hi Chris,
if I remember correctly, XIDE does not uses MSBuild, but calls the compiler directly, and the .NET Core thing is implemented in MSBuild.
Wolfgang

[Chris]

Hi Wolfgang,

What do you mean it is implemented in MSBuild? Doesn't it still use the compiler to simply create executable files?

I remember during the Compact Framework early days when during a conference there were people from MS telling us that the only way to build compact framework apps was by using VS (not the other freeware alternative clones), and at the same time in another room another speaker was demonstrating writing compact framework apps in VIDE (as it was called back then)

[ic2]

Let me try to summarize what I have collected and see where other readers may show if I am wrong somewhere:

- .Net 4.8 is the last .Net Framework version. It is a stable Windows desktop only development environment.
- .Net Core 3.0 is the last .Net Core version. It is multi platform (software will work on Linux or Mac) and it operates faster. But it is not yet matured, relies more on command prompt command and is harder to learn and use.
- You can't just "go from .Net Framework to .Net Core" . If I take a look at https://docs.microsoft.com/en-us/dotnet/core/porting/ it is not something I would look forward to.
- Around November 2020 .Net 5 will be released which is the next version of both .Net Core 3 and .Net Framework 4.8.
- It is now possible to create an installation package to run a (any?) X# program on .Net Core.

What is unclear to me is:

1 Will current & future .Net Framework programs stop running on .Net5 unless you go through Microsoft's impossible conversion routine?

Or will that conversion no longer be needed in .Net 5?

Or does anyone .not converting to .Net Core have to rely on 4.8 from 2019 for the length of years? .Net Framework 4.8 won't maintained anymore but only "supported as a Windows component on the latest required update for the operating systems W7 SP1, W8.1 + W10 from 1607). Hence a bit like VO it still works but it is not maintained.

2 Could X# users run all programs on .NetCore? Of course when using X# libs only (we reverted to the Vulcan DBFCDX system for some of our programs). Or isn't it that simple?


More info in
https://www.c-sharpcorner.com/article/d ... -net-core/

Dick

[wriedmann]

Hi Chris,
if I understand correctly what Robert wrote, the entire build process for .NET Core is done by MSBuild. This is not only done by compiling the source code, but also downloading the needed assemblies from somewhere (Nuget?).
I have to look how to do that manually, or better, with XIDE. Currently I have no idea about that.
Of course, .NET Core is not a requirement for the next days, but rather for the next months and years.
Specially the possibility to build an all-inclusive executable is very interesting - it would simplify the upgrade process for my current type of work (several builds and installations of an application during a workday).
Wolfgang