Dotnet linux команда не найдена

Обновлено: 04.07.2024

Полезная версия libssl не была найдена

Прервана (ядро бросила)

UPDATE: информация о системе:

openSUSE прыжок 15.0

Kernel версия 4.12.14-lp150.12.22-default

4 ответа

Немного более длинное объяснение для тех, кому любопытно:

OpenSSL-одна из наиболее распространенных криптографических библиотек, используемых на Linux. Он имеет несколько версий. Версия 1.0 довольно старая, но часто используемая. 1.1-это более новая версия, которая была (относительно) недавно выпущена. 1.0 и 1.1 несовместимы. Приложение, которое ожидает 1.0, не может ни строить против 1.1, ни работать против него.

У меня была та же проблема с запуском sqlpackage на Ubuntu 20.04, когда dotnet работал регулярно.

Решается с помощью

Dotnet прекрасно работает сам по себе. Но запуск sqlpackage не работает:

Все это прекрасно работало. Внезапно я получаю эту ошибку на azure при развертывании приложения. Указанная версия SDK [2.0.0] из global.json [D:\home\site\repository\global.json] не найдена; установите указанную версию SDK version\r\n\r\nDid вы хотите запустить команды dotnet SDK? Пожалуйста.

Для raspberry pi / debian он хочет именно libssl 1.0.2, и ничего больше.

sudo apt-get установить libssl1.0.2

должен сделать трюк для пи! Я не могу говорить о других вариантах.

Похожие вопросы:

Поэтому я снял opensuse Docker-всего 94 м, здорово! Я создал такой файл Docker: FROM opensuse RUN zypper --non-interactive install tar RUN zypper --non-interactive clean -a RUN rm -rf /var/log/zypp.

Я скачал двоичный пакет dotnet-core SDK (dotnet-sdk-2.1.400-linux-x64.tar.gz) и хочу установить его на мою систему void-linux, которая использует LibreSSL. После запуска dotnet help я получил ответ.

Поэтому я скачал NET Core 2.1 SDK для mac и установил его. Но когда я запускаю команду dotnet из terminal, она выдает ошибку -bash: dotnet: command not found . Я пытаюсь использовать dotnet new.

Все это прекрасно работало. Внезапно я получаю эту ошибку на azure при развертывании приложения. Указанная версия SDK [2.0.0] из global.json [D:\home\site\repository\global.json] не найдена;.

Команда 'dotnet' не найдена, но может быть установлена с помощью: sudo snap install dotnet-sdk '

Я ожидал, что скрипт сделает все и сделает доступным dotnet .

TL;DR: curl | bash curl | bash не может изменить PATH поэтому он не добавит dotnet к вашему PATH . Вам нужно добавить dotnet к вашему пути вручную. Добавьте export PATH="$PATH: /home/<!username!>/.dotnet" в ваш

/.bashrc или эквивалентный) и выйдите из системы и снова войдите в систему.

Когда вы запускаете команду в оболочке (например, bash), оболочка пытается найти исполняемый файл с именем во всех путях, перечисленных в переменной окружения PATH . PATH обычно устанавливается на что-то вроде /bin: /usr/bin . Поэтому, когда вы вводите команду, подобную curl , ваша оболочка ищет в исполняемых файлах /bin и /usr/bin исполняемый файл с именем curl .

Вы можете увидеть, каков ваш PATH , выполнив env | grep PATH env | grep PATH или echo $PATH .

Другая важная часть информации - как распространяются переменные среды. Это довольно просто, на самом деле:

  1. Программа (или процесс) может изменять только свой собственный набор переменных среды.
  2. Любые дочерние процессы, которые создает процесс, наследуют его переменные среды.

Это означает, что выполняемая вами программа не может изменять переменные окружения другой случайной программы. Оболочка фактически предоставляет специальную команду export для установки своих собственных переменных среды (и любые дочерние процессы, которые она создает позже, наследуют их).

Обратите внимание на вывод в конце шага 1.

Примечание. Это изменение будет отображаться только в сценарии поиска.

