Warum benötigen vollständig qualifizierte Assemblynamen manchmal Leerzeichen?

Question

Bin gerade über diesen hier gestolpert und ich kann keine Informationen darüber finden. Deshalb frage ich hier. Vielleicht weiß jemand warum.

Ich habe eine benutzerdefinierte WCF-Verhaltenserweiterung zu meiner web.config hinzugefügt. Es sieht wie folgt aus:

<behaviorExtensions> 
    <add name="errorBehavior" type="MyNs.TracingErrorBehaviorElement,MyNs, 
     Version=1.0.6.0, Culture=neutral, PublicKeyToken=null" /> 
</behaviorExtensions> 

(Kein Platz drin: MyNs.TracingErrorBehaviorElement,MyNs)

Es funktioniert perfekt auf meinem Entwicklungsrechner, auf unserem Testserver, auf unserem Live-Server usw.

Heute wir das Produkt auf einem Kundenserver installiert und bekam die folgende Ausnahme:

System.Configuration.ConfigurationErrorsException: ein Fehler ist aufgetreten cr den Konfigurationsabschnitt-Handler für System.ServiceModel/Verhalten essen: Erweiterungselement 'errorBehavior' kann nicht zu diesem Element hinzugefügt werden. Stellen Sie sicher, dass die Erweiterung in der Verlängerung Sammlung an system.serviceModel/extensions/behaviorExtensions registriert ist ...

Nach einer halben Stunde verbringen Sie im Internet nach möglichen Ursachen suchen ich Räume auf den vollständig qualifizierten Montagenamen hinzugefügt. So habe ich es zu:

<behaviorExtensions> 
    <add name="errorBehavior" type="MyNs.TracingErrorBehaviorElement, MyNs, 
     Version=1.0.6.0, Culture=neutral, PublicKeyToken=null" /> 
</behaviorExtensions> 

(Siehe den Raum: MyNs.TracingErrorBehaviorElement, MyNs)

und es funktionierte.

Weiß jemand, warum es ohne Platz auf einigen Maschinen und nicht auf anderen Geräten funktioniert? Ich überprüfte die .Net-versions. Sie passten zusammen. Könnte es durch regionale Einstellungen verursacht werden?

bearbeiten sagt:

ich die gebrauchten .Net-Versionen auf allen Maschinen überprüft und sie sind alle gleich: .Net 4.0 Aber ich finde einen Unterschied zwischen der Maschine, wo ich den Fehler mit einem fehlenden blank erhalten und die anderen Maschinen, wo es funktioniert: Alle Maschinen, auf denen es ohne das Leerzeichen funktioniert, haben .Net Framework 4.5 installiert. Es könnte also einer dieser Fehler sein, die in 4.0 behoben und mit 4.5 bereitgestellt wurden, oder?

Answer 1

Dies ist ein bekannter Fehler, dokumentiert in this blog post von Shawn Cicoria.

Es sagt nichts über genau, wann der Fehler behoben wurde, die WCF-Config-Klassen sind zu verschachtelt, um es einzugrenzen. Ich würde erraten, angesichts des Alters des Beitrags, dass dies eine .NET 4.5-Lösung ist. Bei einem Fehler auf der Client-Site aufgrund der 4.0-Installation. Sie würden besser von dem Ziel wissen, das Sie für Ihr Projekt ausgewählt haben.

Ansonsten eine gute Demonstration, wie schwierig es für Microsoft ist, Bugs jemals zu beheben.

Answer 2

Nun, die MSDN sagt:

Spaces in allen Typnamen Komponenten außer den Namen der Assembly relevant sind. Im Assemblynamen sind Leerzeichen vor dem Trennzeichen ',' relevant, Leerzeichen nach dem Trennzeichen ',' werden jedoch ignoriert.

Tatsächlich zeigen Tests, dass dies in der Tat der Fall ist - GetType und andere Typ Auflösung Methoden wirklich Räume ignorieren nach der , Separator.

Allerdings kompliziert WCF dies irgendwie, weil es tatsächlich erfordert den voll qualifizierten Typ Name genau den Wert sein, den Sie aus irgendeinem Grund aus Type.AssemblyQualifiedName erhalten. Vielleicht hält es irgendwo einen Cache von Typen, ich weiß es nicht.

Warum dies nur auf einigen Rechnern passiert, würde ich entweder auf den GAC oder ein anderes System setzen, das die Auflösung der Baugruppen/Typen geringfügig ändert. Da Sie kein snk verwenden, kommt GAC nicht in Frage, aber vielleicht gibt es eine Konfiguration, die das für Sie ändert, vielleicht in der machine.config oder wenn es in einer Webanwendung in der IIS-Konfiguration ist.

Es scheint, dass dies ein Konfigurationsfehler in .NET 3.5 ist. .NET 4.0+ hat nicht das gleiche Problem. Sind Sie sicher, dass die Anwendung dieselbe Version von .NET ausführt? Dies kann sehr wohl der Unterschied sein, wenn Sie mit einer Webanwendung arbeiten (der Server des Kunden ist sehr gut für die Verwendung von .NET 3.5 konfiguriert, Sie sollten system.web.compilation[targetFramework] und httpRuntime angeben, um die richtige Framework-Version zu erreichen würde einen Link zu dem Fehler hinzufügen, aber während es in vielen Orten referenziert wird, scheint der Artikel aus MS Connect seit :)