Progress Update Summer 2022

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.

18 comments

  • Here are my 2c on the .net5 discussion. While the switch from .net framework 4.8 to .net5 is very complicated because you switch to a new runtime (mostly rewritten from scratch) and also new tooling (dotnet instead of msbuild, new winforms designer, ...).Γö¼├í
    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/)  
  • Volkmar,

    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
  • 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)?
  • Volkmar,
    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

  • @Volkmar: have you actually noticed any real life performance gains in your .Net5 based programs? My experience is that any Microsoft claim that they improved something was almost always untrue and often it got even worse.
    @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.
  • @Dick,

    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

    development time is going to "shared projects" and .Net5-x


    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.



  • @Ic2: as a matter of fact, I noticed quite huge performance differences on specific functions. I made a .net Standard 2.0 assembly for encryption, because the functionality was needed by an X# .net framework application and a .net6 webapi. I created unit tests to check, if the functionality works as expected on both runtimes. I was surprised to see, that the execution time was 45 seconds on .net framework and 6,5 seconds on .net6. The code for the unit tests was exactly the same, because I shared the file between the two unit test projects.Γö¼├í
  • @VR: that's an interesting performance gain. I am not used to seeing any MS claim that something improved is actually true. Nevertheless I still won't hurry to use it as the End of Support is very limited and .Net Framework's support isn't. You could argue that with often some small changes you can also support the upcoming versions but I would then expect chaos among different DLL's used or different users, apart from the huge chance that Microsoft invents something else halfway.

    @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.