This removes all of the (now actually non-trivial) conversion logic from
the class which is actually responsible for executing the Jint engine.
This moves it all to a new service which uses chain of responsibility to
convert the result, using one of a few different mechanisms.
Of note is the handling of ExpandoObject when no specific type
information has been provided, and also the handling of enumerables,
with the exception of strings.
Unfortunately Jint still chokes in this case if the expando contains
further nested expandos. It turns out that I need to do this
recursively for it to always work.
We also have trouble with IEnumerable types. They also can't be
round-tripped from/to JSON when they aren't deserialized as a very
specific type.
It appears that this can be fixed by intercepting occasions
when Jint returns an ExpandoObject but the desired return type
is simply object. In this scenario we must return
a Dictionary<string,object> instead of a simple object, or else
Jint freaks out should we try to stringify it later.
I also added a second test to prove that making this change hasn't
broken the way we expect Jint to work for us.
This is an experimental commit. It does stop the exception from
occurring, but it doesn't really fix the problem because now the
output is always empty-object.
It does prove that the exception was occurring because of the
usage of JsonConvert to serialize/deserialize the result.
The change made in this commit probably can't go into prod
but it is useful because it llustrates a part of the problem.
It looks like the docker credentials are incorrect, because
builds are failing with an auth problem. For example build 2.0.0-preview7.1704:
https://ci.appveyor.com/project/sfmskywalker/elsa/builds/38438996#L6715
This can be re-enabled once the auth issue is fixed. There should be
no real harm in disabling it, since it's not working at the moment anyway.
It seems that some work done in these commits, for the
file ForEachBuilderExtensions was responsible:
* 4807ace13c
* dfbba1e176
A couple of the extension methods were missing out a ToList()
which later caused an ArgumentException when setting a property
value via reflection.
I also added an extra exception for the set-value logic. This way,
if/when there is a problem, the exception will indicate which property
it was trying to set at the time.