Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Les pièges de WCF en partial trust (shared hosting par exemple)

Je vous palais récemment des nouvelles possibilités offertes par Windows Server 2008 en matière d'hébergement de services WCF.

Ce qui peut être intéressant, c'est d'héberger un service WCF en hébergement mutualisé. Je suis en train d'en faire l'expérience, et si cela n'a rien d'impossible, il y a quand même quelques pièges pour l'instant très peu (voire pas) documentés.

Le principal souci vient du fait qu'en hébergement mutualisé, votre application va s'exécuter sous des conditions de sécurité restreintes. Dans la plupart des cas, ce sera en medium trust.

Première chose à savoir, WCF 1.0 (du Framework 3.0) ne supporte pas de s'exécuter en medium trust. Il peut s'exécuter qu'en Full Trust. Par contre, la version fournie avec .NET 3.5 (RTM à la fin du mois) peut désormais s'exécuter en medium trust.

Pour un hébergement mutualisé, c'est donc cette version que vous utiliserez. Ce post de Steve Maine indique les fonctionnalités disponibles en Medium Trust :

  • BasicHttpBinding avec HTTP transport security
  • WebHttpBinding
  • Serialization avec XML Serializer
  • Serialization avec DataContractSerializer
  • RSS/Atom

J'ai suivi ces guidelines, et mon service utilise BasicHTTPBinding et le DataContractSerializer. Pourtant, lors de l'appel de certaines opérations sur mon service, mon client jette une CommunicationException qui n'est d'aucune aide, et ferme la connexion :

An error occurred while receiving the HTTP response to *myserver*. This could be due to the service endpoint binding not using the HTTP protocol. This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down). See server logs for more details.

Ce qu'il se passe, c'est que le serveur a rencontré un problème lors de la sérialisation et a fermé la connexion. Coté serveur, aucune exception n'est lancée, il est donc impossible de savoir ce qu'il s'est passé.

Pour débugger ceci, je vous conseille de créer une page qui contient uniquement une opération de sérialisation avec le DataContractSerializer :

public static void Test(Player item)
{
    DataContractSerializer ser = new DataContractSerializer(typeof(Player
));
    MemoryStream stream = new MemoryStream
();
    ser.WriteObject(stream, item);
    stream.Close();
}

En affichant cette page, vous saurez peut être d'où vient le problème (l'exception s'affichera dans la page).

Dans mon cas le problème était que les attributs [DataMember] étaient placés sur des membres privés. Cela fonctionne en FullTrust (donc dans mon environnement de développement), mais pas en medium trust. Ce qui est logique, mais documenté nulle part. J'ai donc juste déplacé les attributs sur les propriétés get/set associées pour que cela fonctionne.

J'ai remplacé :

[DataContract]
public class
PlayerInfo
{
    [DataMember
]
    private long money;
    [DataMember]
    private long useableMoney;

    public
long Money
    {
        get { return
money; }
        set { money = value
; }
    }
    public long
UseableMoney
    {
        get { return
useableMoney; }
        set { useableMoney = value
; }
    }
}

par :

[DataContract]
public class
PlayerInfo
{
    private long
money;
    private long
useableMoney;

    [DataMember
]
    public long Money
    {
        get { return
money; }
        set { money = value
; }
    }
    [DataMember
]
    public long UseableMoney
    {
        get { return
useableMoney; }
        set { useableMoney = value
; }
    }
}

Publié lundi 5 novembre 2007 17:12 par RaptorXP
Classé sous : , ,
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires

# re: Les pièges de WCF en partial trust (shared hosting par exemple)

Pratique la petite méthode de Test, en effet les problèmes de sérialization sont récurrents mais ne sont pas présentés très clairement par WCF. Pour ma part j'ai eu le même soucis, je m'en suis sortis en activant les traces WCF et en les examinant avec SvcTraceViewer. Au final bien plus long et galère...

Merci pour le tips!

lundi 17 mars 2008 12:07 by BxB
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01