2012-08-17 31 views
18

Bir dev makine üzerinde VS2012 Premium yüklendikten sonra birim sınaması başarısız oldu, bu nedenle geliştirici sorunu giderdi. Değişiklikler TeamCity'ye aktarıldığında, birim testi başarısız oldu. Proje, VS2012 ile uyumlu olacak şekilde yükseltilmekte olan çözüm dosyası dışında değişmedi. Yine de, Uri.ToString numaralı telefonu arayarak unicode karakterleri kaçınılan bir soruna sorunu çözdüm. Aşağıdaki kod, davranışı çoğaltır. VS2012 yüklü olmayan bir makinede VS2010 bu RunningSystem.Uri.ToString davranışı, VS2012 yüklendikten sonra değişiklik

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 

başarısız yüklü VS2012 ile bir makinede VS2010 bu çalışan yerine geldi. Her ikisi de NuGet'in en son NCrunch ve NUnit versiyonunu kullanıyor. Başarısız assert gelen

Machine without VS2012 Install

Machine with VS2012 Install

mesajlar,

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" 
    -----------------------------------------------------^ 

hem .NET 4. ve .NET 4.5 için MSDN üzerine dokümantasyon ToString bu karakteri kodlamak gerektiğini göstermektedir vardır eski davranışın doğru olanı olması gerektiği anlamına gelir.

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

VS2012'yi yükledikten sonra, bu unicode karakteri kaçıyor.

VS2012 ile makinede System.dll dosya sürüm yapı sunucuda System.dll dosya sürümü biz neden yararları göz ardı edilmesi 4.0.30319.236

olduğunu 4.0.30319.17929

olduğunu uri.ToString() kullanarak, neyi test ediyoruz ve etrafta potansiyel bir çalışma var. Herkes bu davranışın neden değişmiş olduğunu açıklayabilir mi, yoksa bu bir hata mıdır? Ben Başarılı sonra .NET 3.5 bunu geçerseniz ben, .NET 4.0 veya .NET 4.5 testin başarısız hedeflerseniz

Düzen, burada, C# sürümü

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()); 
     } 

    } 
} 

fazla araştırma Biraz olduğunu.

+0

Ben mantık yanlış bir şey yapıyorum ve orada .NET bir hata olmayacak, ama sadece işe olamayacağını dikte farkındayım

Ağ Takımı Bunun neden olduğu ortaya çıktı. –

+0

Muhtemelen 'bool check = @ "http://www.example.org/test?helloworld=foo¶bar" == uri.ToString(); 'false, değil mi? – t3hn00b

+0

Evet, yanlış olan –

cevap

6

Değişiklik, standartlara daha uyumlu hale gelmek üzere değiştirilmiş olan önceki .NET sürümleriyle ilgili sorunlarla ilgilidir. %B6, UTF-16'dır, ancak standartlara göre UTF-8, Uri'de kullanılmalıdır, yani %C2%B6 olmalıdır. %B6'un UTF-8 olmadığı için, artık doğru bir şekilde göz ardı ediliyor ve kodu çözülmez.

connect report'dan daha ayrıntılı bilgiler aşağıdaki verbatim'e bakınız.

.NET 4.5 geliştirilmiş ve URI'nın en için IRI ayrıştırma kuralları destekleyen RFC 3987 daha uyumlu uygulama olmuştur. IRI'ler Uluslararası Kaynak Tanımlayıcılarıdır. Bu, ASCII olmayan karakterlerin ayrıştırılması için URI/IRI dizesinde olmasını sağlar. .NET 4.5'den önce, IRI'ların bazı tutarsız işlemlerini gerçekleştirdik.

bazı IRI kullanımı/ayrıştırılmasını yaptı: Biz açtığınızda ki yanlış bir varsayılan bir app.config girişi vardı. Ancak, bazı problemleri vardı. Özellikle 'da yanlış yüzde kodlama işleme için izin verilir. Bir URI/IRI dizesindeki yüzde kodlanmış öğelerin RFC 3987'ye göre yüzde olarak kodlanmış UTF-8 sekizli olması gerekir. Bunlar, yüzde kodlanmış UTF-16 olarak yorumlanan değildir. Bu nedenle, “% B6” işleminin yapılması UTF-8'e göre hatalıdır ve kod çözme gerçekleşmez. Enco için kodlayan doğru UTF-8 aslında “% C2% B6” dır.

dize yerine bu olsaydı:

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

Sonra ToString() yöntemi ve deşifre ve kaldırılan yüzde kodlamada normalize alacak.

Uygulama gereksinimleriniz ve ToString() yönteminin kullanımı hakkında daha fazla bilgi verir misiniz? Genellikle, normalleştirme gereksinimlerinin çoğu için Uri nesnesinin AbsoluteUri özelliğini öneririz.

Bu sorunun uygulama geliştirme ve daha sonra ihtiyacı bize e-posta adresine "Microsoft nokta com netfx45compat" aracılığıyla bizi bilgilendirin iş engelliyorsa.

Thx,

0

Bu durumda böyle yapamazsınız. Ana konu "¶" karakteridir.

In. Net'de karakter problem ile ilgili bir sorun var. Bunun hakkında bir araştırma yapabilirsiniz.

uri 'parametrelerini tek tek alın. Bunları birer birer ekleyin ve karşılaştırın. Oluşturmak veya değiştirmek için "¶" karakteri için bir yöntem kullanabilirsiniz.

Örneğin;

uri.AbsolutePath çalışacağız

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) 

:/test

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

uri.Query: helloworld = foo¶bar

+0

VS2012'yi yüklemeden önce çalıştı ve MSDN belgelerine göre çalışmalıdır. Çevremdeki bir işte ilginç değilim - bu basit, neden artık işe yaramadığını merak ediyorum. –

8

Orada VS2012 ile birlikte yüklü olan .NET Framework 4.5, tanıtılan bazı değişiklikler vardır ve (benim en iyi bildiğim için) de olduğu bir "yerinde yükseltme" denir. Bu, aslında .NET Framework 4.

'u yükseltmesi anlamına gelir, ayrıca breaking changes documented in System.Uri vardır. Bunlardan biri Unicode normalizasyon formu C (NFC) artık URI'ler'un host olmayan kısımlarında uygulanmayacağını söylüyor. Bunun sizin durumunuz için geçerli olup olmadığından emin değilim, ancak hatayı araştırmanızda iyi bir başlangıç ​​noktası olabilir.

+0

İlginç, neden değiştiğini açıklıyor - bu kırılma değişikliklerinden birinin bir yan etkisi olabilir, şimdiye kadar bağlantı yoluyla bir yanıt almayı umuyordum ama şans yok. –

+0

Ancak iyi nokta, "Bu yalnızca .NET Framework 4.5'ü hedefleyen uygulamaları etkiler." – Justin

İlgili konular