企业官网建设流程全解析

简介：面向 Delphi/C++Builder 开发者的 Raize 6.1.1.12 DX10.1 Berlin 修正版组件库，重点解决了安装过程中因 pas 文件错误导致编译不成功的问题。整套资源以 RAR 格式打包，体积仅 10.74MB，包含 956 个文件：202 个 hpp 头文件、114 个 pas 源文件、198 个 dcu 编译单元、71 个 dfm 窗体文件，并有 bmp 图像、res 资源、inc 配置、dpk 工程文件、dproj 项目文件等，类型齐全，便于直接用于组件源码分析和环境配置。目前已有 328 人学习下载，适合在 Delphi 10.1 Berlin 环境下集成 Raize 6 的开发者、项目团队及组件库学习者使用。压缩包中配置文件已预先调整，解压到 C:\Program Files\Raize\ 即可完成目录部署；随后执行 RC6\Source 目录下的 !Build_RC6.cmd，即可自动完成组件编译与安装，实测可用。相比需要手动排查和修正 pas 错误的旧版本，这款修正版能显著缩短环境搭建时间，同时保留了完整的源文件、图像与编译脚本，便于后续在可视化界面、工具栏、图像列表等组件开发场景中直接取用。包内还含有大量用于窗体、按钮、复选框、工具栏等界面的图像与样式资源，方便二次调整和参考。

1. Raize 6.1.1.12 修正版的定位：先搞清它修了什么、适合谁

如果你的项目还在 Delphi 10.1 Berlin 上，又需要 Raize 那套老牌的 VCL 组件，大概率绕不开 Raize_6.1.1.12_DX10_1_Berlin_cocashu 这个修正版。它解决的问题很具体：原版 Raize 安装包年代久远，直接拿到 Berlin 上用会碰到 dpk 找不到对应版本、编译报 F2613、设计期包注册不进去等一系列问题。所谓修正版，就是有人在原包基础上补全了源码路径、重新整理了 DPK 工程选项，让它能按 Berlin 的环境顺利装进 IDE。适合谁呢？正在维护老 VCL 项目、不想升级 IDE、又必须用 Raize 控件的开发者。不适合谁呢？项目允许升级到新版本 Delphi、或者愿意花时间把 Raize 控件替换成原生控件的人，没必要碰这个安装包。

2. 安装前先把版本账算对：6.1.1.12 与 DX10_1_Berlin 的匹配关系

2.1 Raize 组件包的两层结构：运行时包与设计期包为什么必须分开

Raize 进入 IDE 的方式是 VCL 包（package），而且一定要分成两层看：运行时包（runtime package）提供 RzEdit、RzTreeView 这些控件的实际实现代码，设计期包（design-time package）只负责属性编辑器、组件编辑器这类 IDE 内嵌逻辑。运行时包编译出来的 .bpl 会被每个工程引用，设计期包编译出来的 .bpl 则挂在 IDE 进程里。

很多第一次装 Raize 的人以为“只要把包装上就行”，其实 IDE 的规则是必须先有运行时包、再装设计期包。顺序反了，IDE 加载设计期包时会因为找不到对应运行时单元直接弹错；漏了设计期包又会导致组件面板上根本看不到 Raize 页面。修正版一般先帮你把运行时包和设计期包的目录分开，但安装顺序仍然要自己把握。

典型目录布局大概是这样的示意结构，不同打包者整理方式略有不同，但“源码、预编译产物、组件包”三块通常都在：

Raize_6.1.1.12_DX10_1_Berlin_cocashu修正版/ ├── Source/ │ ├── RzLib/ # 运行时单元源码 │ └── RzDes/ # 设计期编辑器源码 ├── Lib/ │ ├── dcu32/ # 预编译 32 位 DCU │ └── dcu64/ # 预编译 64 位 DCU ├── Dpk/ │ ├── Runtime/ │ └── Design/ └── Docs/

先看这套结构是把脚本作者的分段逻辑理解清楚：Source 是给“打算重新编译源码”的人准备的，Lib 是为“直接用预编译 DCU 链接”准备的。多数厂房项目走的是后一条路，省去重编译带来的版本波动。但预编译 DCU 必须和你 IDE 的编译器版本严格对应，否则链接阶段一样翻车。

2.2 “修正版”修正的常见问题：dpk 编译不过与 dcu 缺失

