Teilen über

WCF-Vereinfachungsfunktionen

  • Artikel

In diesem Thema werden neue Funktionen erörtert, die das Schreiben von WCF-Anwendungen vereinfachen.

gRPC als Alternative zu WCF

gRPC ist ein modernes RPC-Framework und eine beliebte Alternative zu WCF. gRPC basiert auf HTTP/2, das eine Reihe von Vorteilen gegenüber WCF bietet, einschließlich:

  • Leistung: gRPC ist deutlich effizienter als WCF, insbesondere bei Verbindungen mit langer Ausführungszeit.
  • Skalierbarkeit: gRPC ist darauf ausgelegt, auf eine große Anzahl von Clients und Servern skaliert zu werden.
  • Sicherheit: gRPC unterstützt eine Vielzahl von Sicherheitsmechanismen, einschließlich TLS und Authentifizierung.
  • Plattformübergreifend: gRPC ist plattformneutral und kann mit einer Vielzahl von Programmiersprachen verwendet werden.

Weitere Informationen zur Entwicklung oder zum Migrieren von WCF-Apps zu gRPC finden Sie unter:

Vereinfachte generierte Konfigurationsdateien

Wenn Sie einen Dienstverweis in Visual Studio hinzufügen oder das SvcUtil.exe-Tool verwenden, wird eine Clientkonfigurationsdatei generiert. In früheren Versionen von WCF enthielten diese Konfigurationsdateien den Wert jeder Bindungseigenschaft, auch wenn deren Wert dem Standardwert entsprach. In WCF 4.5 enthalten die generierten Konfigurationsdateien nur die Bindungseigenschaften, die auf einen nicht standardmäßigen Wert festgelegt sind.

Im folgenden Beispiel wird eine mit WCF 3.0 generierte Konfigurationsdatei gezeigt.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IService1" closeTimeout="00:01:00"
                    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                    allowCookies="false" bypassProxyOnLocal="false"
                    hostNameComparisonMode="StrongWildcard" maxBufferSize="65536"
                    maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" transferMode="Buffered"
                    useDefaultWebProxy="true">
                    <readerQuotas maxDepth="32" maxStringContentLength="8192"
                        maxArrayLength="16384" maxBytesPerRead="4096"
                        maxNameTableCharCount="16384" />
                    <security mode="None">
                        <transport clientCredentialType="None" proxyCredentialType="None"
                            realm="" />
                        <message clientCredentialType="UserName" algorithmSuite="Default" />
                    </security>
                </binding>
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:36906/Service1.svc" binding="basicHttpBinding"
                bindingConfiguration="BasicHttpBinding_IService1" contract="IService1"
                name="BasicHttpBinding_IService1" />
        </client>
    </system.serviceModel>
</configuration>

Im folgenden Beispiel wird eine mit WCF 4.5 generierte Konfigurationsdatei gezeigt.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.serviceModel>
        <bindings>
            <basicHttpBinding>
                <binding name="BasicHttpBinding_IService1" />
            </basicHttpBinding>
        </bindings>
        <client>
            <endpoint address="http://localhost:36906/Service1.svc" binding="basicHttpBinding"
                bindingConfiguration="BasicHttpBinding_IService1" contract="IService1"
                name="BasicHttpBinding_IService1" />
        </client>
    </system.serviceModel>
</configuration>

Vertrag zuerst-Entwicklung

WCF unterstützt jetzt die Vertrag zuerst-Entwicklung. Das Tool „svcutl.exe“ verfügt über die Option „/serviceContract“, die das Generieren von Dienst- und Datenverträgen über ein WSDL-Dokument ermöglicht.

Hinzufügen eines Dienstverweises aus einem Projekt für die portable Teilmenge

Portable Subset-Projekte ermöglichen Programmierern von .NET-Assemblys, eine einzelne Quellstruktur zu verwalten und das System mit Unterstützung mehrerer .NET-Implementierungen (Desktop, Silverlight, Windows Phone und Xbox) aufzubauen. Portable Subset-Projekte verweisen nur auf portierbare .NET-Bibliotheken, bei denen es sich um .NET-Assemblys handelt, die von einer beliebigen .NET-Implementierung verwendet werden können. Die Entwicklererfahrung ist identisch mit dem Hinzufügen eines Dienstverweises innerhalb einer beliebigen anderen WCF-Clientanwendung. Weitere Informationen finden Sie unter Hinzufügen eines Dienstverweises in einem Portable Subset-Projekt.

