1、部署方式

关于WPF应用开发完成后的发布处理
功能开发结束并不是应用开发的最终阶段
就算在调试状态下测试后，依然需要在发布模式进行文件打包后再做一遍功能检查才能确定最终的结果

在生产下与开发状态下的项目在文件目录上有明显差异
生产下一般是一个单文件，而开发状态下的目录包含被复制的资源以及调试信息所需要使用的记录文件，而最多的则是运行环境下所必须的全部DLL资源

点击Visual Studio 菜单栏>生成>发布XXXXX 即可打开发布选项的对话框

Azure

第一个是Azure部署，这一发布方式是微软公司提供的一个云部署功能。
一般在Visual Studio中开发Web应用程序后，可以将该应用程序通过Azure应用程序向导部署到Azure云服务上。这一方式非常的方便快捷，但需要搭配微软的Azure云服务才能使用此功能，并且其并不适合WPF桌面应用程序的发布。

ClickOnce

第二个选项是ClickOnce部署，ClickOnce目的是创建完全独立运行的应用程序。任何使用 ClickOnce 技术发布的WPF、Windows窗体或控制台应用程序。
均可以采用三种不同的方式发布。
|网页发布|网络文件共享发布| 媒体发布(如CD-ROM)|
|-------|-------|-------|

ClickOnce 应用程序可以安装在最终用户的计算机上，即使在该计算机脱机时也能在本地运行；或者可以仅以联机模式运行，而不在最终用户的计算机上永久安装任何内容

ClickOnce应用程序还可以自行更新；这些应用程序可以在较新版本可用时检查是否存在较新版本，并自动替换所有更新后的文件。
开发人员可以指定更新行为；并且网络管理员可以修改更新的策略，可以设置强制更新。还可以回滚更新，使应用恢复到之前的版本。

相比于普通的安装部署，ClickOnce部署更加易于统一的应用管理，一般更适用于大型公司的内部软件更新和控制。无需终端用户自行管理。

Docker

第三个选项是Docker部署，在Visutal Studio上是比较新的一个部署方式.

尽管2013年Docker就已经诞生，但微软IDE是在VS2017上才将Docker部署正式纳入。

Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux或Windows操作系统的机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。

Docker部署更多的考虑是在服务器的资源利用率和配置程度上。在WPF的部署中不需要考虑这么大的影响，我们的软件本身就是运行在不同的客户机上，因此和Docker技术的关系不大。

在原有传统的物理机搭配OS的情况下，应用服务会遇到以下三个问题：
环境依赖问题
一个业务需要它所依赖的环境来支持它的运行，而由于每个业务依赖的系统环境不同，在服务器之间无法通用，服务器负载也各不相同；另外，各个业务都需要独立管理服务器容量以处理服务器故障，这样，对业务开发造成较大负担。
资源管理问题
精细资源隔离——服务隔离要求按照服务接口对进程物理隔离，以防止因为某一个接口而影响整体服务，同时也需要根据不同接口的特性设置不同的进程数、CPU和内存配置，以实现更加精细的资源管理。
资源动态调整问题
许多业务需要快速自动适应流量负载的变化，这样，才可以在负载高峰期快速增加资源，以保证业务服务质量。另外，在负载低峰期释放资源给其它服务，提高集群资源利用率。

文件夹

第四个选项是文件夹部署，也就是文件部署，其主要部署要点注重在项目文件的打包和封装上，最终的生成是以一个或多个文件之类的形式存在。这也是我们WPF发布部署所要选取的方式。

2、部署配置

可以看到的是，文件发布的选项中包含了许多基本的配置，根据不同的平台要求和需要，我们可以自由的选择应用发布的方式。
在此记录中，我们选择的是独立依赖下的Win-x64位的模式。

如果选择的部署模式为依赖框架时，客户机中一定要有相应的运行环境才能正常使用应用。

详细的配置信息如下所示

在此基础上，我们点击文件部署后，可以看到在生成文件夹下，尽管嵌入的文件已经合并到相应的本程序自身的DLL中，但除此之外大部分的文件没有被合并，复杂的文件结构很明显不是我们需要的。

因此我们勾选上合并为单个文件，这样独立部署下所依赖的所有DLL文件和其他的资源文件都将合并到exe可执行文件中。我们还勾选了裁剪未被用到的程序集来进一步减小程序体积

这一部署过程耗时相对更久，因为IDE正在将所有资源文件进行内部链接并压缩入exe中。
裁剪未被用到的程序集功能有可能会影响正常应用的功能，如果有影响需要关闭此部署功能。

最后生成的结果如下所示，尽管我们勾选了单文件，但依然有很多的语言相关的空文件夹和数个DLL文件，文件夹的残留其实是因为IDE本身处理机制的问题，这些空文件夹直接删除或者将发布文件夹内清空后重新部署一遍均可以处理这一问题。而数个相关的DLL的留存原因是因为它们是和系统相关的。

这几个dll是系统原生的native dll(在不同的系统上不一样)，他们无法和.net的程序集合并。

在.Net5中提供了一种方式来为程序生成真正的单个文件。我们需要双击解决方案栏下的项目名以此打开xxxxxx.csproj，作为项目的配置文件，我们在PropertyGroup标签下添加

<IncludeNativeLibrariesForSelfExtract>true</IncludeNativeLibrariesForSelfExtract>

我们可以看到所有的DLL文件都已经看不见了，它们也被放进了exe文件中，而目录下仍存在另一个后缀名为pdb的文件。

这个文件是微软的IDE用来帮助进行Debug调试的，正常的关闭流程下应该打开本项目的属性配置，在 生成>高级 选项中

设置调试信息为无，即可关闭pdb的输出
如果你想保留这个选项，则需要将设置改为嵌入式，这样pdb文件也会被包含进exe中

请注意设置所对应的发布平台，否则会出现错误

最后，我们终于得到了一个单exe文件的结果