构建服务器 - 在构建服务器上安装外部控制库（DevExpress）
什么是正确的方法？
我们为我们的项目提供一台构建服务器。 我们有不同的项目，引用了不同版本的 DevExpress。
我们应该安装每个 DevExpress 构建服务器上的版本或者
每个项目都有自己的 版本 包含 DevExpress 程序集的文件夹。
- 存在其他可能的方式吗？
我认为：
优点1：每个开发人员都更容易维护项目的本地副本。 缺点 1：DevExpress 版本在构建服务器上很糟糕，因为必须安装每个新版本。
优点2：每个项目都可以无条件构建。 缺点2：每个开发人员都必须手动将他的dll放在单独的Libs文件夹中。如果您从工具箱中拖动了 DevExpress 控件，则必须重新组织对此 dll 的引用。
what's the right way?
We have one build server for our projects.
We have different projects, wich reference different versions of DevExpress.
Should we install every DevExpress
Version on the build server orshould every project have its own
folder with DevExpress assemblies.- Exists an other possible way?
In my opinion:
Advantage 1: It is easier for every developer to maintain his local copy of the project.
Disadvantage 1: DevExpress version hell on build sever because every new release must be installed.
Advantage 2: Every project could be builded without prerequisite.
Disadvantage 2: Every developer must manually put his dlls in a separate Libs folder. If you have dragged a DevExpress control from the toolbox, you must reorganize your references for this dlls.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我建议您在构建服务器上安装我们的安装。如果你只安装安装，你的机器上就不会有DLL地狱。这将保证您的项目将使用我们控件的许可版本来构建，因此在现成的应用程序中不会出现导航屏幕。当客户在支持中心提出此类问题时，我们通常会建议......
I would suggest that you install our installations on the Build server. There will not be a DLL hell on your machine if you install only installation. This will guarantee, that your project will be built using a licensed version of our controls and thus no nag screens in a ready built application. This is what we usually suggest when our customers ask such questions in the support center...
构建服务器的最佳解决方案和无麻烦是在源代码管理中拥有一个共享文件夹，您可以在其中保存 devexpress 程序集或不同的文件夹（如果您在不同的项目中使用不同的 devexpress 版本并在项目中引用这些程序集）。除了 devexpress dll 之外，还将 App_Licenses.dll 添加到该文件夹，并在使用 devexpress 程序集的所有项目中引用它。当新版本的 devexpress 发布时，您只需要更新这些 DLL，而不是每次安装新的 devexpress 版本时都安装，这样您还可以在出现阻止错误时恢复到以前的版本，甚至可以在 devexpress 上运行不同的 devexpress 版本同一台机器。
该解决方案与 Hudson 构建集成服务器和 svn 完美配合。
如果您想让新的 devexpress 更新变得更加容易，并且不想每次运行项目转换器来更新引用中的版本号，请从引用中排除 ', Version=10.2.6.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a'所以而不是：
<%@ Register TagPrefix="dxe" Namespace="DevExpress.Web.ASPxEditors" Assembly="DevExpress.Web.ASPxEditors.v10.2, Version=10.2.6.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" %>
您的参考将如下所示：
<%@ Register TagPrefix="dxe" Namespace="DevExpress.Web.ASPxEditors" Assembly="DevExpress.Web.ASPxEditors.v10.2" %>
这样，当程序集名称通过主要版本更改为例如更改时，您将很少需要运行项目转换器。 11.1
Best solution and hassle free with build servers is to have a shared folder in the source control where you keep the devexpress assemblies or different folders if you use different devexpress versions in different projects and reference those assemblies in the projects. In addition to the devexpress dlls add also App_Licenses.dll to that folder and reference it in all projects that use devexpress assemblies. This when a new version of devexpress is out you need just to update those DLLs instead of installing every time a new devexpress version and this way you can also revert to a previous version in case of a blocker bug or even run different devexpress ver on the same machine.
This solution works perfect with Hudson build integration server and svn.
If you want to make things even easier at new devexpress updates and do not want to run each time project converter to update the version number in the references exclude from you references ', Version=10.2.6.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a' so instead of:
<%@ Register TagPrefix="dxe" Namespace="DevExpress.Web.ASPxEditors" Assembly="DevExpress.Web.ASPxEditors.v10.2, Version=10.2.6.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" %>
your ref would look like this:
<%@ Register TagPrefix="dxe" Namespace="DevExpress.Web.ASPxEditors" Assembly="DevExpress.Web.ASPxEditors.v10.2" %>
this way you'll need to run the project converter quite rarely when the assembly name changes through major version changes to eg. 11.1
最好的解决方案是不必在构建服务器上安装完整的产品。相反，您只需在服务器上获得“许可”即可。
在构建计算机上启动安装程序，登录安装程序，当出现产品列表时，退出安装程序。
现在您的构建将获得授权！
Best solution is not to have to install the full product on your build servers. Instead you can just get it 'licensed' on the server.
Start the installer on your build machine, login to the installer, when your list of products come up, exit the installer.
Now your builds will be authorized!