企业官网建设流程全解析

简介：DevExpress VCL 20.2.6 控件安装包面向已升级到 Delphi 11、需要同步更新界面控件库的开发者，重点解决旧版控件包兼容性不足、网上资源无法编译或并非完整版等问题，适合项目迁移、老项目维护、控件库恢复及开发环境重建等场景，也适合中高级开发者参考。资源包为 7z 压缩格式，大小约 473.21MB，文件总数与主要类型明细暂未提供，需以解压内容为准；安装入口为 DxAutoInstaller.exe，可减少手动配置环节，装完后可直接在 Delphi 11 中调用。已有 514 人学习或下载，在控件升级场景中具有一定参考价值。对于升级或维护 Delphi 项目、需要稳定使用全源码版本的开发者来说，这份亲测、非试用版的安装包能节省查找、甄别与排错时间，便于快速恢复原有控件开发环境，降低升级过程中的试错成本。

1. Delphi 11 下的 DevExpress VCL 20.2.6：为什么“装上”不等于“能用”

Delphi 11 项目里最容易被低估的环节，不是控件功能多不多，而是这套 DevExpress VCL 20.2.6 控件安装包能不能被 IDE 正确加载。很多人拿到 full source 包，第一反应是双击安装器一路下一步，结果设计期面板出来了，编译却提示找不到 dxCore.dcu；或者命令行能编，IDE 里一放控件就报包加载失败。这个资源的价值不在于“控件数量”，而在于它带源码、标称支持到 Delphi 11，并且是非试用版安装包，可以让你把运行时包和设计期包按依赖顺序重新编一遍，避开旧版 DCU 和 BPL 混用带来的玄学问题。它适合手里已经有 Delphi 11、需要 Grid、编辑器、报表这类 VCL 控件，又不想被试用弹窗和旧版残留拖住的人。先别急着装，下面从环境盘点开始拆。

2. 装前把环境拆开看：Delphi 11、旧版残留与目录权限

2.1 先确认包是不是 full source，以及 Delphi 11 的包工程在哪

拿到 DevExpress VCL 20.2.6 的控件安装包，先别双击安装器。解压后先看目录结构，确认它是不是 full source，而不是只有设计期 BPL 的试用包。常见目录会包含 Sources、Library、Packages、Bin 这几类，Sources 下是 .pas 源码，Packages 下是按 Delphi 版本分的包工程。Delphi 11 对应 BDS 28.0，包目录或输出后缀里常能看到 280 字样；有些包会写成 Delphi 11 或 Delphi11，以实际目录为准。判断 full source 的标准很简单：能找到 dxCore.pas、cxGrid.pas 这类源码，并且 Packages 下有可编译的 .groupproj 或 .dproj，而不是只给几个 dcl 开头的 BPL。

确认完源码形态，再确认编译目标。Delphi 11 的 IDE 本身是 32 位，所以设计期包通常只需要 Win32；运行时包要同时准备 Win32 和 Win64，业务工程切到 64 位时才不会临时找不到 BPL。不要看到“支持 Delphi 11”就默认所有目标平台都自动配好，full source 包的优势是你自己能重编，代价是路径和包顺序也要自己管。

2.2 旧版 BPL、DCP、DCU 的清理顺序

DevExpress VCL 这类控件库最容易翻车的地方，不是新包编不过，而是旧版还在 PATH 或 Library Path 里。IDE 启动时先加载了旧的设计期包，你再装 20.2.6，组件面板可能看起来正常，编译时却把旧 DCU 链进来。清理顺序建议从 IDE 内部往外走：先打开 Component > Install Packages，看已加载的设计期包里有没有旧版本；再检查系统 PATH 里有没有 dx 开头的 BPL 目录；最后检查项目自身的搜索路径和 IDE 的 Library Path。

可以用 PowerShell 先做一次文件盘点，不要急着删，先把旧版本位置找出来：

