Веб-приложение ASP.NET не может найти сборку

Question

Я развернул веб-приложение ASP.NET прошлой ночью, и когда я проснулся этим утром, он был очень медленным и иногда просто выдавал ошибку «Служба недоступна».

Я проверил Просмотрщик событий, и он был заполнен этими ошибками:

Произошло необработанное исключение, и процесс был остановлен.

Исключение: System.Runtime.Serialization.SerializationException

Сообщение: не удается найти сборку 'MonoTorrent, версия = 0.80.0.0, культура = нейтральная, PublicKeyToken = null'

Я озадачен, так как он отлично работал, когда я его развернул (MonoTorrent требуется для извлечения количества сеялок / пиявок для определенного торрента с трекера - это работало нормально), но это больше не работает и всякий раз, когда код при использовании MonoTorrent рабочий процесс просто падает.

MonoTorrent.dll находится в каталоге / bin /.

---

ОБНОВЛЕНИЕ 6/4/10: Я скомпилировал исходный код MonoTorrent с остальной частью моего веб-приложения, но он по-прежнему аварийно завершает работу всякий раз, когда он использует MonoTorrent. Однако теперь говорится, что это Unable to find assembly 'OpenPeer, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null. Здесь OpenPeer - это название сборки веб-приложения.

Answer 1

Это может произойти в следующих случаях:

Приложение ASP.NET создает фоновый поток, который генерирует необработанное исключение. Похоже, ASP.NET ловит исключение и хочет записать его в журнал событий. Для этого он отправляет это исключение из домена приложения веб-приложения в свой собственный домен приложения (по умолчанию один из процессов w3wp). Для этого требуется сериализация / десериализация исключения.

Если исключение является пользовательским (то есть определенным веб-приложением), его нельзя десериализовать в основном домене приложения ASP.NET, поскольку сборка, определяющая исключение, обычно находится в каталоге bin веб-приложения, а не там, где w3wp .exe есть (c: \ windows \ system32 \ inetsrv). Это вызывает исключение сериализации и сбой w3wp.

Существуют возможные способы решения проблемы (в очень субъективном порядке предпочтения):

1. Скопируйте отсутствующую DLL в c: \ windows \ system32 \ inetsrv
2. Установите недостающую DLL в GAC
3. Устранить причину исключения (сделать сложнее, чем сказать, как мы говорим по-французски)
4. Поймайте все исключения из фоновой цепочки и ведите запись самостоятельно.

Примечания:

• Если используется WCF, а неперехваченным исключением является FaultException, WCF проглатывает его, и сбоя не происходит
• Если необработанное исключение находится в потоке веб-запроса, появляется желтый экран смерти, а не это исключение сериализации
• Это действительно похоже на ошибку в ASP.NET
• Выше приведено краткое изложение моих вчерашних исследований по этому вопросу, и это только теория. Я проверял исправления 1 и 4, а также использовал FaultException.

Answer 2

Вот несколько вещей, которые вы можете попробовать ..

1.) Очистить временную директорию ASP.Net . Перезапустите IIS и перезапустите пул приложений .

2.) Убедитесь, что ваше веб-приложение работает в FULL-TRUST , если оно действительно нуждается в FULL-TRUST.

3.) Возьмите сборку, попробуйте использовать ее в другом приложении asp.net и запустите тестовое приложение на отдельном сервере . Это может помочь вам диагностировать проблему. Также попробуйте запустить тестовое приложение asp.net на том же сервере, но в отдельном пуле приложений.

4.) Убедитесь, что веб-сайт IIS вашего приложения работает под учетной записью пользователя с необходимыми привилегиями безопасности . Попробуйте запустить приложение под Administratotr как пользователь.

EDIT-1

5.) Также убедитесь, что версия сборки совпадает с упомянутой в web.config. Если есть несоответствие версий, вы можете сделать перенаправление AssemblyBinding в web.config.

6.) Также попробуйте заново зарегистрировать сборку в GAC и посмотреть, правильно ли она загружается.

EDIT-2

7.) Попробуйте перенастроить поддержку ASP.NET на сервере, или может помочь переустановка среды выполнения. Возможно, это не верное решение, но, глядя на проблему, мы можем попробовать различные решения.

8.) Убедитесь, что вы не пропустили ни одного критического обновления вашего сервера Windows платформа.

Answer 3

Попробуйте очистить временные файлы ASP.NET . Это позволило мне решить некоторые странные вопросы.

В противном случае Fusion-logging может пролить некоторый свет.

ОБНОВЛЕНИЕ: @Charlie - я не уверен, что делать с этими журналами ... похоже, что ошибочный журнал произошел из другого AppDomain. Обратите внимание, что для AppBase установлено значение «file: /// c: / windows / system32 / inetsrv /», а AppName - w3wp.exe.

