2015-01-15 85 views
2

與ASP.net vNext/Core CLR的非託管代碼互操作的故事將會如何(如果有的話)?與ASP.net中的非託管代碼進行互操作vNext

關鍵位(DllImport和好友)似乎存在以允許非託管代碼互操作,但包裝和部署等工作在這種情況下會如何工作? vNext/CoreFX中的基本構建工件不再顯示爲程序集,而是NuGet程序包。那麼在那種情況下,我們將如何使新的project.json系統工作,以便我們P/Invoking到的非託管dll也包含在生成的NuGet包中?

或者我在談論尚未考慮的情景(或者更令人失望,不會發生)?

回答

5

這個故事還沒有完全充實,但已經有如何做到這一點的例子。最終,我們(微軟團隊正在研究這些)正在研究一些場景,以使NuGet包更好地支持包中的本地內容。

要查看其中的一個示例,Kestrel web server擁有一些自己的託管代碼,並且在其NuGet包中包含libuv以實現跨平臺的高效異步IO實現。

因爲NuGet中還沒有內置的通用解決方案,所以Kestrel的構建腳本使用一些custom actions將原生內容包含在NuGet包中。然後加載libuv就有some code,根據它運行的環境動態地找出要加載哪個本地libuv。

所以,是的,這有點麻煩,但它確實有效,而且這對團隊的優先級列表來說是非常重要的。

+0

這很好聽。 如果我們採用您的假設libuv軟件包,我們是否可以創建一個單獨的xplat nuget軟件包(包括本機windows/unix/osx二進制文件),還是我們必須使用每個平臺的軟件包? – jumpinjackie 2015-01-16 10:10:43

+0

@JackieNg一個包裹來統治他們所有的,都是這個想法,就像Kestrel包,這不是假設 - 這是一個真正的包。它具有在Win7 +,Win2K8 R2 +,OS X和* nix上運行所需的功能。 – Eilon 2015-01-16 16:19:15