Как развернуть приложение Blazor WASM в среде разработки?

Проблема, с которой вы столкнулись, связана с тем, как Blazor WebAssembly (WASM) обрабатывает файлы конфигурации при работе в различных окружениях, особенно в контексте контейнеризации с Docker.

### Причины проблемы

1. **Конфигурация только на стороне сервера:** Приложение Blazor WASM работает в браузере, и конфигурационные файлы (`appsettings.json`, `appsettings.Development.json`) загружаются через HTTP запросы на серверное приложение. В вашем случае конфигурация устанавливается на стороне сервера, но, когда вы разворачиваете приложение в Docker, вы используете только статические файлы для отдачи контента NGINX, который не выполняет серверную логику ASP.NET.

2. **Окружение NGINX:** NGINX не понимает, что такое `ASPNETCORE_ENVIRONMENT`, и он просто отдает статические файлы. Соответственно, он не может выбирать между `appsettings.json` и `appsettings.Development.json` в зависимости от установленного окружения.

### Шаги для исправления проблемы

Чтобы решить эту проблему, можно рассмотреть несколько подходов:

1. **Преобразование файлов конфигурации:** Если вам нужно использовать разную конфигурацию в зависимости от окружения, вы можете либо создать отдельные статические файлы конфигурации и использовать их, либо настроить сервер для работы с динамической конфигурацией. Например, можно создать серверный API на ASP.NET Core, который будет возвращать нужную конфигурацию в зависимости от окружения.

2. **Использование переменных окружения:** Если вы хотите, чтобы ваше Blazor WASM приложение получало настройки из переменных окружения, вам нужно будет реализовать логику получения этих переменных в код вашего приложения и загружать их в конфигурацию при инициализации.

3. **Изменение Dockerfile и nginx.conf:**
   - Можно настроить ASP.NET Core для работы в контейнере, чтобы он служил в качестве API для вашего Blazor приложения, и оставить конфигурацию на стороне сервера.
   - Например, вместо статической привычки отдать  NGINX, можно использовать Kestrel, чтобы обрабатывать запросы к API, а не только статические файлы.

Пример использования Kestrel в вашем `Dockerfile`:
```dockerfile
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /app
COPY /src .
COPY /modules /modules
RUN dotnet restore TestClient.csproj
RUN dotnet build TestClient.csproj -c Release -o /app/build

FROM build AS publish
RUN dotnet publish TestClient.csproj -c Release -o /app/publish

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "TestClient.dll"]
```

Это позволит вашему приложению работать как сервер с поддержкой файлов конфигурации.

4. **Запуск Docker-контейнера с настройками:** Убедитесь, что при запуске вашего контейнера с Docker вы правильно указываете переменные окружения, которые необходимы для работы вашего приложения.

### Примечание

Если вы собираетесь оставаться с NGINX как с вашим сервером, подумайте о том, как лучше интегрировать ваши конфиги, возможно, используя сторонние библиотеки, которые могут помочь в конфигурации в зависимости от окружения или даже создания конфигурационных API. 

Таким образом, важно учесть архитектурные решения для правильного состава вашего сервера и клиентской части Blazor WASM.

И так, решение найдено. 
 За environment в blazor WASM отвечает не сервер, а клиент. А чтобы клиент узнал, что он в другом environment'e, то нужно отдать ему в заголовке это. 
 
 nginx.conf: 
 
 
server {
    listen 80;

    add_header Blazor-Environment TO_REPLACE_BLAZOR_ENVIRONMENT;

    location / {
        root /usr/share/nginx/html;
        try_files $uri $uri/ /index.html =404;
    }
}
 
 
 Затем в Dockerfile нужно будет просто поменять TO_REPLACE_BLAZOR_ENVIRONMENT на ваш Environment: 
 
 
FROM nginx:alpine AS final
# Объявляем аргумент сборки
ARG BUILD_ENVIRONMENT
WORKDIR /usr/share/nginx/html
COPY --from=publish /app/publish/wwwroot .
COPY nginx.conf /etc/nginx/nginx.conf
#меняем nginx.conf
RUN sed -i -e 's/TO_REPLACE_BLAZOR_ENVIRONMENT/'"$BUILD_ENVIRONMENT"'/g' /etc/nginx/nginx.conf