什么是正确的方法？
我们的项目有一台构建服务器。 我们有不同的项目，引用不同版本的 DevExpress。
我们是否应该安装每个 DevExpress 构建服务器上的版本或
每个项目都应该有自己的 包含 DevExpress 程序集的文件夹。
在我看来：
优势 1：每个开发人员都可以更轻松地维护其项目的本地副本。 缺点 1：DevExpress 版本在构建服务器上非常糟糕，因为必须安装每个新版本。
优势 2：每个项目都可以在没有先决条件的情况下构建。 缺点 2：每个开发人员都必须手动将他的 dll 放在单独的 Libs 文件夹中。如果您从工具箱中拖动了 DevExpress 控件，则必须重新组织此 dll 的引用。
【问题讨论】：
标签： .net build-automation devexpress project-organization
我建议您在构建服务器上安装我们的安装。如果您只安装安装，则您的机器上不会有 DLL 地狱。这将保证您的项目将使用我们的控件的许可版本构建，因此在现成的应用程序中没有唠叨屏幕。当客户在支持中心提出此类问题时，我们通常会建议这样做...
【讨论】：
构建服务器的最佳解决方案和无忧无虑是在源代码管理中拥有一个共享文件夹，如果您在不同的项目中使用不同的 devexpress 版本并在项目中引用这些程序集，您可以在其中保存 devexpress 程序集或不同的文件夹。除了 devexpress dll 之外，还将 App_Licenses.dll 添加到该文件夹并在所有使用 devexpress 程序集的项目中引用它。当新版本的 devexpress 发布时，您只需更新这些 DLL，而不是每次都安装新的 devexpress 版本，这样您还可以在出现阻止程序错误时恢复到以前的版本，甚至在同一台机器。
此解决方案与 Hudson 构建集成服务器和 svn 完美配合。
如果您想在新的 devexpress 更新时使事情变得更容易，并且不想每次运行项目转换器来更新引用中的版本号，请排除您的引用 '、Version=10.2.6.0、Culture=neutral、PublicKeyToken =b88d1754d700e49a' 所以而不是：
你的 ref 看起来像这样：
这样，当程序集名称通过主要版本更改为例如更改时，您将很少需要运行项目转换器。 11.1
【讨论】：
最好的解决方案是不必在构建服务器上安装完整的产品。相反，您可以在服务器上获得“许可”。
在您的构建机器上启动安装程序，登录到安装程序，当您的产品列表出现时，退出安装程序。 现在您的构建将获得授权！
【讨论】：