Я почти уверен, что программа просмотра событий должна показывать Application Id: LM / W3SVC / # / ROOT, если это тоже был AppDomain по умолчанию. На данный момент все, что у меня есть, это случайные догадки.

1. Я заметил, что вы используете x64 ... Возможно, MonoTorrent требует x86 ?
2. Проверено ли дважды, что каталог является приложением IIS и настроен для правильной версии ASP.NET?
3. Есть ли какое-либо другое приложение, которое использует MonoTorrent на этом сервере? Может быть, сервис WCF или что-то? Я не уверен, где происходит сериализация ....
4. Попробуйте перехватить событие AssemblyResolve и загрузить его вручную.
5. Можете ли вы воспроизвести на компьютере разработчика? Если нет, может быть, это форекс установка FX. Удалите и переустановите.
6. Временный запуск, переработка или остановка / запуск AppPool временно устраняют проблему или вызывают ее появление?

Возможно, вы тоже захотите напечатать текст со скриншота, чтобы получить любовь от Google ....

Answer 4

Я знаю, что это просто, но однажды у меня была эта проблема, потому что у меня был проект веб-приложения, содержащий

    References

Папка и я просто скопировали мои файлы в

    Bin

В папке

в любом веб-приложении .net в окнах Свойства проекта имеется вкладка Ссылочный путь , которая по умолчанию ничего не должна включать в нее. отметьте эту опцию, а также вкладка "Сборка" в Окно свойств проекта , которое Путь вывода будет таким же, как bin \

Answer 5

Отличается ли часовой пояс сервера от вашего часового пояса? У меня была эта проблема при развертывании файлов ресурсов, время компиляции было в будущем, поэтому они не смогли загрузить.

Answer 6

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

Этот метод работает для меня.

Answer 7

Я бы посоветовал установить регулярное обслуживание, вероятно, один раз в неделю в воскресенье вечером и т. Д. Для следующего,

1. Удалить все временные файлы
2. Удалить все временные файлы ASP.NET IIS
3. Перезагрузите сервер

Проблема в том, что веб-приложения ASP.NET приводят к тому, что на диске остается много временных файлов из-за динамической компиляции регулярных выражений, сборок сериализации и т. Д., Такие временные файлы никогда не удаляются, и все больше и больше мусора начинает собираться в Временные местоположения, ASP.NET работает медленнее и медленнее, и наступает момент, когда диск и дефрагментация памяти достигают очень высокой точки, вещи начинают давать сбои.

Никто не любит перезапускать сервер один раз в неделю, но я помню, что у нас не было выбора, в ASP.NET 1.1 у нас была стабильная система после перезапуска каждый день, в ASP.NET 2.0 и более поздних, мы можем запланировать перезапуск на один раз в неделю.

Answer 8

Полагаю, у вас много открытых, но не закрытых соединений. Я имею в виду соединения не возвращаются в пул. Выглядит нормально, когда вы запускаете приложение, но через некоторое время в пуле становится доступно только несколько сокетов, и все идет медленно. Другое дело - незакрытое соединение может держать DLL в памяти, не позволяя освободить обработчик. Попробуйте отладить уничтожение объекта.

Answer 9

Я пытаюсь дать вам несколько идей - что я буду делать, если буду на вашей позиции.

Прежде всего, перед тем, как вы зададите свой вопрос, я через несколько дней посмотрю на MonoTorrent.dll, и сегодня снова посмотрю. Я нашел и функцию, которая загружает DLL. Мое первое мнение, что что-то связано с разрешениями.

Я надеюсь, что у вас есть доступ к серверу - верно?

Мои первые шаги таковы:

Убедитесь, что ваш файл monotorrent.dll действительно имеет права доступа к каталогу bin для чтения и выполнения приложением asp.net. Несколько раз копия одной dll, не получавшей директории с разрешениями, осуществляла свои собственные разрешения. Чтобы проверить, имеют ли ваши dll другие разрешения от остальных, просто щелкните правой кнопкой мыши и выберите Свойства | Безопасность, затем перейдите в каталог bin и сделайте то же самое, и сравните разрешения безопасности. Если они отличаются, тогда примените снова разрешения Справочника и удостоверьтесь, что dll унаследован каталогом.

Мой второй шаг

Загрузить ProcessMonitor от sysinternals

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

Запустите ProcessMonitor и попробуйте воссоздать ошибку , остановите ее и проанализируйте, чтобы узнать, где и почему DLL получает запрещенные разрешения на запуск. С ProcessMonitor вы даже можете увидеть, есть ли какая-нибудь dll, которая не может быть найдена!

Я проверил dll MonoTorrent и не нашел ничего необычного. У него есть вызовы kerner32.dll, и он использует небезопасный код для запуска, ничего особенного.

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