文章目录

• • vs2019 - 打包(开发机win10x64 - 目标机win7x64 - debug版程序)
  • 概述
  • 笔记
  • 添加组件
  • 添加程序集
  • 删掉组件时，支持多选
  • 加入全部组件后，需要删除的组件如下
  • 删掉有依赖的组件
  • 去掉有依赖的组件后，编译结果有很明显的区别
  • VS2019打包工程确实有bug
  • • mfc140ud.dll需要的组件
    • VCRUNTIME140D.dll需要的组件
    • ucrtbased.dll需要的组件
  • 最终下载的win7x64 ucrt补丁一共有3个
  • 需要添加自己应用缺的dll
  • 在自己应用中补充缺少的vs2019DLL
  • • 补充缺少的vs2019DLL的本地来源
  • 建立打包工程
  • 给安装后的目录添加子文件夹
  • 给安装后的目录中添加文件
  • • 给安装后目录的子目录中添加文件
  • 可以在目标计算机添加更多位置的文件夹
  • 添加应用的快捷方式
  • 给安装程序添加组件
  • 设置工程安装的选项
  • 修改默认安装路径
  • 用户桌面文件夹的总是建立要选为true
  • 修改版本号后，最好将产品代码的GUID也更新一下
  • 备注 - ucrt
  • 备注
  • 备注 - 使用体验
  • 备注 - win8.1环境
  • windows的ucrt补丁的总链接
  • 备注 - 修改打包编译输出的名称
  • 在桌面自己建立的文件夹中再建立自己应用安装后的文件夹的快捷方式
  • 补充缺少的vs2019DLL的Release版本地来源
  • 补充 - ucrtbase.dll
  • WARNING: Two or more objects have the same target location ('[targetdir]\ucrtbased.dll')
  • END

vs2019 - 打包(开发机win10x64 - 目标机win7x64 - debug版程序)

概述

一般打包时，需要将工程输出都编译成release版。
但是我想先试试debug版，做个debug版的安装包。安装到测试机上，如果有问题，可以看到debug版的断言。

用vs2019setup工程默认打包后的安装包，因为只有自己应用相关的文件，到新的测试环境后，是无法正常运行的。e.g. 刚安装完的win7x64旗舰版。
运行自己的应用，总会少vs2019自己的dll.

这时，应该在setup工程中添加vs2019自己的组件，保证自己应用的vs2019环境是全的。重新打个包。

笔记

添加组件

如果不知道应该安装哪个vs2019组件，就全选。
因为是无脑的选择，有些组件无法引入setup工程，有报错。

ERROR: Unable to import merge module 'C:\Program Files (x86)\Common Files\Merge Modules\niWininet.msm'
WARNING: Error merging 'MDAC.MSM': Unable to merge data from the merge module because it conflicts with existing data in the package.
MergeModule: table='File' row='adcvbs.inc'
Database: table='File' row='adcvbs.inc'
WARNING: Error merging 'MDAC.MSM': Unable to merge data from the merge module because it conflicts with existing data in the package.
MergeModule: table='File' row='odbc32gt.dll'
Database: table='File' row='odbc32gt.dll'
Database: table='File' row='adcjavas.inc'
ERROR: Unable to import merge module 'C:\Program Files (x86)\Common Files\Merge Modules\nidcom95.msm'
Build process cancelled
========== 全部重新生成: 成功 0 个，失败 1 个，跳过 0 个 ==========

将这些错误的组件从setup工程移除。再打包。
移除的组件如下：

niWininet.msm
MDAC.MSM
nidcom95.msm

移除不能引入的组件后，打包成功

Packaging file 'POLICY~7.DLL'...
Packaging file 'mfc140d.dll'...
========== 全部重新生成: 成功 1 个，失败 0 个，跳过 0 个 ==========

但是有些警告如下：

已启动重新生成…
------ Starting pre-build validation for project 'caseSetupPrj' ------ 
WARNING: Unable to find module dependency with signature 'OpenGL32.09188572_BCB5_11D3_AB7C_006008CA11D7'
WARNING: Unable to find module dependency with signature 'MSVCRT.51D569E0_8A28_11D2_B962_006097C4DE24'
// ...
------ Pre-build validation for project 'caseSetupPrj' completed ------
------ 已启动全部重新生成: 项目: caseSetupPrj, 配置: Debug ------
Building file 'D:\my_dev\my_local_git_prj\xx\src\installer\caseSetupPrj\Debug\caseSetupPrj.msi'...
WARNING: Two or more objects have the same target location ('[payload_ul]\8.0.50727.5592.policy')
WARNING: Two or more objects have the same target location ('[payload_ul]\8.0.50727.5592.policy')

