Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1

TOPIC:

Best practice to handle error XS7038 21 Mar 2022 09:14 #22006

  • Jan
  • Jan's Avatar
  • Topic Author


  • Posts: 5
  • We are currently migrating a project from Vulcan to XSharp. After eliminating all errors, we are getting a new error:
    XS7038	Failed to emit module 'CrefoFact-debug': Unable to determine specific cause of the failure.

    We are also getting some thousand warnings (huge project). What is the best way to handle XS7038?

    Thanks,

    Jan

    Please Log in or Create an account to join the conversation.

    Best practice to handle error XS7038 21 Mar 2022 09:40 #22009

    • Chris
    • Chris's Avatar


  • Posts: 3843
  • 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.

    .
    XSharp Development Team
    chris(at)xsharp.eu

    Please Log in or Create an account to join the conversation.

    Best practice to handle error XS7038 23 Mar 2022 01:06 #22026

    • jeromegorlick
    • jeromegorlick's Avatar


  • Posts: 7
  • 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?

    Please Log in or Create an account to join the conversation.

    Best practice to handle error XS7038 23 Mar 2022 01:26 #22027

    • Chris
    • Chris's Avatar


  • Posts: 3843
  • 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.

    .
    XSharp Development Team
    chris(at)xsharp.eu

    Please Log in or Create an account to join the conversation.

    Last edit: by Chris.

    Best practice to handle error XS7038 23 Mar 2022 07:37 #22029

    • robert
    • robert's Avatar


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

    Robert
    XSharp Development Team
    The Netherlands

    Please Log in or Create an account to join the conversation.

    Best practice to handle error XS7038 23 Mar 2022 22:59 #22035

    • jeromegorlick
    • jeromegorlick's Avatar


  • Posts: 7
  • 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.

    Please Log in or Create an account to join the conversation.

    • Page:
    • 1