XSharp Cahors 2.5

Today we have released a new installer for XSharp Cahors 2.5.
This new build has many changes. To name a few:

  • The Visual Studio integration has received a major overhaul. The background scanner has been rewritten and de "code model" used inside the editor is now stored in an external (SQLite) database. We have also rewritten the way how type information for external assemblies is read.We are now using the Mono.Cecil library for that, which is faster and uses less memory than the System.Reflection classes we used before
  • We have made many changes in the runtime, and fixed a bug in the DBFCDX RDD. We have also added a method to validate an index. See the What's new document for more information.
  • There are also some changes to the compiler. For example we now support typed parameters in compile time codeblocks !
  • Finally, this build also included typed version of Console Classes, System Classes and RDD Classes. One of the next builds will also include typed versions of SQL classes and GUI classes.

XSharp 2.5 will be the last build that works with Visual Studio 2015. We are going to make more changes to our VS integration and use features that are not supported by Visual Studio 2015.

The what's new document describing all the changes can be found here:

{rsfiles path="general/Readme/whatsnew25.rtf"}

{rsfiles path="fox/Compiler/XSharpSetup25Fox.zip"}

The public version of the 2.5 build will follow shortly, unless some important problem is found in the next couple days.
Thank you to all of you for your continued support and invaluable help in further developing the XSharp product!

 

11 comments

  • Tried 2.5 this morning and had issues editing WinForms in the designer in VS2017 - hanging for ages then getting the can't open form screen - gone back to 2.4a and they open fine - anyone else had this issue?
  • As a quick example I tried:
    1) Fron Solution Explorer, Add > New Item
    2) Select Windows Forms Form
    3) Designer opens with empty form - all ok
    4) Close the form and open the form again - all ok
    5) Add a standard WinForms button from the toolbox
    6) Save and close the form
    7) Try to open the form again and it fails with:
    Could not find type 'System.EnvDTE.Windows.Forms.NetOffice.ExcelApi.Button'. Please make sure that the assembly that contains this type is referenced.

    NetOffice is a library I have referenced but the control I added is a normal button - PRIVATE button1 AS System.Windows.Forms.Button
  • Just installed 2.5 and it woks like a charm. Everything compiles and runs fine. And the speed improvement in VS2019 is great.
    Thanks a lot for your great work!
    Markus
  • Leigh, Can you please send us that exact dll, so we can test with it? Does this problem happen also if you create a new Form project, add a reference to this dll and create a form? If not, we will really need to have a repro sample taken from your real app.
  • The integration in VS is much faster.
    Also the programs are running faster. The array access has been enhanced using dotnet array indexes. This may give some additional errors in execution when trying to access non existing two-dimensional array elements that are nil. I found yesterday those cases where I could not believe that they existed. VO did it often ignoring non-existing elements and returning nil instead, but the previous X#-versions must have done it similarly in some cases. But it is it worth to change code. The VO-converted programs are based on arrays, so enhancing the array access is one of the possibilities to get additional speed.
  • Arne,

    Thanks for your comments. And indeed VO allows this:

    LOCAL aValues := {1,2,3} AS ARRAY
    // note that the array has one dimension but we ask for 2 dimensions
    ? aValues[1,1] // NIL

    Although we really do not like this behavior we will implement it to make sure that VO programs migrate better

    Robert
  • Perhaps we can also wait until someone sees difficulties correcting the own code. The speed enhancements you have brought with the new version are nice and should be left.
    In the past I have seen also some advantages correcting obviously wrong code by analyzing runtime of X#-compiled programs. In so many cases I asked me: Why could have worked?
    There have been also cases where we found really wrong behavior of the VO-program - not by verifying results but by running into an exception in the X#-Program.

Main menu

  • Buy
  • Contact
  • Free software