xsharp.eu

We are currently migrating a project from Vulcan to XSharp. After eliminating all errors, we are getting a new error:
We are also getting some thousand warnings (huge project). What is the best way to handle XS7038?

Thanks,

Jan

Hi Franz,

There were a couple errors like that which were fixed in the latest build, but can't be sure if those apply to your code as well. Due to the nature of this problem, I am afraid the only reason to confirm if this is fixed now, or let us debug, find and fix the problem in the compiler in case it is not already solved, is to zip and send us your code so we can test it in our machines.

.

Hey, we are in a similar situation, unlikely we would be able to get permission to send our code for testing, what is the time line estimated for the updated version of x# to be released?

For subscribers, new builds become available every month or so (latest one was released 2 weeks ago). Not sure about when will be the next public build, will need to discuss and decide on that.

If there's no way to send the code, then you could try to spot the problem manually like this: Create a copy of all your code/project and in that copy, start deleting/disabling large pieces of code, until the error goes away. When it no longer happens, you will know what caused it and you can tell us so it can be fixed in the compiler. Sometimes the problem can be found quickly this way, but sometimes in might also take a lot of time I am afraid. It's the nature of this problem, unfortunately there's no information available in the compiler to report, in order to make it easier to spot what causes it.

Edit: Just to be clear, we do not need to receive the whole code of an application in order to debug the problem here. Only the source code for the specific project/library that produces this, will be enough. Would just need of course all the other dlls (binaries) that the library depends on, so we can reproduce the problem.

.

Jerome,
We can signed an NDA when that is needed to look at the source code.

Robert

Hey Robert, thanks for the clarification, I ended up finding the Module that was causing the library to fail building, I've excluded it for now as I am only doing a POC and if we get to a point where we are ready to proceed with full product conversion then If we hit the same error again we will certainly consider getting all the appropriate agreements in place to ensure we can proceed with conversion.

As the OP did not provide an example, I am willing to submit mine, as it is open-source.
I just ran into this issue today, in a simple app to try out WinForms in X#.
i am running XIDE 2.16 in Windows & SP1 in VirtualBox 6.1.38 on Linux Mint 21.1.
I have attached a zip file of the project.
The issue occurs when I un-comment line 81 in FrmMain.prg, and goes away of that line is commented.

Steve S



 

Hi Steve,

Thanks for the report, problem confirmed and logged! Should be fixed soon.
Btw, unfortunately there can be different reasons for this error, so fixing this case does not guarantee it will not happen again, with different code. But we are trying to find and fix all similar cases (which shouldn't be too any now).

Chris, Steve,
The reason for this problem is the following:
Roslyn (C#) detects this problem (the missing initializer for the const field) in the parser.
We (X#) have our own parser and produce a parse tree that we pass to Roslyn for further processing.
We did not catch this during parsing, and the Roslyn backend "trusts" that an error like this was caught during the parse phase, which obviously did not happen, and no longer reports the error.

I will adjust our parser to detect this at parse time.
This will now report:
Robert

Thanks! Will adjust my Const declaration accordingly.