这些警告咱不懂啊，不管了。
试试添加vs2019组件后，重新打包的安装程序在新环境计算机上是否好使?

可以看到加了vs2019组件的安装包比没加组件的安装包大了大概50MB.
尝试安装

安装程序本身需要4.7.2了…
我的应用没用这玩应啊…, 估计是选的那些vs2019组件需要dotnet472.
点击是，得到4.7.2的下载链接 http://go.microsoft/fwlink/?LinkId=863262
是在线版安装包，这不行啊。
在网上找到了离线版安装包 https://go.microsoft/fwlink/?linkid=863265
先下载(ndp472-kb4054530-x86-x64-allos-enu.exe 大概80MB)，然后尝试是否可以打在VS2019的setup工程中。

添加程序集

打包完成，发现比打了组件的安装包，又大了170MB.
尝试安装运行。

安装程序还是需要dotnet472, 无法将dotnet472打在安装包中。
那提供2个安装包包吧，一个是MS原版的472安装包，一个是自己打了vs2019组件的安装包。

先安装472, 发现win7不支持472.
那就不能安装那么多vs2019组件了，需要将多余组件去掉才行。只保留自己应用相关的组件。

在setup工程中，看到安装程序是依赖的。尝试去掉多余的组件，看看是否还需要
将组件从setup工程中都删除了，就没有依赖了。

那再全加上，慢慢删掉组件，看删到那个组件，显示不需要环境？

安装包本身需要的依赖项，可以在依赖项文件夹上右击"刷新依赖项"来查看。
通过实现发现，依赖项是可以实时更新的，如果删掉哪个组件，导致安装程序不需要依赖了，马上就能显示。

删掉Microsoft_VC80_CRT_x86.msm后，显示安装程序需要Microsoft_VC80_CRT_x86.msm.

删掉MStudioCommon.2005.msm后，就不需要Microsoft_VC80_CRT_x86.msm了。

删掉MStudioCommon.msm后，就不需要支持了。
现在有点明白了，MStudioCommon.msm和MStudioCommon.2005.msm可能是写VS2019插件DLL才要的组件。
现在知道了，将组件全部去掉，再重新加入，将MStudioCommon.msm和MStudioCommon.2005.msm拿掉，再打个包试试。

删掉组件时，支持多选

一个一个删除setup工程中的参与编译项，太麻烦了，试了，可以多选，然后按delete键一次性移除。

加入全部组件后，需要删除的组件如下

niWininet.msm
MDAC.MSM
nidcom95.msm
MStudioCommon.2005.msm
MStudioCommon.msm

现在打包完，仅仅比没加组件的打包版本大50MB.
试试。

安装程序还需要?
重新启动虚拟机再试试。
安装程序还需要.
那就得在setup工程中，再删掉可能需要的组件。

删掉有依赖的组件

先尝试将还需要依赖的组件拿掉。

如果加入的组件不依赖其他组件，就留在setup工程中。
再尝试打包。

去掉有依赖的组件后，编译结果有很明显的区别

已启动重新生成…
------ Starting pre-build validation for project 'caseSetupPrj' ------ 
------ Pre-build validation for project 'caseSetupPrj' completed ------
------ 已启动全部重新生成: 项目: caseSetupPrj, 配置: Debug ------
Building file 'D:\my_dev\my_local_git_prj\xx\src\installer\caseSetupPrj\Debug\caseSetupPrj.msi'...
WARNING: Two or more objects have the same target location ('[payload_ul]\8.0.50727.5592.cat')
WARNING: Two or more objects have the same target location ('[payload_ul]\8.0.50727.5592.cat')
// 上述警告说安装位置一样，这不是问题(重复安装就重复安装)
Packaging file 'z2yaprdo.dll'...
Packaging file 'xx.dll'...
// ...
Packaging file '3xubcbxg.etb'...
========== 全部重新生成: 成功 1 个，失败 0 个，跳过 0 个 ==========

这次编译结果，没有了另外一个警告 WARNING: Unable to find module dependency with signature ‘OpenGL32.09188572_BCB5_11D3_AB7C_006008CA11D7’

看着像打包没问题了，再试试。

这次只加没依赖的组件，比只加自己应用的版本大40MB

居然还需要472…
是不是虚拟机缓存文件的问题? 尝试将setup工程改名，将GUID的值换了，再试试。
还是需要472, 不是安装程序缓存的问题。

