WCF-Vereinfachungsfunktionen

In diesem Thema werden neue Features erläutert, die das Schreiben von WCF-Anwendungen vereinfachen.

gRPC als Alternative zu WCF

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

Leistung: gRPC ist viel effizienter als WCF, insbesondere für lang andauernde Verbindungen.
Skalierbarkeit: gRPC ist darauf ausgelegt, auf eine große Anzahl von Clients und Servern zu skalieren.
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 zum Entwickeln oder 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 der Wert der Standardwert ist. In WCF 4.5 enthalten die generierten Konfigurationsdateien nur die Bindungseigenschaften, die auf einen Nicht-Standardwert festgelegt sind.

Nachfolgend sehen Sie ein Beispiel für eine Konfigurationsdatei, die von WCF 3.0 generiert wird.

<?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>

Nachfolgend sehen Sie ein Beispiel für dieselbe Konfigurationsdatei, die von WCF 4.5 generiert wird.

<?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>

Contract-First Entwicklung

WCF unterstützt jetzt die Vertrag zuerst-Entwicklung. Das tool svcutil.exe verfügt über einen /serviceContract Switch, mit dem Sie Dienst- und Datenverträge aus einem WSDL-Dokument generieren können.

Dienstreferenz aus einem portablen Teilprojekt hinzufügen

Portable Teilmengenprojekte ermöglichen .NET-Assemblyprogrammierern die Verwaltung einer einzelnen Quellstruktur und eines Buildsystems, während weiterhin mehrere .NET-Implementierungen (Desktop, Silverlight, Windows Phone und Xbox) unterstützt werden. Portable Subset-Projekte verweisen nur auf tragbare .NET-Bibliotheken, die Assemblys sind, die für jede .NET-Implementierung verwendet werden können. Die Entwicklerumgebung entspricht dem Hinzufügen eines Dienstverweises innerhalb einer anderen WCF-Clientanwendung. Weitere Informationen finden Sie unter Dienstverweis in einem portablen Teilprojekt hinzufügen.

Standardmäßiger ASP.NET-Kompatibilitätsmodus geändert

WCF bietet ASP.NET Kompatibilitätsmodus, um Entwicklern vollzugriff auf die Features in der ASP.NET HTTP-Pipeline beim Schreiben von WCF-Diensten zu gewähren. 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 App-Domäne die RequirementsMode-Eigenschaft in AspNetCompatibilityRequirementsAttribute auf Allowed oder Required festgelegt sein. Standardmäßig ist AspNetCompatibilityRequirementsAttribute jetzt auf Allowed festgelegt, und in der Standardvorlage für die WCF-Dienstanwendung wird das Attribut aspNetCompatibilityEnabled auf true gesetzt. Weitere Informationen finden Sie unter What's New in Windows Communication Foundation 4.5 und WCF Services and ASP.NET.

Streamingverbesserungen

Neue Unterstützung für asynchrones Streaming wurde zu WCF 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 kann von der Skalierbarkeit profitieren, wenn ein Dienst gestreamte Nachrichten an mehrere Clients sendet, die langsam gelesen werden. WCF blockiert nicht mehr einen Thread pro Client und gibt den Thread frei, um einen anderen Client zu bedienen.
Entfernte Einschränkungen beim Puffern von Nachrichten, wenn ein Dienst iis gehostet wird. In früheren Versionen von WCF beim Empfangen einer Nachricht für einen von IIS gehosteten Dienst, der die Streamingnachrichtenübertragung verwendet hat, würde ASP.NET die gesamte Nachricht puffern, bevor sie an WCF gesendet wird. Dies würde zu einer großen Speicherauslastung führen. Diese Pufferung wurde in .NET Framework 4.5 entfernt, und jetzt können von IIS gehostete WCF-Dienste mit der Verarbeitung des eingehenden Datenstroms beginnen, bevor die gesamte Nachricht empfangen wurde, wodurch das echte Streaming aktiviert wird. Dadurch kann WCF sofort auf Nachrichten reagieren und eine verbesserte Leistung ermöglichen. Darüber hinaus müssen Sie keinen Wert mehr für maxRequestLength, die ASP.NET-Größenbeschränkung für eingehende Anforderungen, angeben. Wenn diese Eigenschaft festgelegt ist, wird sie ignoriert. Weitere Informationen zu maxRequestLength finden Sie im <httpRuntime-Konfigurationselement>. Sie müssen weiterhin "maxAllowedContentLength" konfigurieren, weitere Informationen finden Sie unter IIS-Anforderungsbeschränkungen.

Neue Transportstandardwerte

In der folgenden Tabelle werden die Einstellungen beschrieben, die geändert wurden und wo zusätzliche Informationen zu finden sind.

