We think it is time for a progress update and a preview of what you can expect the rest of this year from us.
When | What |
End of July 2022 | A new build X# 2.13 for our FOX subscribers. This build will have some changes to the compiler, mostly in the area of the handling of DEFINES and numeric conversions and the /vo4 and /vo11 compiler options. No real new features are planned for the compiler. The runtime contains some fixes for FoxPro code and contains some small enhancements. The VS Integration contains improvements in the formatting and intellisense, Windows Forms editor |
End September 2022 | We plan to release a new build (most likely called X# 3.0) that is compatible with .Net 5 and beyond. This requires changes to the build system and VS integration and some changes to the compiler. We will also additional compile the X# runtime for .Net 5 and beyond. This build will also no longer be "binary compatible" with X# 2, so new versions of 3rd party components will be needed. Of course we will still support .Net Framework 4.x We also plan to release the first version of the VFP Xporter that takes a VFP project file and converts that to a .Net solution. |
October 2022 | We hope to meet many of you during our X# summit in Memmingen. And you can still register for this event. We will also present a session on Virtual FoxFest about converting FoxPro apps to .Net. |
December 2022 | We plan to release the final version of the AnyCpu/Unicode VO Compatible GUI Classes and the AnyCpu/Unicode VO Compatible SQL Classes. A first beta version of the X# SQL RDD is also planned for this month These runtime components will be for FOX subscribers only. |
The switch from .net5 to .net 6 on the other hand is mostly fixing some namespaces and a recompiling the project. So once X# works on .net5, it most likely works also on .net6 and .net7. 
And one benefit of using .net5 over .net framework is impressive performance gains, because the new runtime is heavily performance optimized (https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-5/)  
You are right. Once we have the support for the SDK style projects then compiling for .Net Core, .Net Standard, .Net 5, .Net 6, .Net 7 and .Net Next will be relatively easy. We will also look to see if we can add support for so called "shared projects", so you can relatively easy compile assemblies for .Net Framework and the other .Net versions in a single solution.
In fact we don't expect that we will need to change (much) in the compiler. The necessary changes mostly have to be done in the build system and the VS integration.
Robert
not sure what you mean by "shared projects". Do you mean .net standard 2.0 projects, that work on .net framework 4.7.2 and net5+ or the sdk style multi-target projects (https://docs.microsoft.com/en-us/nuget/create-packages/multiple-target-frameworks-project-file)?
Shared projects are something that exists for C# and VB.
These are projects that cannot be compiled by themselves. When another project has a reference to a shared project then the source files in the shared project are considered to be part of that project.
Something like:
XSharp.Core-Shared - contains all the source files
XSharp.Core-Framework - Compiles to the .Net framework and has a projectreference to XSharp.Core-Shared
XSharp.Core-Net5        - Compiles to .Net 5 and has a projectreference to XSharp.Core-Shared
XSharp.Core-Net6        - Compiles to .Net 6 and has a projectreference to XSharp.Core-Shared
If you add a new file for XSharp.Core you would add it to the Shared project. By doing that the file will be used by all projects that have a reference to the shared project.
C# uses this for Xamarin. The common code for all platforms is in the shared project. Each platform has its own project that includes the common code.
You could also create a library and include that in each of the projects. But the shared project makes sure that the code in the "library" is compiled for the right framework.
See https://www.c-sharpcorner.com/UploadFile/7ca517/shared-project-an-impressive-features-of-visual-studio-201/ for more info
Robert
@Robert: I still haven't heard you about when the Immediate Window will be usable in X#? While I am now often going through issues with the converted VO program together with Frank who is doing the conversion, I am always confronted with the extremely poor debugging options in X#/VS compared with VO and the extremely long compiler times. Often we have to stop the program to make a small change and then wait another >30 seconds before we can see the result. In VO we could often retrieve some DBF values or retrieve/change variables in the Ctrl X window instead and also a change is compiled and running again in a matter of seconds instead of nearly a minute. If the development time is going to "shared projects" and .Net5-x and Immediate Windows and compile times remains as it is today, I think the priorities are wrong. Unless I am the only one who would want to save on daily waiting times instead of getting features needed by few users.
The intermediate window is coming to VS. We're working on it, but it is a bit more difficult than adding something like that to the VO IDE, because we have to follow the rules of Visual Studio and the rules of .Net.
If you see compilation times of > 30 seconds then you either have a slow PC or there is something wrong in how your solution/project is setup or your solution/project is VERY large.
What we will try to do is add  support for "edit and continue" like C# and VB has. But again, that may be complex.
Anyway, I think it is unfair to state that
Others would probably argue that we should not spend too much time on the Intermediate window.
We try to make everybody happy, but with a small team we have to set priorities.
For example: this week I have spent a significant amount of time on the formatting of the source code in the editor. That is something that you have asked for. Does this make the language any better: no.
Does this benefit users that are working with XIDE: no. But I have given it priority anyways.
@Robert: I am looking forward to improved code formatting in X#, thanks for spending time on that. It's probably an idea to organize some vote of what users like to see most, although with the results you can sometimes give priority to a less voted feature with little programming time. For me I am nearly only interested in working fast and comfortable like I do in VO (where possible, there will always be some advantages in VS and some, larger, disadvantages). Nearly everything else is unimportant for me. I prefer better editing much more than what you consider, no doubt on good grounds, "a better language". But if the majority of users prefer the support of every flavour of the day Microsoft releases instead of of saving development / waiting time, then I can well imagine you will spend your time differently.
Franks Pc is brand new and very fast, the large project is the (xPorted) project which compiles and reruns in VO in seconds and despite some recommended attempts to exclude recompiling everything X#&VS need for example 23 seconds to restart the program even after just adding 1 space in a comment where it shows "Build started..." and then builds 16 libraries before it eventually starts the program. That would take 3 seconds in VO on the same Pc.