Взаимодействие с неуправляемым кодом в ASP.net vNext

Question

Какова будет история (если таковая будет) взаимодействия с неуправляемым кодом для ASP.net vNext / Core CLR?

Кажется, что присутствуют ключевые биты (DllImport и друзья), позволяющие взаимодействовать с неуправляемым кодом, но как будут работать такие вещи, как упаковка и развертывание, в этом контексте? Основной артефакт сборки в vNext / CoreFX больше не является сборкой, а представляет собой пакет NuGet. Итак, в таком случае, как мы должны заставить работать новую систему project.json, чтобы неуправляемые библиотеки, в которые мы выполняем P/Invoking, также включались в получившийся пакет NuGet?

Или я говорю о сценариях, которые еще не рассматривались (или, что более печально, не произойдет)?

Answer 1

История еще не полностью раскрыта, но примеры того, как это сделать, уже есть. В конечном итоге мы (команды Microsoft, работающие над этим) работаем над некоторыми сценариями, чтобы позволить пакетам NuGet лучше поддерживать нативный контент в пакетах.

Чтобы увидеть один пример этого, веб-сервер Kestrel имеет свой собственный управляемый код, плюс он включает libuv в свой пакет NuGet для эффективной реализации асинхронного ввода-вывода, которая является кроссплатформенной.

Поскольку в NuGet еще нет встроенного общего решения, сценарии сборки для Kestrel используют некоторые пользовательские действия для включения собственного содержимого в пакет NuGet. Затем для загрузки libuv есть некоторый код, который динамически определяет, какой нативный libuv загружать в зависимости от среды, в которой он работает.

Так что, да, это немного грязно, но это работает, и это определенно занимает первое место в списке приоритетов команды для улучшения.