Sounds great. Looking forward to it seeing how it progresses.

On Mon, Aug 26, 2019 at 4:14 PM Johan Nel johan.nel@xsinet.co.za wrote:

Hi Patrick,

The aim is to have 100% VFP syntax support in X#. You can use then from a compiled X# application ILSPY to generate c# code. Or the beauty of .NET is that you can mix and match .NET languages. So you can have a .DLL compiled in X# and just consume it in a c# application, same the other way around or even VB.NET/F#. The choice is yours. Beauty is you can have a .DLL with X#(VFP code) e.g. DBF support and consume it from c# etc.

Johan Nel George, South Africa.

On 2019/08/26 19:17, Patrick Bibro wrote:

...

How useful would xsharp be in migrating a VFP application to .NET with

the

...

ultimate goal of having a C# application? Could it be converted to X#

and

...

then decompiled into C#?

On Mon, Aug 19, 2019 at 8:21 AM Johan Nel johan.nel@xsinet.co.za

wrote:

...

...

Good day VFPers,

As promised by the DevTeam the above version was released to the Paid members today. The public release will follow in a weeks time.

Some exciting news:

VFP DBF files are now supported (read/write) with DBC to follow soon.

Xs2Ado an ADO driver for DBF like interfacing to SQL will also be released later this week.

And I believe most important of all, the DevTeam will soon release the Compiler source code also in the public domain!

Hope this is of interest to some.

XBase greetings,

Johan Nel Friend(s) of XSharp(FOX) member https://xsharp.info George, South Africa.

[excessive quoting removed by server]

Apologies for not responding immediately, seems this post got into the wrong folder.

On Mon, 26 Aug 2019, at 6:17 PM, Patrick Bibro wrote:

...

How useful would xsharp be in migrating a VFP application to .NET

with the

...

ultimate goal of having a C# application? Could it be converted to

X# and

...

then decompiled into C#?

Since it presumably generates CIL like any .NET language, you could then decompile it back into C# or VB.Net. Whether the code you get back is of any quality is another question. Tools like ILSPY aren't really

designed for

that purpose.

Yes X# generates CIL, since it is build on Roslyn the c# compiler.

There is also a plug-in for ILSPY to view any .NET assembly in X# syntax, same goes for decompiling it into X#.  I have used it successfully for that purpose.  Still some minor code changes needed, but Fabrice is constantly working on enhancing the ILSPY plug-in.

For converting X# code to other .NET languages, it might look "odd" due to .NET languages being strict typed.

In X# it is allowed to do late-binding, hence:

LOCAL i i := 0 i := "Foo"

is acceptable, however c#/VB.NET don't like that, so you will find decompiled X# code in c# looking like:

XSharp.__Usual i; i = 0; i = "Foo";

It is not a problem as long as you reference the XSharp(XBase) runtime in your c# project, because that is how X# internally convert late-bound variables to a Type USUAL that manages all XBase type variables.

In terms of migration I would see X# as mainly being used for building DLLs that leverage existing non-UI code, and then use those assemblies in a C# solution.  Alan Bourke

As you stated, yes non-UI is probably a primary interest for migration, business classes and processes, but it also gives you the ability to interface to DBF etc.  It is anticipated that VFP UI should also be supported, ideally as WinForms/WPF, but as in the case of Visual-Objects the VO Window classes were so far from WinForms that they were implemented with same behaviour as separate classes in X#.  The next month or two will give a clear indication how VFP UI will be handled.  Matt Slay and I have done some work taking scx/vcx files and convert them to X# and VS Designer code.  Most work, but there might be some anomalies that will have to be fixed manually.  Time will tell.

Regards,

Johan Nel

--- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---