简介：PowerBuilder 11.5 安装包面向仍需维护、迁移或复现 PB11.5 项目的开发者、企业信息化人员及教学实验人员，核心作用是提供该版本开发环境的安装介质，便于搭建本地开发、测试与兼容性验证环境，尤其适合处理历史工程打开、旧版代码编译运行和课程实验准备等场景。资源以 rar 压缩包形式分发，体积约 729.75MB；文件总数与具体类型明细上游暂未提供，下载后可据此预留解压与安装空间。压缩包采用通用 rar 格式，便于归档与传输，适合在本地磁盘或离线环境中保存备份。目前已有 1349 人学习或下载，具备一定参考热度。对于需要还原 PowerBuilder 11.5 基础工具链的读者，该安装包可减少四处寻找旧版安装文件的时间，并为后续项目维护、环境对照、版本差异排查和升级评估提供便利，适合作旧系统维护与教学实验的基础资料。

1. PowerBuilder 11.5 安装第一道坎：为什么 64 位机器上 pb11.5 最容易翻车

上周接手一台开发机，PowerBuilder 11.5 装完了，桌面图标双击一闪就退，事件查看器里连条像样的错误都没有，纯黑匣子。pb11.5 这种老一代 IDE 在今天的环境里属于「装得上不算完，跑得起来才算数」：它本身是 32 位程序，却要被塞进 64 位系统，还要去加载 32 位的数据库客户端和 ODBC 驱动，任何一环没对齐，表现出来都是闪退、连不上库或者 .NET 目标编译报错。

这套环境在维护老系统的团队里极其常见，老项目要改一个 DataWindow、补一个 .NET 发布包，绕不开它。这篇记录写给两类人：第一次装 pb11.5 的新手，照着顺序能从解压一路走到编译出 exe；装过但总在某个环节翻车的老手，能看到版本怎么选、参数怎么调、报错该看哪里。

2. 解压与介质核对：PowerBuilder115.rar 里先装什么、后装什么

拿到一个 rar 包，最常见的动作是双击、点 setup.exe、一路下一步，装到 60% 回滚了再回头找原因。pb11.5 的安装介质里通常不止一个 setup，还混着先决组件、补丁包和文档，顺序错了后面全得重来。这一章先把「包里有什么、机器够不够、谁先装谁后装」这三件事定下来，再动手。

2.1 解开 rar 之后先做三件事

第一件事是解压到短路径。不要解到桌面，也不要解到「新建文件夹 (2)」这种带空格和括号的目录里，pb11.5 安装和后续 .NET 编译会拼出很长的临时路径，路径一长或者一带中文，编译阶段就容易出莫名其妙的错。我一般固定用D:\pb115_setup这种两层的短目录。

:: 在 cmd 里执行，-o 后面紧跟目标目录，不能有空格 "C:\Program Files\7-Zip\7z.exe" x D:\download\PowerBuilder115.rar -oD:\pb115_setup -y :: 先做一次压缩包完整性测试，确认下载过程没把包弄坏 "C:\Program Files\7-Zip\7z.exe" t D:\download\PowerBuilder115.rar :: 对解出来的安装引导做一次哈希，和发布方提供的值比对 certutil -hashfile D:\pb115_setup\setup.exe SHA256

第一条命令里-o是输出目录参数，它和路径之间不能有空格，写成-o D:\...会被当成两个参数，解压直接失败。第二条t是 test，只校验不解压，rar 包在下传过程中坏掉一两个块是常事，等到安装中途报「 cabinet 文件损坏」再排查就晚了。第三条certutil是系统自带的哈希工具，SHA256 比默认的 MD5 稳，拿到值以后和介质来源给的值对一遍。

第二件事是看目录结构。解压完先进去看一眼，一般能分出四类东西：安装引导（setup.exe 或 msi）、先决组件目录（.NET Framework、MDAC、JRE 之类）、补丁目录（维护版本或补丁包）、文档目录。补丁目录要单独记下来，主程序装完、能正常启动之后再打，顺序反了会出现「补丁装上了但主程序文件对不上」的尴尬局面。

第三件事是处理嵌套目录。有些 rar 解开后会多套一层同名目录，实际内容在D:\pb115_setup\PowerBuilder115\下面。这种情况我一般把内层内容整体上移一层，或者直接把内层目录当作安装根，目的还是缩短最终路径。顺手确认目标盘是 NTFS，别放在移动硬盘或者网络映射盘上，pb11.5 安装过程要往注册表和共享组件目录写东西，网络盘上装完大概率起不来。