那只能再尝试删掉一些组件，再打包试试。

一个一个删除，然后打包，不行，安装程序需要472.
直到删掉最后一个组件，已经和开始新建工程一样了，打包后还是需要472.
这不科学啊，估计是打包工程有bug.

重新建立一个工程，先添加自己应用的文件，打包试试。
然后再添加必要的组件，打包再试试。

VS2019打包工程确实有bug

如果加入了组件，即使将组件移除，如果这个组件原来依赖. 移除之后，setup工程打包后的安装程序还是需要.
必须在工程中新加入自己需要的组件才行，只要一加入，这个组件就会被打包好的setup程序用上。
所以要保证组件在一个工程中，只能新加入一次。
如果组件加错了，要重新在新建的setup工程中重新加入，而不能在旧工程中改。

mfc140ud.dll需要的组件

如果程序运行时，缺少mfc140ud.dll, 添加组件 Microsoft_VC140_DebugMFC_x64.msm 就好了。

VCRUNTIME140D.dll需要的组件

如果缺VCRUNTIME140D.dll， 加入Microsoft_VC140_DebugCRT_x64.msm

ucrtbased.dll需要的组件

https://www.microsoft/en-us/download/details.aspx?id=49093

https://www.microsoft/zh-cn/download/details.aspx?id=49093

ucrtbased.dll是系统的补丁，需要windows升级才行。
对于win7,需要安装KB2999226补丁
这个补丁必须在win7Sp1上才行，原版的win7不行(win7x64旗舰版 - 6.1.7600)
看来我用（win7x64旗舰版 - 6.1.7600）时，vmware安装vmtools时要求更新到win7sp1是有道理的…

最终下载的win7x64 ucrt补丁一共有3个

windows6.1-kb2533552-x64_0ba5ac38d4e1c9588a1e53ad390d23c1e4ecd04d.msu
windows6.1-kb976932-x64_74865ef2562006e51d7f9333b4a8d45b7a749dab.exe
Windows6.1-KB2999226-x64.msu
安装次序如上。
windows6.1-kb2533552-x64_0ba5ac38d4e1c9588a1e53ad390d23c1e4ecd04d.msu 和 windows6.1-kb976932-x64_74865ef2562006e51d7f9333b4a8d45b7a749dab.exe 是给win7x64原版升级到win7sp1x64

Windows6.1-KB2999226-x64.msu 是在win7sp1x64基础上，添加ucrt库。

需要添加自己应用缺的dll

上面添加的.msm一共5个如下：

microsoft_vc140_crt_x64.msm
Microsoft_VC140_DebugCRT_x64.msm
Microsoft_VC140_DebugMFC_x64.msm
MIcrosoft_VC140_MFC_x64.msm
MSVCRT.msm

这些.msm会向目标机的C:\Windows\System32\中拷贝VS2019的基础dll
自己手工拷贝这些vs2019的基础dll到自己工程，很麻烦，不靠谱。 还是用打包添加组件的方式来的方便靠谱。

在自己应用中补充缺少的vs2019DLL

在上述打包基础上，根据提示，缺哪个DLL就补充哪个DLL.
补充的DLL从在自己开发机上找，都在VS2019的安装目录和windows SDK的安装目录中。
补充的DLL如下：

concrt140d.dll
msvcp140_1d.dll
msvcp140_2d.dll
msvcp140d.dll
msvcp140d_atomic_wait.dll
msvcp140d_codecvt_ids.dll
ucrtbased.dll
vccorlib140d.dll
vcruntime140.dll
vcruntime140_1d.dll
vcruntime140d.dll

补充缺少的vs2019DLL的本地来源

C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Redist\MSVC\14.29.30133\debug_nonredist\x64\Microsoft.VC142.DebugCRT

concrt140d.dll
msvcp140_1d.dll
msvcp140_2d.dll
msvcp140d.dll
msvcp140d_atomic_wait.dll
msvcp140d_codecvt_ids.dll
vccorlib140d.dll
vcruntime140_1d.dll
vcruntime140d.dll

C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Redist\MSVC\14.29.30133\x64\Microsoft.VC142.CRT
vcruntime140.dll

C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.UniversalCRT.Debug\10.0.22000.0\Redist\Debug\x64

ucrtbased.dll

建立打包工程

给安装后的目录添加子文件夹

如果应用需要子文件夹中的东西，可能由于权限问题，无法在目标机上建立子文件夹。
这时，在安装程序中就预先建立好，这个主意好。

