VB.NET AOT无法编绎DLL,微软的无能，正是你的机会
.net8 AOT编绎-跨平台调用C#类库的新方法-函数导出
1，C#命令行创建工程：dotnet new classlib -o CSharpDllExport
2，编写一个静态方法，并且为它打上UnmanagedCallersOnly特性，告诉编译器我们需要将它作为函数导出，指定名称为Add。
using System.Runtime.InteropServices;
namespace CSharpDllExport
{
public class DoSomethings
{
[UnmanagedCallersOnly(EntryPoint = “Add”)]
public static int Add(int a, int b)
{
return a + b;
}
}
}
——————–
3，导出动态库DLL
dotnet publish CSharpDllExport -p:NativeLib=Shared -r win-x64 -c Release -p:PublishAot=true
4,使用DLL Export Viewer工具打开生成的.dll文件，查看函数导出是否成功.
如下图所示，我们成功的把ADD方法导出了，另外那个是默认导出用于Debugger的方法，我们可以忽略。
————————————
这几天一直为了微软抛弃VB6,vb.net（2020年放弃）而苦恼，不可否认微软是一个强大的公司。
自从.NET CORE跨平台，开源vb.net这2年几乎和C#一样的热度和使用人数了，可惜微软马上急刹车，永久停止了更新。
这有点像是怕自家大儿子学习太好而不让他上大学一样。
我不准备把你当成一个大学生去发展，你去打工吧！！！
其实微软在很多地方做的不好，没统计有多少用户是需要的。
比如.NET 8 aot编绎成独立的EXE，不需要安装.NET框架就能运行，这是20年前就需要的功能。
结果到了现在亚马逊云，阿里云这些公司需要容器布署（安装一个EXE虚拟环境运行JAVA或.NET就能代替一整个庞大的操作系统）
一个系统相同的内存和CPU可以做100个，1000个容器卖给不同的客户，这是新的发明，微软却以前想不到。
这下微软才想着，独立EXE好像有用了。结果C#可以导出标准DLL动态库（支持像WINDOWS API一样的调用），可惜VB.NET不支持该功能。
C#也无法导出activex dll。
前2天想学着用一下hpsocket.dll实现WEBSOCKET，弄半天才知道这玩意本身是没有websocket支持功能的。
并且里面有1400个API，多少恐怖的事情。API太多，别的语言要调用就很麻烦，学会可能要10小时到10天一个月。
如果是COM DLL，双击注册（免注册加载），10秒到10分钟就学会使用了。
.NET8或.net程序创建时直接设置一下就能支持生成标准DLL,Com DLL(同时提供免注册功能选项)，创建WINDOWS 服务，或者导出体积较大的独立EXE。
这些本来就该VS应该做到的功能，因为是有钱人世界上最优秀的公司，所以傲慢，没有主动为客户着想。
以前很少用VB.NET，最近开始一个月强势入门发力学习，一个最简单的窗体复制一下，结果生成2个文件类名都需要手工去修改。
想想微软有多少坑或缺点？
但也不可能全部决策都是胜利的。比如现在安卓系统免费，跨时代的发明受益了多少人？
python的免费开源跨平台，也成为了全球第一受欢迎的人。
只有微软的一些失误，别人才能有更多的机会不是，否则那和被垄断有何区别。
要是微软主导的WINDOWS PHONE或者win10 arm版之类的平板电脑手机主导世界
那我们每个手机要多付100-300元授权费用，同时更新缓慢，速度卡卡的（微软经常一些严重的失误，代码修修补补，做的很难用）
也不会有这么多优秀的APP给我们用。
————–
别人的无能，就是你的机会