XMLSerializer在TeamCity上產生不同的結果

我們爲TeamCity添加了一個傳統解決方案。其中一個單元測試現在失敗了，儘管它在本地通過。XMLSerializer在TeamCity上產生不同的結果

單元測試檢查來自XmlSerializer的實際輸出字符串是否如預期。

string expectedXmlText = File.ReadAllText("TestFile.xml"); 
objectToSerialize = ...; 

string actual = UtilsClass.SerializeObject(objectToSerialize); 

Assert.That(xmlText, Is.EqualTo(expectedXmlText));

在TeamCity的失敗，消息如下：

Test(s) failed. String lengths are both 476. Strings differ at index 59. 
    Expected: "..."utf-16"?>\r\n<Envelope xmlns:xsi="http://www.w3.org/2001/XM..." 
    But was: "..."utf-16"?>\r\n<Envelope xmlns:xsd="http://www.w3.org/2001/XM..."

注意，命名空間不同，一個具有的xsi開始並以XSD一個開始。

現在我意識到XML在兩種情況下都是有效的，adn代表同樣的事情。我也意識到你不應該編寫依賴XML中命名空間順序的代碼。

問題

什麼是測試一個XmlSerializer的輸出正確的方法，是是錯誤的檢查輸出文本？
爲什麼XMLSerializer會以不同的順序返回命名空間？

來源

2017-01-31 openshac

從Inconsistent Namespace Order using XmlSerializer on x86/x64

的命名空間集合只是一個內部字典。它返回值的順序是不確定的，理論上每次調用它時都會改變。字典排序沒有韻律或理由。如果你需要一致的排序，那麼你必須切換到SortedDictionary和朋友。

更具體地說，XmlSerializerNamespaces在內部使用一個Hashtable，它根據字典和哈希碼中已經存在的內容計算項目的放置位置。實際上，Hashtable會根據插入時發生多少次碰撞來定期重建字典。這是在類型的MSDN信息中記錄的。

即使對於同一個實例，也沒有關於字典排序的保證，因爲字典（或本例中的散列表）可以重新排序項目以提高性能。通常我們希望看到單個實例甚至跨機器的一致行爲，但沒有保證。

來源

2017-01-31 18:08:37 stuartd

居然有人建議避免使用string對象的實際使用中的XML對象從反序列化（無論是從LINQ到XML的XDocument或從System.Xml核心庫的XmlDocument ）。

有一篇很好的文章介紹Fluent斷言的特徵，它也展示了一些例子：Unit testing XML Generation

來源

2017-02-01 08:44:23 arobin

XMLSerializer在TeamCity上產生不同的結果

回答

相關問題