我正在创建一个在运行时加载程序集以执行工作的工具。它会收到一条消息，说明要处理的工作类型和其他数据，然后查找并加载必要的程序集。每个任务程序集都引用一个共享程序集，其中许多程序集共享一个或两个其他组件。
目前，我将每项任务都包含在自己的解决方案中。最终将有大约50个任务，所以在一个巨大的解决方案中发展，这将是有点笨拙。但是，为了防止任务过时，我想创建一个大型解决方案，让我们检查共享组件的更改是否会破坏任务。
如果我对TaskBaseClasses项目中的类进行了更改，则必须针对包含对该更改的类的引用的其他项目检查该更改。有两个任务，这不是什么大问题。当我们有40或50个任务时，打开它们中的每个任务并做出改变将是一个真正的痛苦。
在部署中，应用程序的设置如下： ApplicationDirectory
以上说明了另一个问题。当我单独构建任务时，所有共享引用都是重复的。现在这不是问题，但是当我有50个TaskBaseClasses.dll副本时
所以我真的很想（除了我较小的单个任务组装解决方案之外）一个大型解决方案，它允许我检查所有任务以确保共享组件的一致性，并以这样的方式构建所有内容通过在一个单独的位置托管共享程序集，尽可能减少二进制重复，项目可以通过相对路径引用它们。
这可行吗？我想保留开发解决方案并创建一个或多或少的部署解决方案。当我开始更改部署解决方案的引用时，是否会抛弃开发解决方案中的引用？
我们正在使用TFS 2012（即将升级到2013年）自动构建，我只想拥有一个可以进行测试的大型解决方案的每晚构建。
我怎样才能吃蛋糕呢？
答案 0 :(得分：1)
听起来不错。使用较小的解决方案来完成更多本地化的任务 - 每个解决方案可能只需要一个任务 - 并根据需要使用大型解决方案。
另一种方法是不使用二进制引用进行任务之间的通信。考虑一种更具弹性的变化耦合，例如使用JSON的HTTP服务。以这种方式维护向后兼容性要容易得多。
当您需要共享代码时，请使用程序集引用。当您需要共享行为时，请考虑使用HTTP服务。
答案 1 :(得分：0)
手工制作的解决方案可能是一场维护噩梦。我建议你的项目有严格的命名和结构约定，这样你就可以轻松编写收集器脚本并进行部署。