注意：安装期间临时把杀毒软件的实时防护关掉，装完立刻恢复。pb11.5 安装时会注册大量 COM 组件和 DLL，实时防护拦截注册动作是「装到一半回滚」的常见原因之一。

2.2 系统与依赖对照表：pb11.5 能落在哪些机器上

pb11.5 是 32 位程序，这条是硬约束，后面所有选择都从这条推出来。它可以在 64 位系统上跑，走的是系统的 32 位兼容层，但它加载的每一个组件——ODBC 驱动、数据库客户端、COM 组件——都必须是 32 位版本。这是新手最容易忽略的地方：机器上明明装了数据库客户端，PB 就是说连不上，原因是装的是 64 位那套。

解释一下表里几条容易被跳过的。.NET Framework 那一行，很多人看到机器上已经有 4.x 就以为够了，实际上 pb11.5 的 .NET 目标生成的是 2.0 时代的程序集，缺 3.5 会在编译阶段直接报找不到目标框架。数据库客户端那一行，判断方法很简单：打开任务管理器看进程有没有「*32」标记，或者干脆去装客户端时选 x86 包。

磁盘和权限这两行看着像废话，实际踩坑率不低。pb11.5 安装会往系统目录写共享组件，非管理员账户装完，IDE 能启动但一编译就报权限错误。至于路径，PB 本身能认中文路径，但它调用的 C# 编译器在拼临时文件路径时不一定认，输出目录带中文导致编译失败的情况我见过不止一次。

2.3 先决组件按顺序装：.NET 3.5、IIS、数据库客户端

顺序我固定成这样：.NET Framework 3.5 → IIS（只在做 WebForm 目标时需要）→ 32 位数据库客户端 → PB 主程序 → 补丁。每装完一个，重启一次再装下一个，听起来笨，但能避免「组件装上了但没生效」这类问题。

Windows 10 及以上系统默认不带 .NET 3.5，需要单独启用。联网的机器直接开功能就行，内网机器要准备离线源：

:: 联网环境，从系统源启用 .NET 3.5 dism /online /enable-feature /featurename:NetFx3 /all :: 内网离线环境，把安装介质里的 sxs 目录挂上作为源 dism /online /enable-feature /featurename:NetFx3 /all /LimitAccess /Source:D:\sxs

/all表示把父功能一并启用，/LimitAccess是禁止去外部源找文件，/Source指向离线组件目录。内网机器不加这两个参数，命令会卡在「正在搜索源」很久然后失败。

IIS 只有在你准备做 .NET WebForm 目标时才需要，做 WinForm 或纯客户端应用的可以跳过：

:: 启用 IIS 基础角色，WebForm 目标调试需要 dism /online /enable-feature /featurename:IIS-WebServerRole /all dism /online /enable-feature /featurename:IIS-ASPNET /all

装完先决组件，做一次快速确认：打开「启用或关闭 Windows 功能」，看 .NET Framework 3.5 那一项是不是勾上的；再看数据库客户端目录里有没有 32 位的驱动文件。确认无误再进第 3 章，不要抱着「先装主程序，缺了再补」的想法，pb11.5 的安装程序不会帮你补这些，它只会在安装日志里记一笔然后继续往下走。

3. 安装 PowerBuilder 11.5 主程序：向导里那几屏别一路下一步

pb11.5 的安装向导本身不复杂，复杂的是几个默认值不适合今天的机器。路径默认落在系统盘深处，组件默认全勾，授权方式默认选到网络授权——这三处只要有一处没改，装完就是各种别扭。这一章按向导屏顺序走一遍，再补上装完第一次启动必须做的配置。

3.1 安装向导逐屏选择：路径、组件、授权方式

前面几屏是协议和欢迎页，没什么可说的。到安装路径那一屏要停一下，把默认路径改成D:\PB115，理由和上一章一样：短、无空格、不在系统盘。装在系统盘还有个隐患，某些系统清理动作会误删临时目录里的编译中间文件。

组件选择那一屏是重点，勾多了拖慢启动，勾少了后面要补装。我按用途列一下：

