Сайты и приложения
Как выложить приложение на .NET (C#) в интернет
Коротко
Приложение на ASP.NET Core выкладывается в интернет без аренды сервера: загрузите исходный код вместе с файлом проекта .csproj — платформа сама определит .NET, соберёт проект и выдаст публичную ссылку с HTTPS. Главное условие одно: приложение должно слушать адрес, который задаёт платформа переменной окружения ASPNETCORE_URLS, а не зашитый в коде localhost или порт 5000. Свой HTTPS внутри приложения включать не нужно — защищённое соединение и сертификат даёт платформа снаружи, приложению достаточно обычного http. Строку подключения и ключи держите в переменных окружения, а не в appsettings.json.
Обычно, чтобы выложить приложение на .NET в интернет, начинают искать хостинг под ASP.NET Core: арендовать сервер, поставить туда нужную версию .NET, собрать проект, повесить перед ним nginx или IIS, выпустить сертификат и следить, чтобы процесс поднимался после перезагрузки. Для одного сайта или небольшого сервиса на C# это несколько вечеров работы, никак не связанной с самим приложением.
В Netrun это выглядит иначе: вы загружаете папку с исходным кодом, платформа находит файл проекта с расширением .csproj, сама ставит нужную версию .NET, собирает приложение и выдаёт публичную ссылку с HTTPS. Ни сервера, ни IIS, ни ручного сертификата. Ниже — шесть шагов, которые отделяют папку с кодом от рабочей ссылки, и три места, где чаще всего спотыкаются именно .NET-проекты.
Оставьте в архиве только исходники#
Платформа собирает проект у себя, поэтому нужен исходный код вместе с файлом .csproj, а если проектов несколько — и с файлом решения .sln. Папки bin и obj в архив класть не нужно: это результат сборки на вашей машине, он только раздувает архив и иногда мешает сборке. Пакеты NuGet тоже не переносите — они подтянутся сами по списку зависимостей из файла проекта.
Слушайте адрес из ASPNETCORE_URLS#
Адрес и порт задаёт платформа: нужное значение приезжает в переменной окружения ASPNETCORE_URLS, и Kestrel читает её сам, без единой строчки кода. Уберите всё, что перебивает это значение: вызов UseUrls в коде, секцию Kestrel с портами 5000 и 5001 в appsettings.json, привязку к localhost или 127.0.0.1. Захардкоженный порт и привязка к localhost — причина номер один, по которой ссылка потом не открывается. Файл launchSettings.json на публикацию не влияет вообще, он нужен только для запуска на вашем компьютере.
Не включайте HTTPS внутри приложения#
Защищённое соединение и сертификат даёт платформа снаружи, а до вашего приложения запрос доходит уже обычным http. Поэтому сертификат разработчика, вызов UseHttpsRedirection и HTTPS-порт в настройках Kestrel внутри проекта не нужны: они либо ничего не делают, либо уводят посетителя на адрес, которого нет, и он видит бесконечное перенаправление. Замочек в браузере при этом остаётся на месте — его обеспечивает платформа.
Вынесите строку подключения и ключи в секреты#
Строку подключения к базе, ключи внешних сервисов и токены не оставляйте в appsettings.json: этот файл едет вместе с кодом и попадает в репозиторий. При настройке проекта Netrun спросит эти значения и подставит их в переменные окружения в зашифрованном виде. Конфигурация ASP.NET Core читает окружение поверх appsettings.json автоматически, а вложенные ключи записываются через двойное подчёркивание — например, ConnectionStrings__Default.
Решите, где будут лежать данные#
Файлы, которые приложение записывает рядом с кодом, при следующей публикации создаются заново. Всё, что должно пережить обновление кода, — загруженные пользователями файлы или база SQLite — сохраняйте в постоянную папку /data: её содержимое видно в кабинете на вкладке «Данные», оттуда файлы можно скачать, загрузить и удалить. Если нужна полноценная база вроде PostgreSQL, поднимите её отдельным сервисом рядом с приложением через свой файл docker-compose. У проектов со своим docker-compose папки /data нет: там постоянное хранилище задают именованные тома из вашего файла.
Загрузите код и заберите ссылку#
Принесите проект одним из двух способов: ZIP-архивом с исходниками или импортом репозитория с GitHub, в том числе приватного. Ставить .NET SDK где-либо и выполнять команды сборки не нужно, всё происходит на нашей стороне. Логи и статус публикации видны в кабинете в реальном времени, поэтому ошибку сборки видно сразу, а не по пустой странице; когда приложение поднялось, вы получаете публичную ссылку с HTTPS.
Итог: сайт или API на C# открывается по обычной ссылке, которую можно отправить кому угодно, без аренды сервера и настройки сертификатов. На бесплатном тарифе доступен один проект, и сайт на нём засыпает при простое, а просыпается сам, когда кто-то открывает ссылку — первый заход после паузы будет чуть медленнее. Если приложение должно отвечать без задержек круглосуточно или к нему нужен свой домен, подойдёт тариф Pro; актуальные цены и лимиты видны в кабинете. Попробовать Netrun.
Частые вопросы
Нужно ли выполнять dotnet publish перед загрузкой?
Нет, загружайте исходный код: сборка выполняется на нашей стороне по файлу проекта .csproj. Готовую сборку и папки bin и obj в архив класть не нужно — они только увеличивают размер архива. Устанавливать .NET SDK где-то у себя тоже не требуется.
Что делать, если в решении несколько проектов?
Оставьте в архиве файл решения .sln вместе с запускаемым веб-проектом и библиотеками, от которых он зависит — тогда сборка пройдёт как обычно. Если структура сложная и проектов для запуска несколько, надёжнее положить рядом свой Dockerfile: платформа использует его вместо автоматической сборки. Отдельные фоновые сервисы удобнее вынести в отдельные проекты Netrun.
Почему сайт на ASP.NET Core не открывается по ссылке?
Чаще всего приложение слушает не тот адрес: порт прописан в коде или в appsettings.json, либо привязка сделана к localhost вместо 0.0.0.0. Уберите свои значения и дайте Kestrel прочитать ASPNETCORE_URLS. Вторая частая причина — включённое перенаправление на HTTPS внутри приложения: оно уводит посетителя на адрес, которого внутри контейнера нет. Что именно произошло, видно в логах в кабинете.
Нужен ли сертификат разработчика и dotnet dev-certs?
Нет. Сертификат и защищённое соединение выдаёт платформа снаружи, а внутрь запрос приходит обычным http. Команды вроде dotnet dev-certs нужны только для локальной разработки, при публикации они ничего не решают.
Blazor, Minimal API и MVC поддерживаются?
Да, для платформы это обычное веб-приложение на ASP.NET Core, разница в шаблоне проекта роли не играет. Blazor Server и Blazor WebAssembly, размещённые вместе с сервером, работают так же, как MVC или Minimal API. Отдельный клиент Blazor WebAssembly без сервера можно выложить как статический сайт.
Можно ли использовать SQLite и Entity Framework?
Да, но файл базы должен лежать в постоянной папке /data, иначе он пересоздастся при следующей публикации. Строку подключения указывайте в переменных окружения, а не в appsettings.json. Миграции удобнее применять при старте приложения — доступа по SSH внутрь контейнера нет, отдельную команду выполнить негде.
Какие языки и технологии поддерживаются?
Python, Node.js, Go, Rust, Ruby, PHP, Java, .NET, Deno, Bun, Elixir, статические сайты и bash-скрипты. Можно принести свой Dockerfile или docker-compose, но чаще стек определяется по коду автоматически.
Нужно ли уметь работать с Docker?
Нет. Netrun сам определяет язык проекта и собирает его. Если у вас уже есть Dockerfile или docker-compose, мы их поддержим, но писать их специально не требуется.
Где указать токены и другие секретные значения?
В проекте есть вкладка «Секреты» — там задаются значения из кода, например токен от BotFather. Мы храним их в зашифрованном виде: названия переменных вы видите, сами значения не показываем никому, включая вас.
Почему мой сайт иногда засыпает?
На бесплатном тарифе сайты засыпают после простоя и просыпаются за пару секунд при первом запросе. На тарифе Pro проект работает без сна.