给安装后的目录中添加文件

添加文件时，如果提示有组件中包含这些文件，是否添加组件，选择否。
组件另外添加。
操作完成时，可以看到在目标机的应用文件夹中，就有我们添加的安装后的文件了。

给安装后目录的子目录中添加文件

和"给安装后的目录中添加文件"操作步骤一样，只不过需要在添加的子文件夹上右击，选择添加文件。

可以在目标计算机添加更多位置的文件夹

添加应用的快捷方式

改快捷方式的图标

给安装程序添加组件

根据自己应用的实际需要添加必要的组件，对于本实验(VS2019 + MFC + X64), 添加一下5个组件。

microsoft_vc140_crt_x64.msm
Microsoft_VC140_DebugCRT_x64.msm
Microsoft_VC140_DebugMFC_x64.msm
MIcrosoft_VC140_MFC_x64.msm
MSVCRT.msm

设置工程安装的选项

为所有用户安装
安装前，自动卸载旧版本。

修改默认安装路径

e.g. 想将程序安装到一个英文路径且没有空格的目录。

用户桌面文件夹的总是建立要选为true

不知道是不是我自己改成false的，重新生成时有报错提示，要将桌面文件夹的“总是创建”改为true才行。

修改版本号后，最好将产品代码的GUID也更新一下

备注 - ucrt

ucrt是同一运行时库，是作为OS的一部分内建组件。无法包含在安装包内。VS2019是这样。
如果自己做的安装包报错为 api_x.dll没找到之类的，就是系统需要打ucrt的升级补丁(对于win7原版来说，就要升级到win7sp1 + win7x64的ucrt的补丁)

备注

上述打包过程正确，可以生成想要的x64安装包。
已经试过了，安装后好使。
如果要打release版的包，区别：

• 将工程输出都搞成release版
• 添加release版的组件

备注 - 使用体验

用VS2019的setup工程添加组件挺方便的。
VS2019的setup工程基本功能都有，只要用了第一遍，估计就不想换其他第三方的安装制作程序了。
和微软家出的其他产品一样，只要不想做太精致的东西(能用(功能性的特性都在)，但是不好看)，就微软家自带的就行。

备注 - win8.1环境

也需要安装ucrt环境，否则会报错 api-x.dll找不到之类。
https://www.microsoft/zh-cn/download/details.aspx?id=49081
下载后为 Windows8.1-KB2999226-x64.msu，不大，传进win8.1，然后安装一下，有了ucrt环境，VS2019打包，安装到win8.1的程序就可以正常运行了。

windows的ucrt补丁的总链接

https://support.microsoft/zh-cn/topic/windows-%E4%B8%AD%E7%9A%84%E9%80%9A%E7%94%A8-c-%E8%BF%90%E8%A1%8C%E6%97%B6%E6%9B%B4%E6%96%B0-c0514201-7fe6-95a3-b0a5-287930f3560c
从官方资料看，很多操作系统都需要单独安装ucrt环境。

win8.1 - x86/x64
winserver2012 -R2
win8 - x86/x64
winserver 2012
win7 - x86/x64
winserver2008 - R2
vista - x86/x64
winserver2008 - x86/x64

如果不想被ucrt困扰，只能使用VS2013.
但是现在好多库（第三方/开源）都升级到用VS2019编译了。
做好程序让用户使用，如果他的环境没打ucrt补丁， 就让他装一个，应该也能说的通。

备注 - 修改打包编译输出的名称

在桌面自己建立的文件夹中再建立自己应用安装后的文件夹的快捷方式

先建立安装后文件夹的快捷方式

生成的文件夹的快捷方式位置不合适

拖动建立的文件夹快捷方式到自己建立的桌面上的子文件夹中。

将快捷方式改成合适的名称。
将有快捷方式的子文件夹属性的“总是建立”的属性改为TRUE, 否则编译不过。

补充缺少的vs2019DLL的Release版本地来源

C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Redist\MSVC\14.29.30133\x64\Microsoft.VC142.CRT

补充 - ucrtbase.dll

ucrtbase.dll 应该是release版需要的ucrt的dll
C:\Program Files (x86)\Windows Kits\10\Redist\10.0.22000.0\ucrt\DLLs\x64\ucrtbase.dll

WARNING: Two or more objects have the same target location (‘[targetdir]\ucrtbased.dll’)

这种警告说明，自己添加的文件有重复的，可能是手误，或多次添加同一个文件引起的，去掉多余的，留一个就好了。

END

