呓|Jarlyyn's website

用Avalonia(dotnet)或者Flutter 在windows下发布 桌面aot程序需要ms build tool

ms build tool需要有效的Visual Studio 许可证

在企业环境(>250电脑或者>250wusd营收)的情况下，不能使用Visual Studio社区版。

虽然到了这个规模，订阅vs也算九牛一毛

但这个的确和完全free的方案相比，法务问题多很多。

怎么说呢，除了C#一贯的一堆引用外，还是和express/go差不多的洋葱模型。

够轻，容易处理，总体来说还是不错的，如果要在C#桌面程序中嵌入的话，完全够用了。

给玩具项目整了一波大更新，开打包专用的mac mini,然后噩梦开始了。

真，无语。

苹果是怎么做到，一个只用来打包上架的机器，重新发布要种系统到文件权限到IDE全部需要升级折腾一遍的？

怎么做到的？

为啥我为爱发电贴打包机贴开发者账号还要受苹果这样的折磨。

叹气啊。

这一阵gnome的现实设置崩了，多屏设置不能起效，提醒是因为硬件错误，切换回老的linux-image也没用。

于是切到了kde。

怎么说呢，一段时间没用后，kde完善了不少的样子。

例行盘点下目前使用的桌面应用程序

浏览器:chrome/edge,基本不用火狐了

代码编辑:vscode,这个基本已经是行业老大了

图片变加:gimp/krita

git客户端:sourcegit

团队协作:飞书

游戏:steam

IM:微信

办公软件:wps

邮件客户端:雷鸟

发现用的应用数量也开始逐渐减少了。

疯玩一段时间暗黑2重置后，还是思考了下代码。

语言不能脱离生态。

Go语言本质上最大的优势是他的大标准库及其衍生库。

就是基础互联网服务器这一块。

真的到真刀真枪在桌面用户/商业用户这块，第三方库就有点捉襟见肘了。

csharp相应的库是真多，go的第三方库开发浪潮也已经过了，在几年里看来是很难有起色。

人生苦短，没必要为难自己。

用了go这么多年，终于遇到局限性了。

具体来说，就是给go程序加入v8 binding后，发现编译windows版出问题了。

cgo不支持msvc的lib静态库.v8用mingw很难编译。

对，go在windows下是用mingw编译的。

沉默。

说明对于go来说，windows是二等公民。主要力量还是集中在服务端(linux)下。

配合之前测试了把c#的pinvoke的体验。

只能说，go的优势还是在小程序，高并发，服务上。

面向用户的，可能还是c#这类传统语言比较好。

最近在搞typescript同时编译到js和lua。有部分系统函数，比如获取unix时间戳，在js和lua由不同的系统函数获取。

所以必须引入类似条件编译的机制。

最后实现的方式是这样的:

1.建立不同的tsconfig,设置paths,指定平台依赖库在不同的目录下

    "paths": {

      "@include/*": [

        "include/*"

      ],

    },

"paths": {

      "@include/*": [

        "include.lua/*"

      ],

    },

2.js因为用webpack打包，在webpack.config.js的resolve里添加alias,大概为

    resolve: {

        alias:{

            "@include/*": path.resolve(__dirname, 'include/*'),

        },

        extensions: [".ts", ".tsx", ".js"],

    },

3.里为了防止ts报错，安装并引入对应的types

    "types": ["lua-types/5.1"],

4.代码中进行引用申明

/// <reference types="lua-types/5.1" />

重构了下代码，整理了一下最新的代码的分层。

Application 应用层，这个一般跟框架来

UI交互层:ViewModel/View/Controller，这个也跟框架来，这里不放重的逻辑，展示层

Services服务层：处理各种交互用的数据，展示层

Cores核心层：各个核心子系统放在这里，业务层。程序的全局预设也放在这里。同时定义一个单例AppKernel，放具体的核心子系统的实例。业务层

Helpers帮助类:处理业务逻辑和各种跨Model交互的数据，业务层

Adapters:各种与系统交互的实现，比如文件IO/网络IO,分为Interface和实现，方便测试。定义一个单例 SystemAdapter，用于存放实际使用的具体Adapter的实现。

Models模型类，具体的数据，和简单处理，数据层。

utils工具类，简单的工具函数。

不同的Core里 通过Bus总线提供互相调用，事件太不可靠。

先暂时按这个走，感觉Helpers和Cores里面可以加一层业务层。

看看又没有问题。

使用单例时，如果测试并发进行，很明显会造成数据读写冲突。

但是很多时候业务层涉及单例的测试时必须的。

使用XUnit时可以通过集合的注解来避免这个问题

参考

https://stackoverflow.com/questions/1408175/execute-unit-tests-serially-rather-than-in-parallel

实际代码

先定义一个单例的集合类

然后在会使用的这个单例的类里使用Collection注解

即可。