Если вы запустите curl | bash curl | bash , он запускает bash как дочерний процесс. Этот дочерний процесс не может изменять переменные среды программы, которая его запустила (оболочка, которая вызвала curl | bash ). Поэтому он не может изменить PATH чтобы добавить в него местоположение dotnet . Это даже (полезно) говорит вам, что не может.

На шаге 2 вы перезагружаете

/.profile . Но содержит ли он какие-либо команды для добавления dotnet в PATH ? Я так не думаю. Я знаю, что скрипт dotnet-install.sh исторически не добавлял его. Вам нужно добавить строку как

/.bashrc , или эквивалентный) вручную.

На самом деле, я написал бы это следующим образом, чтобы сделать изменение более переносимым для других пользователей:

Команда 'dotnet' не найдена, но может быть установлена с помощью: sudo snap install dotnet-sdk`

Я ожидал, что сценарий сделает все и сделает доступным dotnet .

2 ответа

TL; DR: curl | bash не может изменить PATH , поэтому он не добавит dotnet в ваш PATH . Вам нужно добавить dotnet в свой путь вручную. Добавьте export PATH="$PATH:/home/<!username!>/.dotnet" в свой

/.bashrc или аналогичный), выйдите из системы и снова войдите в систему.

Когда вы запускаете команду в оболочке (например, bash), оболочка пытается найти исполняемый файл с именем во всех путях, перечисленных в переменной среды PATH . PATH обычно устанавливается на что-то вроде /bin:/usr/bin . Поэтому, когда вы набираете команду типа curl , ваша оболочка ищет как в /bin , так и в /usr/bin исполняемый файл с именем curl .

Вы можете увидеть, что делает ваш PATH , выполнив env | grep PATH или echo $PATH .

Другая важная информация - это то, как распространяются переменные среды. На самом деле это довольно просто:

  1. Программа (или процесс) может изменять только свой собственный набор переменных среды.
  2. Любые дочерние процессы, создаваемые процессом, наследуют его переменные среды.

Это означает, что программа, которую вы выполняете, не может изменять переменные среды другой случайной программы. Оболочка фактически предоставляет специальную команду export для установки собственных переменных среды (и любые дочерние процессы, которые она создает позже, наследуют их).

Обратите внимание на результат в конце шага 1.

Примечание. Это изменение будет видно только при поиске скрипта.

Если вы запустите curl | bash , он запустит bash как дочерний процесс. Этот дочерний процесс не может изменять переменные среды программы, которая его запустила (оболочки, которая вызвала curl | bash ). Таким образом, он не может изменить PATH , чтобы добавить к нему местоположение dotnet . Он даже (услужливо) говорит вам, что не может.

На шаге 2 вы перезагружаете

/.profile . Но содержит ли он какие-либо команды для добавления dotnet в PATH ? Я так не думаю. Я знаю, что сценарий dotnet-install.sh исторически не добавлял его. Вам нужно добавить строку вроде

/.bashrc , или аналогичный) вручную.

На самом деле, чтобы сделать изменение более переносимым для других пользователей, я бы написал его следующим образом:

о dotnet

Для начала мы собираемся открыть терминал (Ctrl + Alt + T) и ввести следующие команды:

скачать microsoft .net и установить на Ubuntu

также нам нужно будет включить репозиторий «Вселенная», если он еще не включен. Это можно сделать, набрав в терминале:

установить apt-transport-https

установить dotnet sdk 2.2

После установки мы можем проверьте установленную версию печатать:

версия dotnet

Создание вашего первого приложения с помощью dotnet

В качестве примера я создам новое приложение под названием 'ubunlogApp'. Для этого вам просто нужно открыть терминал (Ctrl + Alt + T) и запустить:

Создать консольное приложение с помощью dotnet

Как вы можете видеть на скриншоте выше, dotnet создал новое приложение консольного типа. Параметр -o создает каталог с именем 'ubunlogApp'где хранятся данные приложения со всеми необходимыми файлами.

Если мы перейдем в каталог ubunlogApp, мы найдем что-то вроде следующего:

файлы из приложения, созданного с помощью dotnet

Есть два файла с именами ubunlogApp.csproj и Program.cs и каталог с именем obj. По умолчанию, файл Program.cs будет содержать код для запуска программы 'Привет мир'на консоли. Мы можем взглянуть на программный код, набрав:

hello world dotnet program.cs файл

Если мы хотим запустите приложение, которое мы только что создали, вам просто нужно написать следующую команду:

результат терминала hello world dotnet

"Привет, мирТипичный вариант - это так просто. Сейчас же, любой может написать свой код в файле Program.cs и запустите его таким же образом.

Еще мы можем создать новый каталог, например, мой код, используя команды:

… И оттуда мы можем сделать этот каталог наша новая среда разработки выполнив следующую команду:

приложение dotnet мой код

Приведенная выше команда создаст два файла с именами mycode.csproj и Program.cs, а также каталог с именем obj. Теперь мы можем открыть файл Program.cs в редакторе и удалить или изменить существующий код hello world с помощью нашего собственного кода.

После того, как код, который мы хотим, написан, нам просто нужно сохранить и закрыть файл Program.cs. После этого мы можем запустить приложение:

Он может обратитесь в справку dotnet печатать:

Редактор кода Microsoft Visual Studio

Это легкий и мощный редактор исходного кода с открытым исходным кодом. Он поставляется со встроенной поддержкой JavaScript, TypeScript и Node.js и имеет богатую экосистему расширений для других языков, таких как C ++, C, Python, PHP или Go.

к узнать больше о dotnet, вы можете проконсультироваться официальная страница проекта.

Содержание статьи соответствует нашим принципам редакционная этика. Чтобы сообщить об ошибке, нажмите здесь.

Предупреждение читателю: статья ориентирована на совсем новичков в docker/dotnet core и писалась большей частью, как напоминалка для себя. Вдохновлялся я первыми 3 частями Docker Get Started Guide и неким блог-постом на english. У кого хорошо с английским, можно читать сразу их и в общем-то будет сильно похоже. Если же после всего вышенаписанного вы еще не передумали продолжить чтение, то добро пожаловать под кат.

Пререквизиты

Итак нам понадобится собственно Linux (в моем случае это была Ubuntu 16.04 под VirtualBox на Windows 10), dotnet core, docker, а также docker compose, чтобы было удобнее поднимать сразу несколько контейнеров за раз.

Никаких особых проблем с установкой возникнуть не должно. По крайней мере, у меня таковых не возникло.

Из того, что может под Linux, для себя я попробовал Visual Studio Code и JetBrains Rider.

Visual Studio Code
Что могу сказать — оно работает. Отлаживаться можно, синтаксис подсвечивается, но уж очень все незатейлево — осталось впечатление, что это блокнот с возможностью отладки.

Rider
По сути Idea, скрещенная с решарпером — все просто и понятно, если работал до этого с любой IDE от JetBrains. До недавнего времени не работал debug под linux, но в последней EAP сборке его вернули. Вообщем для меня выбор в пользу Rider был однозначен. Спасибо JetBrains за их классные продукты.

Создаем проект

Презреем в учебных целях кнопки Create Project различных IDE и cделаем все ручками через консоль.

1. Переходим в директорию нашего будущего проекта
2. Посмотрим ради интереса, какие шаблоны мы можем использовать


3. Создадим WebApi проект


4. Подтянем зависимости


5. Запустим наше приложение

Готовим приложение к докеризации

Заходим в Program.cs и в настройке хоста добавляем


В итоге должно получится что-то типа

Соответственно, докеризовав dotnet core приложение с дефолтной настройкой прослушиваемых url можно потом довольно долго удивляться, почему проброс портов не работает, и перечитывать свой docker-файл в поисках ошибок.

А еще можно добавить приложению немного функциональности

Передача параметров в приложение

При запуске контейнера хотелось бы иметь возможность передавать приложению параметры.
Беглое гугление показало, что если обойтись без экзотики типа обращения изнутри контейнера к сервису конфигурации, то можно использовать передачу параметров через переменные окружения или подмену файла конфига.

Отлично, будем передавать через переменные окружения.

Идем в Startup.cs publicpublic Startup(IHostingEnvironment env) и смотрим, что у нашего ConfigurationBuilder вызван метод AddEnvironmentVariables() .

Собственно все — теперь можно инжектить параметры из переменных окружения куда угодно через DI.

Идентификатор инстанса

При старте инстанса приложения будем генерировать новый Guid и засунем его в IoC-контейнер, чтобы раздавать страждущим. Нужно это, например, для анализа логов от нескольких параллельно работающих инстансов сервиса.

Все тоже достаточно тривильно — у ConfigurationBuilder вызываем:


После этих двух шагов public Startup(IHostingEnvironment env) будет выглядеть примерно так:


Немного про DI

Он не показался мне хоть сколько-нибудь интуитивным. Глубоко я не копал, но тем не менее приведу ниже небольшой пример того, как прокинуть Id инстанса, который мы задаем при старте, и что-нибудь из переменных окружения(например переменную MyTestParam) в контроллер.

Первым делом надо создать класс настроек — имена полей должны совпадать с именами параметров конфигурации, которые мы хотим инжектить.


Далее идем в Startup.cs и вносим изменения в ConfigureServices(IServiceCollection services)


И последним шагом идем в наш подопытный и единственный созданный автоматом ValuesController и пишем инжекцию через конструктор


не забывая добавить using Microsoft.Extensions.Options; . Для теста переопределяем ответ любого понравившегося Get метода, чтобы он возвращал обретенные контроллером параметры, запускаем, проверяем → профит.

Собираем и запускаем docker-образ

1. Первым делом получим бинарники нашего приложения для публикации. Для этого открываем терминал, переходим в директорию проекта и вызываем:


Более подробно про команду можно почитать тут.

Запуск этой команды без доп. аргументов из директории проекта сложит dll-ки для публикации в ./bin/Debug/[framework]/publish

2. Собственно эту папочку мы и положим в наш docker-образ.

Для этого создадим в директории проекта Dockerfile и напишем туда примерно следующее:


3. После того, как Dockerfile написан, запускаем:


Где my-cool-service — имя образа, а 1.0 — тэг с указанием версии нашего приложения

4. Теперь проверим, что образ нашего сервиса попал в репозиторий:


5. И, наконец, запустим наш образ:

Посмотреть образы в локальном репозитории

Посмотреть запущенные контейнеры

Запустить контейнер в detached mode

Получить информацию о контейнере

Остановить контейнер

Удалить все контейнеры и все образы

Немного docker-compose напоследок

docker-compose удобен для запуска групп связанных контейнеров. Как пример, приведу разработку нового микросервиса: пусть мы пишем сервис3, который хочет общаться с уже написанными и докеризованными сервисом1 и сервисом2. Сервис1 и сервис2 для целей разработки удобно и быстро поднять из репозитория через docker-compose .

Напишем простенький docker-compose.yml , который будет поднимать контейнер нашего приложения и контейнер с nginx (не знаю, зачем он мог понадобиться нам локально при разработке, но для примера сойдет) и настраивать последний, как reverse proxy для нашего приложения.


docker-compose поднимает при старте между сервисами, описанными в docker-compose файле, локальную сеть и раздает hostname в соотвествии с названиями сервисов. Это позволяет таким сервисам удобно между собой общаться. Воспользуемся этим свойством и напишем простенький файл конфигурации для nginx


из директории с docker-compose.yml и получаем nginx, как reverse proxy для нашего приложения. При этом рекомендуется представить, что тут вместо nginx что-то действительно вам полезное и нужное. Например база данных при запуске тестов.

Мы создали dotnet core приложение на Linux, научились собирать и запускать для него docker-образ, а также немного познакомились с docker-compose .

Надеюсь, что кому-нибудь эта статья поможет сэкономить немного времени на пути освоения docker и/или dotnet core.

Просьба к читателям: если вдруг среди вас у кого-нибудь есть опыт с dotnet core в продакшене на Linux (не обязательно в docker, хотя в docker особенно интересно) — поделитесь, пожалуйста, впечатлениями от использования в комментариях. Особенно будет интересно услышать про реальные проблемы и то, как их решали.

Читайте также: