Änderung des System.Uri.ToString-Verhaltens nach Installation von VS2012

Question

Nach der Installation von VS2012 Premium auf einem Dev-Computer ist ein Komponententest fehlgeschlagen, sodass der Entwickler das Problem behoben hat. Wenn die Änderungen an TeamCity übertragen wurden, ist der Komponententest fehlgeschlagen. Das Projekt hat sich nicht geändert, außer dass die Lösungsdatei aktualisiert wurde, damit sie mit VS2012 kompatibel ist. Es zielt immer noch. NET Framework 4.0

Ich habe das Problem auf ein Problem mit Unicode-Zeichen, die beim Aufruf Uri.ToString aufgerufen werden. Der folgende Code repliziert das Verhalten.

Imports NUnit.Framework 

<TestFixture()> 
Public Class UriTest 

    <Test()> 
    Public Sub UriToStringUrlDecodes() 
     Dim uri = New Uri("http://www.example.org/test?helloworld=foo%B6bar") 

     Assert.AreEqual("http://www.example.org/test?helloworld=foo¶bar", uri.ToString()) 
    End Sub 

End Class 

dies auf einer Maschine in VS2010 ausführen, die nicht VS2012 nicht installiert gelingt, mit VS2012 dies in VS2010 auf einem Computer ausgeführt wird installiert ausfällt. Beide verwenden die neueste Version von NCrunch und NUnit von NuGet.

Die Nachrichten aus dem ausgefallenen assert sind

Expected string length 46 but was 48. Strings differ at index 42. 
    Expected: "http://www.example.org/test?helloworld=foo¶bar" 
    But was: "http://www.example.org/test?helloworld=foo%B6bar" 
    -----------------------------------------------------^ 

Die Dokumentation auf MSDN sowohl für .NET 4 und .NET 4.5 zeigt, dass ToString sollte dieses Zeichen nicht kodieren, was bedeutet, dass das alte Verhalten das richtige sein sollte.

A String instance that contains the unescaped canonical representation of the Uri instance. All characters are unescaped except #, ?, and %. 

Nach der Installation von VS2012 wird dieses Unicode-Zeichen mit Escapezeichen versehen.

Die Dateiversion von System.dll auf der Maschine mit VS2012 ist 4.0.30319.17929

Die Dateiversion von System.dll auf dem Build-Server 4.0.30319.236

Ignoriert die Verdienste, warum wir sind mit uri.ToString(), was wir testen und jede mögliche Arbeit um. Kann jemand erklären, warum sich dieses Verhalten geändert hat, oder ist das ein Fehler?

bearbeiten, hier ist die C# -Version

using System; 
using NUnit.Framework; 

namespace SystemUriCSharp 
{ 
    [TestFixture] 
    public class UriTest 
    { 

     [Test] 
     public void UriToStringDoesNotEscapeUnicodeCharacters() 
     { 
      var uri = new Uri(@"http://www.example.org/test?helloworld=foo%B6bar"); 

      Assert.AreEqual(@"http://www.example.org/test?helloworld=foo¶bar", uri.ToString()); 
     } 

    } 
} 

Ein bisschen eine weitere Untersuchung, ob ich .NET 4.0 oder .NET 4.5 die Tests fehlschlagen Ziel, wenn ich es auf .NET 3.5 und schalten es gelingt.

Answer 1

Die Änderung bezieht sich auf Probleme mit früheren .NET-Versionen, die jetzt geändert wurden, um mehr den Standards zu entsprechen. %B6 ist UTF-16, aber gemäß den Standards UTF-8 sollte in der Uri verwendet werden, was bedeutet, dass es %C2%B6 sein sollte. So wie %B6 nicht UTF-8 ist, wird es jetzt korrekt ignoriert und nicht decodiert.

Weitere Details aus dem connect report im Folgenden wörtlich zitiert.

.NET hat eine erweiterte und kompatiblere Anwendung von RFC 3987 , die IRI-Parser-Regeln für URIs unterstützt. IRIs sind internationale Resource Identifiers. Dadurch können Nicht-ASCII-Zeichen in einer URI/IRI-Zeichenfolge analysiert werden.

Vor .NET 4.5 hatten wir einige inkonsistente Behandlung von IRIs. Wir hatten eine app.config Eintrag mit einem Standardwert von falsch, dass Sie einschalten könnte:

die einige IRI tat Handhabung/Parsing. Es hatte jedoch einige Probleme. In insbesondere erlaubt es für die falsche prozentuale Codierung Handhabung. Prozentcodierte Elemente in einer URI/IRI-Zeichenfolge sollen prozentcodierte UTF-8-Oktetts gemäß RFC 3987 sein. Sie werden nicht als interpretiert, die als prozentcodiertes UTF-16 interpretiert werden. Daher ist die Behandlung von "% B6" gemäß UTF-8 inkorrekt und es findet keine Decodierung statt. Die korrekte UTF-8 Kodierung für ¶ ist tatsächlich "% C2% B6".

Wenn Ihr String war dies statt:

 string strUri = @"http://www.example.com/test?helloworld=foo%C2%B6bar"; 

Dann wird es normalisiert bekommen in der ToString() -Methode und die Prozent-Codierung decodiert und entfernt.

Können Sie weitere Informationen über Ihre Anwendungsanforderungen und die Verwendung der ToString() - Methode bereitstellen? Normalerweise empfehlen wir die Eigenschaft AbsoluteUri des Uri-Objekts für die meisten Normalisierungsanforderungen.

Wenn dieses Problem Ihre Anwendung Entwicklung und Geschäft Bedürfnisse blockiert dann bitte informieren Sie uns über die "netfx45compat at Microsoft dot com" E-Mail-Adresse.

Thx,

Networking-Team

Answer 2

In dieser Situation können Sie nicht so tun. Das Hauptproblem ist das Zeichen "¶".

In .Net haben wir ein Problem mit dem Zeichen ¶. Sie können darüber Nachforschungen anstellen.

Nehmen Sie die uri Parameter nacheinander. Fügen Sie sie durch eins hinzu und vergleichen Sie sie. Möglicherweise können Sie eine Methode für "¶" Zeichen verwenden, um es zu erstellen oder zu ersetzen.

Zum Beispiel;

Dim uri = New Uri("http://www.example.org/test?helloworld=foo%B6bar") 

Assert.AreEqual("http://www.example.org/test?helloworld=foo¶bar", uri.Host+uri.AbsolutePath+"?"+uri.Query) 

die

uri.AbsolutePath arbeiten werden:/test

url.Host: http://www.example.org

uri.Query: Hello World = foo¶bar

Answer 3

Es gibt einige in .NET Framework eingeführt Änderungen 4.5, die zusammen mit VS2012 installiert ist, und die auch (nach bestem Wissen und Gewissen) ein sogenanntes "In-Place-Upgrade". Dies bedeutet, dass es tatsächlich aktualisiert .NET Framework 4.

Darüber hinaus gibt es breaking changes documented in System.Uri. Einer von ihnen sagt Unicode Normalisierung Form C (NFC) wird nicht mehr auf Nicht-Host-Teile von URIs durchgeführt werden. Ich bin mir nicht sicher, ob dies für Ihren Fall zutrifft, aber es könnte ein guter Ausgangspunkt für Ihre Untersuchung des Fehlers sein.