.NET Core开发日志——Runtime IDentifier

.NET Core对于传统.NET开发人员而言是既熟悉又陌生的新平台,所以有时遇上出乎意料的事情也纯属正常情况。这时只需点耐心,多查查资料,努力找到原因,也未尝不是件有意义的体验。

比如当建完一个最简单的控制台应用程序:

dotnet new console -o helloRID

并完成编译后:

dotnet build

你在bin目录下会发现生成的程序集是dll文件,而非之前经验里的exe文件。

再查下工程文件,输出类型确实是Exe。

是不是感到很意外?

固然,我们也可以使用dotnet run的方式获得程序运行的结果,但这样的文件格式绝不是用户所希望的,他们没有办法直接运行该文件。

问题的缘由很容易借由搜索引擎找到——在编译的时候需要额外指定Runtime IDentifier(运行时标识)。

Runtime IDentifier的作用是指定应用程序运行时的目标平台。这样就很容易理解了,因为.NET Core支持跨平台,所以在编译时编译器默认并不知道你所想生成的可执行文件是需要在哪个平台上运行的,只有你主动告诉它,才能得到你想要的结果。

于是运行dotnet build -r osx-x64(假设你像我一样在macOS系统上运行程序),可执行文件如预期般出现在bin目录的osx-64文件夹下。

如果是Windows 10系统,则运行dotnet build -r win10-x64。熟悉的exe文件再次出现。

更多的Runtime IDentifier可以在微软官网上找到,这里需要夸一下微软,改进后的官方文档现在越来越好用了。

posted @   Ken.W  阅读(1416)  评论(2编辑  收藏  举报
编辑推荐:
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
阅读排行:
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
· C#/.NET/.NET Core优秀项目和框架2025年2月简报
· Manus爆火,是硬核还是营销?
· 终于写完轮子一部分:tcp代理 了,记录一下
· 【杭电多校比赛记录】2025“钉耙编程”中国大学生算法设计春季联赛(1)
点击右上角即可分享
微信分享提示