# 在常用开发盘符里找 DevExpress 相关的 BPL/DCP，先定位再清理 $roots = @("D:\DX", "D:\Projects", "C:\Users\Public\Documents") foreach ($root in $roots) { if (Test-Path $root) { Get-ChildItem -Path $root -Recurse -Include *.bpl,*.dcp -ErrorAction SilentlyContinue | Where-Object { $_.Name -match '^(dx|cx|dcl)' } | Select-Object FullName, Length, LastWriteTime | Sort-Object LastWriteTime -Descending } }

这段脚本只做定位，不直接删除。$roots换成你机器上实际放旧版控件和工程的目录；-Include *.bpl,*.dcp只找包文件，避免把源码目录扫得太散；Where-Object用 dx、cx、dcl 前缀过滤 DevExpress 常见包名。输出里重点看 LastWriteTime，如果同一个包名出现在两个目录，时间新的不一定是当前要用的，还要看它属于哪个版本。确认旧版不再使用后，再删目录或从 PATH 里移除。IDE 已经加载的包要先卸载再重启，否则文件被占用，删不干净。

提示：清理前把旧版的 BPL、DCP 目录整体备份一份，不要逐个文件删。后面如果某个老项目还要回到旧版，整目录恢复比到处找文件省事。

2.3 目录规划：短路径、可写目录、别放中文和空格

安装目录建议用短路径，例如D:\DX\VCL206，不要放在C:\Program Files下。不是权限一定不够，而是 full source 编译会往 Library 目录写大量 DCU、BPL、DCP，UAC 和杀毒软件很容易在中间锁文件，最后表现为“编译到一半失败，日志里看不出原因”。路径里也不要带中文和空格，Delphi 的包工程、msbuild 参数、旧版安装器对这类路径的处理并不总是一致，能避开就避开。

目录规划可以按“源码、输出、工程”三块分开：源码解压到D:\DX\VCL206，编译输出统一落到D:\DX\VCL206\Library\Delphi11，自己的验证工程放到D:\DX\Demo。这样清理时不会误删业务代码，配置 Library Path 时也只需要指向一个输出根目录。安装前把 Delphi IDE 关掉，尤其是你之前打开过旧版控件工程的情况下，IDE 进程会占用 BPL，导致新包覆盖失败。杀毒软件如果实时扫描比较激进，可以把输出目录加入排除项，或者编译时暂时关闭实时扫描；这不是必须，但能减少“文件被占用”的假故障。

3. 从源码到设计期包：DevExpress VCL 20.2.6 的编译顺序与命令行

3.1 运行时包、设计期包、DCU：先把依赖链排清楚

full source 包不是“编一个包就完事”。DevExpress VCL 的包通常分运行时包和设计期包：运行时包提供业务代码运行需要的 BPL 和 DCU，设计期包负责把控件注册到 IDE 的工具面板。设计期包依赖运行时包，所以顺序必须是先运行时、后设计期；如果先装设计期包，IDE 会提示找不到依赖的 BPL。DCU 是编译后的单元文件，BPL 是运行时包，DCP 是编译期包信息，三者不要混为一谈。项目编译时找 DCU，运行时装 BPL，IDE 加载设计期包时又要能找到它依赖的运行时 BPL。

我一般会先把输出目录清空，再按 Win32 运行时包、Win32 设计期包、Win64 运行时包的顺序编。设计期包不要编 Win64，Delphi 11 的 IDE 是 32 位，加载不了 64 位设计期包。这个顺序看着笨，但能避免很多“为什么 IDE 里有控件、编译却找不到单元”的问题。

3.2 用 msbuild 编 Win32 运行时包和设计期包

如果包内安装器能选 Delphi 11 路径并编译，可以先用安装器走一遍，确认它能识别你的 IDE。但安装器失败时，命令行更容易看日志。下面这个批处理把包工程路径、Delphi 安装目录和输出日志都变量化，方便你按实际目录改。注意PKG要指向包内实际的 .groupproj，不同打包方式文件名可能不同。

