Comments 5
Круто! Всегда хотелось позаниматься чем то подобным, но лень и огромное количество нюансов отбивали желание. Замечательный цикл статей!!
нужная функция в Roslyn уже существует, работает внутри Visual Studio и даже имеет почти идеальный для моей задачи API. Открываешь исходники, радуешься — а потом замечаешь перед классом или методом слово internal.
А через отражение доступ получить?
Я, кстати, тоже об этом думал, можно было бы получить эти фичи через UnsafeAccessor, но все же я передумал. Раз эти методы internal то Roslyn оставляет за собой право сильно их менять. Да, можно сказать что в случае с ISymbol они тоже оставили за собой такое право, но по факту стараются особо его не трогать и в основном работают с ISymbolInternal. А каждый раз заново настраивать все это не хотелось. Поэтому я подумывал, может, открыть issue с предложением сделать эти методы публичными или добавить какой-нибудь публичный контракт для этих фич.
можно было бы получить эти фичи через UnsafeAccessor
У меня, когда писал предыдущий комментарий, в голове был другой механизм, тоже вполне типовой, вовсе не мной придуманный: вытащить MethodInfo нужных методов (и конструктора, если нужно) через отражение, сделать делегаты с нужными параметрами через компиляцию Expression Trees с MethodCallExpression для вызова этих методов, а в остальном своем коде вызывать внутренние методы уже через эти делегаты (а при желании их можно и в свой класс-адаптер собрать). Тогда эффект от изменения внутреннего интерфейса будет локализован - он будет влиять только на генерацию Expression Tree, которую, чаще всего, несложно и подправить.
Как-то так.
Создаём DSL на C#: LSP и поддержка в Visual Studio