授权那一屏要看清是本地授权文件还是授权服务器。单机开发选本地授权文件，把介质里带的授权文件路径指过去；团队共用授权服务器的话，填服务器地址和端口，注意这台机器的系统时间必须准，时间偏差超过阈值会直接判授权无效，这个坑很隐蔽，报错信息也不会提时间。

向导跑完到进度条这一屏，正常情况十几分钟。如果进度条倒退，说明某个组件安装失败触发了回滚，不要急着重装，先按第 5 章的方法把日志捞出来看是哪一步挂的。

装完先别打补丁，先启动一次 IDE，确认能进主界面、能新建工作区，再去装补丁。补丁装完再启动一次，两次都正常，才算主程序这一关过了。

3.2 首次启动配置：workspace、Target 与库列表

pb11.5 启动后是空的，需要先建工作区（workspace，.pbw文件），再在工作区里建目标（Target，.pbt）。这两个概念新手容易混：工作区是容器，一个工作区可以挂多个目标；目标是实际的构建单元，应用的类型（纯客户端、.NET WinForm、.NET WebForm）在目标这一层定。

我习惯的目录结构是这样，工作区和源码分开，方便后面接版本管理：

D:\PB115\ ws\ 工作区文件放这里 demo.pbw demo.pbt src\ 源码（pbl 库文件） app.pbl dw.pbl win.pbl output\ 编译输出 backup\ 每日备份

建完工作区，第一件事是调库列表（Library List）。库列表决定运行时按什么顺序找对象，顺序错了会出现「明明改了代码，运行起来还是老逻辑」的玄学现象，本质是加载到了另一个库里的同名对象。我一般把基础库放前面、业务库放后面，应用对象所在库放最前面。

第二件事是设置系统选项里的默认路径，把源码目录、输出目录、备份目录都指到上面这套结构里。这些设置在 IDE 的选项里改，改完会写进用户的配置文件，换机器要重设一遍，建议在团队里统一成一份说明。

第三件事是建数据库配置（Database Profile）。这一步先不做连接测试也行，但配置项要先建好，因为后面的 DataWindow 和 .NET 目标都会引用这个配置名。具体参数在下一章展开。

3.3 环境变量与注册表：装完必须核对的几个位置

pb11.5 的 IDE 依赖安装目录下的共享组件目录，如果这个目录不在 PATH 里，表现就是双击图标一闪就退，连错误框都不给。这是最典型的翻车现场，也是最容易修的一个。

# 用 PowerShell 追加 PATH，别用 setx，setx 有 1024 字符截断问题 $p = [Environment]::GetEnvironmentVariable('Path','Machine') [Environment]::SetEnvironmentVariable('Path', $p + ';D:\PB115\Shared\PowerBuilder','Machine') # 确认写入结果 [Environment]::GetEnvironmentVariable('Path','Machine') -split ';' | Select-String 'PB115'

为什么不推荐setx /M：setx在 PATH 超过 1024 个字符时会静默截断，截断之后系统里一堆命令都找不到了，属于典型的「修一个问题引出三个问题」。PowerShell 的SetEnvironmentVariable没这个限制。改完 PATH 要重开一个终端或者注销一次才生效，别在原地反复双击图标怀疑人生。

注册表这一块，pb11.5 会在系统级的软件根键下写自己的配置，64 位系统上因为走兼容层，实际位置在WOW6432Node下面。不同发行包写入的厂商根键名不完全一致，直接按产品名搜最稳：

:: 在 32 位兼容视图里按产品名搜索子键，找到实际安装根 reg query HKLM\SOFTWARE\WOW6432Node /f "PowerBuilder" /k /s :: 找到之后核对安装路径和版本号 reg query "HKLM\SOFTWARE\WOW6432Node\<实际厂商根键>\PowerBuilder\11.5" /v "Path"

第一条命令会列出所有名字里带 PowerBuilder 的子键，输出可能有点长，正常。第二条把<实际厂商根键>换成上一条查到的名字，核对Path值是不是你装的目录。如果这个值指向一个已经不存在的旧目录，说明机器上以前装过别的版本，残留没清干净，这种情况按第 5 章第一条处理。

最后是共享组件的注册。装完如果某些功能（比如 DataWindow 预览）报控件未注册，可以手动补一次：

