Discussion :

[Picsonald]

Bonjour à tous,

Je suis actuellement en train de coder un service WCF dont une des méthodes doit pouvoir récupérer en paramètre un String, un Int32 ou une List<String>.

Concrètement, le code serveur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
[ServiceContract]
class MonService
{
    [OperationContract]
    void PasserObjet(Object monObjet)
    {
        // Je peux recevoir un String, un Int32 ou une List<String>.
        MessageBox.Show("Objet de type " + monObjet.GetType().FullName);
    }
}

Voici ce qu'il se passe lorsque le programme client sollicite la méthode "PasserObjet" de mon service WCF :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
void btn1_Click(object sender, EventArgs e)
{
    proxy.PasserObjet("Chaine de caractère");
}

Dans le cas présent, mon serveur me dit "Objet de type System.String". Je peux alors faire un cast et utiliser mon paramètre. Tout va bien.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
void btn2_Click(object sender, EventArgs e)
{
    List<String> _lstStr = new List<String>();
    _lstStr.Add("Liste de");
    _lstStr.Add("chaine de");
    _lstStr.Add("caractère.");
    proxy.PasserObjet(_lstStr);
}

Dans ce cas par contre, le programme client plante et me renvoie une exception qui ressemble à cela :

Une erreur s'est produite en tentant de sérialiser le paramètre. Le type 'System.Collections.Generic.List`1[System.String]' avec le nom de contrat de données 'ArrayOfstring' n'est pas attendu. Utilisez un DataContractResolver ou ajoutez tous les types non connus statiquement à la liste des types connus, par exemple en utilisant l'attribut KnownTypeAttribute.

Le serveur ne se sent pas sollicité et reste stable.


Avez-vous une idée pour résoudre ce problème ? J'ai fait pas mal de recherches sur Internet, et je ne vois pas de solution...

Merci d'avance !

[Bluedeep]

Bonjour

Il faut utiliser l'attribut KnownType pour chaque type à passer, sinon WCF ne peux pas déterminer à quels types il est susceptible d'avoir affaire.

[Picsonald]

Merci pour ta réponse Bluedeep.

Je viens d'essayer. "KnowType", en soit, n'est pas reconnu. Donc j'ai utilisé "ServiceKnownType" de la façon suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
[OperationContract, ServiceKnownType(typeof(List<String>))]
void PasserObjet(Object objet)
{
    MessageBox.Show("Objet de type " + objet.GetType().FullName);
}

Ça n'a pas fonctionné. Du coup j'ai essayer de déposer l'attribut au niveau de la classe carrément :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
[ServiceContract]
[ServiceKnownType(typeof(List<String>))]
class SupervisionService
{
    // ...
}

L'erreur reste la même. Y a-t-il quelque chose que je fais mal ?

[Invité]

Peut-on savoir ce qui t'empêche d'avoir autant d'opérations qu'il y a de types à utiliser ? Parce que là dans ce que tu fais ça ne sent pas du tout la bonne pratique.

[Bluedeep]

Bonjour

Bizarre; j'ai toujours utilisé cela sur la classe qui contient le DataContract (mais jamais sur le ServiceContract au demeurant).

Si tu utilises le ServiceKnownType, donc sur le ServiceContract, tu dois aussi préciser le nom de la méthode concernée. (en général, on définit cela au niveau de l'interface, pas de l'implémentation du service).


Mais il est vrai que cela a toujours été sur des retours et pas sur des arguments (dans ce cas, il est plus simple de mettre une méthode surchargée pour chaque type).

[Picsonald]

@ h2s84 : Oh... oui :-). Mais c'est loin d'être évident.

Mon service WCF est utilisé par des programmes clients qui s’exécutent sur quelques unes de mes machines distantes. Le serveur a pour but de me montrer en un coup d’œil l'état de mes clients (supervision).

Les clients peuvent m'envoyer un Int32 qui contiendra le taux de remplissage du disque dur, ou de la mémoire vive.
Il peuvent m'envoyer un String qui contiendra la version d'un driver, la version de Windows Update.
Il peuvent m'envoyer une List<String> qui contiendra la liste des process en cours d'exécution ou la liste des utilisateurs connectés.


Pourquoi ne pas faire des méthodes dédiées ? Pour des motifs de rétrocompatibilité et d'évolutivité.

Admettons qu'un jour, je souhaite également surveiller la version de mes anitivirus, l'état du trafic réseau, la liste des services anormalement arrêtés... Je vais devoir changer le code source de mon client, mais celui du serveur : non. Le serveur connait les critères de surveillance grâce à des infos situées en base de données, et il est capable de les retranscrire à l'aide d'un code dynamique.

A terme, toute version de mon serveur pourra fonctionner avec toute version de mon client, sans risque, du coté de mon client, un plantage pour "Méthode distante inexistante".


Tu penses que je fais fausse route avec mon paramètre "Object" ?




Bluedeep, Ok je vais essayer de regarder ça. Les surcharges, perso, moi, ça ne veut pas marcher (mais j'ai pas beaucoup creusé dans ce sens).

[Bluedeep]

Admettons qu'un jour, je souhaite également surveiller la version de mes anitivirus, l'état du trafic réseau, la liste des services anormalement arrêtés... Je vais devoir changer le code source de mon client, mais celui du serveur : non. .

Mais si, tu devras changer le code du serveur, puisque une ligne KnownType devra de toute manière être ajoutée en plus.

C'est la raison pour laquelle on utilise normalement le KnownType que pour les retours et les propriétés : pour les arguments, la surcharge de méthode remplit bien mieux la tâche.

A vrai dire, peut on utiliser le KnownType pour les arguments ? à la réflexion, je n'en sais rien puisque cela ne correspond à aucun besoin de design normal.

[Invité]

Ok je vois. Mais là j'aimerai savoir comment à partir du passage d'un Int32 ton code côté serveur pourra différencier qu'il s'agit de la quantité de la mémoire RAM ou que c'est celle de la taille du disque dur.

Sinon au lieu de lui passer une collection de string List<string> essaies de lui passer un tableau de string string[] et voir ce que ça donne.

[BenoitM]

Euh Je trouve illogique de passer un Objet

Crées 3 méthodes différentes

perso je passe des list<string>, des list<int>, des list<MesClasses> sans problème

les string[] seront convertis en list<string>

[Picsonald]

Merci pour vos réponses.

Mais si, tu devras changer le code du serveur, puisque une ligne KnownType devra de toute manière être ajoutée en plus.

Tu marques un point... À condition bien sûr que le problème soit lié à cela (car moi, avant que tu ne m'en parles, j'étais persuadé que le problème ne venait pas de là).

cela ne correspond à aucun besoin de design normal.

Là tu m'intéresses car je veux essayer de faire du code propre. Mais j'ai dû partir sur une mauvaise piste avec cet "object"... Je me suis un peu inspiré, en fait, du fameux "object sender" que l'on retrouve dans les événements liés à un contrôle en WinForm, et qui correspond au contrôle auteur de l’événement. Je me suis dit : dans mon cas, c'est pareil. je ne sais pas exactement le type que je vais avoir en paramètre de cette méthode.

Mais là j'aimerai savoir comment à partir du passage d'un Int32 ton code côté serveur pourra différencier qu'il s'agit de la quantité de la mémoire RAM ou que c'est celle de la taille du disque dur.

En fait, j'ai voulu réduire les extraits de code au plus simple pour que le problème soit bien apparent. Je ne voulait pas vous ennuyer avec les contraintes diverses et variées pour laquelle j'ai déjà trouvé une solution. Toutefois, pour répondre à ta question : ma méthode "PasserObjet" s'appelle "SetValeur". Voici les paramètres qu'elle prend :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
[OperationContract]
public void SetValeur(Object valeur, String hostName, Int32 type)
{
    // ...
}

Un exemple d'appel a cette méthode par le client :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SetValeur(85, "SQLSERV01", 5);

Ici le type "5" indique au serveur que la valeur "85" concerne le pourcentage d'utilisation processeur moyen sur la machine SQLSERV01.

Crées 3 méthodes différentes

Oui. En attendant de trouver une solution au problème qui se pose, j'ai créé trois méthodes différentes (au nom différent, puisque je n'arrive pas à faire de surcharges). Mais je ne saurais trop dire pourquoi : ça me chagrine.



Vous n'avez pas un idée qui me permettrais d'avoir un paramètre "objet" dans lequel je pourrais passer String, Int32 et List<String> ?

[StringBuilder]

+1 pour la surcharge.

+1 aussi pour reconnaître la différence entre la taille de la RAM et la taille du disque dur

Aussi, pourquoi ne pas envoyer un message complexe : une structure sérialisée en XML ?

Côté serveur, tu pourras utiliser différentes méthodes pour désérialiser selon la version du message reçu.

[StringBuilder]

Ah ben c'est plus clair comme ça.

Essaie le string[]

Et si ça marche pas, tu peux toujours faire un string.join() avant de l'envoyer au serveur.

PS : Et en terme de code propre, perso je préférerais limiter les accès client/server, en envoyant toutes les propriétés d'un coup (soit un gros string en paramètre qui contient un array de tes messages sérialiés, soit directement un array de struct correspondant à tes messages)

[BenoitM]

En attendant de trouver une solution au problème qui se pose, j'ai créé trois méthodes différentes (au nom différent, puisque je n'arrive pas à faire de surcharges). Mais je ne saurais trop dire pourquoi : ça me chagrine.

Parce que les WebService ne supporte pas le polymorphisme

[BenoitM]

Tu peux peut-être essayer de cree une classe message

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
class message
{
public property Object Value;
public property string hostname;
}

et que ton service aie une methode
public

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

void PasserMessages( List<Message> messages)

[Invité]

tu peux toujours faire un string.join() avant de l'envoyer au serveur.

+1,
Tu devrais essayer la méthode de StringBuilder je pense que ça résout ton problème si tu choisis bien le caractère de séparation pour les différentes parties (paramètres envoyés) et aussi pour les listes bien que cela ne soit pas du tout une bonne pratique.

Parce que les WebService ne supporte pas le polymorphisme

C'est le polymorphisme paramétré (surcharge de méthodes) qui n'est pas pris en compte. Mais le polymorphisme par sous-typage (héritage) est pris en compte (on peut le simuler avec l'attribut KnownType).

[StringBuilder]

Je viens d'installer VWD Express pour tester (mon premier web service WCF, snif)

Et ça donne :

Service1.svc.cs

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
using System;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.ServiceModel.Web;
using System.Text;
 
namespace WCFTestParams
{
    // REMARQUE*: vous pouvez utiliser la commande Renommer du menu Refactoriser pour changer le nom de classe "Service1" dans le code, le fichier svc et le fichier de configuration.
    public class Service1 : IService1
    {
        public int TestParameters(Message[] messages)
        {
            int res = 0;
            foreach (Message message in messages)
            {
                switch (message.type)
                {
                    case 1:
                        res += (int)message.value;
                        break;
                    case 2:
                        res += ((string)message.value).Length;
                        break;
                    case 3:
                        res += ((string)message.value).Split('|').Length;
                        break;
                }
            }
            return res;
        }
    }
}

IService1.cs

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
 
using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.ServiceModel.Web;
using System.Text;
 
namespace WCFTestParams
{
    // REMARQUE*: vous pouvez utiliser la commande Renommer du menu Refactoriser pour changer le nom d'interface "IService1" à la fois dans le code et le fichier de configuration.
    [ServiceContract]
    public interface IService1
    {
        [OperationContract]
        int TestParameters(Message[] messages);
        // TODO: ajoutez vos opérations de service ici
    }
 
 
    // Utilisez un contrat de données comme indiqué dans l'exemple ci-après pour ajouter les types composites aux opérations de service.
    [DataContract]
    public class Message
    {
        [DataMember]
        public int type { get; set; }
        [DataMember]
        public object value { get; set; }
        [DataMember]
        public string host { get; set; }
    }
}

Et enfin un client console :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
 
using System;
using System.Collections.Generic;
using System.Text;
using TestService.ServiceReference1;
 
namespace TestService
{
    public static class Extensions
    {
        public static string Join(this string[] s, char c)
        {
            StringBuilder sb = new StringBuilder();
 
            int i, nb;
            for (i = 0, nb = s.Length - 1; i < nb; i++)
            {
                sb.AppendFormat("{0}{1}", s[i], c);
            }
            return sb.Append(s[i]).ToString();
        }
    }
 
    class Program
    {
        static void Main(string[] args)
        {
            Message[] messages = new Message[3];
            Message message1 = new Message();
            message1.host = "toto";
            message1.type = 1;
            message1.value = 10;
            messages[0] = message1;
 
            Message message2 = new Message();
            message2.host = "toto";
            message2.type = 2;
            message2.value = "test";
            messages[1] = message2;
 
            Message message3 = new Message();
            message3.host = "toto";
            message3.type = 3;
            message3.value = (new string[2] { "toto", "titi" }).Join('|');
            messages[2] = message3;
 
            Service1Client sc = new Service1Client();
 
            // Le retour devrait être 10 + 4 + 2 = 16
            Console.WriteLine(sc.TestParameters(messages));
            Console.ReadKey(true);
        }
    }
}

J'obtiens bien 16 en réponse, donc ça me semble tout à fait bien fonctionner.

[StringBuilder]

Sâchant qu'à la limite, puisque c'est tout sérialisé en XML au final, pourquoi ne pas prendre un paramètre string et non object puis faire int.tryparse() quand tu attends un int ?

Perso, les object, moins j'en vois, mieux je me porte

[BenoitM]

C'est le polymorphisme paramétré (surcharge de méthodes) qui n'est pas pris en compte. Mais le polymorphisme par sous-typage (héritage) est pris en compte (on peut le simuler avec l'attribut KnownType).

Ah j'avais jamais entendu parler des deux types

Ben pour moi le polymorphisme par sous-typage n'en n'etait pas un

...

awww courageux

[Nathanael Marchand]

Autant je suis d'accord avec le fait qu'accepter un object ca soit pas jojo, autant il y'a des solutions assez élégantes possibles
Le premier point serait quand même de faire un type de base (pour pas accepter n'importe quel objet).
Ensuite, il faut effectivement que tu passes parle ServiceKnownType mais que tu utilises un autre constructeur de l'attribut:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
 
[ServiceKnownType("GetKnownTypes", typeof(KnownTypesHelper))]
[ServiceContract()]
public interface IService
{
    [OperationContract]
    void DoSomething(TypeBase obj);
}
 
public static class KnownTypesHelper
{
	public static IEnumerable<Type> GetKnownTypes(ICustomAttributeProvider provider)
	{
		var types = new List<Type> { typeof(TypeBase) };
		types.AddRange(Assembly.GetExecutingAssembly().GetTypes().Where(t => t.IsSubclassOf(typeof(TypeBase))));
		return types;
	}
}
 
public class TypeBase {}
 
public class TypeA : TypeBase {}
public class TypeB : TypeBase {}

Ce petit helper, te permets de découvrir à la volée les types qui peuvent transiter (sans déclarer tous les types de la terre, ni les déclarer explicitement).
Si tu ne fais qu'ajouter des types dans ton assembly, il ne devrait pas y avoir de problèmes de compatibilités avec tes clients.

[Picsonald]

Woooow ^^ Quel engouement pour mon problème.

Merci à tous pour vos apport. Je vais regarder tout ça, et je vous tiens au courant.

C'est super sympa en tout cas :-) !