Я получил эту ошибку после открытия проекта, в котором была ссылка на Entity Framework, поэтому я удалил такие ссылки и переустановил Entity Framework версии 6.0.0.0 через pcket-менеджер следующим образом:
install-package entityframework -version 6.0.0.0
Ошибка все еще показывал, поэтому я подумал, что эти ссылки были там, потому что в проекте была более ранняя версия Entity Framework, якобы «предустановленная», но на самом деле она не работала.
Итак, я подошел к файлу packages.config
и заметил, что есть еще одна ссылка:
<packages>
**<package id="EntityFramework" version="5.0.0" targetFramework="net45" />**
<package id="EntityFramework" version="6.0.0" targetFramework="net45" />
</packages>
Затем я удалил строку, очистил и пересобрал проект и контейнерное решение, и оно наконец заработало .
Dottrace примерно вдвое дешевле, чем Ants, и это действительно хорошо. Сделано теми же людьми, что и ReSharper.
Если вы просто ищете разовую оптимизацию своего кода, вам все равно стоит выбрать Ants, поскольку у него есть полнофункциональная 15-дневная бесплатная пробная версия, которая должно быть достаточно, чтобы провести большую оптимизацию.
VSProfiler поставляется с VS и работает довольно хорошо. Если вы ищете проблемы, связанные с памятью, вам подойдет CLRProfiler.
В общем, я использую метод это .
Меня не столько интересует синхронизация фрагментов кода, сколько поиск больших ненужных временных затрат так что я могу очистить их и добиться ускорения.
Это действительно другой процесс.
ДОБАВЛЕНО: Если я могу уточнить, типичные проблемы производительности, которые я вижу, заключаются в том, что некоторая деятельность (которая почти всегда является вызовом функции) потребляет некоторые доля времени, например, 10%, 50%, 90%, что угодно, и на самом деле в этом нет необходимости - ее можно заменить чем-то другим или не делать вообще, и это количество времени будет сэкономлено.
Предположим для иллюстрация это 50%.
Я беру случайные выборки из стека вызовов, например 10, и вероятность появления этого вызова в каждом из них составляет 50%, так что он будет примерно в половине выборок. Таким образом это привлечет мое внимание, и я посмотрю, действительно ли то, что он делает, необходимо, а если нет, я исправлю это, чтобы получить ускорение.
Итак, это было измерение? Если так, это было действительно плохое измерение, потому что количество образцов было очень маленьким. Если 5 из 10 образцов показали призыв, доля времени, вероятно, составляет около 50%, плюс-минус, и определенно больше 10%. Так что я могу не знать процент с точностью, но я определенно знаю, что это стоит исправить , и я определенно знаю, где именно проблема .
(Примечание: я знал не подсчитывать количество вызовов или оценивать продолжительность вызова. Скорее, я оценил стоимость вызова, то есть то, что его удаление могло бы сэкономить, а именно его дробное время пребывания в стеке. Также обратите внимание, что я работаю над вызов уровень, не уровень функции . Мне может быть интересно, какие вызовы функций находятся выше и ниже интересующего вызова, но кроме этого, проблемы на уровне функций, такие как исключительное время, графики вызовов и рекурсия, не играют никакой роли.)
Вот почему я говорю об измерении производительности , и поиск проблем с производительностью, хотя они могут дополнять друг друга, на самом деле являются разными задачами.
EQATEC Profiler является бесплатным.
Я сам не пробовал, но звучит нормально, и на их сайте есть несколько положительных отзывов.
Мне было бы интересно услышать мнение любого, кто действительно его использовал.