Мы используем System.Reflection.Emit для генерации кода во время выполнения из исходного кода (да - как в компиляторе). Мы предоставляем правильную информацию о символах в ILGenerator с помощью MarkSequencePoint и т.д. И включаем все флаги отладки на AssemblyBuilder. Сборка хранится в памяти в том же процессе, который скомпилирован и выполняется непосредственно.
При использовании отладчика Visual Studio для перехода по источнику для динамически сгенерированного кода он действительно работает отлично, и Visual Studio, похоже, полностью знает, откуда приходит код с точки зрения файлов и номеров строк.
ОДНАКО - Когда исключения генерируются сгенерированным кодом, объекты System.Exception содержат стеки, которые полностью ошибочны. Они указывают на другие (действительные, но неправильные) файлы и номера строк. Он получает имя класса и метода правильно, но указанный номер файла и строки не имеет никакого отношения к пути кода, из которого действительно произошло исключение.
Файлы, на которые указывает, настолько не связаны друг с другом, кажется, что они не могут быть связаны с встраиванием или оптимизацией. Единственный образец, который я могу заметить, заключается в том, что он, кажется, компенсируется некоторыми файлами (в мнимом отсортированном в алфавитном порядке списке исходных файлов, из которого была создана сборка). Однако эта схема не соответствует 100%, и кажется иррациональным, что это связано с источником проблемы.
Если я создаю объект System.Diagnostics.Debug из Exception, он содержит ту же самую неисправную информацию.
Я предполагаю, что среда выполнения .NET использует те же метаданные для построения трассировок стека Exception, которые использует отладчик для перехода через код, и в этом случае это поведение действительно странно.
Я пытаюсь выяснить, является ли это известной ошибкой в .NET при работе с динамическими сборками в памяти, или если у кого-то были подобные проблемы в других областях.