Understanding Deployment Errors

Aaron Van
Aaron Van
in AppWorks #1

I've figured out the majority of the designers quirks when it comes to error messages.

 

One of the biggest is how regardless of what the Messages window tells you it's generally just the last error that is causing the problem. Once I receive an error I move my mouse over to the red X circle on the bottom right and hover. If you click the tooltip it will give you the actual error causing all of the other cascading errors.

 

But when it comes to deploying I can't decipher how to tackle the errors. As an example:

 

I have a library that is used by 4 other solutions. The library deploys fine and imports to the solutions without trouble.

The solution shows a green check mark so it allows me to deploy.

The deployment goes through the basic warning messages then stutters for a bit before dropping these errors:

 

Error 9/3/2013 1:45:37 PM PROJECTNAME Cannot implicitly convert type 'string[]' to 'string[][]' 102 20

 

Now I understand what the error means, but I have no idea where this is occurring. Our library is large and our solutions larger. I can only assume it is the library causing the issue since it happens in multiple solutions. I will probably hunt this error down eventually but only in a trial and un-error manner. 

 

So I guess my question is if anyone has tips for debugging errors with out the 'Component' column filled out. Furthermore, is there any plans for the designer to eliminate error messages without a Component attached to it? I know the component only refers to actual workflow elements, but what about server side scripts? 

 

Should the columns 'Line No' or 'Column No' in the error give me any insight?

 

Thanks,

 

...aaron

 

Tagged:

Comments

  • Brian Mellert
    Brian Mellert Member
    #2

    Wow, great timing.  The one I hate most on deployment is:

     

    The type arguments for method 'Metastorm.Runtime.Core.Mstm.If(Metastorm.Runtime.Types.Check, T, T)' cannot be inferred from the usage. Try specifying the type arguments explicitly. 

    Listed on line 2159, column 84.

     

    It validates well, and individual components validate.  Its only during deployment.

    Its MBPM generated code, I have no line 2159 anywhere in my direct code, there is no reference to location, except for what MBPM builds itself.  I have no idea where to look and its very frustrating!

  • Aaron Van
    Aaron Van
    #3

    In an effort to better this product, is there a way to place the Designer in a verbose logging mode to help us report bugs back to the Opentext team?

  • Prakash__Kanchan
    Prakash__Kanchan
    #4

    Unfortunately, I havent found a logical way to debug or understand metastorm errors yet. The only strategy that I find works for me is to make small incremental changes, publish and validate often. If there's an error look at the last change you made and thats probably where the error is. This often gets compounded with libraries - which is why I try to have a separate procedure to unit test library methods that are flaky (coz libraries can't have admin forms :smileyindifferent:)

     

    That way at least you can trace back to a certain thing. Designer validation errors are almost always useless. A missing semicolon in some random script can throw you 200 errors on validating another script elsewhere :)

     

    PS - I have tried the Visual studio debugging, but it was way too confusing for me, but thats just my stupidity getting in the way

  • Aaron Van
    Aaron Van
    #5

    VS debugging is fine for server side scripts, but otherwise it's non-functional.

    I've often found that if it's impossible to find the underlying issue and all my code looks good I can resort to one last ditch effort.

    Go to the process you expect is causing a problem, highlight everything, delete, ctrl-z to undo. I have seen this fix the problem more times than I'd like. I can only assume the reason this works is because the code is generated XML and in some instances it may just get corrupt.

    I'd still like to see a way to see more granular errors; perhaps in the stack trace of the underlying caller.

  • Petio_Ivanov
    Petio_Ivanov
    #6

    Hi,

     

    Has anyone tried using any of the Preprocessor Directives in order to help them define how their code is layed out and hopefully determine where the error is occuring.

     

    One directive that I'm thinking about is the #line directive, which lets you modify the compiler's line number and file name for errors and warnings.

     

    For example adding the following preprocessor directive to the code:

      #line 70000000 "MyLibraryCodeSection1"

     

    The result I think would be that if an error occurs in that block of code then the error reported will have the line of 70000000 + n (the number of lines respective to that statement)

     

    This way one could divide the library into multiple sections of code based on pre-set line numbers.

     

    I have not tried this myself but I'm wondering if it works with the Metastorm IDE.

     

     

  • Aaron Van
    Aaron Van
    #7

    That is a good idea for server side scripts.

     

    We also see the problem in that errors are thrown from a random stage in a random sub-process because a variable has gone missing or some other anomaly. The error barely has any userful information. This isn't code we have access to drop directives into. This is internal Metastorm code throwing errors but without enough detail to find the problem. 

     

    A good example is a removed variable or flag parameter. If an action button has a 'Only Show If...' bool that has otherwise been removed an error will be thrown. The error displays without reference in the 'Component' column of the stage that has the rogue variable. That is a fairly simple fix through process of elimination, but there are far more devious errors that are nearly impossible to find.

Categories

image
OpenText CE Products
AppWorks
Gateway & Platform