在代码的规范化方面，我最近尝试了几种方式。

在代码的规范化方面，我最近尝试了几种方式。

首先，我已经将项目代码中的业务逻辑和框架逻辑进行了剥离。

在不同的项目中，业务逻辑是变动的，但是框架逻辑是可以复用的，比如日志，持久化，图像编辑器，菜单，权限，主题，语言等等。

当然框架并不适用于任何一个项目，构建也会依赖于开源的nuget包，比如日志模块就是对log4net进一步封装，增加了显示的窗口以及持久化的部分。持久化是基于Newtonsoft Json，当然实现的方案有很多，也可以使用ini,或者是xml 又或者是wpf框架下自带的。

更换新的项目，我尝试过将代码copy过去，效果很好，但是很快不断迭代和修改的框架代码就和copy过去的代码产生了脱节。可以使用但是麻烦。

我又尝试了使用dll copy的方式，将指定一个dll 的文件夹路径，依赖从这里读取。方便很多，但灵活性还是差一点，如果在工程中配置工程外的地址指定复制，换台电脑又不可以了。而且dll 的版本很难管控。

于是我尝试使用 子项目的方式，项目添加子项目，在VS上面两个项目都可以管理。更新也来得及，修改也方便。

不过成子项目之后，引起了一些新的问题，并且不好解决。最关键的是我记不住子项目的git命令，每次都要查。

在这种的情况下，优化使用dll的方式貌似更靠谱。而且我可以通过配置多框架的方式，支持NET48以及NETCORE.

只要把UI框架代码和业务代码做一个简单的分拆。

考虑到每次变更版本都需要我手动上传的话，也太麻烦了。

更进一步的集成 github action。

dotnet nuget push *.nupkg --api-key ${{ secrets.NUGET_API_KEY }} --source https://api.nuget.org/v3/index.json --skip-duplicate

每次提交之后，自动触发编译上传，同时触发webhook 到jeninks编译。

本来我是想要将python 打包的自动化也一起挂起来的，不过这里出了点问题，编译ok了

不过暂时手动打包也足够用了。

增量更新的逻辑，后面还是需要在优化一下，应该是一步一步升上来，而不是仅仅替换文件。