2009-06-15 5 views
0

J'ai une application WCF, s'exécutant sur .NET 3.5 SP1, hébergé dans IIS7, sur un Windows Server 2008 64 bits.Avoir deux applications WCF dans le même pool provoque des problèmes étranges

Dans notre architecture, il y a 1 instance de l'application par client, les DLL sont copiées dans un répertoire séparé pour chaque client. Dans IIS, nous hébergeons 5 clients par pool d'applications, chaque client ayant sa propre application/répertoire virtuel/répertoire physique configuré.

Cette configuration fonctionne correctement pour notre version actuelle, qui utilise les services Web .NET 2.0 ASMX avec WSE.

Lorsque nous avons mis notre nouvelle version à l'aide de WCF en test, cela a fonctionné correctement lorsque le pool d'applications ne comportait qu'une seule application. Lorsque nous mettons deux applications dans le même pool, les services commencent à retourner null sans raison, alors qu'il n'est pas isolé.

Notre ligne de pipeline géré par l'application est "classique", et j'ai également essayé en mode "intégré", le problème est toujours là.

Quelqu'un a-t-il une idée de ce qui se passe?

+0

Pouvez-vous le déboguer? Quand vous dites que les services retournent null, votre code est-il activé? Est-ce que le message est envoyé à votre code? Que faire si vous insérez un Debuger.Break() dans l'implémentation du service WCF? – Cheeso

+0

Bonjour, je n'ai pas essayé cette configuration dans un environnement de développement. Je vais faire quelques tests sur ma machine locale et je reviendrai vers vous. Merci pour la suggestion. – Sebastien

+0

Je peux reproduire ce comportement sur ma machine de développement Vista/II7 lors du débogage. Et l'implémentation du service WCF n'est pas appelée, Debugger.Break() ne se produit pas. Remarque importante, mon implémentation UserNamePasswordValidator est appelée et un autre service WCF est appelé avec succès avant que le service qui renvoie null est appelé ... Une idée? – Sebastien

Répondre

0

L'affaire avec Microsoft a été résolue. Ceci est un bug dans .Net frameowkr 2.0 et un correctif sera disponible sous peu.

La KB est 971030.

Le problème était lié sur la façon dont les charges CLR assemblées dans un domaine d'application.

0

Oki, il y a de nouvelles informations. Il ne pourrait pas du tout un problème WCF ...

Notre implémentation du service WCF a été effectuée via le proxy d'objet (System.Runtime.Remoting.Proxies.RealProxy).

Notre proxy de base avait l'attribut DebuggerNonUserCode qui masquait le côté du serveur d'exceptions en mode débogage.

Pour l'instant, je pense que notre RealProxy est la source du problème. Je posterai mes conclusions plus tard. Merci

+0

J'ai ouvert un appel avec Microsoft pour ce problème. Je posterai les résultats lorsque le cas sera résolu. – Sebastien

+0

Toujours en attente de Microsoft à ce sujet. – Sebastien

Questions connexes