[DotNet] Dll et webservice

Dev
1

Humf,

J’ai un projet de serveur syslog impliquant un service windows et un web service utilisant tout deux des types définis dans une dll (j’ajoute la dll dans les références du web service et du service windows).

j’ai dans mon service web une méthode du type :

[code] [WebMethod]

public void AddMessage(message msg)

{

	this.buffer.Add(msg);

}[/code]

que j’appelle dans mon service windows

[code] public override void Flush()

	{

		localhost.Service service = new localhost.Service();

		foreach (message msg in this.buffer)

		{

			service.AddMessage(msg);

		} 

		buffer.Clear();

	}[/code]

Mon problème est que la méthode AddMessage du service web exige un objet du type SyslogLibrary.localhost.message et non pas SyslogLibrary.message comme je le voudrais.

Le type message est bien le même dans les deux et provient de la même dll.

Comment faire ? car là je ne sais pas passer mon message du service win au service web vu qu’il ne sait pas convertir SyslogLibray.message en SyslogLibrary.localhost.message

merci de votre aide.

2

Ton problème est classique. En fait il suffit de penser que les webservices sont d’abord fait pour fonctionner entre des systèmes pour lesquels l’interopérabilité n’existe pas forcément.

Donc ils intègrent leur propre système pour définir les données.

De ce fait, lorsque tu passes des types complexes comme paramètres, ils sont transformés en un format propre à SOAP. Les deux extrémités ne partagent donc que ce contrat WSDL.

Partant de là, le générateur de proxy client que tu utilises sous visual studio recréé une classe imitant ce type de données. C’est pour cela que tu as un type message créé dans ton proxy client.

Le seul moyen pour être sur qu’une seule classe sera utilisée côté serveur et côté client est de garantir que sa sérialisation puisse se faire en xml (avec un namespace) dans un premier temps de personnaliser le proxy client pour qu’il se serve de ta classe (tu auras un problème de conversion si tu n’ajoute pas de namespace sur ta classe).

Concrètement, il te faut rajouter un attribut System.Xml.Serialization.XmlRoot() sur ta classe message en y indiquant un ElementName pour le nom de la balise, et surtout un Namespace unique (du style http://schemas.monprojet/message).

Il te faut ensuite t’assurer que ta classe se sérialize parfaitement en xml (en ajoutant les attributs qui vont bien sur les propriétés/champs).

Normalement, dès lors, si tu regardes le contrat WSDL de ton service (en appelant ta page avec le paramètre ?WSDL), tu devrais voir déclaré ton type message avec le bon namespace.

Une fois cela fait, tu vas pouvoir t’occuper de ton proxy client. Le principal problème étant que si tu veux utiliser ta propre classe message, il va falloir que tu cesses d’utiliser le proxy généré par visual studio pour en utiliser un que tu auras créé spécifiquement.

Pour faire simple, tu prends celui que génère VS, et tu modifies les endroits où il utilise le type qu’il a créé pour utiliser à sa place ta classe message. Et normalement ça roule :stuck_out_tongue:

3

[long message à caractère inutile, supprimé suite à la résolution du stupide problème qu’il contenait.]

4

mmmh, j’ai réussi à sérializer correctement.
cependant ca ne m’a servi à rien. Je suis de nouveau au même stade qu’au début :

comment lui faire comprendre qu’au final c’est le même type ? :stuck_out_tongue:

5

Tu as édité le proxy client webservice que créé visual studio ?

Si tu as rajouté une référence web, il te faut récupérer le code généré, le customizer, et virer la référence web.

Tu ne peux plus faire avec une simple référence web pour ton problème, il te faut toi même créer le proxy client.

6

J’ai réussi à modifier le proxy correctement, merci :stuck_out_tongue: