JS to CLR mapper

  • 180 Views
  • Last Post 29 September 2024
Scott Malyon posted this 23 July 2024

Hi,

I have been digging around your script engine and would like to know a bit more about the constraints.

Could you tell which package you are using to map onto the CLR so I can refer to it docs. Mainly I am trying to work out what is indeed possible.

For example:

  1. I tried to load my own DLL but the reflection namespace is excluded.
  2. I tried including some of the C# syntax such as @litteral and using.
  3. I tried deserializing some JSON to a class I included but it did not like me defining classes.

I also note you say to avoid async as the workflow engine is not going to wait. This is fair enough but does that only include JS async? Can I use .net async?

Also can you use async when not "part of the workflow" for example building a list for a question.

 

 

Sorry for the random questions, just getting my head around it

 

  • Liked by
  • Axel Hammar
Order By: Standard | Newest | Votes
Scott Malyon posted this 23 July 2024

I did find a jint dll lurking, is this the script engine - GitHub - sebastienros/jint: Javascript Interpreter for .NET

luca.scarpati posted this 25 July 2024

Hi Scott,

 

in general all you need to know about our JS is this: https://help.scanshare.com/home/scripting/js/ 

I don't know what you're trying to do and what you're trying to use, but in general the use of scripting (VBS and JS) in our application is about trying to get where some modules can't go (extraction of ocr part, create specific file from input variables or documents, store with some special steps or other).

 

I hope it was helpful smile!

 

Best regards,

Luca

 

Axel Hammar posted this 29 September 2024

It seems you're exploring the capabilities and limitations of a script engine that interacts with the CLR (Common Language Runtime). Here are some clarifications:

  1. Mapping to CLR: The specific package used to interface with CLR isn't detailed here, but you might refer to the official Microsoft documentation on the CLR for more insights.

  2. Loading DLLs and Reflection: Reflection is often restricted in certain environments for security and stability reasons. This may limit your ability to load DLLs dynamically.

  3. C# Syntax: The use of specific C# features like @literal and class definitions may not be supported depending on the scripting context. Typically, the scripting environment has its own syntax rules.

  4. Async Behavior: Generally, async operations in JavaScript may not wait for completion in a workflow. .NET async may be supported outside the workflow context, but it depends on the specific implementation of the engine.

  5. Async in Non-Workflow Contexts: If you're building data outside the workflow, you might be able to use async. However, it's essential to check the engine's documentation for any restrictions.

  • Liked by
  • luca.scarpati
Categories
Search
Popular Tags
This Weeks High Earners
Hot Topics
Close