Eigentum	Auf	Neuer Standardwert	Mehr Informationen
channelInitializationTimeout	NetTcpBinding	30 Sekunden	Diese Eigenschaft bestimmt, wie lange eine TCP-Verbindung sich mithilfe des .NET Framing-Protokolls authentifizieren kann. Ein Client muss einige anfängliche 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
Listenrückstand	NetTcpBinding	16 * Anzahl der Prozessoren	Diese Eigenschaft auf Socketebene gibt an, wie viele Anforderungen, deren Annahme aussteht, in die Warteschlange eingereiht werden dürfen. Wenn die Listen-Backlog-Warteschlange gefüllt 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. Wenn MaxPendingAccepts zu niedrig ist, gibt es ein kurzes Zeitintervall, in dem alle wartenden Kanäle die Bearbeitung von Verbindungen begonnen haben, aber keine neuen Kanäle mit dem Lauschen begonnen haben. Eine Verbindung kann während dieses Intervalls eingehen und schlägt fehl, da nichts auf den Server wartet. Diese Eigenschaft kann durch Festlegen der MaxPendingConnections Eigenschaft auf eine größere Zahl konfiguriert werden. Weitere Informationen finden Sie unter MaxPendingAccepts und Konfigurieren des Net.TCP-Portfreigabediensts
maximaleWartendeVerbindungen	ConnectionOrientedTransportBindingElement	12 * Anzahl der Prozessoren	Diese Eigenschaft steuert, wie viele Verbindungen von einem Transport akzeptiert, vom ServiceModel-Verteiler jedoch noch nicht ausgewählt wurden. Verwenden Sie zum Festlegen dieses Werts `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. Dies dient dazu, eine Obergrenze für die Zeitspanne zu setzen, in der der SMSvcHost.exe-Dienst eingesetzt wird, um die Präambel-Daten von einer eingehenden Verbindung zu lesen. 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 .NET Framework 4.0-Standardwerte verwendet. In solchen Fällen wird empfohlen, diese Einstellungen explizit zu konfigurieren.

XmlDictionaryReaderQuotas

XmlDictionaryReaderQuotas enthält konfigurierbare Kontingentwerte für XML-Wörterbuchleser, die den von einem Encoder beim Erstellen einer Nachricht genutzten Arbeitsspeicher einschränken. Während diese Kontingente konfigurierbar sind, haben sich die Standardwerte geändert, um die Möglichkeit zu mindern, dass ein Entwickler sie explizit festlegen muss. MaxReceivedMessageSize Das Kontingent wurde nicht geändert, damit der Arbeitsspeicherverbrauch weiterhin begrenzt werden kann und Sie sich nicht mit der Komplexität des XmlDictionaryReaderQuotas auseinandersetzen müssen. In der folgenden Tabelle sind die Kontingente, ihre neuen Standardwerte und eine kurze Erläuterung der für jedes Kontingent verwendeten Werte aufgeführt.

Kontingentname	Standardwert	BESCHREIBUNG
MaxArrayLength	Int32.MaxValue	Ruft die maximal zulässige Arraylänge ab und legt sie fest. Dieses Kontingent beschränkt die maximale Größe eines Arrays von Grundtypen, die der XML-Reader zurückgibt, einschließlich Bytearrays. Dieses Kontingent schränkt den Arbeitsspeicherverbrauch im XML-Reader selbst nicht ein, sondern in jeder 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 maximal zulässigen Bytes ab, die für jeden Lesevorgang zurückgegeben werden, und legt diese fest. Dieses Kontingent begrenzt die Anzahl der Bytes, die bei einem einzelnen Lesevorgang gelesen werden, wenn das Start-Tag eines Elements und seine Attribute verarbeitet werden. (In nicht gestreamten Fällen wird der Elementname selbst nicht für das Kontingent gezählt). Wenn zu viele XML-Attribute vorhanden sind, kann die Verarbeitungszeit unverhältnismäßig hoch sein, da Attributnamen auf Eindeutigkeit überprüft werden müssen. MaxBytesPerRead mindert dieses Risiko.
MaxDepth	128 Knoten tief	Diese Kontingent schränkt die maximale Schachtelungstiefe von XML-Elementen ein. MaxDepth interagiert mit MaxBytesPerRead: Der Leser behält immer Daten im Arbeitsspeicher für das aktuelle Element und alle seine Vorgänger, sodass der maximale Speicherverbrauch des Readers proportional zum Produkt dieser 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. Eine direkte Korrelation besteht zwischen XML-Schachtelung und Objektschachtelung für die DataContractSerializer und die XmlSerializer. MaxDepth wird verwendet, um diese Bedrohung zu mindern.
MaxNameTableCharCount	Int32.MaxValue	Dieses Kontingent beschränkt die maximale Anzahl von Zeichen, die in einer Namenstabelle zulässig sind. Die Nametable enthält bestimmte Zeichenfolgen (z. B. Namespaces und Präfixe), die beim Verarbeiten eines XML-Dokuments auftreten. Da diese Zeichenfolgen im Arbeitsspeicher gepuffert werden, wird dieses Kontingent verwendet, um übermäßige Pufferung zu verhindern, wenn streaming erwartet wird.
MaxStringContentLength	Int32.MaxValue	Dieses Kontingent beschränkt die maximale Zeichenfolgengröße, die der XML-Reader zurückgibt. Dieses Kontingent beschränkt den Arbeitsspeicherverbrauch im XML-Reader selbst nicht, sondern 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.

Von Bedeutung

Weitere Informationen zum Sichern Ihrer Daten finden Sie unter " Sicheres Verwenden von XML".

Hinweis

WCF-Konfigurationsüberprüfung

Im Rahmen des Buildprozesses in Visual Studio werden jetzt WCF-Konfigurationsdateien überprüft. Eine Liste der Überprüfungsfehler oder Warnungen wird in Visual Studio angezeigt, wenn die Überprüfung fehlschlägt.

XML-Editor-QuickInfos

Damit neue und vorhandene WCF-Dienstentwickler ihre Dienste konfigurieren können, stellt der XML-Editor von Visual Studio jetzt QuickInfos für jedes Konfigurationselement und seine Eigenschaften bereit, die Teil der Dienstkonfigurationsdatei sind.

Verbesserungen bei BasicHttpBinding

Ermöglicht es einem einzelnen WCF-Endpunkt, auf verschiedene Authentifizierungsmodi zu reagieren.
Ermöglicht die Steuerung der Sicherheitseinstellungen eines WCF-Diensts durch IIS

Last updated on 2025-06-20