@echo off setlocal set DX_ROOT=D:\DX\VCL206 set BDS=D:\Delphi\Studio\22.0 set MSBUILD=%BDS%\bin\msbuild.exe set PKG=%DX_ROOT%\Packages\Delphi11\DevExpressVCL.groupproj if not exist "%MSBUILD%" ( echo [ERROR] 找不到 msbuild：%MSBUILD% exit /b 2 ) if not exist "%PKG%" ( echo [ERROR] 找不到包工程：%PKG% exit /b 3 ) echo [INFO] 开始编译 Win32 运行时包和设计期包 "%MSBUILD%" "%PKG%" /t:Build /p:Config=Release /p:Platform=Win32 /v:minimal /fl /flp:LogFile=build_win32.log;Verbosity=detailed if errorlevel 1 ( echo [ERROR] Win32 编译失败，查看 build_win32.log exit /b 1 ) echo [INFO] Win32 编译完成 endlocal

/t:Build表示重新构建，不是增量编译；/p:Config=Release走发布配置；/p:Platform=Win32指定 32 位目标；/fl /flp:LogFile=...把详细日志写到文件，失败时先看日志里第一个 error，不要被后面的连锁错误带偏。errorlevel 1判断编译结果，失败就退出，避免脚本继续往下跑造成“看起来成功”的假象。如果包工程里运行时包和设计期包是分开的 .dproj，不要图省事只编设计期包，依赖链会断。

Win32 通过后，再编 Win64 运行时包。可以把上面的脚本复制一份，把Platform=Win32改成Platform=Win64，日志改成build_win64.log。如果 Win64 报错，先确认包工程是否真的支持 Win64，再看是不是某个第三方依赖只有 32 位。设计期包不需要再编 Win64，编了也加载不进 IDE。

3.3 安装设计期包：IDE 里看到控件面板才算落地

编译完成后，先不要直接双击 BPL。设计期包安装时，IDE 需要找到它依赖的运行时 BPL。比较稳妥的做法是用一个启动脚本临时把运行时 BPL 输出目录加到 PATH 最前面，再启动 Delphi。这样不会永久污染系统 PATH，也方便你同时保留多个版本。

@echo off setlocal set BDS=D:\Delphi\Studio\22.0 set DX_BPL=D:\DX\VCL206\Library\Delphi11\Win32\Release set PATH=%DX_BPL%;%PATH% start "" "%BDS%\bin\bds.exe" -pDelphi endlocal

DX_BPL指向你实际的 Win32 运行时 BPL 输出目录，不要指向源码目录；-pDelphi启动 Delphi 个性，避免打开其他 IDE 个性时加载不同包集合。IDE 启动后进 Component > Install Packages > Add，选择 dcl 开头的设计期 BPL，勾选后重启 IDE。工具面板出现 DevExpress 页签，才算设计期包注册成功。如果 Add 时提示“找不到依赖模块”，回到上一步检查运行时 BPL 是否在 PATH 里，以及设计期包是不是用当前版本源码编出来的。不要用旧版设计期包配新版运行时包，这种混搭最容易出现面板正常、编译报错的怪现象。

4. 接进项目：Library Path、最小 Grid 工程与高 DPI 配置

4.1 Library Path 和 Browsing Path 各管什么

Library Path 是给编译器找 DCU 的，Browsing Path 是给 IDE 找源码跳转的，两者不要混。很多安装教程让你把 Sources 下所有子目录都加进 Library Path，这在 full source 场景下是血泪经验的反面：编译器会优先找到 .pas 现场编译，结果你项目里用的 DCU 和 BPL 不是同一批，运行时包版本对不上。正确做法是 Library Path 只指向编译输出目录，Browsing Path 再指向源码根目录，调试时能跳进 DevExpress 源码就够了。

