以編程方式檢查統一容器類型註冊

我使用統一容器來解析應用程序內的依賴關係。以編程方式檢查統一容器類型註冊

依賴關係及其依賴關係（等等）在app.config中註冊，因爲我需要能夠改變應用程序在生產中的行爲方式。

有時候，錯過了依賴關係的類型註冊，只有在應用程序的生命週期中解析類型的實例時纔會發現這一點，這意味着可能存在一些問題，只能在集成測試期間收集 - 這並不理想。

我希望能夠以編程方式檢查（可能作爲CI構建過程的一部分）統一類型註冊已正確完成。通過這個我的意思是，如果我解決了一個類型的實例，我可以確信該類型的依賴關係（通過構造函數注入）也被註冊並將被解析。

我只需要檢查默認的內置配置，這裏對活動網站所做的更改不作考慮。另外 - 我不想使用硬編碼的統一註冊。

我能想到此刻這樣做的唯一方法是分析的統一配置文件，並嘗試解決發現的該類型的每個實例...

是否有驗證團結註冊更簡單的方法都存在嗎？

來源

2016-05-10 Jay

至於

我希望能夠以編程方式檢查（可能爲CI 構建過程的一部分）團結類型註冊已經正確地進行。我的意思是，如果我解析一個類型的實例，我可以確信該類型的依賴關係（通過構造函數注入）也被註冊並將被解析。

我們在我們的一個項目中遇到了同樣的情況，最後編寫集成測試並閱讀Unity.config，然後查找註冊類型爲字符串的對象。非常相似的方法介紹如下 https://blogs.msdn.microsoft.com/miah/2009/04/03/testing-your-unity-xml-configuration/

的問題，這是你必須保持登記和測試，但是這是可以驗證所有類型的註冊是否正確的唯一途徑。

簡單地比較xml與期望值比重新註冊所有類型（基於您的配置）並在測試中解析它們更有效。

來源

2016-05-10 23:31:03 Spock

我使用團結，經常面臨這個問題。

您可以編寫一個應用程序，它使用反射來獲取構造函數參數。像這樣： ConstructorInfo.GetParameters（）;並遞歸地獲取每個返回的參數的構造函數參數。如果你將這個清單區分開來，那至少會給你一個應該註冊的預期類型清單。

希望這會有所幫助。

來源

2016-05-17 19:40:50 Fish

這聽起來像個好主意。你有一個例子嗎？ – Jay

這個單元測試似乎足以驗證我的配置到目前爲止。按照https://msdn.microsoft.com/en-us/library/dn507504(v=pandp.30).aspx的說明，我能夠加載我的容器並驗證所有註冊已解決。

[TestMethod] 
    public void TestContainer() 
    { 
     IUnityContainer container = new UnityContainer().LoadConfiguration(); 
     foreach (var registration in container.Registrations) 
     { 
      Assert.IsNotNull(container.Resolve(registration.RegisteredType, registration.Name)); 
     } 
    }

來源

2017-07-12 22:00:53 Thorb

以編程方式檢查統一容器類型註冊

回答

相關問題