Geänderter Standard für den ASP.NET-Kompatibilitätsmodus

WCF bietet einen ASP.NET-Kompatibilitätsmodus, der Entwicklern beim Schreiben von WCF-Diensten vollständigen Zugriff auf die Funktionen in der ASP.NET-HTTP-Pipeline gewährt. Um diesen Modus zu verwenden, müssen Sie das Attribut aspNetCompatibilityEnabled im Abschnitt <serviceHostingEnvironment> von „web.config“ auf „true“ festlegen. Darüber hinaus muss für jeden Dienst in dieser appDomain die RequirementsMode-Eigenschaft in AspNetCompatibilityRequirementsAttribute auf Allowed oder Required festgelegt sein. Standardmäßig wird AspNetCompatibilityRequirementsAttribute jetzt auf Allowed festgelegt, und in der Standardvorlage für die WCF-Dienstanwendung ist das aspNetCompatibilityEnabled-Attribut auf true festgelegt. Weitere Informationen finden Sie unter Neuerungen in Windows Communication Foundation 4.5 und WCF-Dienste und ASP.NET.

Verbesserungen beim Streaming

  • Der WCF wurde neue Unterstützung für asynchrones Streaming hinzugefügt. Um das asynchrone Streaming zu aktivieren, fügen Sie dem Diensthost das DispatcherSynchronizationBehavior-Endpunktverhalten hinzu, und legen Sie dessen AsynchronousSendEnabled-Eigenschaft auf true fest. Dies begünstigt die Skalierbarkeit, wenn ein Dienst gestreamte Nachrichten an mehrere Clients mit niedriger Lesegeschwindigkeit sendet. Von WCF wird nicht mehr ein Thread pro Client blockiert; der Thread steht für weitere Clients zur Verfügung.

  • Einschränkungen im Hinblick auf die Nachrichtenpufferung bei von IIS gehosteten Diensten wurden aufgehoben. Wenn in früheren WCF-Versionen eine Nachricht für einen IIS-gehosteten Dienst einging, der die Nachrichtenübertragung per Stream nutzte, wurde die gesamte Nachricht vor der Übertragung an WCF von ASP.NET gepuffert. Dieser Vorgang beanspruchte viel Arbeitsspeicher. Da diese Pufferung in .NET Framework 4.5 entfernt wurde, können IIS-gehostete WCF-Dienste jetzt mit der Verarbeitung des eingehenden Datenstroms beginnen, bevor die Nachricht vollständig empfangen wurde. Das schafft die Voraussetzungen für echtes Streaming. Dadurch kann WCF sofort auf Nachrichten reagieren, was eine verbesserte Leistung bedeutet. Außerdem muss für das ASP.NET-Größenlimit für eingehende Anforderungen maxRequestLength kein Wert mehr angegeben werden. Wenn diese Eigenschaft festgelegt ist, wird sie ignoriert. Weitere Informationen zu maxRequestLength finden Sie unter <httpRuntime>-Konfigurationselement. Sie müssen „maxAllowedContentLength“ allerdings trotzdem konfigurieren. Weitere Informationen finden Sie unter IIS-Anforderungslimits.

Neue Standardwerte für Transporte

Anhand der folgenden Tabelle erfahren Sie, welche Einstellungen geändert wurden und wo Sie zusätzliche Informationen finden.

Eigenschaft Ein Neuer Standard Weitere Informationen
channelInitializationTimeout NetTcpBinding 30 Sekunden Diese Eigenschaft bestimmt die Zeit, die eine TCP-Verbindung beanspruchen darf, um sich über das .NET-Framingprotokoll zu authentifizieren. Ein Client muss vorab einige Daten senden, bevor der Server über genügend Informationen zum Ausführen der Authentifizierung verfügt. Für dieses Timeout wurde bewusst ein geringerer Wert als für ReceiveTimeout (10 Minuten) festgelegt, damit Serververbindungen von böswilligen, nicht authentifizierten Clients nicht zu lange aufrechterhalten werden können. Der Standardwert ist 30 Sekunden. Weitere Informationen zu ChannelInitializationTimeout
listenBacklog NetTcpBinding 16 × Anzahl der Prozessoren Diese Eigenschaft auf Socketebene gibt an, wie viele Anforderungen, deren Annahme aussteht, in die Warteschlange eingereiht werden dürfen. Sobald die listenBacklog-Warteschlange voll ist, werden neue Socketanforderungen abgelehnt. Weitere Informationen zu ListenBacklog
maxPendingAccepts ConnectionOrientedTransportBindingElement

