.NET Core改造

[Akarinnnnn]

#20

[Akarinnnnn]

同时解决了无证书编译Release的问题。
只在存在证书文件时才进行签名

[wmjordan]

改得有点多啊。
建议考虑用户环境和使用旧开发环境的朋友。
如果将几个更改分开来提交拉取请求就好了。

[wmjordan]

ILRepack 好像还不支持 .NET 6。

[Akarinnnnn]

有两个备选项，参见.NET Core 3.0 的新增功能

[Akarinnnnn]

不能使用剪裁

[calcitem]

最好是rebase一下。至少最后一个提交可以squash和上个提交压缩。

[Akarinnnnn]

已提出建议

[Akarinnnnn]

最好是rebase一下。至少最后一个提交可以squash和上个提交压缩。

明天吧

[wmjordan]

我觉得现在并不是将程序转到 .NET Core 的合适时机。
在十几年前，大部分机器上都运行 Windows XP 系统，没有预装 .NET Framework，这程序还没怎么推广，就时不时有用户来信或留言，问程序下载了之后打不开的问题。即使是下载页提示了要装框架，并给出了运行时的下载连接，还是有人来问。
转到 .NET Core，大量的机器上都没有预装那个东西。对于这个程序而言，这个改造增加了用户使用上的困难，却没有带来什么好处。我不想再回答“怎么运行不了”之类的问题。

[calcitem]

楼主本意可能是想利用Core的跨平台优点，提升项目的受众。

对于解决方案，我觉得楼主可以考虑一下：

将.NET Core托管（CLR）应用程序编译为本地（特地平台）的单一可执行文件。

就是将.NET Core编译为机器码（也可以是其他东西，如C++代码），而不再有之前的运行时，将.NET变为真正的“静态编译形”语言。

[Akarinnnnn]

我觉得现在并不是将程序转到 .NET Core 的合适时机。 在十几年前，大部分机器上都运行 Windows XP 系统，没有预装 .NET Framework，这程序还没怎么推广，就时不时有用户来信或留言，问程序下载了之后打不开的问题。即使是下载页提示了要装框架，并给出了运行时的下载连接，还是有人来问。 转到 .NET Core，大量的机器上都没有预装那个东西。对于这个程序而言，这个改造增加了用户使用上的困难，却没有带来什么好处。我不想再回答“怎么运行不了”之类的问题。

可以在发布时附带运行时，这样就不需要用户自行安装。

楼主本意可能是想利用Core的跨平台优点，提升项目的受众。

对于解决方案，我觉得楼主可以考虑一下：

将.NET Core托管（CLR）应用程序编译为本地（特地平台）的单一可执行文件。

就是将.NET Core编译为机器码（也可以是其他东西，如C++代码），而不再有之前的运行时，将.NET变为真正的“静态编译形”语言。

.NET Native目前还没有正式发布。

[Akarinnnnn]

[calcitem]

打包出的文件会有多大？
从用户体验的角度看，之前的版本，点击后，如未安装运行库，Windows会自行弹出对话框安装运行库。改造后，就不会弹出了吧？

[Akarinnnnn]

打包出的文件会有多大？ 从用户体验的角度看，之前的版本，点击后，如未安装运行库，Windows会自行弹出对话框安装运行库。改造后，就不会弹出了吧？

FxDependent不带运行库，28MB；Independent自带运行库，163MB

[calcitem]

那么估计是比较不容易被接受。目前有用户认为网盘下载慢。

[Akarinnnnn]

那么估计是比较不容易被接受。目前有用户认为网盘下载慢。

FxDependent会自动弹框，提示用户安装框架

[wmjordan]

Independent自带运行库，163MB

太巨大了。我上传都吃力啊。要知道我有时候是要用手机流量上传的啊。
还是等大部分机器自带那运行环境了，再移植吧。

另外，您提交中有一些与迁移 .NET Core 无关的，但仍然有用的优化，我会将它们手工加到源代码里面去。

感谢阁下的帮助！

[Akarinnnnn]

我之前就提到过，.NET Core不会在Windows中自带，必须由用户自行安装。这出多少有点因噎废食

[calcitem]

优点，目前已知 .Net Core 跨平台是优势，之前 .net 跨平台一直是一大软肋。.Net Core 使用最宽松的MIT和Apache 2开源协议，和AGPL不存在兼容性问题。

问题，可能在更老的机器上，不能安装 .net Core? 甚至有的不能弹出安装提示？

[wmjordan]

从最终用户的角度，他们是要用这个软件来解决他们所遇到的问题。如果一项技术不影响他们的使用体验，他们并不太关心这个软件是用什么技术实现的。但一旦某个改动影响了他们的使用体验，就对用户造成麻烦，甚至会影响到软件的普及。

我们做什么改动，都应该从最终用户的使用体验上面来考虑，而不能单纯从开发者自身的角度来考量。
对 .NET Core 的改造，也应从上面的出发点来权衡利弊。

好处：

1. 程序的性能可能有一点提升（不太明显）
2. 可能让其它操作系统上的用户受益（本提交请求未解决平台兼容性问题，故此不能成为优点）

缺点：

1. 普通用户解包后不能马上运行该程序，要先安装运行环境（影响较大，即使是能弹出安装运行环境的提示，对最终用户来说也不是喜闻乐见的）
2. 打包出来的程序文件较大（在已安装运行环境后，影响一般）

[Akarinnnnn]

1. 不支持xp，win7 win8需要补丁。 2. 确定可以弹出提示，提醒用户安装运行时。

[Akarinnnnn]

1. Winform（本项目使用）和WPF只支持Windows。.NET 6的MAUI可以。 2. FxDependent需要安装运行时。压缩成zip后，文件大小约为7.1MB，与目前版本大小持平。

[calcitem]

2020年2月，https://gs.statcounter.com/ 发布的数据显示，全球桌面操作系统市场份额数据，从占比高到低排列：

Windows 77.26%
OS X 17.69%
Linux 1.89%

同期（2020年2月）亚洲的市场份额为：

Windows 83.53%
OS X 12.05%
Linux 2.02%

因此支持 .NET Core 有助于拓展 15% 的用户群，目前确实也有 macOS 用户在微信公众号留言希望发布 mac 版本。

不知解决平台兼容性问题还需要做多少工作。

如果修改量很少，控制住不是必须的改动，可以考虑另建一个 sln 和原有的共存，然后用 .NET Core 的sln 单独编译 macOS 版？

如果修改量大，我觉得可以考虑鼓励贡献者自己 fork 出来维护跨平台版。

后补充：因第三方库依赖问题，跨平台迁移比较困难。