文章目录

• • vs2019 - 打包(开发机win10x64 - 目标机win7x64 - debug版程序)
  • 概述
  • 笔记
  • 添加组件
  • 添加程序集
  • 删掉组件时，支持多选
  • 加入全部组件后，需要删除的组件如下
  • 删掉有依赖的组件
  • 去掉有依赖的组件后，编译结果有很明显的区别
  • VS2019打包工程确实有bug
  • • mfc140ud.dll需要的组件
    • VCRUNTIME140D.dll需要的组件
    • ucrtbased.dll需要的组件
  • 最终下载的win7x64 ucrt补丁一共有3个
  • 需要添加自己应用缺的dll
  • 在自己应用中补充缺少的vs2019DLL
  • • 补充缺少的vs2019DLL的本地来源
  • 建立打包工程
  • 给安装后的目录添加子文件夹
  • 给安装后的目录中添加文件
  • • 给安装后目录的子目录中添加文件
  • 可以在目标计算机添加更多位置的文件夹
  • 添加应用的快捷方式
  • 给安装程序添加组件
  • 设置工程安装的选项
  • 修改默认安装路径
  • 用户桌面文件夹的总是建立要选为true
  • 修改版本号后，最好将产品代码的GUID也更新一下
  • 备注 - ucrt
  • 备注
  • 备注 - 使用体验
  • 备注 - win8.1环境
  • windows的ucrt补丁的总链接
  • 备注 - 修改打包编译输出的名称
  • 在桌面自己建立的文件夹中再建立自己应用安装后的文件夹的快捷方式
  • 补充缺少的vs2019DLL的Release版本地来源
  • 补充 - ucrtbase.dll
  • WARNING: Two or more objects have the same target location ('[targetdir]\ucrtbased.dll')
  • END

vs2019 - 打包(开发机win10x64 - 目标机win7x64 - debug版程序)

概述

一般打包时，需要将工程输出都编译成release版。
但是我想先试试debug版，做个debug版的安装包。安装到测试机上，如果有问题，可以看到debug版的断言。

用vs2019setup工程默认打包后的安装包，因为只有自己应用相关的文件，到新的测试环境后，是无法正常运行的。e.g. 刚安装完的win7x64旗舰版。
运行自己的应用，总会少vs2019自己的dll.

这时，应该在setup工程中添加vs2019自己的组件，保证自己应用的vs2019环境是全的。重新打个包。

笔记

添加组件

如果不知道应该安装哪个vs2019组件，就全选。
因为是无脑的选择，有些组件无法引入setup工程，有报错。

ERROR: Unable to import merge module 'C:\Program Files (x86)\Common Files\Merge Modules\niWininet.msm'
WARNING: Error merging 'MDAC.MSM': Unable to merge data from the merge module because it conflicts with existing data in the package.
MergeModule: table='File' row='adcvbs.inc'
Database: table='File' row='adcvbs.inc'
WARNING: Error merging 'MDAC.MSM': Unable to merge data from the merge module because it conflicts with existing data in the package.
MergeModule: table='File' row='odbc32gt.dll'
Database: table='File' row='odbc32gt.dll'
Database: table='File' row='adcjavas.inc'
ERROR: Unable to import merge module 'C:\Program Files (x86)\Common Files\Merge Modules\nidcom95.msm'
Build process cancelled
========== 全部重新生成: 成功 0 个，失败 1 个，跳过 0 个 ==========

将这些错误的组件从setup工程移除。再打包。
移除的组件如下：

niWininet.msm
MDAC.MSM
nidcom95.msm

移除不能引入的组件后，打包成功

Packaging file 'POLICY~7.DLL'...
Packaging file 'mfc140d.dll'...
========== 全部重新生成: 成功 1 个，失败 0 个，跳过 0 个 ==========

但是有些警告如下：

已启动重新生成…
------ Starting pre-build validation for project 'caseSetupPrj' ------ 
WARNING: Unable to find module dependency with signature 'OpenGL32.09188572_BCB5_11D3_AB7C_006008CA11D7'
WARNING: Unable to find module dependency with signature 'MSVCRT.51D569E0_8A28_11D2_B962_006097C4DE24'
// ...
------ Pre-build validation for project 'caseSetupPrj' completed ------
------ 已启动全部重新生成: 项目: caseSetupPrj, 配置: Debug ------
Building file 'D:\my_dev\my_local_git_prj\xx\src\installer\caseSetupPrj\Debug\caseSetupPrj.msi'...
WARNING: Two or more objects have the same target location ('[payload_ul]\8.0.50727.5592.policy')
WARNING: Two or more objects have the same target location ('[payload_ul]\8.0.50727.5592.policy')