原版 Raize 6.1.1 对应的年代和 Berlin 差了整整一代。原包里不少 DPK 文件写的还是老式路径，比如默认引用$(BDS)\lib或者老版本的$(DELPHI)\Lib，在 Berlin 上打开后 IDE 找不到单元，报错信息通常长这样：

[dcc32 Fatal Error] RaizeUtil.pas(101): F2613 Unit 'ToolsAPI' not found.

看到 Unit not found 别急着怀疑源码坏了。一般来说两个原因：要么是库路径（Library Path）里没加 Source 目录，要么是 DPK 文件里的输出目录还指向旧 IDE 安装路径。修正版干的主要事情之一，就是把这些路径批量改成 Berlin 能识别的结构，再把预编译 DCU 按 Win32/Win64 分别放好。

cocashu 这个后缀是发布者的标识，不重要，重要的是你拿到包后先做一次快速自查：看 Dpk 文件夹里有没有按 IDE 版本号命名的子目录，或者有没有专门给 Berlin 的编译说明。有就说明包是针对性适配过的；没有，就只能把 6.1.1.12 当成“原始素材包”，自己走一遍源码重编译，这个我在下一章会讲具体命令。

2.3 32 位与 64 位库路径：Berlin 下最容易漏配的一步

Delphi 10.1 Berlin 的库路径是分平台的。Tools > Options > Delphi Options > Library 面板左下角有 Platform 下拉框，分别有 32-bit Windows 和 64-bit Windows 两个入口。绝大多数修正版安装说明只叮嘱你加一次路径，结果 64 位编译时dcu32目录被当成 64 位 DCU 引用，编译器报错又找不到头绪。

实际配置原则很简单：Win32 平台的路径指向 dcu32（或 Source），Win64 平台的路径指向 dcu64。如果修正包只带了一套预编译 DCU，那 64 位就必须走源码重建，没有捷径。我一般会把两个平台路径分开写，而不是图省事只加一个公共目录，因为你无法保证 IDE 一定优先匹配子目录。

3. 把 Raize 装进 10.1 Berlin：从解压到组件面板出现的完整步骤

3.1 解压后先确认目录布局与版本分支

第三步不能直接双击任何 exe 或者直接拷 bpl，先花两分钟确认目录布局。Raize 这类老组件最忌讳装完发现版本分支选错。用命令行看结构最直接：

cd /d D:\Components\Raize dir /s /b *.dpk *.dproj

命令输出出来后逐个核对：有没有 Runtime 和 Design 两组包文件？有没有 10.1 Berlin 相关的.dproj？如果只有.dpk没有.dproj，说明安装流程要回到 IDE 里手动打开编译；如果有.dproj，恭喜，至少工程文件层面是适配过的。修改建议是：把目录放在纯英文、无空格路径下，比如D:\Components\Raize，后面 dpk 编译时会少很多莫名其妙的坑。

这一步还要顺手做一件事：检查Lib下有没有dcu64。没有的话，意味着后面 64 位目标需要你自己重新编译一遍运行时包，别等建了工程才发现。

3.2 手工添加 Library Path：IDE 里改，先加源码再加预编译 DCU

Library Path 是 Raize 能不能被编译器找到的命根子。打开 Tools > Options > Delphi Options > Library，左侧 Platform 选 32-bit Windows，然后把 Source 目录和 dcu32 目录分别加进去。顺序有讲究：先加 Source，再加预编译 DCU。因为编译器搜索单元时按路径先后顺序，Source 在前，debug 时能跟到源码；dcu 在前，调试时只能进反汇编。

这里有一个日常最容易忽略的点：Library Path 里每一行末尾要不要加分号？不用。Delphi 的选项面板会自动处理分隔符，你只管逐行添加。添加完点 OK，IDE 会重新编译一次包缓存，等右下角消息窗没有红色错误再继续。

加了路径之后怎么确认真的生效？简单办法是随便打开一个工程，用 Ctrl+F12 打开 Unit 窗口，输入RzEdit，能在列表里看到这个单元名就说明编译器已经能感知 Raize 的存在。看不到就回到 Library Path 检查是不是加错了目录层级，不少人把Source直接写成Source\RzLib，导致 IDE 找不到其余子目录。

3.3 编译 dpk 的正确顺序：先运行时包，后设计期包

