naveen_g Ответов: 3

Как найти все ссылки на метод в разных решениях.

В нашем проекте есть разные модули. Каждый модуль реализован как отдельное решение. В проекте есть более 40 решений. Я вношу изменения в один метод в одном решении, например. Метод Enctypt (). Это перегруженный метод, и он используется во многих местах в различных решениях. Я хочу узнать все места, где упоминается этот метод.

Есть ли лучший способ / любой доступный инструмент, чтобы найти все ссылки на метод в различных решениях?

Что я уже пробовал:

Я попытался найти метод Encrypt () во всех решениях, но он вернул тысячи результатов. поскольку есть метод с таким же именем, доступный и в других решениях, hens it возвращает много результатов.

Я также попытался выполнить поиск по пространству имен и имени класса.

ваше ценное предложение будет мне очень полезно. Спасибо.

3 Ответов

Рейтинг:
2

OriginalGriff

Я думаю, вы путаете "решение" и "проект" - Visual Studio загружает одно решение, которое может состоять из нескольких проектов: каждый проект генерирует отдельную сборку.
Внутри решения вы можете перейти к определению метода, щелкнуть правой кнопкой мыши его имя и выбрать пункт "Найти все ссылки", чтобы получить полный список везде, где он используется в решении.

Однако если это несколько решений, то AFAIK не имеет встроенного метода для поиска всех ссылок во всех решениях одного метода - хотя бы потому, что проекты с использованием ссылок на сборку (а не на проект) не имеют никаких обратных ссылок на источник сборки.

Рейтинг:
12

F-ES Sitecore

Загрузите все проекты в одно решение и попросите их ссылаться друг на друга по ссылке на проект. Если это невозможно\слишком много усилий, загрузите инструмент под названием IL Spy, загрузите в него все ваши сборки и используйте его функцию "анализ", чтобы показать вам, какие методы что вызывают.

Рейтинг:
1

johannesnestler

Привет naveen_g

Интересно, как вам удается держать вещи вместе, если вы организуете свои решения таким образом?
Что я делаю: работаю только со ссылками на проекты внутри решений, никаких сборочных ссылок на ваши собственные проекты.
Затем я группирую проекты вместе в тех решениях, которые мне нужны (вполне допустимо, чтобы проект принимал участие в различных решениях).
Затем распределите / сгруппируйте ваши решения-своего рода" постановку " для ссылок (например, я использую Shared, Service, Client, Data, Hardware, Gateway) так, чтобы было создано наименьшее возможное перекрытие проекта.
- а проблемы вроде твоей должны быть очень редко...

Затем, если у вас есть система сборки и вы используете CI, вы узнаете при валидации-сборке, что вы сломали одно из поэтапных (а затем связанных с сборкой) решений (все соответствующие решения должны быть построены вашим определением builddefinition, конечно).

Но я должен признаться, что это был долгий и мучительный способ организовать все таким образом и найти хороший рабочий процесс, с которым каждый может справиться...

Поэтому, возможно, более простым решением может быть (зависит от того, сколько проектов у вас действительно есть) создание одного большого "фиктивного" решения для всех ваших проектов (это будет только для таких случаев, как у вас сейчас, просто не забудьте добавить туда новые проекты, если вы создадите новые решения или добавите проекты к существующим позже.

С уважением

Иоганнес