这些警告咱不懂啊，不管了。
试试添加vs2019组件后，重新打包的安装程序在新环境计算机上是否好使?

可以看到加了vs2019组件的安装包比没加组件的安装包大了大概50MB.
尝试安装

安装程序本身需要4.7.2了…
我的应用没用这玩应啊…, 估计是选的那些vs2019组件需要dotnet472.
点击是，得到4.7.2的下载链接 http://go.microsoft/fwlink/?LinkId=863262
是在线版安装包，这不行啊。
在网上找到了离线版安装包 https://go.microsoft/fwlink/?linkid=863265
先下载(ndp472-kb4054530-x86-x64-allos-enu.exe 大概80MB)，然后尝试是否可以打在VS2019的setup工程中。

添加程序集

打包完成，发现比打了组件的安装包，又大了170MB.
尝试安装运行。

安装程序还是需要dotnet472, 无法将dotnet472打在安装包中。
那提供2个安装包包吧，一个是MS原版的472安装包，一个是自己打了vs2019组件的安装包。

先安装472, 发现win7不支持472.
那就不能安装那么多vs2019组件了，需要将多余组件去掉才行。只保留自己应用相关的组件。

在setup工程中，看到安装程序是依赖的。尝试去掉多余的组件，看看是否还需要
将组件从setup工程中都删除了，就没有依赖了。

那再全加上，慢慢删掉组件，看删到那个组件，显示不需要环境？

安装包本身需要的依赖项，可以在依赖项文件夹上右击"刷新依赖项"来查看。
通过实现发现，依赖项是可以实时更新的，如果删掉哪个组件，导致安装程序不需要依赖了，马上就能显示。

删掉Microsoft_VC80_CRT_x86.msm后，显示安装程序需要Microsoft_VC80_CRT_x86.msm.

删掉MStudioCommon.2005.msm后，就不需要Microsoft_VC80_CRT_x86.msm了。

删掉MStudioCommon.msm后，就不需要支持了。
现在有点明白了，MStudioCommon.msm和MStudioCommon.2005.msm可能是写VS2019插件DLL才要的组件。
现在知道了，将组件全部去掉，再重新加入，将MStudioCommon.msm和MStudioCommon.2005.msm拿掉，再打个包试试。

删掉组件时，支持多选

一个一个删除setup工程中的参与编译项，太麻烦了，试了，可以多选，然后按delete键一次性移除。

加入全部组件后，需要删除的组件如下

niWininet.msm
MDAC.MSM
nidcom95.msm
MStudioCommon.2005.msm
MStudioCommon.msm

现在打包完，仅仅比没加组件的打包版本大50MB.
试试。

安装程序还需要?
重新启动虚拟机再试试。
安装程序还需要.
那就得在setup工程中，再删掉可能需要的组件。

删掉有依赖的组件

先尝试将还需要依赖的组件拿掉。

如果加入的组件不依赖其他组件，就留在setup工程中。
再尝试打包。

去掉有依赖的组件后，编译结果有很明显的区别

已启动重新生成…
------ Starting pre-build validation for project 'caseSetupPrj' ------ 
------ Pre-build validation for project 'caseSetupPrj' completed ------
------ 已启动全部重新生成: 项目: caseSetupPrj, 配置: Debug ------
Building file 'D:\my_dev\my_local_git_prj\xx\src\installer\caseSetupPrj\Debug\caseSetupPrj.msi'...
WARNING: Two or more objects have the same target location ('[payload_ul]\8.0.50727.5592.cat')
WARNING: Two or more objects have the same target location ('[payload_ul]\8.0.50727.5592.cat')
// 上述警告说安装位置一样，这不是问题(重复安装就重复安装)
Packaging file 'z2yaprdo.dll'...
Packaging file 'xx.dll'...
// ...
Packaging file '3xubcbxg.etb'...
========== 全部重新生成: 成功 1 个，失败 0 个，跳过 0 个 ==========

这次编译结果，没有了另外一个警告 WARNING: Unable to find module dependency with signature ‘OpenGL32.09188572_BCB5_11D3_AB7C_006008CA11D7’

看着像打包没问题了，再试试。

这次只加没依赖的组件，比只加自己应用的版本大40MB

居然还需要472…
是不是虚拟机缓存文件的问题? 尝试将setup工程改名，将GUID的值换了，再试试。
还是需要472, 不是安装程序缓存的问题。

