方法名称是否编译到EXE中？

在将 Windows应用程序项目编译为EXE后，类，方法和变量名称是否包含在MSIL中 ？

例如，如果通过名称调用方法：

是的，他们在IL – 启动reflection器，你会看到它们。如果他们没有最终进入IL，你就无法将它们作为库来构建。（是的，您可以引用.exe文件，就好像它们是类库一样。）

但是，这在JIT中都解决了一次。

保持名称可读，以便将来能够维护代码。性能问题不太可能产生任何可衡量的差异，如果你想混淆你的代码，不要在源代码级别（你是那个读代码的那个）做它 – 用专门的方法来做混淆。

编辑：至于包括什么 – 为什么不启动Reflector或ildasm并找出？从内存中，您丢失了本地变量名称（如果您构建它，它们位于pdb文件中），但这就是它。私有方法名称和私有变量名称仍然存在。

是的，他们这样做。我不认为使用较短的名称会有显着的性能提升。这种收获无法克服可读性的损失。

MSIL中不包含局部变量。字段，方法，类等。变量是基于索引的。

成员名称确实包括在IL中，无论他们是私人还是公共。事实上，所有代码都包含在内，如果您使用Reflector，您几乎可以阅读应用程序的所有源代码。剩下的就是调试应用程序，我认为可能有这样的工具。

如果您正在制作具有大量客户端和竞争对手的打包应用程序，那么您必须绝对（并且我不能再强调它）混淆您的代码。幸运的是，有许多混淆器可用。

这是我与.Net的一个主要抱怨。由于MS在这方面做了很多努力，为什么不开发（或获得）专业的混淆器并使其成为VS的一部分。 Dotfuscator不会削减它，而不是它们用于社区的版本。

保持名称简短，更好的命名查找性能。

这有什么不同呢？我不确定VM如何查找标识符，但我很确定它没有进行直接字符串比较查找。这将是最糟糕的方式。

保持名称神秘，反编译更难。

说实话，我认为代码混淆对此没有多大帮助。大多数有能力的开发人员已经开发了一种“第六感”来快速找出问题，即使像方法名这样的标识符完全无用，因为他们需要维护或改进的源代码已经存在这些问题（我说的是方法名称）比如“DoAllStuff（）”。

无论如何， 通过默默无闻的安全通常是一个坏主意 。

如果您担心混淆，请查看.NET Reactor。我测试了8种不同的混淆器，Reactor不仅是最便宜的商用，它是第二好的（最好的是最昂贵的，Dotfuscator Gold）。

[编辑]

实际上现在我想到了，如果你关心的是混淆方法名称，那么VS.NET，Dotfuscator Community Edition附带的那个应该可以正常工作。

我认为它们已被添加，但名称的长度不会影响任何内容，因为查找函数名称的方式。至于混淆，我认为有一些工具（Dotfuscator或类似的东西）基本上完全按照你所说的去做。