开发工具构建工具【免费下载链接】wix3WiX Toolset v3.x项目地址https://gitcode.com/gh_mirrors/wi/wix3点击查看免费下载本文基于 WiX Toolset 仓库中的 lit 官方文档 展开完整覆盖 litLibrary Tool的命令行用法与全部参数并结合 lit 主程序源码、Librarian 核心类 与 wixlib 集成测试 深入讲解其内部工作机制。读完本文你将掌握如何在 WiX 构建流程中用 lit 将多个.wixobj对象文件组合成.wixlib库、如何配置-bf文件绑定与-loc本地化字符串以及如何在 MSBuild 项目.wixproj中通过Lit任务自动化这一流程。lit 在 WiX 构建流程中的位置WiX 的 MSI 构建采用“编译—链接”两阶段模型candle.exe负责把.wxs源文件编译为中间对象文件.wixobjlight.exe负责把多个.wixobj链接为最终的.msi。在这两个工具之间存在一个可选的中间环节即 lit.wxs ──candle── .wixobj ──lit── .wixlib ──light── .msiLit 的定位是库创建工具它把多个.wixobj文件合并为一个.wixlib库文件这个库随后可以作为 light 的输入被消费。其典型价值在于把一组相关的 WiX 源例如一个可复用的组件集、一个“功能块”预先组合打包供其他产品包以“库”的形式引用而无需在 light 阶段罗列所有对象文件。这一点可以从源码的入口注释直接印证——lit.cs 中的Lit类被标注为 “Main entry point for library tool.”而 Librarian 类 的注释则写明 “Core librarian tool”其Combine方法的文档注释明确写着 “Create a library by combining several intermediates (objects).”用法与命令行参数官方文档给出的完整调用形式为lit.exe [-?] [-nologo] [-out libraryFile] objectFile [objectFile ...] [responseFile]其中objectFile为 candle 产出的.wixobj文件实际上也接受已有的.wixlib见下文源码分析responseFile表示响应文件可以在一行一行列出参数以便复用。lit 支持的全部命令行参数如下完整继承自官方文档的 参数表开关含义-b指定用于定位所有文件的基路径base path默认值为当前工作目录。可重复使用也支持namepath的命名形式见下文-bfBind files into the library file即把源文件绑定进库文件内部默认不绑定-ext extension指定扩展程序集WixExtension 实现可加载多张表定义并解析 lit 自身不认识的附加参数-loc loc.wxl提供.wxl本地化文件将本地化字符串读入库-nologo跳过 lit 版本/logo 信息的输出-out指定输出库文件路径默认情况下 lit 会写入当前工作目录-pedantic显示 pedantic吹毛求疵级提示消息-ss抑制文档的 schema 校验链接大型项目时可换取明显的性能提升-sv抑制中间文件.wixobj版本不匹配检查-swN按消息 ID 抑制指定警告可多次使用例如-sw1011 -sw1012-swall抑制所有警告已弃用等价于无参数-sw-v生成详细verbose输出-wxN把指定 ID 的警告提升为错误例如-wx1011 -wx1012-wxall把所有警告当作错误已弃用等价于无参数-wx-?显示 lit 帮助信息从 ParseCommandLine 方法 的实现可以看到文档与行为之间的几处对应细节-b支持命名基路径解析-b时并不只收集目录。Run 方法 会把不含的-b值加入sourcePaths而在处理-bf时第 214–229 行会把namepath形式的值拆开后写入NamedBindPaths。也就是说命名形式用于在绑定文件时按名字定位而普通形式同时充当源搜索路径与绑定搜索路径。默认输出文件名当只给了一个输入文件且未显式-out时lit 会把该输入文件扩展名替换为.wixlib作为输出第 111–119 行如果给了多个输入文件却未指定-out则会抛出MustSpecifyOutputWithMoreThanOneInput错误。-sw/-wx的“空参即全部”语义-sw后面不带数字时等价于抑制全部警告第 356–384 行-wx同理这也正是文档标注-swall、-wxall为“deprecated”的原因——它们只是向后兼容的旧拼法触发时会通过DeprecatedCommandLineSwitch警告提示改用-sw/-wx。-ss与-sv的作用点这两个开关最终传入Intermediate.Load/Library.Load第 185–196 行分别跳过 XSD schema 校验与中间文件格式版本比对。文档中提到-ss能带来“链接期间的性能提升”对应的就是跳过每次加载.wixobj/.wixlib时的 XML schema 验证开销。响应文件以开头的参数会被CommandLineResponseFile.Parse展开后递归解析第 433–436 行。输入文件的识别先试 .wixobj再试 .wixlib一个容易被忽略的细节是lit 的输入既可以是.wixobj也可以是已有的.wixlib因此 lit 天然支持“库中库”的逐级合并。源码中对该输入做了两次尝试加载// try loading as an object file try { Intermediate intermediate Intermediate.Load(inputFileFullPath, librarian.TableDefinitions, this.suppressVersionCheck, this.suppressSchema); sections.AddRange(intermediate.Sections); continue; // next file } catch (WixNotIntermediateException) { // try another format } // try loading as a library file Library loadedLibrary Library.Load(inputFileFullPath, librarian.TableDefinitions, this.suppressVersionCheck, this.suppressSchema); sections.AddRange(loadedLibrary.Sections);见 lit.cs 第 182–197 行。即先按对象文件解析失败后再按库文件解析两种格式的 Section 被统一收集最后交给librarian.Combine(sections)合成一个新库。Combine 阶段做了什么入口 Section 与符号校验Librarian.Combine并不是简单拼接它还会执行结构校验。Librarian.cs 第 79–89 行 显示Combine在把 Section 装入新Library后调用Validate后者第 118–133 行会通过FindEntrySectionAndLoadSymbols检查库中是否存在多个入口 Sectionentry section并收集全部符号用于检查重复对每个 Section 调用ResolveReferences在库内部先解析符号引用。换句话说如果两个输入对象各自声明了会冲突的符号或都声称自己是入口 Sectionlit 会在这一阶段报错而不是留到 light 阶段才暴露——这是 lit 相比“直接把所有 .wixobj 丢给 light”多出来的一层提前校验。-bf 文件绑定把文件装进 .wixlib-bfbind files的含义是“把文件绑定进库文件”。其底层逻辑在 Library.Save 中当提供BinderFileManager即启用了-bf时lit 会遍历库中每张表、每行中的ObjectField指向外部文件的路径字段逐个调用binderFileManager.ResolveFile解析文件路径并给该字段分配一个CabinetFileId——被绑定的文件最终会打进库文件内部cabinet 形式随库一起分发而不要求 light 阶段还能在磁盘上找到这些文件。对应到 Run 方法的绑定分支若未指定-bfbinderFileManager被置为 nullLibrary.Save就不会执行任何文件绑定若指定了-bf则使用扩展提供的BinderFileManager若加载的扩展自带否则回退到内置的new BinderFileManager()-b收集到的路径会同时进入BinderFileManager.BindPaths绑定搜索路径与sourcePaths源搜索路径。因此-b与-bf是配套使用的-bf决定“是否绑定”-b决定“去哪里找要绑定的文件”文档中-b的默认值说明当前工作目录即指此搜索路径。-loc 本地化字符串-loc loc.wxl允许把 WiX 本地化源文件.wxl的字符串读入库。从 lit.cs 第 242–247 行 可以看到每个-loc文件通过Localization.Load加载后调用library.AddLocalization(localization)即本地化字符串作为库的一部分被保存供 light 在链接阶段按语言选用。这与-ext一样是可重复的开关解析代码对-loc走的是localizationFiles.Add(...)的累加分支第 315–325 行。一个可复用的调用示例基于上述分析一个典型的 lit 手工调用形如路径为示例参数含义见上文lit.exe -out ProductComponents.wixlib -bf -b ..\resources -loc strings.wxl -nologo Product.wixobj Components.wixobj含义把Product.wixobj与Components.wixobj合并为ProductComponents.wixlib-bf使对象中引用的文件被绑定进库-b ..\resources告诉 lit 去哪里解析这些文件-loc把strings.wxl的字符串一并存入库。之后的链接阶段只需light.exe -ext WixUIExtension ProductComponents.wixlib -out Product.msiMSBuild 集成wixproj 中的 Lit 任务在.wixprojWiX 项目文件体系中lit 不需要手工调用而是由 WixTasks 中的 Lit 任务 驱动。该任务继承WixToolTaskToolName固定为lit.exe第 117–120 行。把任务属性映射回命令行开关的 BuildCommandLine 方法 展示了完整的参数生成逻辑任务属性生成的命令行说明ObjectFiles必填追加为位置参数要合并的.wixobj文件OutputFile必填、输出-out输出.wixlib路径BindInputPaths/BaseInputPaths-b基/绑定路径BindInputPaths的项若带BindName元数据会生成namepath命名形式对应 CLI 的命名-b。BaseInputPaths已被标记[Obsolete]计划 v4.0 移除BindFiles-bf是否绑定文件Extensions/ExtensionDirectory/ReferencePaths-ext扩展加载LocalizationFiles-loc本地化文件Pedantic-pedantic显示 pedantic 消息SuppressSchemaValidation-ss跳过 schema 校验SuppressIntermediateFileVersionMatching-sv跳过中间文件版本检查AdditionalOptions原样拼接逃生舱口用于传入-sw、-wx等值得注意的是-nologo、-sw、-wx等在任务属性中并未一一对应而是通过WixToolTask基类的通用选项以及AdditionalOptions透传-nologo则由 MSBuild 日志行为Verbosity在基类中统一处理。测试用例佐证仓库的自动化测试为 lit 的行为提供了可直接查阅的验证依据单库链接等价性Input.WixlibTests.cs 的 SingleWixlib 测试 先用 candle 编译BasicProductWxs再用Lit对象测试框架中的Lit类自动继承Candle的输出与设置生成.wixlib最后分别用原始.wixobj和.wixlib各链接一次 MSI 并用Verifier.VerifyResults断言两者一致——证明了“经 lit 合并”不改变链接结果。多库合并MultipleWixlibs测试第 44–97 行分别构建Product.wixlib与Component.wixlib验证 light 能同时链接多个.wixlib并产生与直接链接两个.wixobj相同的结果后续还有“多库共享目录”的变体用例第 99–133 行。wixproj 构建库WixprojTests 的 SimpleLibrary 测试 构建一个简单 wixproj断言输出目录中生成WixProject.wixlibLibraryWithParameters测试第 122–140 行则进一步断言传给Lit任务的命令行包含-bf、-nologo、-sw1、-wx等子串验证项目属性到命令行开关的透传是否正确。小结lit 是 WiX Toolset 中专门用于“预链接/组合”的工具它把 candle 产出的.wixobj或既有.wixlib合并为.wixlib在合并期完成入口 Section 与符号引用校验Librarian.CombineValidate并可选地通过-bf-b把文件绑定进库、通过-loc把本地化字符串打包入库最终交给 light 完成 MSI 链接。对于手工命令行构建完整参数以本文参数表与 官方文档 为准对于 wixproj 项目构建则通过 Lit 任务 的属性完成同等配置。需要注意的适用前提是lit 消费的是 WiX 3.x 的中间文件格式-ss/-sv仅用于绕过校验/版本检查以换取性能或兼容旧对象不建议在无必要时长期开启。赞分享开发工具构建工具【免费下载链接】wix3WiX Toolset v3.x项目地址https://gitcode.com/gh_mirrors/wi/wix3点击查看免费下载相关推荐WiX Toolset 的 Lit MSBuild 任务Lit Task完整指南从 .wixproj 配置到 .wixlib 库构建WiX Toolset 的 Lit MSBuild 任务Lit Task完整指南从 .wixproj 配置到 .wixlib 库构建 导读 Lit Tas开发工具构建工具WiX Toolset 链接器 light.exe 完全指南从 .wixobj 到 MSI 数据库的链接与绑定全流程WiX Toolset 链接器 light.exe 完全指南从 .wixobj 到 MSI 数据库的链接与绑定全流程 本文以 WiX Toolset v3.x开发工具构建工具WiX Toolset 3.x 中的 Light 任务.wixproj 链接参数完整指南WiX Toolset 3.x 中的 Light 任务.wixproj 链接参数完整指南 Light 是 WiX 工具集v3.x的 MSBuild 链接任开发工具构建工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 WiX Toolset lit 库工具详解：将 .wixobj 组合成可被 light 链接的 .wixlib
开发工具构建工具【免费下载链接】wix3WiX Toolset v3.x项目地址https://gitcode.com/gh_mirrors/wi/wix3点击查看免费下载本文基于 WiX Toolset 仓库中的 lit 官方文档 展开完整覆盖 litLibrary Tool的命令行用法与全部参数并结合 lit 主程序源码、Librarian 核心类 与 wixlib 集成测试 深入讲解其内部工作机制。读完本文你将掌握如何在 WiX 构建流程中用 lit 将多个.wixobj对象文件组合成.wixlib库、如何配置-bf文件绑定与-loc本地化字符串以及如何在 MSBuild 项目.wixproj中通过Lit任务自动化这一流程。lit 在 WiX 构建流程中的位置WiX 的 MSI 构建采用“编译—链接”两阶段模型candle.exe负责把.wxs源文件编译为中间对象文件.wixobjlight.exe负责把多个.wixobj链接为最终的.msi。在这两个工具之间存在一个可选的中间环节即 lit.wxs ──candle── .wixobj ──lit── .wixlib ──light── .msiLit 的定位是库创建工具它把多个.wixobj文件合并为一个.wixlib库文件这个库随后可以作为 light 的输入被消费。其典型价值在于把一组相关的 WiX 源例如一个可复用的组件集、一个“功能块”预先组合打包供其他产品包以“库”的形式引用而无需在 light 阶段罗列所有对象文件。这一点可以从源码的入口注释直接印证——lit.cs 中的Lit类被标注为 “Main entry point for library tool.”而 Librarian 类 的注释则写明 “Core librarian tool”其Combine方法的文档注释明确写着 “Create a library by combining several intermediates (objects).”用法与命令行参数官方文档给出的完整调用形式为lit.exe [-?] [-nologo] [-out libraryFile] objectFile [objectFile ...] [responseFile]其中objectFile为 candle 产出的.wixobj文件实际上也接受已有的.wixlib见下文源码分析responseFile表示响应文件可以在一行一行列出参数以便复用。lit 支持的全部命令行参数如下完整继承自官方文档的 参数表开关含义-b指定用于定位所有文件的基路径base path默认值为当前工作目录。可重复使用也支持namepath的命名形式见下文-bfBind files into the library file即把源文件绑定进库文件内部默认不绑定-ext extension指定扩展程序集WixExtension 实现可加载多张表定义并解析 lit 自身不认识的附加参数-loc loc.wxl提供.wxl本地化文件将本地化字符串读入库-nologo跳过 lit 版本/logo 信息的输出-out指定输出库文件路径默认情况下 lit 会写入当前工作目录-pedantic显示 pedantic吹毛求疵级提示消息-ss抑制文档的 schema 校验链接大型项目时可换取明显的性能提升-sv抑制中间文件.wixobj版本不匹配检查-swN按消息 ID 抑制指定警告可多次使用例如-sw1011 -sw1012-swall抑制所有警告已弃用等价于无参数-sw-v生成详细verbose输出-wxN把指定 ID 的警告提升为错误例如-wx1011 -wx1012-wxall把所有警告当作错误已弃用等价于无参数-wx-?显示 lit 帮助信息从 ParseCommandLine 方法 的实现可以看到文档与行为之间的几处对应细节-b支持命名基路径解析-b时并不只收集目录。Run 方法 会把不含的-b值加入sourcePaths而在处理-bf时第 214–229 行会把namepath形式的值拆开后写入NamedBindPaths。也就是说命名形式用于在绑定文件时按名字定位而普通形式同时充当源搜索路径与绑定搜索路径。默认输出文件名当只给了一个输入文件且未显式-out时lit 会把该输入文件扩展名替换为.wixlib作为输出第 111–119 行如果给了多个输入文件却未指定-out则会抛出MustSpecifyOutputWithMoreThanOneInput错误。-sw/-wx的“空参即全部”语义-sw后面不带数字时等价于抑制全部警告第 356–384 行-wx同理这也正是文档标注-swall、-wxall为“deprecated”的原因——它们只是向后兼容的旧拼法触发时会通过DeprecatedCommandLineSwitch警告提示改用-sw/-wx。-ss与-sv的作用点这两个开关最终传入Intermediate.Load/Library.Load第 185–196 行分别跳过 XSD schema 校验与中间文件格式版本比对。文档中提到-ss能带来“链接期间的性能提升”对应的就是跳过每次加载.wixobj/.wixlib时的 XML schema 验证开销。响应文件以开头的参数会被CommandLineResponseFile.Parse展开后递归解析第 433–436 行。输入文件的识别先试 .wixobj再试 .wixlib一个容易被忽略的细节是lit 的输入既可以是.wixobj也可以是已有的.wixlib因此 lit 天然支持“库中库”的逐级合并。源码中对该输入做了两次尝试加载// try loading as an object file try { Intermediate intermediate Intermediate.Load(inputFileFullPath, librarian.TableDefinitions, this.suppressVersionCheck, this.suppressSchema); sections.AddRange(intermediate.Sections); continue; // next file } catch (WixNotIntermediateException) { // try another format } // try loading as a library file Library loadedLibrary Library.Load(inputFileFullPath, librarian.TableDefinitions, this.suppressVersionCheck, this.suppressSchema); sections.AddRange(loadedLibrary.Sections);见 lit.cs 第 182–197 行。即先按对象文件解析失败后再按库文件解析两种格式的 Section 被统一收集最后交给librarian.Combine(sections)合成一个新库。Combine 阶段做了什么入口 Section 与符号校验Librarian.Combine并不是简单拼接它还会执行结构校验。Librarian.cs 第 79–89 行 显示Combine在把 Section 装入新Library后调用Validate后者第 118–133 行会通过FindEntrySectionAndLoadSymbols检查库中是否存在多个入口 Sectionentry section并收集全部符号用于检查重复对每个 Section 调用ResolveReferences在库内部先解析符号引用。换句话说如果两个输入对象各自声明了会冲突的符号或都声称自己是入口 Sectionlit 会在这一阶段报错而不是留到 light 阶段才暴露——这是 lit 相比“直接把所有 .wixobj 丢给 light”多出来的一层提前校验。-bf 文件绑定把文件装进 .wixlib-bfbind files的含义是“把文件绑定进库文件”。其底层逻辑在 Library.Save 中当提供BinderFileManager即启用了-bf时lit 会遍历库中每张表、每行中的ObjectField指向外部文件的路径字段逐个调用binderFileManager.ResolveFile解析文件路径并给该字段分配一个CabinetFileId——被绑定的文件最终会打进库文件内部cabinet 形式随库一起分发而不要求 light 阶段还能在磁盘上找到这些文件。对应到 Run 方法的绑定分支若未指定-bfbinderFileManager被置为 nullLibrary.Save就不会执行任何文件绑定若指定了-bf则使用扩展提供的BinderFileManager若加载的扩展自带否则回退到内置的new BinderFileManager()-b收集到的路径会同时进入BinderFileManager.BindPaths绑定搜索路径与sourcePaths源搜索路径。因此-b与-bf是配套使用的-bf决定“是否绑定”-b决定“去哪里找要绑定的文件”文档中-b的默认值说明当前工作目录即指此搜索路径。-loc 本地化字符串-loc loc.wxl允许把 WiX 本地化源文件.wxl的字符串读入库。从 lit.cs 第 242–247 行 可以看到每个-loc文件通过Localization.Load加载后调用library.AddLocalization(localization)即本地化字符串作为库的一部分被保存供 light 在链接阶段按语言选用。这与-ext一样是可重复的开关解析代码对-loc走的是localizationFiles.Add(...)的累加分支第 315–325 行。一个可复用的调用示例基于上述分析一个典型的 lit 手工调用形如路径为示例参数含义见上文lit.exe -out ProductComponents.wixlib -bf -b ..\resources -loc strings.wxl -nologo Product.wixobj Components.wixobj含义把Product.wixobj与Components.wixobj合并为ProductComponents.wixlib-bf使对象中引用的文件被绑定进库-b ..\resources告诉 lit 去哪里解析这些文件-loc把strings.wxl的字符串一并存入库。之后的链接阶段只需light.exe -ext WixUIExtension ProductComponents.wixlib -out Product.msiMSBuild 集成wixproj 中的 Lit 任务在.wixprojWiX 项目文件体系中lit 不需要手工调用而是由 WixTasks 中的 Lit 任务 驱动。该任务继承WixToolTaskToolName固定为lit.exe第 117–120 行。把任务属性映射回命令行开关的 BuildCommandLine 方法 展示了完整的参数生成逻辑任务属性生成的命令行说明ObjectFiles必填追加为位置参数要合并的.wixobj文件OutputFile必填、输出-out输出.wixlib路径BindInputPaths/BaseInputPaths-b基/绑定路径BindInputPaths的项若带BindName元数据会生成namepath命名形式对应 CLI 的命名-b。BaseInputPaths已被标记[Obsolete]计划 v4.0 移除BindFiles-bf是否绑定文件Extensions/ExtensionDirectory/ReferencePaths-ext扩展加载LocalizationFiles-loc本地化文件Pedantic-pedantic显示 pedantic 消息SuppressSchemaValidation-ss跳过 schema 校验SuppressIntermediateFileVersionMatching-sv跳过中间文件版本检查AdditionalOptions原样拼接逃生舱口用于传入-sw、-wx等值得注意的是-nologo、-sw、-wx等在任务属性中并未一一对应而是通过WixToolTask基类的通用选项以及AdditionalOptions透传-nologo则由 MSBuild 日志行为Verbosity在基类中统一处理。测试用例佐证仓库的自动化测试为 lit 的行为提供了可直接查阅的验证依据单库链接等价性Input.WixlibTests.cs 的 SingleWixlib 测试 先用 candle 编译BasicProductWxs再用Lit对象测试框架中的Lit类自动继承Candle的输出与设置生成.wixlib最后分别用原始.wixobj和.wixlib各链接一次 MSI 并用Verifier.VerifyResults断言两者一致——证明了“经 lit 合并”不改变链接结果。多库合并MultipleWixlibs测试第 44–97 行分别构建Product.wixlib与Component.wixlib验证 light 能同时链接多个.wixlib并产生与直接链接两个.wixobj相同的结果后续还有“多库共享目录”的变体用例第 99–133 行。wixproj 构建库WixprojTests 的 SimpleLibrary 测试 构建一个简单 wixproj断言输出目录中生成WixProject.wixlibLibraryWithParameters测试第 122–140 行则进一步断言传给Lit任务的命令行包含-bf、-nologo、-sw1、-wx等子串验证项目属性到命令行开关的透传是否正确。小结lit 是 WiX Toolset 中专门用于“预链接/组合”的工具它把 candle 产出的.wixobj或既有.wixlib合并为.wixlib在合并期完成入口 Section 与符号引用校验Librarian.CombineValidate并可选地通过-bf-b把文件绑定进库、通过-loc把本地化字符串打包入库最终交给 light 完成 MSI 链接。对于手工命令行构建完整参数以本文参数表与 官方文档 为准对于 wixproj 项目构建则通过 Lit 任务 的属性完成同等配置。需要注意的适用前提是lit 消费的是 WiX 3.x 的中间文件格式-ss/-sv仅用于绕过校验/版本检查以换取性能或兼容旧对象不建议在无必要时长期开启。赞分享开发工具构建工具【免费下载链接】wix3WiX Toolset v3.x项目地址https://gitcode.com/gh_mirrors/wi/wix3点击查看免费下载相关推荐WiX Toolset 的 Lit MSBuild 任务Lit Task完整指南从 .wixproj 配置到 .wixlib 库构建WiX Toolset 的 Lit MSBuild 任务Lit Task完整指南从 .wixproj 配置到 .wixlib 库构建 导读 Lit Tas开发工具构建工具WiX Toolset 链接器 light.exe 完全指南从 .wixobj 到 MSI 数据库的链接与绑定全流程WiX Toolset 链接器 light.exe 完全指南从 .wixobj 到 MSI 数据库的链接与绑定全流程 本文以 WiX Toolset v3.x开发工具构建工具WiX Toolset 3.x 中的 Light 任务.wixproj 链接参数完整指南WiX Toolset 3.x 中的 Light 任务.wixproj 链接参数完整指南 Light 是 WiX 工具集v3.x的 MSBuild 链接任开发工具构建工具创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考