那只能再尝试删掉一些组件，再打包试试。

一个一个删除，然后打包，不行，安装程序需要472.
直到删掉最后一个组件，已经和开始新建工程一样了，打包后还是需要472.
这不科学啊，估计是打包工程有bug.

重新建立一个工程，先添加自己应用的文件，打包试试。
然后再添加必要的组件，打包再试试。

VS2019打包工程确实有bug

如果加入了组件，即使将组件移除，如果这个组件原来依赖. 移除之后，setup工程打包后的安装程序还是需要.
必须在工程中新加入自己需要的组件才行，只要一加入，这个组件就会被打包好的setup程序用上。
所以要保证组件在一个工程中，只能新加入一次。
如果组件加错了，要重新在新建的setup工程中重新加入，而不能在旧工程中改。

mfc140ud.dll需要的组件

如果程序运行时，缺少mfc140ud.dll, 添加组件 Microsoft_VC140_DebugMFC_x64.msm 就好了。

VCRUNTIME140D.dll需要的组件

如果缺VCRUNTIME140D.dll， 加入Microsoft_VC140_DebugCRT_x64.msm

ucrtbased.dll需要的组件

https://www.microsoft/en-us/download/details.aspx?id=49093

https://www.microsoft/zh-cn/download/details.aspx?id=49093

ucrtbased.dll是系统的补丁，需要windows升级才行。
对于win7,需要安装KB2999226补丁
这个补丁必须在win7Sp1上才行，原版的win7不行(win7x64旗舰版 - 6.1.7600)
看来我用（win7x64旗舰版 - 6.1.7600）时，vmware安装vmtools时要求更新到win7sp1是有道理的…

最终下载的win7x64 ucrt补丁一共有3个

windows6.1-kb2533552-x64_0ba5ac38d4e1c9588a1e53ad390d23c1e4ecd04d.msu
windows6.1-kb976932-x64_74865ef2562006e51d7f9333b4a8d45b7a749dab.exe
Windows6.1-KB2999226-x64.msu
安装次序如上。
windows6.1-kb2533552-x64_0ba5ac38d4e1c9588a1e53ad390d23c1e4ecd04d.msu 和 windows6.1-kb976932-x64_74865ef2562006e51d7f9333b4a8d45b7a749dab.exe 是给win7x64原版升级到win7sp1x64

Windows6.1-KB2999226-x64.msu 是在win7sp1x64基础上，添加ucrt库。

需要添加自己应用缺的dll

上面添加的.msm一共5个如下：

microsoft_vc140_crt_x64.msm
Microsoft_VC140_DebugCRT_x64.msm
Microsoft_VC140_DebugMFC_x64.msm
MIcrosoft_VC140_MFC_x64.msm
MSVCRT.msm

这些.msm会向目标机的C:\Windows\System32\中拷贝VS2019的基础dll
自己手工拷贝这些vs2019的基础dll到自己工程，很麻烦，不靠谱。 还是用打包添加组件的方式来的方便靠谱。

在自己应用中补充缺少的vs2019DLL

在上述打包基础上，根据提示，缺哪个DLL就补充哪个DLL.
补充的DLL从在自己开发机上找，都在VS2019的安装目录和windows SDK的安装目录中。
补充的DLL如下：

concrt140d.dll
msvcp140_1d.dll
msvcp140_2d.dll
msvcp140d.dll
msvcp140d_atomic_wait.dll
msvcp140d_codecvt_ids.dll
ucrtbased.dll
vccorlib140d.dll
vcruntime140.dll
vcruntime140_1d.dll
vcruntime140d.dll

补充缺少的vs2019DLL的本地来源

C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Redist\MSVC\14.29.30133\debug_nonredist\x64\Microsoft.VC142.DebugCRT

concrt140d.dll
msvcp140_1d.dll
msvcp140_2d.dll
msvcp140d.dll
msvcp140d_atomic_wait.dll
msvcp140d_codecvt_ids.dll
vccorlib140d.dll
vcruntime140_1d.dll
vcruntime140d.dll

C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Redist\MSVC\14.29.30133\x64\Microsoft.VC142.CRT
vcruntime140.dll

C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.UniversalCRT.Debug\10.0.22000.0\Redist\Debug\x64

ucrtbased.dll

建立打包工程

给安装后的目录添加子文件夹

如果应用需要子文件夹中的东西，可能由于权限问题，无法在目标机上建立子文件夹。
这时，在安装程序中就预先建立好，这个主意好。

