TOPIC:

Hi everyone, admins,

Do we have updates about the progress of version 3 of Xsharp ?
My main interest is the support of .net5+

In the next few months, our project is to migrate our applications from VO to XSharp.
We have 3 applications totalling about 500 form windows and 35mb of source code (don't know how many lines of code that would be but the last estimate was about 500k)
We don't use many third party libraries.

Now with XSharp3 being - from my understanding - not that far away, I'm thinking why migrate to XSharp2 if we'll have breaking changes when migrating to XSharp3. Of course that is if XSharp3's out in a not so distant future.

Also, not many new developments will be carried out on those apps themselves, but more around (web)services around the data manipulated by the apps.
Our biggest instance has about 130Gb worth of dbf/cdx/fpt files, the biggest table containing about 10milion lines
My Idea is to develop those services using modern .net stacks (asp.net core 7, json, etc..)
Now I've done a bit of research - but I'm still pretty new to this so correct me if I'm wrong - but it seems the best way to access the dbf data would be with the VO/XSharp RDD ?
I saw there is an VFP OleDb library (v9 something), and some pure c# dbf reader (but I don't think they support index files), but are they as performant as the XSharp RDD ones ?
Our databases are, most of the time, behind an ADS Server, sometimes local one.

So my thinking is to develop the DAL (Data Access Layer) in XSharp and consume it in my webservices by referencing the projects.
But in order to achieve that, my understanding is that the XSharp library has to be .net5+ if my webservice is .net7.
Hence XSharp3 !

Now I know it's a lot of questions/reflections/suppositions, but I have to start somewhere so any input, ideas, clues, challenges would be more than welcome !

Best regards.

Hi Basile,
even if I'm not a member of the development team, I can give you some answers.
First: X# 3.0 in the summer was scheduled for the end of September 2022, but personally I would not expect it before January 2023 (there will be an 2.14 release before). Normally, the releases are in 3 steps: for a small beta team, for the FoX members and as last (and only some versions) as public version. But nevertheless I would start immediatly with the migration from VO to X#, and don't wait for X# 3.0.
Regarding the RDD: if your application has to share data with VO applications, then X# is the only possibility you have because all others are not fully compatible with VO. So again: I would immediatly start developing (and learning X# <g>).
Wolfgang

wriedmann wrote:

Hi Basile,
even if I'm not a member of the development team, I can give you some answers.
First: X# 3.0 in the summer was scheduled for the end of September 2022, but personally I would not expect it before January 2023 (there will be an 2.14 release before). Normally, the releases are in 3 steps: for a small beta team, for the FoX members and as last (and only some versions) as public version. But nevertheless I would start immediatly with the migration from VO to X#, and don't wait for X# 3.0.

We subscribed yesterday to FOX program, with this idea in minde, and to support the future of XSharp as well, but duly noted !

wriedmann wrote:

Regarding the RDD: if your application has to share data with VO applications, then X# is the only possibility you have because all others are not fully compatible with VO. So again: I would immediatly start developing (and learning X# <g>).

SO you mean that not other way than via VO/Xsharp to access the .dbf files used by a VO app ? OleDb, ADO.net, ODBC ? Those drivers are not format compatible with the VO/XSharp RDD driver ?

Oh and thanks for your input

Hi Basile,

SO you mean that not other way than via VO/Xsharp to access the .dbf files used by a VO app ? OleDb, ADO.net, ODBC ? Those drivers are not format compatible with the VO/XSharp RDD driver ?

exactly. It is not only an issue of the DBF files (then most of the available drivers work, and you can even write your own because most of the format is documentetd), but mostly an index and a memo issue. I cann assure you that the X# team has spent a lot of time and energy to make the X# RDD compatible to VO.
Personally I'm also using the Advantage ADO.NET driver to access ADS data in the cases where I have ADS installations.

Wolfgang

Personally I'm also using the Advantage ADO.NET driver to access ADS data in the cases where I have ADS installations.

Ok so ruling out accessing the dbf files directly, which is fine, accessing them through the Advantage ADO.Net driver is how good, performance wise ?
From my understanding, you can even use SQL to query data via the ADS driver right ?

I'm not against learning VO/XSharp - and will have to anyways-, it's just that I won't be producing good production code from scratch, and I'd rather leverage my knowlege in C#/.net

Hi Basile,
I don't think it is a good idea to access files used by VO with the RDD using ADS.

The ADO.NET driver for ADS is a ADO.NET driver, so you can use it with SQL statements only.
Even some limited joins are working.
Wolfgang

Hi Basile,

bmellac wrote:

In the next few months, our project is to migrate our applications from VO to XSharp.
We have 3 applications totalling about 500 form windows and 35mb of source code (don't know how many lines of code that would be but the last estimate was about 500k)
We don't use many third party libraries.

On average, X#/VO/Clipper etc source code has around 30 chars per line, so I'm guessing you are more closely to 1 million lines of code
(that is, of course, if 35mb is the size of the source code itself only, not including windows/menu etc binaries or other resources)

bmellac wrote:

Now with XSharp3 being - from my understanding - not that far away, I'm thinking why migrate to XSharp2 if we'll have breaking changes when migrating to XSharp3. Of course that is if XSharp3's out in a not so distant future.

There will not be any breaking changes that you will need to make in your code, that will remain exactly the same from X# 2 to 3.0. Only thing that willl be necessary is to rebuild all your libraries and also 3rd party vendors will need to rebuild their libraries and release new ones, but their code will not change at all, either. This will be required because the signatures of a few of the public methods/functions in the X# runtime will (slightly) change, in order to make them more compatible to VO. So I would suggest not to wait for 3.0, but you can safely start migration now!

.

There will not be any breaking changes that you will need to make in your code, that will remain exactly the same from X# 2 to 3.0. Only thing that willl be necessary is to rebuild all your libraries and also 3rd party vendors will need to rebuild their libraries and release new ones, but their code will not change at all, either. This will be required because the signatures of a few of the public methods/functions in the X# runtime will (slightly) change, in order to make them more compatible to VO. So I would suggest not to wait for 3.0, but you can safely start migration now!

Hi Chris, thanks for your answer !
And that is good news. So there is no reason to delay the migration project.
How about ETA on v3, if any ?

Hi Basile,
I don't think it is a good idea to access files used by VO with the RDD using ADS.

The ADO.NET driver for ADS is a ADO.NET driver, so you can use it with SQL statements only.
Even some limited joins are working.

But our VO application already accesses data via RDS most of the time (only a few customers have local access).
So if I write DAL code in XSharp, it is safe to say that it can access the same ADS than the VO application right ?

Hi Basile,
if the VO application accesses the data via the ADS local server, then of course it is ok (or better: the correct way) to do the same with X#.
But please make sure that it is the case, otherwise you will corrupt your indexes in a moment.
Wolfgang

Duly noted ! thanks for the hint !

Hi Basile,

bmellac wrote:

How about ETA on v3, if any ?

That should be early 2023.

Hi Basile,
let me add one thing: X# has the concept of "dialects" that have different features.
For the migration of VO code you need the "VO" dialect that supports nearly all the language features of VO, like untyped variables and methods, untyped arrays, codeblocks and all datatypes.
Then there is the Core dialect, that is in fact C# with X# syntax, without the need of any X# runtime library, but also without support for the VO specific datatypes and features. In new projects, I'm using only the Core dialect, and when I need to access DBF data, I use a proper library that uses the VO dialect, but exports only datatypes that are supported by the .NET Framework.
I'm using that dialect in production since the very early days of X#, before the runtime libraries were available.
And even in the X# Core dialect you have access to some nice features like the preprocessor or the short properties syntax.

If you ask me why I'm using the X# Core dialect and not C#: the X# syntax is more explicit (a bit like Pascal that was developed as teaching language), and therefore easier to read and faster to understand: really important if you have to write code that should live and be maintained for more than 20 years (in fact, I have VO code that is more than 20 years old).
And then you can add a devteam with an excellent support and open ears for us programmers, and that is tecnology driven and not sales driven. That combined with the possibility to move our VO codebase to X# (we alone have several millions of code lines to maintain and to migrate) is a terrible value.

Wolfgang