Frage

Ich fange gerade erst an, einige WCF-Dienste zu erstellen, aber ich muss sie abwärtskompatibel für ältere Clientanwendungen (.NET 1.1 und 2.0) machen.

Ich habe es geschafft, dass die Dienste für Clients der Version 3.0 und höher ordnungsgemäß ausgeführt werden, aber wenn ich die Dienste mit einem basicHttpBinding-Endpunkt veröffentliche (was meiner Meinung nach für die von mir benötigte Kompatibilität erforderlich ist), überarbeitet der Dienst meine Methodensignaturen.z.B.

public bool MethodToReturnTrue(string seedValue);

erscheint den Client-Apps als

public void MethodToReturnTrue(string seedValue, out bool result, out bool MethodToReturnTrueResultSpecified);

Ich habe jeden Konfigurationsparameter ausprobiert, der mir in der app.config für meine selbsthostende Konsolen-App einfällt, aber es scheint mir nicht gelungen zu sein, dass diese Funktion wie erwartet funktioniert.Ich vermute, dass dies dazu führen könnte, dass meine Erwartungen fehlerhaft sind, aber ich wäre überrascht, wenn ein WCF-Dienst nicht in der Lage wäre, einen Bool-Rückgabetyp an einen Client auf niedrigerer Ebene zu verarbeiten.

Meine aktuelle app.config sieht so aus.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>  
  <system.serviceModel>
    <services>
      <service behaviorConfiguration="MyServiceTypeBehaviors" Name="MyCompany.Services.CentreService.CentreService">
        <clear />
        <endpoint address="http://localhost:8080/CSMEX"    binding="basicHttpBinding" bindingConfiguration="" contract="IMetadataExchange" />
        <endpoint address="http://localhost:8080/CentreService" binding="basicHttpBinding" bindingName="Compatible" name="basicEndpoint" contract="MyCompany.Services.CentreService.ICentreService" />
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="MyServiceTypeBehaviors" >
            <serviceMetadata httpGetEnabled="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>
</configuration>

Kann mir bitte jemand einen Rat geben?

War es hilfreich?

Lösung 2

OK, wir mussten dieses Problem kurzfristig lösen und kamen daher auf die Idee einer „Interop“- oder Kompatibilitätsebene.

Im Grunde haben wir dem Projekt lediglich einen herkömmlichen ASMX-Webdienst hinzugefügt und von dort aus den WCF-Dienst mithilfe nativer WCF-Aufrufe aufgerufen.Anschließend konnten wir die entsprechenden Typen ohne nennenswerten Refactoring-Aufwand an die Clientanwendungen zurückgeben.Ich weiß, dass es eine knifflige Lösung war, aber es war die beste Option, die wir bei einer so großen Legacy-Codebasis hatten.Und der zusätzliche Bonus ist, dass es tatsächlich überraschend gut funktioniert.:) :)

Andere Tipps

Ah, das bringt mich um!Ich habe das vor etwa drei Monaten bei der Arbeit gemacht und kann mich jetzt nicht mehr an alle Details erinnern.

Ich erinnere mich jedoch daran, dass Sie „basicHttpBinding“ benötigen und den neuen Serializer (der die Standardeinstellung ist) nicht verwenden können.Sie müssen den „alten“ XmlSerializer verwenden.

Leider arbeite ich nicht mehr an der Stelle, an der ich das gemacht habe, daher kann ich mir den Code nicht ansehen.Ich rufe meinen Chef an und frage, was ich herausfinden kann.

Sie müssen den XmlSerializer verwenden.Zum Beispiel:

[ServiceContract(Namespace="CentreServiceNamespace")]
[XmlSerializerFormat(Style=OperationFormatStyle.Document, SupportFaults=true, Use=OperationFormatUse.Literal)]
public interface ICentreService {
    [OperationContract(Action="CentreServiceNamespace/MethodToReturnTrue")]
    bool MethodToReturnTrue(string seedValue);
}

Sie müssen den Vorgangsaktionsnamen manuell festlegen, da der automatisch generierte WCF-Name anders aufgebaut ist als der ASMX-Aktionsname (WCF enthält auch den Schnittstellennamen, ASMX nicht).

Alle von Ihnen verwendeten Datenverträge sollten mit dekoriert werden [XmlType] statt [DataContract].

Ihre Konfigurationsdatei sollte nicht geändert werden müssen.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top