给安装后的目录中添加文件

添加文件时，如果提示有组件中包含这些文件，是否添加组件，选择否。
组件另外添加。
操作完成时，可以看到在目标机的应用文件夹中，就有我们添加的安装后的文件了。

给安装后目录的子目录中添加文件

和"给安装后的目录中添加文件"操作步骤一样，只不过需要在添加的子文件夹上右击，选择添加文件。

可以在目标计算机添加更多位置的文件夹

添加应用的快捷方式

改快捷方式的图标

给安装程序添加组件

根据自己应用的实际需要添加必要的组件，对于本实验(VS2019 + MFC + X64), 添加一下5个组件。

microsoft_vc140_crt_x64.msm
Microsoft_VC140_DebugCRT_x64.msm
Microsoft_VC140_DebugMFC_x64.msm
MIcrosoft_VC140_MFC_x64.msm
MSVCRT.msm

设置工程安装的选项

为所有用户安装
安装前，自动卸载旧版本。

修改默认安装路径

e.g. 想将程序安装到一个英文路径且没有空格的目录。

用户桌面文件夹的总是建立要选为true

不知道是不是我自己改成false的，重新生成时有报错提示，要将桌面文件夹的“总是创建”改为true才行。

修改版本号后，最好将产品代码的GUID也更新一下

备注 - ucrt

ucrt是同一运行时库，是作为OS的一部分内建组件。无法包含在安装包内。VS2019是这样。
如果自己做的安装包报错为 api_x.dll没找到之类的，就是系统需要打ucrt的升级补丁(对于win7原版来说，就要升级到win7sp1 + win7x64的ucrt的补丁)

备注

上述打包过程正确，可以生成想要的x64安装包。
已经试过了，安装后好使。
如果要打release版的包，区别：

• 将工程输出都搞成release版
• 添加release版的组件

备注 - 使用体验

用VS2019的setup工程添加组件挺方便的。
VS2019的setup工程基本功能都有，只要用了第一遍，估计就不想换其他第三方的安装制作程序了。
和微软家出的其他产品一样，只要不想做太精致的东西(能用(功能性的特性都在)，但是不好看)，就微软家自带的就行。

备注 - win8.1环境

也需要安装ucrt环境，否则会报错 api-x.dll找不到之类。
https://www.microsoft/zh-cn/download/details.aspx?id=49081
下载后为 Windows8.1-KB2999226-x64.msu，不大，传进win8.1，然后安装一下，有了ucrt环境，VS2019打包，安装到win8.1的程序就可以正常运行了。

windows的ucrt补丁的总链接

https://support.microsoft/zh-cn/topic/windows-%E4%B8%AD%E7%9A%84%E9%80%9A%E7%94%A8-c-%E8%BF%90%E8%A1%8C%E6%97%B6%E6%9B%B4%E6%96%B0-c0514201-7fe6-95a3-b0a5-287930f3560c
从官方资料看，很多操作系统都需要单独安装ucrt环境。

win8.1 - x86/x64
winserver2012 -R2
win8 - x86/x64
winserver 2012
win7 - x86/x64
winserver2008 - R2
vista - x86/x64
winserver2008 - x86/x64

如果不想被ucrt困扰，只能使用VS2013.
但是现在好多库（第三方/开源）都升级到用VS2019编译了。
做好程序让用户使用，如果他的环境没打ucrt补丁， 就让他装一个，应该也能说的通。

备注 - 修改打包编译输出的名称

在桌面自己建立的文件夹中再建立自己应用安装后的文件夹的快捷方式

先建立安装后文件夹的快捷方式

生成的文件夹的快捷方式位置不合适

拖动建立的文件夹快捷方式到自己建立的桌面上的子文件夹中。

将快捷方式改成合适的名称。
将有快捷方式的子文件夹属性的“总是建立”的属性改为TRUE, 否则编译不过。

补充缺少的vs2019DLL的Release版本地来源

C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Redist\MSVC\14.29.30133\x64\Microsoft.VC142.CRT

补充 - ucrtbase.dll

ucrtbase.dll 应该是release版需要的ucrt的dll
C:\Program Files (x86)\Windows Kits\10\Redist\10.0.22000.0\ucrt\DLLs\x64\ucrtbase.dll

WARNING: Two or more objects have the same target location (‘[targetdir]\ucrtbased.dll’)

这种警告说明，自己添加的文件有重复的，可能是手误，或多次添加同一个文件引起的，去掉多余的，留一个就好了。

END