Здравствуйте, Sinclair, Вы писали:

S>·>А какая разница?.. хоть руками, хоть "/usr/bin/patch" хоть, sed-скрипт или ещё чего. В любом случае почти неюзабельно. Если уж патчить, то байт-код. Его хотя бы анализировать гораздо проще.
S>Хм. А вы пробовали анализировать байткод и С#? По моему опыту, анализировать исходник проще, чем восстанавливать семантику по байт-коду.
S>Если у вас есть другой опыт — расскажите, как вы будете находить места вроде "в Enumerable.Where передаётся замыкание-лямбда", и как вы будете генерировать байткод для енумератора со встроенным вызовом байткода этой лямбды.
Ок. На самом деле на входе не Program.cs, а его AST. Ну тогда байткод, конечно сложнее будет анализировать (ибо он даже к яп не привязан). Впрочем подменить вызов метода на какой-то другой — довольно просто и в байткоде.
Тут будет вопрос как можно будет анализировать и преобразовывать аргументы вызова метода. Отличить простую лямду от непростой и что потом с ней делать. Но это всё нерелевантно. Тут вопрос не в том как можно анализировать и генерировать код, а накой результат всего этого описывать в виде патча файл/строка/позиция, и т.п., притом только с возможностью делать подмену вызова метода, вместо того, чтобы просто получить произвольный результирующий код и его компилировать как обычно.

S>>>3. Заменить вызов в пользовательском коде:
S>·>Чем это принципиально отличается от "Взять текст Program.cs", "Сделать String.Replace()", "скомпилировать"?
S>Я вроде бы привёл пример кода. Какой именно вы предлагаете "Сделать String.Replace()" для достижения предложенного эффекта?
Ну раз есть AST, то "распарсить Program.cs а AST", "заменить в AST вызов source.Where(n=>n%2==0) на вызов EnumerableHelper.Where2314234235569567(source)", "сохранить в Program_modified.cs вместе с реализацией Where2314234235569567 как приватного метода", "скомпилировать".