Delphi 11 的 Library 对话框有平台下拉，Win32 和 Win64 要分别配。只配 Win32 的话，切到 64 位目标就会提示单元找不到。配置完不要马上开业务工程，先拿一个空白工程做最小验证，确认路径生效。

4.2 最小验证工程：动态创建一个 cxGrid

空白 VCL 工程里放一个按钮，在按钮事件里动态创建 Grid。下面这段代码只依赖 cxGrid、cxGridLevel、cxGridTableView 三个单元，适合验证控件包有没有真正接进项目。代码放在窗体单元里，编译目标先选 Win32，再切 Win64 各编一次。

unit Unit1; interface uses Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, cxGrid, cxGridLevel, cxGridTableView; type TForm1 = class(TForm) procedure FormCreate(Sender: TObject); private FGrid: TcxGrid; end; var Form1: TForm1; implementation {$R *.dfm} procedure TForm1.FormCreate(Sender: TObject); var Level: TcxGridLevel; View: TcxGridTableView; begin FGrid := TcxGrid.Create(Self); FGrid.Parent := Self; FGrid.Align := alClient; Level := FGrid.Levels.Add; View := FGrid.CreateView(TcxGridTableView) as TcxGridTableView; Level.GridView := View; View.DataController.CreateAllItems; end; end.

TcxGrid.Create(Self)把 Grid 挂到窗体上，Align := alClient让它铺满；Levels.Add创建层级，CreateView创建表格视图，DataController.CreateAllItems让视图生成默认列结构。这段代码的作用不是做业务界面，而是验证cxGrid、cxGridLevel、cxGridTableView三个单元能否被正确解析。如果编译提示找不到cxGridTableView，先查 Library Path 是不是指到了旧版 DCU 目录；如果运行时提示包加载失败，查 BPL 是否在 PATH 里。Win32 编过后切 Win64，重点看 Win64 运行时包有没有编、Library Path 的 Win64 平台有没有配。

4.3 皮肤和高 DPI：设计期正常、运行期发虚的排查

设计期控件看起来正常，运行期字体发虚、边框错位，常见原因有两个：项目 manifest 的 DPI Awareness 和控件包版本混用。Delphi 11 项目选项里可以设置 Per-Monitor V2，但 DevExpress VCL 20.2.6 对高 DPI 的支持取决于具体控件和皮肤单元，不是所有场景都自动适配。先确认项目里没有同时引用旧版皮肤 DCU 和新版皮肤 BPL，再看窗体是不是在设计期用了固定字体大小。排查时把皮肤控制器先去掉，用默认风格跑一遍，如果默认风格正常，问题就在皮肤单元；如果默认风格也发虚，回到项目 manifest 和窗体缩放设置。

注意：皮肤相关单元不要从旧版目录拷。full source 包重新编译后，皮肤 BPL 也要用同一批输出，混用会出现设计期预览正常、运行期报“找不到资源”的情况。

5. 避坑与排查：安装成功但编译报错的 5 个高频现场

5.1 现象：找不到 dxCore.dcu，或者提示单元重复

现象是编译业务工程时提示dxCore.dcu not found，或者反过来提示某个单元在两个路径里重复。原因通常是 Library Path 里同时存在源码目录和旧版 DCU 目录，编译器先找到哪一个就用哪一个；也有可能是旧版安装目录还在 PATH 或搜索路径里，和新版输出目录打架。解决时先把项目搜索路径清空，只保留当前版本编译输出的 DCU 目录；再检查 IDE 的 Library Path 是否还挂着旧版 DevExpress 目录；最后用Build而不是Compile强制重编。如果是单元重复，重点看搜索路径顺序，把当前版本输出目录放到最前面，旧版目录直接移除，不要靠改单元名绕。

5.2 现象：设计期包加载失败，工具面板空白

