依赖注入和代码混淆 [英] Dependency Injection and Code Obfuscation

问题描述

在 Mark Seemann 的书中 .NET 中的依赖注入，他指出越来越多的人正在使用具有 AUTO-REGISTRATION 支持的 DI 容器，其中容器可以在几乎没有任何类型的事先配置的情况下解析所需的具体类型的实例，这与约定优于配置架构方法的做法相得益彰.但这让我想知道如果我使用混淆器会不会破坏代码库并导致容器失败，因为约定已经改变?

In Mark Seemann's book Dependency Injection in .NET, he states that more people are using DI containers with AUTO-REGISTRATION support where the container can resolve instances of the required concrete types without almost any sort of prior configuration, and this goes well with the convention over configuration architecture approach. but this made me wonder if i used an obfuscator wouldn't this break the code base and cause the container to fail because the conventions have changed ?

推荐答案

您通常仍然可以使用依赖项注入，即使您以混淆方式发送应用程序程序集.这会起作用，因为您通常会使用泛型类型(例如 Register())或 typeof 参数(例如 Register(typeof(IService), typeof(Impl))) 来注册类型.换句话说，编译器可以为您检查的所有内容仍然有效(当混淆器正常工作时).

You can typically still use dependency injection, even if you ship your application assemblies in an obfuscated way. This will work, because you would typically use generic typing (such as Register<IService, Impl>()) or typeof arguments (such as Register(typeof(IService), typeof(Impl))) to register types. In other words, everything the compiler can check for you will still work (when the obfuscator works correctly).

您应该密切注意的是编译器无法检查的所有内容.事情如:

What you should watch closely is everything the compiler can't check. Things as:

• 通过使用字符串文字指定参数的名称来覆盖构造函数参数.
• 任何基于名称而不是类型信息的配置方法的转换，例如 将构造函数参数的名称后缀为AppSetting"或ConnectionString"，期望所有类型的名称都以Controller"结尾，期望类型位于特定的命名空间中.

• Override constructor arguments by specifying the name of the argument using a string literal.
• Any convension over configuration approach where the convension is based on a name instead of type information, such as postfixing the name of constructor arguments with "AppSetting" or "ConnectionString", expecting the name of all types to register end with "Controller", expecting types to be in a particular namespace.

因此，您必须仔细观察这些问题.不要忘记通过创建可验证的来保护自己配置，在您的情况下，我会在应用程序启动时验证此配置(或添加命令行开关，以便应用程序可以进行自检).

So you will have to watch these issues carefully. Don't forget to safeguard yourself by creating a verifiable configuration and in your case I would verify this configuration on application startup (or add a command line switch so that the application can do a self-check).

这篇关于依赖注入和代码混淆的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！