:: 以管理员身份运行，静默注册 DataWindow 引擎 regsvr32 /s "D:\PB115\Shared\PowerBuilder\pbdwe115.dll" :: 注册失败时去掉 /s 看具体错误 regsvr32 "D:\PB115\Shared\PowerBuilder\pbdwe115.dll"

/s是静默，不弹成功框。注册失败最常见的原因是文件被占用或者当前不是管理员，去掉/s会弹出具体错误码，比猜快得多。文件名里的115是版本标识，实际文件名以安装目录里看到的为准。

4. 数据库连接与 .NET 目标：让 pb11.5 真正跑起业务的两条腿

IDE 能启动只是第一步。pb11.5 装完能不能干活，取决于两件事：连不连得上数据库、能不能把目标编译成 .NET 程序集。这两条腿任何一条瘸了，工具就等于没装。这一章把 ODBC 数据源、事务对象连接语法和 .NET 编译配置一次讲透。

4.1 建一个 32 位 ODBC 数据源：odbcad32 别开错

64 位系统上有两个 ODBC 数据源管理器，开始菜单里默认打开的是 64 位那个，而 pb11.5 是 32 位程序，只认 32 位数据源。在 64 位管理器里建完 DSN，PB 这边照样报「找不到数据源」，这个坑几乎每个新手都会踩一次。

:: 必须用 SysWOW64 下的这个，才是 32 位数据源管理器 C:\Windows\SysWOW64\odbcad32.exe

打开之后在「用户 DSN」或「系统 DSN」页签新建，选对应的数据库驱动，填服务器地址、数据库名、登录账号，点「测试连接」通过再保存。服务类应用建议建系统 DSN，用户 DSN 只对当前登录账户可见，换一个账户跑服务就找不到。

建完核对一下注册表，确认 DSN 落在 32 位视图里：

:: 32 位 DSN 会写在这个位置，名字换成你建的那个 reg query "HKLM\SOFTWARE\WOW6432Node\ODBC\ODBC.INI\pb115demo" /s

能看到 Server、Database、Driver 这几项就说明建对了。如果这条命令查不到，但你确信自己建过，八成是建到 64 位管理器里去了，回去用SysWOW64那个重来一遍。

4.2 事务对象连接语法与参数取舍

pb11.5 里所有数据库操作都围绕一个叫 SQLCA 的全局事务对象。连库就是给它的字段赋值，然后 CONNECT。字段不多，但每个都有讲究：

DBMS这一项最容易写错，它不是随便写的字符串，必须和安装目录下接口配置文件里登记的接口名完全一致，大小写错了也连不上。不确定有哪些接口名，直接打开安装目录下的接口配置文件看，里面按小节列了所有可用接口。

// 走原生客户端接口的连接写法 SQLCA.DBMS = "SNC SQL Native Client(OLE DB)" SQLCA.Database = "pbdemo" SQLCA.ServerName = "127.0.0.1,1433" SQLCA.LogId = "pbuser" SQLCA.LogPass = "******" SQLCA.AutoCommit = False SQLCA.DBParm = "PROVIDER='SQLNCLI10',DATASOURCE='127.0.0.1',PROVIDERSTRING='database=pbdemo'" CONNECT USING SQLCA; IF SQLCA.SQLCode <> 0 THEN MessageBox("连接失败", SQLCA.SQLErrText) HALT CLOSE END IF

SQLCode是连接结果，0 表示成功，-1 表示出错，100 表示无数据，这三个值是判断分支的基础。SQLErrText里是数据库返回的原始错误信息，出问题第一时间看它，比看 PB 自己弹的提示有用。HALT CLOSE是直接终止应用，用在启动阶段连不上库的场景，比让用户带着一个坏连接继续操作安全。

如果环境里只能用 ODBC，写法换成这样，把连接信息塞进DBParm的ConnectString：

// ODBC 方式，DSN 必须是 32 位数据源管理器里建的那个 SQLCA.DBMS = "ODBC" SQLCA.AutoCommit = False SQLCA.DBParm = "ConnectString='DSN=pb115demo;UID=pbuser;PWD=******'" CONNECT USING SQLCA; IF SQLCA.SQLCode <> 0 THEN MessageBox("连接失败", SQLCA.SQLErrText) HALT CLOSE END IF

