小編今天帶大家了解.NET Core開發(fā)Runtime IDentifier的示例分析，文中知識(shí)點(diǎn)介紹的非常詳細(xì)。覺得有幫助的朋友可以跟著小編一起瀏覽文章的內(nèi)容，希望能夠幫助更多想解決這個(gè)問題的朋友找到問題的答案，下面跟著小編一起深入學(xué)習(xí)“.NET Core開發(fā)Runtime IDentifier的示例分析”的知識(shí)吧。

創(chuàng)新互聯(lián)是一家專業(yè)提供橋東企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站建設(shè)、H5建站、小程序制作等業(yè)務(wù)。10年已為橋東眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)絡(luò)公司優(yōu)惠進(jìn)行中。

.NET Core對于傳統(tǒng).NET開發(fā)人員而言是既熟悉又陌生的新平臺(tái)，所以有時(shí)遇上出乎意料的事情也純屬正常情況。這時(shí)只需點(diǎn)耐心，多查查資料，努力找到原因，也未嘗不是件有意義的體驗(yàn)。

比如當(dāng)建完一個(gè)最簡單的控制臺(tái)應(yīng)用程序：

dotnet new console -o helloRID

并完成編譯后：

dotnet build

你在bin目錄下會(huì)發(fā)現(xiàn)生成的程序集是dll文件，而非之前經(jīng)驗(yàn)里的exe文件。

再查下工程文件，輸出類型確實(shí)是Exe。

是不是感到很意外？

固然，我們也可以使用dotnet run的方式獲得程序運(yùn)行的結(jié)果，但這樣的文件格式絕不是用戶所希望的，他們沒有辦法直接運(yùn)行該文件。

問題的緣由很容易借由搜索引擎找到——在編譯的時(shí)候需要額外指定Runtime IDentifier(運(yùn)行時(shí)標(biāo)識(shí))。

Runtime IDentifier的作用是指定應(yīng)用程序運(yùn)行時(shí)的目標(biāo)平臺(tái)。這樣就很容易理解了，因?yàn)?NET Core支持跨平臺(tái)，所以在編譯時(shí)編譯器默認(rèn)并不知道你所想生成的可執(zhí)行文件是需要在哪個(gè)平臺(tái)上運(yùn)行的，只有你主動(dòng)告訴它，才能得到你想要的結(jié)果。

于是運(yùn)行dotnet build -r osx-x64(假設(shè)你像我一樣在macOS系統(tǒng)上運(yùn)行程序)，可執(zhí)行文件如預(yù)期般出現(xiàn)在bin目錄的osx-64文件夾下。

如果是Windows 10系統(tǒng)，則運(yùn)行dotnet build -r win10-x64。熟悉的exe文件再次出現(xiàn)。

更多的Runtime IDentifier可以在微軟官網(wǎng)上找到，這里需要夸一下微軟，改進(jìn)后的官方文檔現(xiàn)在越來越好用了。

感謝大家的閱讀，以上就是“.NET Core開發(fā)Runtime IDentifier的示例分析”的全部內(nèi)容了，學(xué)會(huì)的朋友趕緊操作起來吧。相信創(chuàng)新互聯(lián)小編一定會(huì)給大家?guī)砀鼉?yōu)質(zhì)的文章。謝謝大家對創(chuàng)新互聯(lián)網(wǎng)站的支持！