少有人走的路上微软教程：
https://dotnet.microsoft.com/zh-cn/platform/upgrade-assistant/tutorial/intro?initial-os=windows
本文把下面文章的代码由.net framework4.6升级为.net 8.0
勇哥这里记录一下实施过程。
WCF盘点+实验分布式halcon应用（一）基本应用
http://www.skcircle.com/?id=23672
（一）下载和安装 SDK
若要开始生成 .NET 应用，请下载并安装 .NET SDK。
勇哥打开要转换的framework项目，发现如果直接选择框架，是没有.net 8的。
实际上我也安装vs2022，它是可以选择.net 8的。
但是判断是否已经安装.net 8 sdk，不是从上面工程属性的框架列表里看，而是用下面控制台的指令。
控制台敲入指令： dotnet --version，发现确实已经安装8.0的.net。
我们跳过安装.net 8 sdk，继续下一步。
（二）安装并运行升级助手
dotnet tool install -g upgrade-assistant
若要升级项目，请运行以下命令:
upgrade-assistant upgrade <Path to csproj to upgrade>
勇哥敲入upgrade-assistant upgrade Hosting.sln 升级全部四个项目。
进入选项界面，要我在四个项目中选择升级哪一个
选择Client项目后，进入选择升级策略选择页面。
这里In-Place project upgrade称为原地升级
而Side-by-side project upgrade 称为并排升级，详细解释如下：
在.NET框架的升级过程中，尤其是在使用.NET Upgrade Assistant （一个用于将旧版.NET应用程序迁移到较新版本的工具）时， 你可能会遇到两种主要的升级策略： in-place（原地）升级和side-by-side（并排）升级。以下是这两种策略的解释： In-Place Project Upgrade (framework.inplace) 原地升级策略意味着升级过程会直接在现有的项目上进行修改， 而不会创建新的项目或解决方案。这种策略的目标是尽可能地保留现有的项目结构、 文件和设置，同时更新它们以兼容新的.NET版本。 原地升级的优点是： 简单易用：直接修改现有项目，无需额外的步骤来管理新的项目或解决方案。 保留历史：Git等版本控制系统中的历史记录得以保留。 但是，原地升级也可能带来一些挑战： 复杂性：在某些情况下，直接修改现有项目可能会导致复杂的合并冲突或其他问题。 兼容性：不是所有的库或依赖项都支持原地升级，这可能需要额外的工作来解决。 Side-By-Side Project Upgrade (framework.sidebyside) 并排升级策略则是创建一个新的项目或解决方案，并将现有项目的代码和设置复制到新的位置。 然后，升级工具会在新的位置进行升级操作，而原始项目保持不变。 并排升级的优点是： 隔离性：新的项目和解决方案与原始项目完全隔离，可以更容易地管理和跟踪更改。 安全性：如果升级过程中出现问题，原始项目仍然保持完整，可以作为回滚的备份。 但是，并排升级也可能带来一些额外的工作： 管理复杂性：需要同时管理两个项目（旧的和新的）。 合并更改：如果原始项目在升级过程中继续有更改，可能需要将这些更改手动合并到新的项目中。
这里勇哥选择并排升级 Side-by-side project upgrade
下面页面是确定升级目标。
New Project 是创建一个全新的项目，并将原始项目的代码、配置和设置迁移到这个新项目中。
新项目将使用目标.NET版本的最新模板和最佳实践来创建，而原始项目则保持不变。
Exising project 是在当前项目上直接升级。
这个页面比较奇怪，因为在选择Upgrade type时，勇哥已经选择了并排升级 Side-by-side project upgrade。
按理说这个页面就不应该再选择一次New Project和Exising了。
那勇哥就选择New proejct吧。
这里要我输入新项目的名称，我就叫ClientNew吧
下面要选择框架版本，勇哥选择.net 8.0。
不过有意思的是.net 8不是LTS长期支持版本吗？
这里怎么是支持到 2026.11月？ 微软这是几个意思 ？
确认页
接下来勇哥把剩下的三个项目都转了。。。
Contracts
Hosting
Services
来看看转换后的工程样子：
来对比一下项目的变化，从中可以读到一些信息：
1。 wcf的引用库，在.net 4.6中通过引用 System.ServiceModel命名空间
在ClientNew中，通过包进行引用，它自动引用了一堆System.ServiceModel.XXXX（它们是wcf开源后的版本）。
（对于这个程序来讲，引用System.ServiceModel.Primitives应该就够了）
这应该是这个工具自动化的选择，它把支持.net 8的wcf包自动导入了。
这让勇哥想到，如果不清楚一个库是否有.net core版本的，可以用这个升级工具试下。
2。 第三方库，比如halcondonet，这个工具不能识别，把它放到“程序集”引用中去了。
3。 现在.net 8工程里，有专门的项目引用，而以前全部都放到“引用”里。
卸载掉原来的方案，重新编译
有两上错误。
第二个问题
channelFactory = new ChannelFactory<IHalon>(binding,new EndpointAddress( "net.tcp://127.0.0.1:9001/halconService"));
第一个问题
ServiceHost不存在，这个是wcf中创建服务的类，在.net 8中找不到了。
这个是个大问题。
查了下资料：
在.NET Core 和.NET 5/6/7等较新版本中，ServiceHost 类并不直接存在，
这与.NET Framework中的WCF（Windows Communication Foundation）的 ServiceHost 类有所不同。
在.NET Core及其后续版本中，WCF并没有得到官方的支持，
因此如果你正在迁移一个基于WCF的服务到.NET Core，你将需要寻找其他方式来实现服务宿主。
从.NET 5开始，微软引入了对WCF客户端的部分支持，
允许你调用WCF服务，但仍然没有提供WCF服务端的功能。
但是有第三方的支持，那就是CoreWcf，下面是一些相关的文摘：
升级 WCF 服务器端项目以在 .NET 6 上使用 CoreWCF
https://learn.microsoft.com/zh-cn/dotnet/core/porting/upgrade-assistant-wcf
CoreWCF 支持策略
https://dotnet.microsoft.com/zh-cn/platform/support/policy/corewcf
探索CoreWCF：下一代.NET服务框架
https://blog.csdn.net/gitblog_00099/article/details/137003923
有空闲时勇哥会再次尝试把wcf转为.net core，如果成功了会继写此贴。
