2009-06-15 6 views
0

У меня есть приложение WCF, работающее на .NET 3.5 SP1, размещенное в IIS7, на 64-разрядной Windows Server 2008.Наличие двух приложений WCF в одном пуле вызывает странные проблемы

В нашей архитектуре есть один экземпляр приложения на клиента, библиотеки DLL копируются в отдельный каталог для каждого клиента. В IIS мы размещаем около 5 клиентов для каждого пула приложений, каждый клиент имеет свой собственный прикладной/виртуальный каталог/физический каталог.

Эта конфигурация отлично подходит для нашей текущей версии, которая использует .NET 2.0 ASMX Webservices с WSE.

Когда мы добавляем нашу новую версию с использованием WCF в тест, она отлично работает, когда пул приложений имеет только одно приложение. Когда мы помещаем 2 приложения в один и тот же пул, службы начинают возвращать нуль без каких-либо причин, пока это не изолировано.

Наша линия управления трубопроводом, используемая для приложений, является «классической», и я также пробовал в «Интегрированном» режиме, проблема все еще существует.

У кого-нибудь есть идеи о том, что происходит?

+0

Можете ли вы его отладить? Когда вы говорите, что службы возвращают null, активируется ли ваш код? Отправляется ли сообщение в ваш код? Что делать, если вы вставляете Debuger.Break() в реализацию службы WCF? – Cheeso

+0

Привет, я не пробовал эту конфигурацию в среде dev. Я сделаю некоторые тесты на своей локальной машине и вернусь к вам. Спасибо за предложение. – Sebastien

+0

Я могу воспроизвести это поведение на своей машине Vista/II7 dev в отладке. И реализация WCF-сервиса не вызывается, Debugger.Break() не возникает. Важное примечание: моя реализация UserNamePasswordValidator вызывается, а другая служба WCF вызывается успешно, пока не будет вызвана служба, которая возвращает null ... Любая идея? – Sebastien

ответ

0

Дело с Microsoft было разрешено. Это ошибка в .Net frameowkr 2.0, и исправление будет доступно в ближайшее время.

КБ является 971030.

Проблема была связана от того, как нагрузки сборок CLR в домен приложения.

0

Oki, есть некоторые новые сведения. Возможно, это не проблема WCF ...

Наша реализация службы WCF была выполнена через прокси объектов (System.Runtime.Remoting.Proxies.RealProxy).

Наш базовый прокси имел атрибут DebuggerNonUserCode, который скрывал сторону сервера исключения в режиме отладки.

На данный момент я подозреваю, что наш RealProxy является источником проблемы. Я выложу свои выводы позже. Спасибо

+0

Я открыл звонок с Microsoft по этой проблеме. Я выложу выводы, когда дело будет разрешено. – Sebastien

+0

Все еще ждет Microsoft об этом. – Sebastien

Смежные вопросы