Я столкнулся с подобным решением после попытки использовать пакет SoapCore NuGet в приложении ASP.NET Core 2.1.Хорошо работал на локальном компьютере в Windows 10, но после публикации в Azure дал ту же самую трассировку стека, что и оригинальный плакат.Следующая проблема с GitHub помогла мне понять проблему:
https://github.com/dotnet/wcf/issues/2349
Для меня SoapCore ссылался на System.ServiceModel.Http 4.4.0
и зависел от System.Private.ServiceModel 4.4.0
.Если вы загрузите пакет NuGet и откроете файл nupkg для System.Private.ServiceModel 4.4.0
и увидите подпапку «runtimes», вы увидите только списки «win7» и «unix».Похоже, что Azure ищет среды выполнения "win-x86" или "win-x64", а проблема GitHub, описанная выше, объясняет, как эти RID не были включены в RID "win7".Видя, что проблема закрыта, я скачал System.Private.ServiceModel 4.5.0
, чтобы проверить подпапку «runtimes» и увидел, что она была изменена с «win7» на «win», как упоминалось в выпуске GitHub.
Чтобы решить мою проблему, я напрямую добавил зависимость для System.ServiceModel.Http 4.5.0
в свой проект.Сюда входила более новая зависимость для System.Private.ServiceModel 4.5.0
, и Azure правильно распознал бы «выигрышную» среду выполнения, чтобы убедиться, что необходимая DLL была включена в мое приложение при публикации.