教程持续更新了25节，这个基于winform开发的私人日记基本算是完成了，这一节我大概讲下程序的发布，做一个最终的总结。
我们在使用VS开发项目的时候，可以直接按F5运行和调试程序，但是我们开发出的软件是要给其他人用的，别人没有VS，要怎么运行呢？这就谈到了程序发布的问题。
一、使用VS的Release发布在VS中的工具栏切换成Release的模式。
在解决方案视图中，选中Diary.Win项目点右键，生成。
提示成功后，我们依次打开项目目录Diary.Win->bin->Release->net5.0-windows，你会发现生成了一堆的文件。把Diary.db复制到目录中后，点Diary.Win.exe，就可以正常运行了。
先说下为什么要切换到Release模式。Debug模式是可以调试的，那就意味着会执行一些调试代码，一会影响速度，二可能会有影响程序的走向，比如使用了预编译代码。所谓的预编译代码你可以理解为基于调试的需要，不同模式下执行的代码不一样。比如Debug模式我想只要出现异常就不捕获，直接弹出，这样可以快速定位问题。但如果Release模式下，就需要截获异常，保证程序不会崩溃。大家可以对比下下面的代码在Debug模式和Release模式下的不同：
Release模式下，代码是灰色的，也意味着是不被编译的，相当于注销掉了一样。
关于预编译，利用好了可以做很多事情，其实可以专门开个专题来讲，这里只是为了说明下Debug和Release的不同，就不多展开了。
对上面通过Release发布的内容，我们需要对这个程序稍微做下包装：
1）程序图标应该换一个
2）程序名称改成私人笔记，而不是Diary.Win
3）右键程序文件，详细信息中的内容需要改下，如下图：
程序图标我一般是到阿里的图标库网站去找。这里使用的图标可能会有版权问题，不过当你还没有名气的时候，没人会找你麻烦的，等你有了用户产品看到了希望再自己做一个就来得及。
下载后一般是png格式的，需要转换成ico格式。我这有个小工具，很方便做转换。图标网址和工具网址我会更新到文章下方。
有了ico格式的文件之后，我们就打开Diary.Win的项目属性页，依次进行设置：
在应用程序标签页：
在打包标签页：
顺道我们把MainForm的窗体图标也改掉：
然后再重新生成。
图标及文件名：
公司名：
程序信息：
主窗口图标
都改变了。
现在我们可以把这一堆的文件压缩成一个文件包，发到其它电脑上测试看能否正常运行。我把压缩包复制到一台Win7的电脑，报如下提示：
意思是这台电脑没有安装.net core的环境，需要下载、安装.net core才能正常使用。
这是微软一直让大家诟病的原因，在.net core之前，是基于.net framework框架，这个从.net 1.1，到.net 2.0、3.5、4.0一直到现在4.8，4.0之前每个版本都不兼容，连向下兼容都做不到，4.0之后还好一些。不同的windows系统预装的framework版本是不同的，一个framework包动辄几百M，一个程序可能才几M。
然而现在的.net core给我们提供了更多选项，之所以仍然给出需要安装.net core框架的提示，是因为我们用的是默认的发布方式，.net core给我们提供了几种方式。
三、使用命令行不依赖.net core发布VS菜单：工具->命令行->开发者命令提示：
使用dos命令 cd diary.win，进入项目目录，然后输入如下命令行：
dotnet publish -r win-x64 -c release /p:PublishSingleFile=true
解释一下：
dotnet publish 是执行发布命令
-r win-x64 是生成windows 64位程序；
-c release 是按哪种编译模式编译；
/p:PublishSingleFile=true 是单一文件发布，也就是不需要安装.net core的环境也可以运行；
生成完成后，我们进入到目录看下，好家伙，500多个文件和目录，一共156M：
把这些文件打包复制到刚刚的电脑，发现运行是没问题的。可是这种要想发布，只能是做成安装文件，不然用户找可执行文件都费劲。不过好在.net core还提供了另外的方法。
四、优化命令行使用下面的命令行：
dotnet publish -r win-x64 -c release /p:PublishSingleFile=true /p:publishtrimmed=true
就是增加了/p:publishtrimmed=true，这种就是告诉编译器，别把所有的包都给我塞进来，我需要的给我，不需要的都剔除掉。
如此执行后，在win-x64目录下多了一个publish的目录，我们进去看下：
只有10个文件了，程序包的大小变成了70多M。但是我们注意到命令行编译的时候给了我们一个提示，优化可能会导致问题，需要测试。
于是我把数据文件复制过来，执行，能够弹出密码框，但是再进入就自动退出了。真的出问题了！检查原因吧，这种意外退出的，没有任何征兆，所以到系统日志看下：
这里指示得很明显了，加载MainForm窗体时获取资源出的问题。然后查了代码，只有加载分类图标列表的时候会从资源中读取内容。
不优化是没问题的，优化后出问题，显然是资源加载方式被优化了，由于我们不知道具体代码是如何执行的，所以可能会很难解决。既然从资源中读取有问题，那换个方式直接从硬盘中读取会不会有问题呢？于是修改了一下代码：
private void MainForm_Load(object sender, EventArgs e)
{
string[] filenames = { "folder.png", "key.png", "text.png" };
foreach (string filename in filenames)
{
string path = string.Format("{0}\\Resource\\png\\{1}", Application.StartupPath, filename);
imgsCategory.Images.Add(Image.FromFile(path));
}
//其他代码
}
再次编译，程序目录附带上包含png文件的Resource目录。发现问题解决了，复制到其他机器也没问题，无需安装.net core的环境就能正常运行。与不优化相比，只需要10几个文件，压缩后大小只有20多M，已经相当满意了。可能就是如编译提示的那样，.net core毕竟算是新技术，可能有些地方还不完善，换个思路就好了。
介绍到这里，虽已接近尾声，但还不是终点。我们使用的命令行是基于x64的，也就是说只能在64位电脑下运行，那32位的怎么办呢？
我的策略是直接都换成32位的，因为32位的在64位下也是可以正常运行的，这种小程序效率不会有太大的差别，所以影响可以基本忽略。
dotnet publish -r win-x86 -c release /p:PublishSingleFile=true /p:publishtrimmed=true
最终发布后，程序压缩包只有23MB，而且不依赖.net core，已经觉得相当完美了。
测试下来：winserver2012 64位，win7 64位，win10 64位机上均正常运行，手头没有32位的机器，暂时作罢了，想来应该问题不大。唯一一台不能运行的是winserver 2007版，可能是它不符合.net core的安装环境吧，老机器就不考虑了，能满足大多数用户就可以了，随着时间的推移，适用面会越来越广。
到此，我们这一阶段的教程就告一段落了。第二段的教程。之前计划是用Blazor，但是我发现Blazor的控件特别少，很多基础的树控件、列表控件都要自己写，网上有的但凡做得好点的都是要付费的。反观我比较熟悉的asp.net，我倒是觉得完全可以胜任，而且开发速度很快，网上很多现成的js控件也都可以直接使用。所以第二阶段的具体选型我需要再斟酌一下。最近收到一些咨询，现在有些需求需要把原来windows开发的winform程序转成Linux下运行的，所以我现在对用.net core做Linux应用比较感兴趣。后面教程具体怎么走还没有完全想好。两天一更时间对我来说确实有点紧，最近身体不大好，我先休息一段时间，希望大家持续关注吧！
----------------------------------------------------
本教程项目源码已作为开源项目加入到Gitee，代码内容会随教程实时更新，大家有兴趣的话可以关注我，以获得最及时的更新。我把回复内容都统一放到一起了，私信：
私人日记 可以获取相关链接；
大家阅读过程中有哪些看不懂或未尽兴的地方，可以在评论区留言，我会先记下来在后续的教程中找机会再说。
教程有帮助的话请大家帮忙关注、转发、扩散，能不能开专栏还需要你们的支持！
,
