Ich habe nicht viel mit Soap-Header gearbeitet, also hoffe ich, es gibt eine Antwort hier. Hier ist ein einfaches Beispiel für das, was ich erreichen möchte.ASMX Verwendet kompilierten Typ anstelle von generierten Typ für SoapHeader
Ich habe einen ASMX-Webdienst und einen Client, zusammen mit einer freigegebenen DLL. In shared.dll habe ich einen serialisierbaren Typ, nennen wir es CustomHeader, abgeleitet von SoapHeader. Es gibt eine Webmethode, die dies als Eingabe über ein SoapHeader-Attribut akzeptiert, sodass mein Dienst wie folgt aussieht:
[WebService]
public class MyService : WebService {
public CustomHeader MyCustomHeader { get; set; }
[WebMethod]
[SoapHeader("MyCustomHeader", Direction = SoapHeaderDirection.In)]
public void Go() { }
}
So weit, so gut. Innerhalb der Go() -Methode kann ich auf das MyCustomHeader-Objekt zugreifen und Dinge damit tun. Wenn ich einen Proxy generiere, enthält der generierte Code vom Client eine CustomHeader-Klasse mit den Dateneigenschaften des MyService-Objekts und eine Eigenschaft mit dem Namen CustomHeaderValue, die ich auf dem Client festlegen kann, bevor der Service-Aufruf an Go() erfolgt es geht gut voran.
Das Problem besteht darin, dass die ursprüngliche CustomHeader-Klasse über Konstruktoren und Methoden verfügte, mit denen die Datenfelder (Hashfunktionen, berechnete Werte usw.) aufgefüllt wurden. Da der Client über einen Verweis auf die gemeinsam genutzte Bibliothek verfügt, kann der Client eine Instanz der ursprünglichen CustomHeader-Klasse erstellen. Dieses Objekt kann jedoch nicht im Serviceaufruf verwendet werden, da es sich um einen technisch anderen Typ handelt.
kann ich denke an ein paar Möglichkeiten, dies Handhabung:
1) umrechnen Custom Objekt auf die generierte Klasse Custom durch die Eigenschaften über einer nach dem anderen zieht. Dies würde nicht viel Verarbeitung sein, aber es würde bedeuten, dass ich entweder Reflektion verwenden müsste, um die Eigenschaften durchzulaufen oder den Konvertierungscode zu berühren, wenn sich die CustomHeader-Klasse ändert.
2) Serialisieren Sie das CustomHeader-Objekt und deserialisieren Sie es in die generierte CustomHeader-Klasse - da sie abgesehen von den Konstruktoren und Methoden wirklich identisch sind, sollte die Serialisierung funktionieren. Dies wäre der einfachste Weg, aber es erfordert eine zusätzliche Runde von Serialisierung/Deserialisierung, die, obwohl nicht sehr teuer, noch zusätzliche Verarbeitung ist.
3) Ändern Sie den generierten Code, um die CustomHeaderValue-Eigenschaft meines freigegebenen Typs anstelle des generierten Typs zu erstellen. Meiner Meinung nach ist dies eine schreckliche Art, Dinge zu tun, aber es wäre wahrscheinlich die billigste dieser Optionen. Ich werde diese Option nicht machen, aber ich wollte es einfach rausbringen, da es technisch funktioniert.
Fehle ich etwas? Gibt es ein akzeptiertes Muster dafür?
Danke für die Hilfe.
Danke. Ich hatte das Gefühl, dass ich das nicht tun würde, ohne entweder auf WCF upzugraden oder eine meiner oben aufgelisteten Lösungen zu machen. Ich gehe mit meiner # 2 Lösung oben, Serialisierung und Deserialisierung des Objekts, um es in den entsprechenden Typ zu konvertieren. –