以编程方式检查统一容器类型注册

我使用统一容器来解析应用程序内的依赖关系。以编程方式检查统一容器类型注册

依赖关系及其依赖关系（等等）在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

以编程方式检查统一容器类型注册

回答

相关问题