SMSvcHost.exe		 2 * Anzahl der Prozessoren für den Transport

4 * Anzahl der Prozessoren für "SMSvcHost.exe"		 Diese Eigenschaft begrenzt die Anzahl der Kanäle, die auf dem Server auf einen Listener warten können. Weist MaxPendingAccepts einen zu geringen Wert auf, ist der Zeitraum, in dem alle wartenden Kanäle mit der Verarbeitung von Verbindungen begonnen haben, zu kurz, als dass neue Kanäle das Lauschen gestartet haben könnten. Wenn während dieses Zeitraums eine Verbindungsanforderung eingeht, wird sie fehlschlagen, da auf dem Server noch nicht auf neue Verbindungen gelauscht wird. Diese Eigenschaft kann konfiguriert werden, indem die MaxPendingConnections-Eigenschaft auf einen höheren Wert festgelegt wird. Weitere Informationen finden Sie unter MaxPendingAccepts und Konfigurieren des Net.TCP-Portfreigabediensts.
maxPendingConnections ConnectionOrientedTransportBindingElement 12 * Anzahl der Prozessoren Diese Eigenschaft steuert, wie viele Verbindungen von einem Transport akzeptiert, vom ServiceModel-Verteiler jedoch noch nicht ausgewählt wurden. Um diesen Wert festzulegen, verwenden Sie MaxConnections für die Bindung oder maxOutboundConnectionsPerEndpoint für das Bindungselement. Weitere Informationen zu MaxPendingConnections
receiveTimeout SMSvcHost.exe 30 Sekunden Diese Eigenschaft gibt das Timeout für das Lesen der TCP-Rahmendaten und das Verteilen der zugrunde liegenden Verbindungen an. Dadurch wird die Dauer beschränkt, die der SMSvcHost.exe-Dienst mit dem Lesen der Präambel einer eingehenden Verbindung beschäftigt ist. Weitere Informationen finden Sie unter Konfigurieren des Net.TCP-Portfreigabediensts.

Hinweis

Diese neuen Standardwerte werden nur verwendet, wenn Sie den WCF-Dienst auf einem Computer mit .NET Framework 4.5 bereitstellen. Wenn Sie denselben Dienst auf einem Computer mit .NET Framework 4.0 bereitstellen, werden die Standardwerte von .NET Framework 4.0 verwendet. In solchen Fällen wird empfohlen, die Einstellungen explizit zu konfigurieren.

XmlDictionaryReaderQuotas

XmlDictionaryReaderQuotas enthält konfigurierbare Kontingentwerte für XML-Wörterbuchreader, die den Arbeitsspeicher begrenzen, der beim Erstellen einer Nachricht von einem Encoder verwendet wird. Während diese Kontingente konfigurierbar sind, wurden die Standardwerte geändert, um die Wahrscheinlichkeit zu vermindern, dass sie von einem Entwickler explizit festgelegt werden müssen. Das MaxReceivedMessageSize-Kontingent wurde nicht geändert und kann den Arbeitsspeicherverbrauch weiterhin einschränken. So entfällt die Notwendigkeit, komplexe XmlDictionaryReaderQuotas zu überwachen. In der folgenden Tabelle sind die Kontingente, die neuen Standardwerte und eine kurze Erläuterung zum Verwendungszweck der einzelnen Kontingente enthalten.

