Я построил эту оболочку на основе скриптового API Roslyns ...
using Microsoft.CodeAnalysis.CSharp.Scripting;
using Microsoft.CodeAnalysis.Scripting;
using System;
using System.Linq;
using System.Reflection;
using System.Threading.Tasks;
namespace Workflow
{
internal class ScriptRunner : IScriptRunner
{
internal static Assembly[] references;
public ScriptRunner()
{
references = ...;
}
public async Task<T> Run<T>(string code, string[] imports, object args)
{
var referencesNeeded = references.Where(r => r.GetExportedTypes().Any(t => imports.Contains(t.Namespace)));
var options = ScriptOptions.Default
.AddReferences(referencesNeeded)
.WithImports(imports);
return await CSharpScript.EvaluateAsync<T>(code, options, args, args.GetType());
}
public Task Run(string code, string[] imports, object args)
=> Run<bool>(code + ";return true;", imports, args);
}
}
... когда я вызываю его с помощью крупного бизнес-объекта, мое приложение просто вылетает с журналом системных событий, в котором есть событие, говорящее .. .
Faulting application name: My.exe, version: 1.0.0.0, time stamp: 0x5e597f86
Faulting module name: coreclr.dll, version: 4.700.20.11803, time stamp: 0x5e4c6185
Exception code: 0xc00000fd
Fault offset: 0x0000000000231774
Faulting process id: 0xfb4
Faulting application start time: 0x01d612424b37cc95
Faulting application path: D:\My Project\My.exe
Faulting module path: D:\My Project\coreclr.dll
Report Id: aa6c531d-dbdb-4f30-bfe1-ab341f9ebc08
Faulting package full name:
Faulting package-relative application ID:
Есть ли способ обработать большие объемы памяти (скажем, до 4 ГБ) внутри скрипта Roslyn и избежать такого поведения (например, установить флаг stati c или что-то в этом роде)?
Похоже, что проблема заключается в переполнении стека других постов, подобных этому ... Как обрабатывать код исключения ошибки приложения: 0xc00000fd
... Я считаю, что причина в том, что «большой объект» в моем случае представляет собой массив из примерно 10 000 элементов, которые я хочу просмотреть через l oop и выполнить некоторый базовый код c, например, преобразовав его. У меня нет шансов сказать ... проблемы глубокой рекурсии, которые никогда не заканчиваются (как правило, то, что я мог бы ожидать при переполнении стандартного стека), поскольку мой набор конечен.
Кажется, что он просто взломал sh в coreclr.dll в случае, если я прошу его l oop через большой набор, даже не пытаясь. Большой набор, который я использую для тестирования, представляет собой CSV-файл размером около 10 тыс. Строк, объемом от 2 до 3 МБ данных, которые будут расти в оперативной памяти во время обработки, но ничего такого, с чем современные компьютеры не могут справиться с легкостью, я не спрашиваю это перебирать множества миллиардов строк.