#c# #docker #asp.net-core
#c# #docker #asp.net-core
Вопрос:
Мы находимся в процессе переноса одного из наших приложений .net core 2.1 в контейнер Linux. Сначала я использовал Visual Studio для создания контейнера для себя, со встроенной поддержкой превращения вашего проекта в исполняемый файл docker. В Visual Studio это отлично сработало, запустив проект и запустив его точно так, как ожидалось. Проблемы начались, когда мы начали переносить проект в Azure Devops.
Насколько мне известно, мы должны запускать контейнер через CLI, и мы делаем это с помощью команды docker build. Это начало выявлять ошибки, которые мы не видели при запуске через VS. Первой ошибкой было наше частное хранилище, нам пришлось добавить конфигурацию nuget с открытым текстовым паролем для восстановления проекта. После того, как мы устранили эту ошибку, мы начали видеть больше отсутствующих библиотек DLL (например, Microsoft.CSharp) и сообщения об ошибках, такие как: « Resolved file has a bad image, no metadata, or is otherwise inaccessible. Assembly file could not be opened -- PE image doesn't contain managed metadata.
«
Именно на этом этапе я решил сделать шаг назад и попытаться исследовать, как VS создал контейнер, и посмотреть, можно ли изменить способ сборки контейнера. Проблема в том, что я не могу найти много документации по этому вопросу, и ни одна из них не описывает, как я мог бы воспроизвести запуск через VS в командной строке. Что я надеюсь получить из этого, так это точные шаги, которые VS использует, чтобы предоставить контейнеру docker мои учетные данные для nuget, и как он создает контейнер, поскольку это, очевидно, работает не так, как docker build .
.
Комментарии:
1. learn.microsoft.com/en-us/visualstudio/containers / … но поделитесь своим файлом dockerfile, пожалуйста
2. В документации либо отсутствует часть головоломки, либо она неточна. Я могу опубликовать общий файл dockerfile, но мой конкретный файл dockerfile не имеет значения, поскольку файл создается только VS. Этот вопрос касается шагов, которые / config VS выполняет за кулисами для запуска файлов, а не какой-либо конкретной проблемы с файлом.