Situation:La désérialisation ne semble pas fonctionner avec les objets fortement nommés dans l'EDI
J'ai un tas d'objets métier assis derrière un service Web. Tous les objets sont encapsulés dans un BusObjects.DLL, qui est fortement nommé et se trouve dans le GAC sur le serveur (car d'autres applications sur le serveur y accèdent également).
J'ai une application client click-once, qui appelle le service Web. L'application click-once est également livré avec ce BusObjects.DLL.
La manière dont le service Web renvoie les données au client est la suivante: Il sérialise l'objet métier en un tableau d'octets et renvoie ce tableau d'octets au client. Le client désérialise le tableau d'octets reçu dans un objet métier. Cela est possible car le client et le code du serveur ont une référence au même BusObjects.DLL. Tout cela fonctionne très bien.
Le problème pour moi est le suivant. Quand j'ai la solution client (qui comprend le projet BusObjects) dans VS2005, le code est incapable de désérialiser le tableau d'octets en objet d'affaires parce que, selon elle,
« Impossible de charger le fichier ou l'assemblage 'CC.BusObjects, Version = 2.12.1.47, Culture = neutral, PublicKeyToken = af56fdb58c626305' ou une de ses dépendances la définition manifeste situé Assemblée ne correspond pas à la référence d'assemblage (Exception de HRESULT:.. 0x80131040) "
J'ai essayé des versions correspondantes, mais rien ne semble fonctionner si le projet BusObjects est référencé en tant que projet, plutôt que comme un assemblage externe. Malheureusement, je dois avoir les BusObjects dans la solution pour le débogage. Que puis-je faire pour résoudre ce problème?
J'ai entendu parler de redirection de version, mais je n'arrive pas à le faire fonctionner avec un assembly nommé fort, mais peut-être que je le fais mal.
Voici le code de sérialisation et désérialisation:
public static byte[] ToBinary(Object objToBinary)
{
MemoryStream memStream = new MemoryStream();
BinaryFormatter formatter = new BinaryFormatter(null,
new StreamingContext(StreamingContextStates.Clone));
formatter.Serialize(memStream, objToBinary);
memStream.Seek(0, SeekOrigin.Begin);
return memStream.ToArray();
}
public static object BinaryTo(byte[] objFromBinary)
{
MemoryStream ms = new MemoryStream(objFromBinary);
BinaryFormatter formatter = new BinaryFormatter();
ms.Position = 0;
object obj = formatter.Deserialize(ms);
return obj;
}
Pour sérialiser:
[WebMethod]
public byte [] GetContacts()
{
return ToBinary(BusObjects.GetContacts());
}
désérialiser:
byte [] bts = ContactService.GetContacts();
List<Contact> lstContacts = (List<Contact>) BinaryTo(bts);
Êtes-vous la signature de l'ensemble sur le côté client ainsi?C'est dans votre projet client, si vous allez à propriétés-> signature, avez-vous la même clé que le côté serveur utilise pour signer votre assembly? –
Eh bien, c'est le même projet, alors oui, c'est signé de la même façon. – AngryHacker
JP, votre intuition initiale était juste sur l'argent. Je suis allé demander aux gars qui font toutes nos constructions ... et il s'avère qu'ils n'utilisent pas la clé que je leur ai fournie, mais leur propre clé, pour des raisons de sécurité. – AngryHacker