这就是很多人装 Raize 反复失败的核心分水岭。用 File > Open 打开 Runtime 目录下的运行时包工程文件，然后在 Project Manager 窗口里右键工程名，选择 Compile。如果这里能顺利无红杠通过，再打开 Design 目录的设计期包，同样右键 Compile。

用命令行编译是更可控的方式，尤其在包数量多、IDE 容易假死时，我会用 msbuild 一次处理完：

@echo off rem 先编译 32 位运行时包 msbuild RaizeComponentsVcl.dproj /p:Platform=Win32 /p:Config=Release /t:Build rem 再编译设计期包，依赖运行时包已经生成 dcp msbuild RaizeDesignEditorsVcl.dproj /p:Platform=Win32 /p:Config=Release /t:Build

这段脚本的核心是两个顺序：第一，运行时包必须先编译，因为设计期包会引用它产生的.dcp和.bpl；第二，Release 配置别改成 Debug，组件包装上 IDE 后跑的一直是 Release 产物，Debug 配置的 bpl 带调试符号，在 IDE 里加载反而更慢更容易崩。

如果你的包文件是.dpk而不是.dproj，那 msbuild 这条路走不通，老老实实回 IDE 里做右键 Compile。dpk 是老式工程格式，IDE 会在项目打开时自动生成同名的.dproj文件，编译一次后下次就能用命令行方式了。

3.4 注册设计期包：让 Raize 出现在组件面板上

编译通过不等于安装完成。运行时包只需要被 IDE 知道，设计期包必须显式“安装”到 IDE 里，组件面板才会出现 Raize 那一页。操作路径是 Component > Install Packages，点 Add，去 bpl 输出目录里找到设计期包的.bpl文件，双击添加。

添加成功后，Install Packages 列表里会出现 Raize 相关的条目，左侧勾选框必须打勾。这时候组件面板会多出一页名字带 Raize 的工具栏，叫 Raize Components 或 Rz 前缀相关。面板没看到的话，先右键组件面板区域，在弹出菜单里检查是不是被勾选用途隐藏了；不是的话，回到 Install Packages 确认勾选状态，再确认设计期包确实编译成功过。

还有一个细节：老工程的 Project Manager 里，右键设计期包时会有 Install 选项，和 Compile 平级。严格顺序是 Compile 之后右键选 Install，它会自动注册到 IDE，比去 Install Packages 手动 Add 要少走一步。不过如果用的包相对特殊，手动 Add 永远是最稳妥的路径。

4. Raize 修正版安装避坑记录：4 条血泪经验

4.1 装上后组件面板没有 Raize 页：大多数人卡在最后一步

现象：按流程走完所有编译和安装，IDE 没有任何报错，组件面板就是看不到 Raize。原因：你在 Install Packages 里勾选的可能是运行时包，而不是设计期包。不少打包者会把两类包的输出放在同一个 bpl 目录，文件名又只差一个后缀，稍不注意就把运行时包当成设计期包加进去了。解决：回到 Component > Install Packages，把列表里可疑的 Raize 条目取消勾选，然后重新 Add 一次，这次打开包文件之前先看文件名带不带 Design 字样。确认后再看组件面板，页签出现速度很快。

4.2 bpl 被占用：替换 bpl 前忘了先关 IDE

现象：编译设计期包时提示cannot open file RaizeDesignEditorsVcl.bpl，或者提示文件被另一个进程锁定。原因：IDE 还开着，当前进程已经加载了同名 bpl，所以无法覆盖输出文件。这个坑特别容易反复出现，因为很多人是“一边开着 IDE 一边找问题”。解决：先把 IDE 完全退出，再重新打开工程编译；如果还锁着，用资源监视器看是哪个进程占用了 bpl 文件，通常就是 explorer 预览窗格，把目录窗口关掉再试。更彻底的方式是编译前手动把输出目录里的旧 bpl 删掉，让 msbuild 从零生成。

4.3 中文路径导致 dpk 编译失败：现象与两条处理路线

现象：dpk 编译时报错路径乱码，或者 IDE 提示找不到某些.dcu文件，但文件明明就躺在那里。原因：Berlin 的 dcc 编译器对非 ASCII 路径支持一直不太稳定，中文文件夹名会让编译器在拼接 include 路径时产生错位。修正版如果放在中文路径下，哪怕包本身的路径配置没问题也会被带偏。解决路径有两条：第一，把整个包挪到D:\Components\Raize这类纯英文路径，重新配 Library Path；第二，用目录联接（junction）把中文路径映射到英文盘符路径，不改原目录结构。前者最省事，后者适合“包必须放在共享盘中文目录下”的公司环境。个人建议一切以第一条为准，别给自己找不痛快。

