我应该在解决方案中包含第三方（Devexpress）dll文件吗？
我要做的方式是在我的解决方案中创建一个SolutionItems目录，并将所有引用的第三方dll文件物理复制到该文件夹中，然后在SolutionItems目录内更改对local copy的引用。但问题是：它是否值得手动管理它的麻烦？我应该在解决方案中包含第三方（Devexpress）dll文件吗？
我认为这是一个好主意，因为它是我的应用程序的依赖项。如果没有安装所需的DevExpress版本，如果不包含dll文件，整个解决方案将无法在Visual Studio内部运行。只要参考设置正确，我的Deployment Project将正确处理依赖关系。
另一方面，因为DevExpress通常会自动添加引用，并且我可以使用Project converter来更新DevExpress的版本。因此，无需参考Local Copy内部解决方案，无论何时更改引用或在DevExpress版本之间进行更改，它都可以很好地工作。相反，如果我正在管理我的local copy，我将为自己创建更多工作来维护dll文件的参考和实际副本。我是否应该保持现在的简单，基于这样的假设：使用此应用程序的人员需要安装DevExpress的副本？
我的工作地点有类似的问题。 5个开发人员，1个svn和多个DevExpress dll副本。我们首先尝试维护一个本地副本（手动更新），如您所描述的那样，而不是对我们来说很好。所以是的，最简单的事情是（根据我的经验），要求在项目中工作的每个人都安装了DevExpress的副本。
谢谢你分享你的经验。我想因为DevExpress组件引用dll文件的方式，所以更多的工作来管理dll文件，而不是那些，我会让DevExpress管理它们。如果我们发现需要在源代码树中包含dll文件，那么我们会处理这个问题。 – 2012-07-09 23:16:07
尝试[此]（http://stackoverflow.com/questions/17825/best-practice-for-releasing-microsoft-dlls-in-setup）前面的讨论 [1]： – tbroberg 2012-07-09 01:36:26
@tbroberg，由于，但我的问题是关于开发，因为我的安装程序将复制依赖项dll文件，而不是关于安装或重新分发。 – 2012-07-09 02:02:45