tl; dr Проблема заключается в собственной библиотеке libgrpc_csharp_ext, которая в настоящее время не компилируется и не собирается для процессора arm7.Я скомпилировал его (на пи) для arm7 и выпустил пакет nuget для преодоления разрыва, пока они не поддержат его полностью: https://www.nuget.org/packages/libgrpc_csharp_ext.arm7/
Я обновлю со ссылкой на сообщение в блоге, когдаЯ заканчиваю работу над остальными инструментами и шаблоном, над которым я работаю.
Более полное объяснение: пакет nuget Grpc.Core содержит встроенную библиотеку libgrpc_csharp_ext, которую реализация grpc в dotnet загружает в NativeExtensions.cs затем сопоставляется с PInvoke в NativeMethods.Generated.cs .Изучив этот пакет, вы увидите версию этой библиотеки в каждой папке / runtimes / [win, osx, linux] / native.К сожалению, версия библиотеки для Linux не включена.Однако в коде, если платформа является linux, она попытается загрузить статическую библиотеку, используя имя в формате здесь .Немного рассмотрите это, и вы увидите, что на данный момент, любая платформа 'linux', которая не является '64-битной' (которая, несмотря на то, что процесс на pi является 64-битным, дистрибутив linux, который вы используете там,включая raspbian, скорее всего нет) будет искать libgrpc_csharp_ext.x86.so.Когда вы dotnet publish -r linux-arm, вы увидите эту библиотеку в выходных данных сборки, но, к сожалению, она неправильная (я думаю, что публикация просто захватывает «самую близкую», когда она не может найти конкретную библиотеку в папке runtime),
Пакет nuget, который я создал выше, скомпилирован для arm7 - на самом деле я клонировал репозиторий grpc на pi и отодвинул достаточно сборки / csharp, чтобы просто создать libgrpc_csharp_ext.«Хитрость», которую использует пакет, заключается в том, чтобы поместить библиотеку в папку runtime / linux-arm / native внутри пакета, которую ядро dotnet распознает при публикации и извлекает в вывод сборки - но библиотека по-прежнему называется libgrpc_csharp_ext.x86.so, потому чтоNativeMethods.cs форматирует имя библиотеки.