首先我要说的是，自从大学的Java（我于2005年12月毕业）以来，我没有用大量的OO编程语言进行编程。自从我毕业以来，我一直在使用FoxPro 2.5 - VFP9进行编程。现在，我工作的公司正在推动将我们所有的FoxPro应用程序转换为C＃。
我的这个项目的一部分是转换我们的报告解析应用程序。在VFP9中，它由5-6个表单组成（我们创建了一个新的C＃前端来替换它，但没有一个表格会被转移），一个 Base 类包含我们所有的标准方法，以及大约575个单独的解析器类（其中一些除了设置一些解析器特定的变量/属性并调用所需的基类之外什么都不做）。一些解析器包含自己的自定义方法，这些方法仍然使用基本方法和全局属性并与之交互。
现在我的问题......
从设计的角度来看，我们希望新的C＃前端能够生成多个可执行文件（3-5个EXE），这些可执行文件将调用我们新的C＃基类/解析器类库（DLL）。我最初的想法是，我将有一个解决方案/项目与Base_Code.cs和其他575 parser.cs文件（H1.cs，H2.cs，H3.cs等）。但是，我们需要能够独立构建每个.cs文件，因为我可能在我的同事更新H1.c时更新Base_Code.cs。
我如何最好地构建这个？我是否保留一个解决方案，但创建了576个项目，还是创建了576个解决方案，所有这些解决方案都使用与另一个团队目前正在尝试的相同的命名空间？
我们在整个基本代码和每个解析器中使用了几个全局变量/属性（这些将从前端应用程序传入），如文件路径，文件名等，这些都是静态的，所以这需要在考虑设计时也要考虑到这一点。
编辑示例 **
C＃前端基本上是一个排队系统和文件/状态查看器。这个前端“排队”我们全天收集的报告。列表顶部的报告确定需要什么DLL。前端应用程序和DLL是完全分开的。
示例：H00001_2342318.MSG - 这将调用H00001 DLL H00002_3422551.MSG - 这将调用H00002 DLL
每个H00001，H00002等（总共575个DLL）将使用BASE DLL中的方法。
如果我必须更新H00001 DLL，我需要这样做而不必重建所有575个DLL。
答案 0 :(得分：0)
听起来你想要的是一种“插件”式的架构。这使您可以在不重新编译主应用程序的情况下放入/更新dll（程序集）。
E.g。 http://code.msdn.microsoft.com/windowsdesktop/Creating-a-simple-plugin-b6174b62
和相关。
答案 1 :(得分：0)
576个项目和/或解决方案是维护的噩梦。对于整套产品，我在十几个解决方案中的项目少得多（75个左右）。这包括测试，框架组件等，我唯一的方法是通过严格的命名/路径约定，源代码控制和自动化脚本。
说到测试，你应该计划进行单元测试（绿地开发为此提供了一个绝佳的机会;不要错过机会）。测试在一个单独的项目中进行;这是为什么每个类都不应该给自己的程序集的另一个原因。理论上你可以将项目数量增加一倍。
我将从具有逻辑上分离的项目的单个解决方案开始（例如，通过函数/依赖项来解决问题，并为每个库添加测试项目）。
源代码管理消除了对团队成员之间冲突的任何担忧。如果您有内部挑战来启动和运行源代码管理，请查看Team Foundation Services Online：http://tfs.visualstudio.com/。安装非常简单，最多可供5位用户免费使用。
如果最终需要在项目之间进行更大的断开连接，您可能需要考虑使用带有local repository的NuGet包来隔离/版本化不同的离散组件。这不是我的第一步，但要记住这是一个值得考虑的选择。
从评论中可以看出，您目前正在执行自治单位的日常部署。
这似乎有风险。这可以由配置/数据而不是代码更改来驱动吗？
576完全自治的单位似乎是应用程序设计的问题（例如重用？）
假设每天必须部署新代码，也许脚本语言+ DLR可以使这更容易。动态编译c＃也是一种可能性。