4.4 旧版本残留导致 IDE 启动弹错：清理残留的固定流程

现象：安装修正版之前机器上已经装过别的 Raize 版本，新包装完，IDE 启动时弹 “Cannot load package ... 找不到指定的模块” 或类似字样。原因：旧版本的 bpl 仍留在 IDE 的 Bpl 目录里，IDE 启动时会尝试加载它，但旧 bpl 依赖的其它 DLL 或包已经不存在了。解决：先打开 Component > Install Packages，把和 Raize 相关的旧条目全部 Remove；然后打开“文档目录\Studio\19.0\Bpl”（版本号按你实际装的 IDE 路径来），把 Raize*.bpl 全选删除。再重新启动 IDE，看启动日志是否干净。删除前可以把旧 bpl 移到备份文件夹而不是直接清空，万一新包有问题还能回滚。

@echo off rem 备份并清理旧 Raize bpl，注意 IDE 必须先关闭 set BPLDIR=%USERPROFILE%\Documents\Studio\19.0\Bpl set BAKDIR=D:\backup\raize_bpl_old if not exist "%BAKDIR%" mkdir "%BAKDIR%" move /Y "%BPLDIR%\Raize*.bpl" "%BAKDIR%\" echo 清理完成，请重新打开 IDE

脚本里的Raize*.bpl通配符覆盖旧的运行时包和设计期包，move而不是del是因为保留后悔药更稳妥。执行后如果 IDE 启动时报别的包缺 Raize 依赖，把那几个备份文件拷回去反而能救急。这个“复制而非删除”的思路在更换任何第三方组件版本时都适用。

5. 装完先做这三件事：验证 32/64 位编译、确认设计器可用并固化库路径

5.1 最少验证动作：放一个 RzEdit 编译一次

安装成功的第一道验证不是看组件面板，而是真实编译一次。新建一个 VCL 工程，往窗体上拖一个RzEdit（或任意 Rz 前缀控件），什么属性都别改，直接编译。能通过，再切换 Win64 平台编译一次。这一步要验证的是两个平台下 DCU 路径是否都配好了。

写一段最小验证代码更直接——不拖控件，直接在窗体构造函数里动态创建：

uses RzEdit; procedure TForm1.FormCreate(Sender: TObject); var ed: TRzEdit; begin ed := TRzEdit.Create(Self); ed.Parent := Self; ed.Align := alTop; ed.Text := 'Raize OK'; end;

这段代码覆盖了三件关键事：单元引用（RzEdit）、对象实例化（TRzEdit.Create）、父容器挂载（Parent）。如果 Library Path 漏配，编译阶段就会报F2613；如果运行时包没装，编译会通过但运行时报“找不到 RaizeComponentsVcl.bpl”。两种失败点能区分开，这就是动态创建比拖动控件更利于定位原因的地方。

5.2 把 Raize 目录归档并固定库路径：避免下次换环境又翻车

验证通过后，趁热打铁把两样东西固化下来：一是把修正版整体归档到一个固定目录，二是把 Library Path 的配置记成一份环境说明，放工程文档里。为什么要做这个？Raize 是老组件，你不会只在一台机器上开发，换电脑、换同事交接、甚至 IDE 重置一次设置，库路径会全部清空。到时候翻出归档目录的 README，照着逐条加回来，比临时回忆“当时到底怎么装上的”省力得多。

另外可以把验证工程本身保留下来，就放在 Raize 归档目录旁边，当作以后任何环境安装的探针。新机器装完组件，先打开这个工程跑一次 32/64 双编译，全绿再判断安装成功。这个习惯对任何第三方 VCL 组件都管用，不限于 Raize。

我在这类老组件安装上吃过不少亏，印象最深的一次是折腾了三个小时，最后发现只是 bpl 目录里躺着旧版本残留。现在不管装什么组件，第一件事都是检查旧包残留、第二件事确认库路径分平台、第三件事用最小工程探针验证，顺序固定下来后基本没有翻过车。Raize 6.1.1.12 这套流程走熟之后，你在 Berlin 上维护老工程会顺很多——希望帮到你。

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