用于生成模糊NuGet包的工作流

我们一直在分解我们的.NET应用程序，以便在多个解决方案中使用的项目被构建并作为NuGet包使用。其中一些项目需要进行模糊处理（我们使用eazfouscator），我不确定正确的工作流程应该是什么

现在，我们的CI流程编译代码，运行检查，并运行自动单元测试。这很有效。但是，如果我在每个构建中引入混淆，我将不得不打破依赖于使用

内部visibletoattribute

的单元测试。我可以运行现有的流程，然后假设一切正常（编译，没有引入检查错误，并且单元测试通过），为不同的配置进行后续构建，这些配置可能会被混淆。但是我并没有完全测试那些模糊的代码

你的店有什么用

另外，我还没有尝试过，但是通过NuGet交付的模糊程序集是否会降低设置符号服务器的有用性？调试情况如何

注意：这些软件包都是供内部使用的，直到我们找到提供给客户的消费应用程序为止，这就是为什么我想在软件包中进行调试

2016年12月12日更新

我们最终使用的工作流是生成服务器：

正常编译

运行单元测试和检查

再次编译-这一次，传入一个参数，启用条件编译符号

OBFUSCATE

• 现在，

  InternalsVisibleToAttribute

  将被抑制（以及我们引用内部的任何测试）

发布到我们的内部提要

此更改和另一项更改（包括

ObfuscateAsemblyAttribute

将导致程序集被标记为在生成消费应用程序时进行适当的模糊处理）。该构建任务执行实际的模糊处理

我对此不是100%满意，但这意味着我们没有使用多个构建配置

---

不过，我仍然对其他人正在做的事情感兴趣。

我们使用.net加密模糊器，需要一段时间才能将其集成，您需要启用发送错误功能，因为客户端将收到错误。。。该包允许在所有级别和所有类型/子类型上进行详细配置。删除调试器步骤，通过选项等，但超级权力来努力。使用GitHub上提供的开源反编译器，EAZfouscator相对容易反转