两种方式的取舍：原生客户端接口性能更好、支持的特性多，但要装对应的 32 位客户端；ODBC 依赖少、换库方便，但多一层驱动，出问题时排查链路更长。老项目里两种写法常常并存，改的时候先确认原来用的哪种，别混着改。

账号密码不要写死在代码里，我一般放到配置文件或者环境变量里读，源码里只留占位。老项目里那种明文写在应用对象 Open 事件里的做法，接手之后第一件事就是挪出去。

4.3 .NET 目标编译配置：csc.exe 指到哪

pb11.5 生成 .NET 程序集的方式有点特殊：它把非可视对象翻译成 C# 代码，再调用 C# 编译器编译。所以光装 .NET 运行时不够，必须有编译器，而且路径要指对。

配置在 IDE 的选项里，找到 .NET 相关页签，填两个东西：C# 编译器路径和目标框架版本。编译器路径指向Framework目录下的v3.5，注意不是Framework64，pb11.5 编译过程是 32 位的，指到 64 位目录会报找不到编译器或者版本不匹配。

# 先看本机装了哪些框架版本目录，确认 v3.5 存在 Get-ChildItem "$env:WINDIR\Microsoft.NET\Framework" -Directory | Select-Object -ExpandProperty Name

输出里要能看到v3.5。如果只有v4.0.30319，说明只装了 4.x，回第 2 章补 .NET 3.5。这一步做了但编译还是报找不到编译器，多半是把路径指到了Framework64，改成Framework就行。

目标属性的配置项不多，关键是输出类型和程序集名称：

编译分两步：先 Deploy，再 Build。Deploy 做的是把 PB 运行时 DLL 复制到输出目录，Build 才是真正编译。只 Build 不 Deploy，输出目录里会缺运行时 DLL，拿到别的机器上一跑就报缺文件。编译完检查一下输出目录：

:: 看输出目录里有没有主程序和运行时 DLL dir /b D:\PB115\output\*.exe dir /b D:\PB115\output\*.dll

正常应该有应用主程序 exe、业务 DLL，以及一批 PB 运行时 DLL。如果 exe 有但 DLL 寥寥无几，回去补一次 Deploy。目标机器上要装 .NET Framework 3.5，这一点在交付文档里必须写清楚，不然用户机器上双击没反应，你还得跑一趟。

5. 排查与避坑：pb11.5 装完起不来、连不上的 5 个现场

前面几章是顺路径，这一章全是逆路径。下面五条是我这些年反复遇到的现场，每条按「现象 → 原因 → 解决」写，遇到问题可以直接对号入座。

5.1 安装阶段的现场：回滚与残留

第一条：安装进度条倒退，提示某个组件安装失败。

现象：向导跑到一半开始回滚，最后弹一个很笼统的失败提示，看不出是哪一步。原因通常是三类：机器上残留了旧版本的同名组件、安装过程被杀毒软件拦了注册动作、安装包本身不完整。解决顺序是先看日志再动手：安装程序一般会在系统临时目录下留 MSI 日志，直接去%TEMP%下按时间排序找最新的日志文件，搜Return value 3，那一行往上几行就是真正失败的动作。

:: 主动带日志重装一次，日志路径自己定 msiexec /i D:\pb115_setup\PowerBuilder.msi /l*v D:\pb_install.log

/l*v是详细日志，装完拿记事本打开搜Return value 3。如果是残留问题，去控制面板把旧版本卸干净，再手动删掉安装目录和前面查到的注册表根键，重启后再装。如果是杀毒拦截，临时关掉实时防护重来。

第二条：安装向导不认授权文件，或者提示授权无效。

现象：授权文件明明选了，向导还是报无效，或者装完启动提示授权过期。原因有三个：授权文件和安装包版本不匹配、系统时间偏差过大、机器上残留了旧的试用授权。先校准系统时间，再确认授权文件对应的版本号，最后清理残留的授权注册项。时间这一条最容易被忽略，报错信息里根本不会提。

5.2 运行阶段的现场：闪退、连库、编译

第三条：双击 IDE 图标，进程一闪就消失，没有任何提示。

现象：任务管理器里能看到进程起来又没了，事件查看器里最多一条应用程序错误。原因基本是共享组件目录不在 PATH 里，导致核心运行时 DLL 加载失败。解决分两步：先确认安装目录下的共享组件目录里确实有运行时 DLL 文件；再按 3.3

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