Namen des Kontingents Standardwert BESCHREIBUNG
MaxArrayLength Int32.MaxValue Ruft die maximal zulässige Arraylänge ab und legt sie fest. Dieses Kontingent schränkt die maximale Größe eines Arrays von Primitiven ein, einschließlich Bytearrays, die vom XML-Reader zurückgegeben werden. Der Arbeitsspeicherverbrauch im XML-Reader selbst wird mit diesem Kontingent nicht eingeschränkt, jedoch in der Komponente, die den Reader verwendet. Wenn DataContractSerializer z. B. einen Reader verwendet, der mit MaxArrayLengthgesichert ist, werden keine Bytearrays deserialisiert, deren Größe dieses Kontingent überschreitet.
MaxBytesPerRead Int32.MaxValue Ruft die bei jedem Lesevorgang zurückgegebenen maximal zulässigen Bytes ab und legt sie fest. Dieses Kontingent beschränkt die Anzahl der Bytes, die in einem einzelnen Vorgang beim Lesen des Starttags des Elements und dessen Attributen gelesen werden. (In Fällen ohne Streaming wird der Elementname selbst nicht in die Berechnung des Kontingents einbezogen.) Bei zu vielen XML-Attributen kann die Verarbeitungszeit übermäßig lange dauern, da die Attributnamen auf Eindeutigkeit überprüft werden müssen. MaxBytesPerRead mindert dieses Risiko.
MaxDepth Tiefe von 128 Knoten Diese Kontingent schränkt die maximale Schachtelungstiefe von XML-Elementen ein. MaxDepth interagiert mit MaxBytesPerRead: Der Reader behält stets Daten für das aktuelle Element und alle seiner übergeordneten Elemente im Arbeitsspeicher, weshalb der maximale Arbeitsspeicherverbrauch proportional zum Produkt aus diesen beiden Einstellungen ist. Wenn Sie ein tief geschachteltes Objektdiagramm deserialisieren, ist das Deserialisierungsprogramm gezwungen, auf den gesamten Stapel zuzugreifen und eine nicht behebbare StackOverflowExceptionauszulösen. Ein direkter Zusammenhang besteht zwischen der XML-Schachtelung und der Objektschachtelung sowohl für DataContractSerializer als auch für XmlSerializer. MaxDepth wird verwendet, um dieses Risiko zu mindern.
MaxNameTableCharCount Int32.MaxValue Dieses Kontingent beschränkt die maximale Anzahl von Zeichen, die in einer Nametable zulässig sind. Die Nametable enthält bestimmte Zeichenfolgen (z. B. Namespaces and Präfixe), die beim Verarbeiten von XML-Dokumenten auftreten. Da diese Zeichenfolgen im Arbeitsspeicher gepuffert werden, kann mit diesem Kontingent eine übermäßige Pufferung verhindert werden, wenn die Zeichenfolgen erwartungsgemäß gestreamt werden sollen.
MaxStringContentLength Int32.MaxValue Dieses Kontingent schränkt die maximale Größe der Zeichenfolgen ein, die vom XML-Reader zurückgegeben werden. Der Arbeitsspeicherverbrauch im XML-Reader selbst wird mit diesem Kontingent nicht eingeschränkt, jedoch in der Komponente, die den Reader verwendet. Wenn DataContractSerializer z. B. einen Reader verwendet, der mit MaxStringContentLengthgesichert ist, werden keine Zeichenfolgen deserialisiert, deren Größe dieses Kontingent überschreitet.

Wichtig

Weitere Informationen zum Schützen Ihrer Daten finden Sie unter „Sichere Verwendung von XML“ unter Sicherheitsüberlegungen für Daten.

Hinweis

Diese neuen Standardwerte werden nur verwendet, wenn Sie den WCF-Dienst auf einem Computer mit .NET Framework 4.5 bereitstellen. Wenn Sie denselben Dienst auf einem Computer mit .NET Framework 4.0 bereitstellen, werden die Standardwerte von .NET Framework 4.0 verwendet. In solchen Fällen wird empfohlen, die Einstellungen explizit zu konfigurieren.

WCF-Konfigurationsvalidierung

Im Rahmen des Buildvorgangs innerhalb von Visual Studio werden WCF-Konfigurationsdateien jetzt überprüft. Eine Liste mit Validierungsfehlern oder Warnungen wird in Visual Studio angezeigt, wenn die Validierung fehlschlägt.

XML-Editor-QuickInfos

Um neuen und bereits erfahrenen Entwicklern von WCF-Diensten die Konfiguration zu erleichtern, zeigt der XML-Editor in Visual Studio nun QuickInfos für jedes Konfigurationselement, das Teil der Dienstkonfigurationsdatei ist, und dessen Eigenschaften an.

BasicHttpBinding-Verbesserungen

  1. Ermöglicht es einem einzelnen WCF-Endpunkt, auf verschiedene Authentifizierungsmodi zu reagieren.

  2. Ermöglicht die Steuerung der Sicherheitseinstellungen eines WCF-Diensts durch IIS.