由于服务器兼容性问题（Windows Server 2000和Windows Server 2003生产服务器），我们有一个需要为.Net 1.1和2.0构建的项目。我正在寻找帮助在条件编译之间作出决定或在源代码控制中分支代码。各有利弊。提前谢谢。
答案 0 :(得分：9)
影响我的解决方案的一件事是知道我希望1.1解决方案能够存活多久以及它的目的是什么。如果解决方案处于维护模式并且实际上不会添加太多新功能，我会选择一个单独的分支解决方案。然后，我会仔细地在两个分支之间迁移所需的更改。
但是，如果它是一个完整的版本，将具有大多数（如果不是全部）相同的功能，那么我将使用条件编译路径。否则，您所做的每一次检查都必须在完成之前合并到另一个分支。
答案 1 :(得分：5)
您有多种选择：
答案 2 :(得分：2)
我要添加的唯一内容是，如果你进行分支，请尽早并经常合并你的更改。有一个人负责合并。合并大量产品是痛苦的，合并少量通常并不是那么糟糕。
答案 3 :(得分：1)
条件编译只会给你带来麻烦。条件编译使用#IFDEF宏填充代码。它暗示程序员在不存在的情况下强制抽象。假设您想创建一个泛型类，现在您想使它与.NET 1兼容，因此您可以在所有强制转换操作中使用ifdef。你要咬的子弹是在两个分支中修复问题（如果有的话），希望你没有写出太多错误：）
分支允许您选择使用共享程序文本文件.CS来自两个不同的解决方案，针对不同平台，在.NET 1和2之间没有区别。
答案 4 :(得分：0)
绝对应用条件编译而不是分支（并尽可能将其隔离到特定模块中）。
分支意味着如果您在代码的不相关部分（即独立于.Net版本的代码）中发现了错误，则必须在两个分支上修复它。如果你不需要，不要走那条路。
我更喜欢使用抽象基类（ABC）来定义接口和特定于平台的派生类，与工厂对象/方法和整个文件条件编译一起解决这些问题（我有一个可以通过这种方式实现Win32和X11的GUI库。
无偿分支从来都不是一件好事！
答案 5 :(得分：0)
分支通常是一场噩梦（重复的努力和合并问题比比皆是）。恕我直言，它应该只用于你永远不会期望与主分支保持同步的死端分支（即你不期望对旧分支进行许多更改，也许只有主要的最关键的错误修复）分支）。
条件编译允许您在代码中“并排”查看差异，当您开始在#if中更改某些内容时，您也需要考虑#else部分。