C# 中的条件编译hackery - 有没有办法解决这个问题？答案

【问题标题】：Conditional compilation hackery in C# - is there a way to pull this off?C# 中的条件编译hackery - 有没有办法解决这个问题？
【发布时间】：2011-02-18 17:35:29
【问题描述】：

我有一个内部 API，我希望其他人在他们的项目中将其作为已编译的 DLL 引用。当它是引用的独立项目时，我使用条件编译（#if 语句）根据编译符号切换关键 Web 服务类的行为。问题是，一旦生成了一个程序集，它似乎被锁定在最初编译时的任何编译符号中 - 例如，如果这个程序集是用 DEBUG 编译的并且被另一个项目引用，即使另一个项目是作为 RELEASE 构建，程序集仍然像在 DEBUG 中一样运行，因为它不需要重新编译。这是有道理的，只是提供一些背景知识。

现在我正在尝试解决这个问题，以便可以通过其他方式切换程序集的行为，例如扫描 app/web 配置文件以查找开关。问题是，我在其中切换的一些程序集代码是方法的属性，例如：

#if PRODUCTION
        [SoapDocumentMethodAttribute("https://prodServer/Service_Test", RequestNamespace = "https://prodServer", ResponseNamespace = "https://prodServer")]
#else
        [SoapDocumentMethodAttribute("https://devServer/Service_Test", RequestNamespace = "https://devServer", ResponseNamespace = "https://devServer")]
#endif
        public string Service_Test()
        {
            // test service
        }

虽然可能有一些语法糖允许我以另一种方式在相同类型的两个属性之间切换，但我不知道。有什么想法吗？

替代方法是引用整个项目而不是程序集，但如果可以的话，我宁愿坚持只引用已编译的 DLL。如果需要的话，我也完全愿意采用一种全新的方法来解决问题。

【问题讨论】：

标签： c# conditional-compilation

【解决方案1】：

问题是，#if 语句仅在编译期间运行。一旦你有一个编译的程序集 - 它会坚持它有什么.. 其余的代码从程序集中被剥离:)

如果您希望测试/生产的 URL 不同，您应该创建一个源自 SoapDocumentMethodAttribute 的新属性，并根据您的 AppSetting 值设置这些值:)

【讨论】：

不错的方法。除了... SoapDocumentMethodAttribute 是密封类。

【解决方案2】：

您不需要这样做。这些 URL 不是“真正的” URL——它们不代表 Internet 上的位置。它们仅用于使名称独一无二。

您应该为 dev 使用与 production 相同的命名空间名称。

【讨论】：

它们必须与它所调用的服务上的服务方法的命名空间相匹配吗？
不，他们不必这样做，但他们可以。这一切都是为了使名称明确。如果您的操作（方法）名称与类型名称相同，那么您希望使用不同的命名空间，以便命名空间+本地名称是唯一的。
太好了，感谢您的指导——我想我会先走这条路，并首先消除我对 XML 命名空间的无知。不能以一种或另一种方式伤害！
到目前为止，我一直在抱怨无法识别带有我任意提供的命名空间的 HTTP SOAPAction，但仍然在破解它。

【解决方案3】：

好吧，好吧 - 首先，显然条件编译在编译后仍然存在。你到底是怎么得到这个想法的？这是一个条件编译。

您可以通过反射修复的属性 - 您可以“覆盖”反射以在那里返回您自己的信息。这很棘手，但它是可能的（同样的方式你可以将属性“注入”到反射代码中）。不过，我不确定我是否希望这种情况发生。基本上......你应该得到类似服务器 URL 的东西，而不是来自反射，而是来自配置文件。错误的方法，我会说。

【讨论】：

+1 用于配置文件！但是您只能为此使用 const。
是的，当我意识到我正在走这条路时，条件编译是一个“哦，该死，呃”的时刻。我会考虑反思，如果需要的话，我不害怕走那条路。我的理解是填充属性的字符串必须是 consts - 如在运行时无法从配置文件中读取，因此有条件切换。不过，我很想在这一点上犯错。
这个答案可以通过不那么粗鲁来改善