У меня есть .NET сборка. Надо получить список статических методов в типах из этой сборки, в которых есть обращения к статическим полям. Как это быстрее и проще всего сделать?
Здравствуйте, Oksana Gimmel, Вы писали:
OG>У меня есть .NET сборка. Надо получить список статических методов в типах из этой сборки, в которых есть обращения к статическим полям. Как это быстрее и проще всего сделать?
Можно с помощью Microsoft.Cci. Вот так можно найти записи стат. полей:
static void Main(string[] args) {
const string LOCATION = @"....";
var assemblyNode = AssemblyNode.GetAssembly(LOCATION, true, true, false);
var q = from t in assemblyNode.Types
from m in t.Members.OfType<Method>()
where m.IsStatic && HasStaticFieldWrite(m)
select m;
foreach (Method method in q) {
Console.WriteLine(method.FullName);
}
}
static bool HasStaticFieldWrite(Method method) {
var q = from st in method.Body.Statements.SelectMany(GetChildStatements).OfType<AssignmentStatement>()
let mb = st.Target as MemberBinding
where mb != null
let f = mb.BoundMember as Field
where f != null && (f.IsStatic)
select st;
return q.Any();
}
static IEnumerable<Statement> GetChildStatements(Statement statement) {
var block = statement as Block;
return block != null ? block.Statements : Enumerable.Empty<Statement>();
}
Здравствуйте, Oksana Gimmel, Вы писали:
OG>У меня есть .NET сборка. Надо получить список статических методов в типах из этой сборки, в которых есть обращения к статическим полям. Как это быстрее и проще всего сделать?
Быстрее всего написать визитор (унаследовав от BaseCodeTraverser) и проверять ITargetExpression и IBoundExpression на наличие таких обращений.
Здравствуйте, gandjustas, Вы писали:
G>Быстрее всего написать визитор (унаследовав от BaseCodeTraverser) и проверять ITargetExpression и IBoundExpression на наличие таких обращений.
Здравствуйте, Sinix, Вы писали:
L>>Можно с помощью Microsoft.Cci. Вот так можно найти записи стат. полей:
S>Позанудствую. let лучше заменить на select ... into (а ещё лучше цепочку из let where let where превратить в отдельный фильтр-метод).
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Быстрее всего написать визитор (унаследовав от BaseCodeTraverser) и проверять ITargetExpression и IBoundExpression на наличие таких обращений.
S>Будет неудобно получать список.
Здравствуйте, gandjustas, Вы писали:
OG>>У меня есть .NET сборка. Надо получить список статических методов в типах из этой сборки, в которых есть обращения к статическим полям. Как это быстрее и проще всего сделать?
G>Быстрее всего написать визитор (унаследовав от BaseCodeTraverser) и проверять ITargetExpression и IBoundExpression на наличие таких обращений.
Мне интересно, чем ты руководствовался, когда писал такой ответ? Ничего же непонятно. Непонятно даже, какое отношение имеют твое сообщение к вопросу.
Здравствуйте, Lloyd, Вы писали:
S>>Позанудствую. let лучше заменить на select ... into (а ещё лучше цепочку из let where let where превратить в отдельный фильтр-метод).
L>Не считаю, что это лучше.
Каковы ваши доказатьельства?(с)
Мои:
1) let заводит новый анонимный тип, что оочень хорошо просаживает нанотесты (в реальном коде, конечно, найдётся чему тормозить и без них). В общем случае лучше обойтись без let.
2) Вынесение цепочки let where в отдельный метод позволяет превратить нагромождение итераторов в пару if'ов.
Здравствуйте, Тролль зеленый и толстый, Вы писали:
ТЗИ>Почитал твои ссылки и не понял, почему это лучше.
Не лучше. let имеет неприятные side-эффекты (неявное создание анонимных типов) и повсевместно использоваться не должен.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, gandjustas, Вы писали:
OG>>>У меня есть .NET сборка. Надо получить список статических методов в типах из этой сборки, в которых есть обращения к статическим полям. Как это быстрее и проще всего сделать?
G>>Быстрее всего написать визитор (унаследовав от BaseCodeTraverser) и проверять ITargetExpression и IBoundExpression на наличие таких обращений.
L>Мне интересно, чем ты руководствовался, когда писал такой ответ? Ничего же непонятно. Непонятно даже, какое отношение имеют твое сообщение к вопросу.
Чтобы получить любое обращение к статическому полю надо писать визитор. Соответственно визитор можно натравливать на каждый статический метода каждого типа.
Задача получения всех методов всех типов решается тривиально с помощью CCI, а поиск обращения к статическому полю — как написал выше.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Прогонять визитором каждый метод — очень удобно. S>Как это поможет решить исходную задачу?
Здравствуйте, Sinix, Вы писали:
S>Каковы ваши доказатьельства?(с) S>Мои: S>1) let заводит новый анонимный тип, что оочень хорошо просаживает нанотесты (в реальном коде, конечно, найдётся чему тормозить и без них). В общем случае лучше обойтись без let.
Это детали реализации. Для меня лучшая читаемость имеет более высокий приоритет, тем более, что в реале ты разницу и в микроскоп не заметишь.
S>2) Вынесение цепочки let where в отдельный метод позволяет превратить нагромождение итераторов в пару if'ов.
Вынесение позволяет позволяет превратить пару let-ов в нагромождение методов.
Здравствуйте, gandjustas, Вы писали:
L>>Мне интересно, чем ты руководствовался, когда писал такой ответ? Ничего же непонятно. Непонятно даже, какое отношение имеют твое сообщение к вопросу.
G>Чтобы получить любое обращение к статическому полю надо писать визитор. Соответственно визитор можно натравливать на каждый статический метода каждого типа.
Зачем так сложно? Где в моем примере визитор?
G>Задача получения всех методов всех типов решается тривиально с помощью CCI,
Ты действительно думаешь, что топикстартер знал о существовании Cci и при этом не знает как выдрать нужные методы?
G>а поиск обращения к статическому полю — как написал выше.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, gandjustas, Вы писали:
L>>>Мне интересно, чем ты руководствовался, когда писал такой ответ? Ничего же непонятно. Непонятно даже, какое отношение имеют твое сообщение к вопросу.
G>>Чтобы получить любое обращение к статическому полю надо писать визитор. Соответственно визитор можно натравливать на каждый статический метода каждого типа. L>Зачем так сложно? Где в моем примере визитор?
Твой пример далеко не все случаи покрывает, только в левой части оператора присваивания.
G>>Задача получения всех методов всех типов решается тривиально с помощью CCI, L>Ты действительно думаешь, что топикстартер знал о существовании Cci и при этом не знает как выдрать нужные методы?
Я думаю теперь уже знает.
G>>а поиск обращения к статическому полю — как написал выше. L>Вот и написал бы код, если все так просто.
Чуть позже, некогда было.
Здравствуйте, gandjustas, Вы писали:
G>>>Чтобы получить любое обращение к статическому полю надо писать визитор. Соответственно визитор можно натравливать на каждый статический метода каждого типа. L>>Зачем так сложно? Где в моем примере визитор?
G>Твой пример далеко не все случаи покрывает, только в левой части оператора присваивания.
Неужели?
Вот так можно найти записи стат. полей
Да и как этот ответ связан с использованием визитора?
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, gandjustas, Вы писали:
G>>>>Чтобы получить любое обращение к статическому полю надо писать визитор. Соответственно визитор можно натравливать на каждый статический метода каждого типа. L>>>Зачем так сложно? Где в моем примере визитор?
G>>Твой пример далеко не все случаи покрывает, только в левой части оператора присваивания.
L>Неужели? L>
L>Вот так можно найти записи стат. полей
Исходная то задача была:
Надо получить список статических методов в типах из этой сборки, в которых есть обращения к статическим полям.
А твой пример не расширяется до поиска любого обращения.
);