现象是 Install Packages 里添加了 dcl 包，但工具面板没有 DevExpress 页签，或者重启 IDE 时提示包加载失败。原因一般是设计期包依赖的运行时 BPL 不在 IDE 能找的路径里，或者设计期包本身没编成功。解决时先用启动脚本把 Win32 运行时 BPL 目录加到 PATH 最前面，再启动 IDE 重新 Add；如果还失败，看 IDE 的包加载错误信息里缺哪个模块，回到编译日志确认那个模块有没有生成。不要用管理员权限硬启动 IDE 来“试试”，权限不是这类问题的根因。设计期包只装 Win32，装 Win64 设计期包没有意义。

5.3 现象：32 位能编，64 位报错

现象是 Win32 目标编译正常，切到 Win64 后提示找不到单元或 BPL。原因通常是只编了 Win32 运行时包，或者 Library Path 的 Win64 平台还指向 Win32 输出目录。解决时单独编一遍 Win64 运行时包，确认输出目录里有对应的 BPL、DCP、DCU；然后在 IDE 的 Library 对话框里把 Win64 平台的 Library Path 指到 Win64 输出目录。设计期包不需要 Win64，但业务工程如果引用运行时包，Win64 目标必须能找到 Win64 BPL。切平台后建议先 Build 一次，不要依赖增量编译。

5.4 现象：换机器后提示试用版或授权异常

现象是同一套源码在 A 机器正常，拷到 B 机器后新建窗体弹试用提示，或者设计期包注册后仍显示试用限制。原因可能是旧版 BPL 混入、授权文件没有按包内说明放置，或者源码包没有重新编译，直接拷了别人机器上的 BPL。解决时先核对包内授权说明，确认授权文件放置位置；再清理 B 机器上的旧版 DevExpress 目录和 PATH；最后用当前机器的 Delphi 11 重新编译运行时包和设计期包。不要从旧版目录拷授权文件，也不要把不同版本的 BPL 混用。非试用版的判断标准不是安装器标题，而是源码完整、重新编译通过、设计期包注册后新建窗体不弹试用框。

5.5 现象：IDE 启动变慢，或者包冲突导致频繁报错

现象是装完控件后 Delphi 启动明显变慢，打开工程偶尔提示包冲突。原因通常是 Install Packages 里加载了太多设计期包，包括旧版残留和当前版本同时存在；也可能是每个项目都往 Library Path 里塞了大量第三方路径。解决时打开 Component > Install Packages，把不用的设计期包取消勾选，只保留当前版本；用启动脚本隔离不同项目的 PATH，不要永久往系统 PATH 里追加一堆 BPL 目录；定期清理 Library Path 里已经不存在的路径。IDE 包加载是启动时一次性完成的，包越多，启动越慢，冲突概率也越高。

6. 长期维护：把 full source 包变成可回归的本地依赖

6.1 版本锁定与升级检查清单

full source 包最大的好处是可重编，最大的风险也是“每次编出来的东西不一样”。我一般会把包版本、Delphi 编译器版本、BPL 输出目录、Library Path 记在一张检查表里，升级前先在分支上跑最小工程，不要直接在业务工程里试。下面这张表可以作为交付前的固定动作：

6.2 交付前跑一次全量重编译

交付或换机前，不要只拷贝 BPL。把源码目录、编译脚本、最小验证工程一起带走，到新机器上先清输出目录，再跑一遍 Win32 和 Win64 编译，最后启动 IDE 确认设计期包能加载。业务工程里只保留必要的 Library Path，不要把整个源码树塞进项目搜索路径。皮肤、授权文件、第三方 DLL 按包内说明单独放，不要和旧版目录混在一起。从那以后我每次装这类 full source 控件包，都先拿一个空白工程做最小闭环，再往业务工程里引；这一步多花十分钟，能省掉后面半天找 DCU 的时间。希望帮到你。

本文还有配套的精品资源，点击获取