Aspnetcore: Включение преобразований web.config для проектов AspNetCore в VS

FWIW, я согласен. Нам просто нужно четко указать, что это для настроек IIS. Другой момент заключается в том, что мы отказались от использования в шаблоне значения по умолчанию web.config так что это необходимо выяснить.

/ cc @sayedihashimi

Но это только для IIS? Я думаю, что суть проблемы заключается в использовании переменной ASPNETCORE_ENVIRONMENT fullstop, чтобы сайт знал, в какой среде он находится.

Я думаю, что довольно распространенный сценарий состоит в том, что различные промежуточные среды / среды контроля качества размещаются на одном компьютере в одном экземпляре IIS. Могут быть 3 команды, каждая со своими собственными «средами», которые они могут развернуть для тестирования своего кода (скажем, развернуть конкретную ветку), но все они используют одну и ту же коробку.

Если мы возьмем пример кода того, как appsettings.json переключается на среду:

public Startup(IHostingEnvironment env) { var builder = new ConfigurationBuilder() .SetBasePath(env.ContentRootPath) .AddJsonFile("appsettings.json", optional: true, reloadOnChange: true) .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true) .AddEnvironmentVariables(); Configuration = builder.Build(); }
Приведенный выше сценарий не сработает, потому что переменная среды является общесистемной. Это может быть IIS, nginix и т. Д., Сидящие перед ним, и смена конфигурации не сработает.

В большинстве случаев я видел вышеупомянутое, появлялись предложения использовать Docker или использовать что-то вроде Puppet / Chef для управления конфигурацией приложения, поэтому нет appsettings. {Env} .json, но я думаю, что это делает путь от полного framework MVC намного сложнее.

@mindingdata Фактически вы можете управлять логикой, которая определяет, откуда берется среда в вашем Program.cs . Переменная окружения - это всего лишь один из способов объявить это (основной способ). Если вы хотите сделать что-то еще, основываясь на каком-то волшебном файле или времени суток, тогда вызовите UseEnvironment(environmentName) на WebHostBuidler

Чтобы уточнить, это абсолютно только для конфигурации IIS. Текущая система конфигурации JSON для настроек приложения довольно хороша, и я полностью ее рекомендую.

Чтобы еще больше запутать ситуацию: я обнаружил, что когда я использую web.config, чтобы попытаться переопределить настройку системной среды, он просто не работает. Когда параметр моей системной среды установлен на «Разработка», и я пытаюсь установить его на «Производство» с помощью web.config (как показано ниже), приложение по-прежнему считает, что оно работает в режиме разработки. (Приложение ASP.NET Core, работающее в IIS).

<environmentVariables>
      <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Production" />
</environmentVariables>

Я думаю, это правильное место. Я создаю N-уровневую демонстрацию и не могу понять, как внедрить IHostingEnvironment в мой проект уровня доступа к данным. В этом проекте я получаю доступ к своей базе данных, и единственный способ получить строку подключения к этому уровню - это переопределить метод OnConfiguring с помощью волшебной строки файла конфигурации.

Я также посмотрел на slow-cheetah, но это похоже на обход текущего метода «Отладка, Выпуск» или «Разработка, Производство» в зависимости от того, используете ли вы метод VS или переменные среды.

Должна быть информация, которую мне не хватает. MS не может желать, чтобы все создавали одноуровневые приложения.

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
           var builder = new ConfigurationBuilder().SetBasePath(Directory.GetCurrentDirectory()) .AddJsonFile("appsettings.json");

            var config = builder.Build();
            var connstr = config.GetConnectionString("connStr");            
            optionsBuilder.UseSqlServer(connstr);
        }

так есть ли в этом прогресс?

мы должны иметь возможность установить env в конфигурации для приложения, не прибегая к магии

Да, я бы тоже хотел продвинуться в этом вопросе. В настоящее время понятия не имею, как я должен публиковать отдельные проекты в одном окне с использованием разных переменных среды.

В итоге я пришел к довольно простому решению. В основном файле appsettings.json я указываю желаемую среду:

{
  "Logging": {
    "IncludeScopes": false,
    "LogLevel": {
      "Default": "Warning"
    }
  },
  "ActiveEnvironment": "Development"
}

Затем в Program.CS я создаю IConfiguration и устанавливаю для имени среды значение ActiveEnvironment перед загрузкой файла конфигурации для конкретной среды.

public static void Main(string[] args)
{
    WebHost.CreateDefaultBuilder()
    .ConfigureAppConfiguration((hostingContext, config) =>
    {
        // Get the environment from our hostContext.
        var env = hostingContext.HostingEnvironment;
        config.AddJsonFile("appsettings.json", optional: false, reloadOnChange: true);

        // Build an initial configuration.
        IConfiguration Configuration = config.Build();

        // Set the environment name.
        env.EnvironmentName = Configuration.GetSection("ActiveEnvironment").Value;

        // Load the configuration file for our specific environment.
        config.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: false, reloadOnChange: true)
        .AddEnvironmentVariables();
    })
    .UseStartup<Startup>()
    .Build()
    .Run();
}

Очевидно, что при публикации в различных средах необходимо соответствующим образом изменить ActiveEnvironment.

@DaleMckeown Я собирался сделать что-то подобное, но у меня возник вопрос о вашей реализации. Я вижу, вы используете Microsoft.AspNetCore.WebHost для создания конфигурации по умолчанию. Применяется ли этот подход к консольному приложению без веб-компонентов?

@Swazimodo Я не пробовал это решение в контексте консольного приложения, поэтому не уверен. Лучше всего посмотреть, есть ли альтернативный способ установки переменных среды для консольных приложений.

Мы позаботились об этом по-другому. Мы настраиваем наш агент сборки, чтобы он принимал
файл настроек для конкретной среды и перезаписать корневой файл настроек
с этим. Наша сборка создает отдельный zip-файл для каждой среды, которую мы
развернуть в.

26 октября 2017 г., в 12:48, Дейл Маккеун [email protected]
написал:

@Swazimodo https://github.com/swazimodo Я не пробовал это решение
int в контексте консольного приложения, поэтому я не уверен. Лучшая ставка на
посмотрите, есть ли альтернативный способ установки переменных среды для
консольные приложения.

-
Вы получаете это, потому что подписаны на эту беседу.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/aspnet/Home/issues/2019#issuecomment-339728441 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AAx4bT20JSb0XSzNBIAiiubq9mTVKbW5ks5swLf6gaJpZM4NMx25
.

Кажется, все решения требуют какой-то настройки пост-сборки / публикации? Я закончил тем, что отбросил пустой текстовый файл в корень приложения и передал его как среду. Я что-нибудь пропустил?

Полностью согласен с первым постом. По замыслу, он довольно гибкий, но в конце концов его оказалось очень сложно автоматизировать. Например, у меня есть приложение, которое я публикую в IIS на другом сервере. Также он работает на локальном IIS (через публикацию папки). Поэтому я установил среду разработки в web.config. Но потом мне нужно поменять его на Production или что-то еще во время публикации. Думаю, довольно обычная задача. Я считаю, что это невозможно, правда? Мне нужно вручную редактировать web.config на удаленных серверах.

В идеале настройка Environment должна поддерживаться через "dotnet publish" (для любой цели публикации):

dotnet publish ... -environment=Production

dotnet publish может искать файлы web.%Enviroment%.config (Web.Production.config, Web.Development.config) и объединять (преобразовывать) их с web.config. В конце у нас будет правильное значение ASPNETCORE_ENVIRONMENT:

    <environmentVariables>
        <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="value passed to publish" />
    </environmentVariables>         

@ evil-shrike взгляните на https://github.com/nil4/dotnet-transform-xdt для преобразований конфигурации времени сборки / публикации.

Возможно, это вариант использования. Мне нужны журналы для записи в. \ App_Data, потому что мой исполнитель приложений имеет доступ для чтения / записи ко всему в. \ App_Data, но может читать только все остальное в. \. Я использую веб-развертывание и хотел бы иметь возможность развернуть web.config, подобный этому, с папкой журналов в App_Data:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath=".\<assembly>.exe" stdoutLogEnabled="true" stdoutLogFile=".\App_Data\logs\stdout" />
  </system.webServer>
</configuration>

Вы можете спросить, почему бы просто не поместить эти настройки в файл web.config вместо web.release.config? Что ж, processPath=".\<executable>.exe" - это не то место, где живет исполняемый файл, когда я разрабатываю локально против IIS Express. Так что я получаю старую добрую ошибку HTTP Error 502.5 - Process Failure.

Мы автоматизируем наши сборки с помощью Jenkins, и наш существующий способ настройки vars для каждой среды в проектах NetFramework - это преобразование web.config. Поэтому мы подумали, что сможем сделать это и в dotnet.

Оказывается, msbuild по-прежнему совместим с csproj ядра aspnet для выполнения преобразований web.config!

Мы можем добавить задачу публикации TransformXml в csproj Asp.Net Core:

<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v15.0\Web\Microsoft.Web.Publishing.Tasks.dll" />

Добавьте конкретные цели преобразования:

<Target Name="ConfigDev">
    <TransformXml Source="web.config" Transform="web.dev.config" Destination="web.config" /></Target>

Сделайте некоторые преобразования, например, в переменной ASPNETCORE_ENVIRONMENT в web.dev.config :

<system.webServer>
    <aspNetCore processPath="dotnet" arguments=".\Test.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" >
      <environmentVariables>
        <environmentVariable xdt:Locator="Match(name)" name="ASPNETCORE_ENVIRONMENT" value="dev" xdt:Transform="SetAttributes" />
      </environmentVariables>
    </aspNetCore>
</system.webServer>

Преобразуйте web.config с помощью msbuild перед запуском публикации:

msbuild Test.csproj /t:ConfigDev

«Позвольте мне префикс этого, сказав, что я не поклонник web.config, но опыт публикации приложений AspNetCore в IIS очень плох».

Я не могу больше согласиться с этой веткой.

После простоты преобразований конфигурации в обычном ASP.Net вся эта зависимость от машинной переменной ASPNETCORE_ENVIRONMENT мерзнет .

Даже собственные примеры Microsoft говорят, что мы можем использовать, скажем, файл _appsettings.Production.json_, просто добавив эту строку ...

            .AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true);

... но он не обращает внимания на НАЗВАНИЕ выбранной конфигурации. Поэтому даже когда я выбрал свою производственную конфигурацию, он все равно будет пытаться открыть appsettings.development.json. И нет, я не хочу, чтобы мне приходилось вручную редактировать переменную ASPNETCORE_ENVIRONMENT каждый раз, когда я публикую в другой среде. Это просто напрашивается на неприятности.

Я еще не видел простого рабочего примера использования файлов _appsettings.XXXX.json_.
Я не могу дождаться, когда все это наконец будет закончено. (Вздох...)

Да, пожалуйста, исправьте !!

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

Я думаю, что сейчас попробую решение @DaleMckeown , я думаю, что оно будет работать, но оно действительно похоже на обходной путь, а не решение. Переменные среды хороши, но ТОЛЬКО если у вас соотношение серверов к средам 1-1, а за пределами предприятия, я сомневаюсь, что это часто случается.

@willapp Мое предложение - определенно обходной путь. Но это действительно работает - у меня уже некоторое время было несколько версий одного и того же приложения, работающих на одном сервере, и у меня не было никаких проблем.

Просто не забудьте изменить настройку ActiveEnvironment перед публикацией, и все будет в порядке.

Я сталкиваюсь с тем, что упоминал dkent600:

<environmentVariables>
      <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Production" />
</environmentVariables>

не работает на рабочем сервере. Приложение продолжает использовать значения appsettings.Development.json, что в конечном итоге сводит на нет преимущества преобразования xml при публикации.

Я попробую обходной путь, предложенный DaleMckeown.

единственный разумный способ изменить ASPNETCORE_ENVIRONMENT - использовать web.config

Не совсем. Если вам нужно запустить несколько экземпляров одного и того же сайта на одном компьютере, вот гораздо более простой способ

• MyCoreSite
  
  
  
  • мусорное ведро
  
  
  • журналы
  
  
• env. что бы то ни было

Направьте свое приложение IIS в bin и в program.cs

.UseEnvironment(ReadEnvExtensionFromParentFolder())

Вот и все. Вы можете иметь столько сайтов, сколько хотите, развертывать их в bin, не беспокоясь о преобразовании, и даже переключать среду, переименовав env.Whenver.

Я поддерживаю это. У меня есть перезапись URL-адресов, настроенная для производственного сервера, которая не работает в тестовой среде. Я не нашел способа публикации, чтобы выбрать правильный файл web.config для развертывания, мне нужно скопировать его вручную.

Взгляните на https://github.com/nil4/xdt-samples/ и на инструмент CLI для применения преобразований во время публикации .

Есть ли в этом прогресс? Прошло 13 месяцев с момента первоначального отчета, версия 2.1.0 уже здесь, а с традиционным хостингом IIS дела все еще довольно плохи. Все работает замечательно, если вы используете Azure, но в настоящее время это не вариант для большей части сайтов, которые я размещаю.

Похоже, что для традиционного хостинга IIS было бы полезно установить желаемую среду в командной строке (как указано выше в @ evil-shrike), а также в любых профилях публикации .pubxml . Как сказал @davidfowl , должно быть ясно, что это будет работать только с использованием web.config и IIS, но это, безусловно, по-прежнему покрывает значительную часть базы установки.

На данный момент у меня есть очень хрупкое решение, использующее перевод Microsoft.DotNet.Xdt.Tools и web.config , но для его работы требуется конфигурация сборки для каждой среды, и оно только что сломалось после обновления до версии v2.1.0.

Было бы здорово узнать, есть ли какие-то планы в этой области, и если да, то каковы они? Если планов нет или до них еще далеко, то наверняка есть лучшее временное решение, чем хрупкие / полуавтоматические способы, которые мы сейчас вынуждены использовать? Специально для развертывания в QA и постановки я бы действительно хотел иметь возможность просто нажать кнопку в VS и знать, что происходит правильно, и не зависеть от знаний руководителя и ручных процессов.

В настоящее время у нас нет никаких планов, но этот инструмент https://github.com/nil4/xdt-samples/ от @ nil4 выглядит неплохо.

@svallis ты пробовал?

Главное, что люди хотят задать в среде?

@davidfowl Да, в моем текущем решении используется инструмент, который вы связали, но для проекта с несколькими адресатами для публикации в нем требуется конфигурация сборки для каждой среды. Вам нужны разные конфигурации сборки, чтобы иметь что-то, за что можно закрепиться в настройке csproj , и для моих целей это обычно отношение 1 к 1 с вашими средами. Например:

• Конфигурация сборки: Debug = Environment: Development
• Конфигурация сборки: Staging = Environment: Staging
• Конфигурация сборки: Release = Environment: Production

Для последних двух у меня есть соответствующие web.{Build configuration}.config и appsettings.{Environment}.json , а web.{Build configuration}.config - это буквально XDT, чтобы сообщить web.config в итоге соответствующая переменная окружения ASPNETCORE_ENVIRONMENT . Так, например, продолжая приведенный выше пример, web.Release.config выглядит так:

<?xml version="1.0" encoding="utf-8"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
  <system.webServer>
    <aspNetCore>
      <environmentVariables>
        <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Production" xdt:Transform="SetAttributes" xdt:Locator="Match(name)" />
      </environmentVariables>
    </aspNetCore>
  </system.webServer>
</configuration>

На самом деле все это довольно хорошо работает из командной строки. Запуск dotnet publish -c Staging или что-то еще создает папку с правильным выводом, а web.config преобразуется по мере необходимости. Хотя кажется, что это можно упростить. Если бы был переключатель -iisenvironment на dotnet publish который сделал это за нас, а затем он был бы представлен в виде простого текстового поля в публикации VS, это устранило бы необходимость в управлении конфигурациями сборки, XDT, и т.д. вручную для традиционных ситуаций размещения IIS.

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

@davidfowl С моей точки зрения, в идеале я хотел бы установить среду как часть профиля публикации при использовании веб-развертывания.

Во-вторых, вариант с публикацией был бы идеальным. Я даже не использую обходной путь, описанный @svallis, поскольку я предпочитаю публиковать через VS IDE, а не из командной строки.

@willapp Решение, которое я использую, работает в Visual Studio, но у меня есть другие проблемы с решением, которое я тестирую, которые вызывают проблемы в VS (https://github.com/aspnet/Home/issues/3190) . Извините, если я не разъяснил это. Все это настраивается с помощью инструментов в csproj , которые должны уважать и командная строка, и VS.

Наконец-то дошло до того, чтобы попробовать инструмент, предложенный выше @davidfowl, и он работает! 👍

Просто следуйте инструкциям здесь https://github.com/nil4/dotnet-transform-xdt в разделе «Инструмент уровня проекта» (так как я еще не использую 2.1.0). Мне пришлось самому создать Web.config по умолчанию, так как у меня его не было (просто скопировал его из того, что VS генерирует при развертывании), затем создал Web.Debug.config с преобразованием, чтобы установить ASPNETCORE_ENVIRONMENT в Development, и эй presto! Он развертывает преобразованную конфигурацию, и теперь сайт запускается правильно.

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

@davidfowl Указанная вами ссылка требует публикации с использованием командной строки. Я хочу опубликовать с помощью инструмента VS GUI. Я не хочу, чтобы моим разработчикам приходилось устанавливать инструменты cli для публикации проекта. Нет смысла указывать ASPNETCORE_ENVIRONMENT в web.config, если преобразования не поддерживаются. Увидев, сколько голосов за эту проблему, она должна быть отправлена ​​в очередь.

@ orobert91 VS - это просто графический интерфейс, обернутый вокруг инструментов командной строки. Я успешно использую https://github.com/nil4/xdt-samples/ для преобразования web.config во время публикации из VS. Если вы правильно настроите его для своего проекта, он будет правильно преобразовываться как из командной строки, так и в вашей IDE.

@svallis Действительно, неправильно прочитал документы. Я решил свою проблему с помощью простой задачи копирования:

  <Target Name="CopyFiles" AfterTargets="Publish">  
      <Copy SourceFiles="web.$(Configuration).config" DestinationFiles="web.config" />  
  </Target>   

Существует свойство msbuild, которое публикует награды для имени среды -

$ (EnvironmentName)

(https://github.com/aspnet/websdk/blob/d7d73e75918ec3168bd3e5d519d0decc04675faf/src/Publish/Microsoft.NET.Sdk.Publish.Targets/netstandard1.0/TransformTargets.#TranssoftPublish.Targets/netstandard1.0/TransformTargets. ).

Прямо сейчас, когда это свойство установлено, все, что мы делаем, это создаем appsettings.$(EnvironmentName).json и добавляем информацию о строке подключения в этот файл (если требуется).

В дальнейшем, когда это свойство установлено во время публикации, мы также можем обновить опубликованный файл web.config, добавив в него следующую запись:

<environmentVariables>
      <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="$(EnvironmentName)" />
</environmentVariables>

Будет ли это работать для большинства сценариев, упомянутых здесь?

Для сценариев, не связанных с настройкой EnvironmentVariable, мы рассмотрим возможность переноса преобразований web.config ( Xdt ) для основных проектов.

Я придумал решение, которое, кажется, охватывает требуемые мне сценарии - я хотел опубликовать его здесь, если оно будет полезно для кого-то еще.

В моем случае у меня есть локальная среда разработки, а также промежуточная и производственная среды на удаленном сервере (том же сервере). Мне удалось извлечь URL-адрес приложения из IApplicationBuilder и использовать его в операторе switch чтобы установить значение EnvironmentName .

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

В Startup.cs :

        public void Configure(IApplicationBuilder app, IHostingEnvironment env)
        {
            env.DetectAndSet(app);

            ... other config method stuff here ...
        }

Вышеупомянутый метод - это расширение, которое я создал на основе коллекции свойств в IApplicationBuilder . Метод расширения (и класс) выглядят так:

using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Http.Features;
using Microsoft.AspNetCore.Hosting.Server.Features;
using System.Linq;

namespace MyRootNamespace.Common.Extensions
{
    public static class IHostingEnvironmentExtensions
    {
        /// <summary>
        /// Detects the current hosting url and sets the <see cref="IHostingEnvironment.EnvironmentName"/> accordingly.
        /// </summary>
        /// <param name="env">The <see cref="IHostingEnvironment"/> to set.</param>
        /// <param name="app">The <see cref="IApplicationBuilder"/> used to retrieve the current app url.</param>
        public static void DetectAndSet(this IHostingEnvironment env, IApplicationBuilder app)
        {
            var _appUrl = string.Empty;

            try
            {
                _appUrl = ((FeatureCollection)app.Properties["server.Features"]).Get<IServerAddressesFeature>()?.Addresses?.FirstOrDefault();
            }
            catch { }

            switch (_appUrl)
            {
                case "https://www.myurl.com":
                case "http://www.myurl.com":
                    env.EnvironmentName = EnvironmentName.Production;
                    break;
                case "https://staging.myurl.com":
                case "http://staging.myurl.com":
                    env.EnvironmentName = EnvironmentName.Staging;
                    break;
                default:
                    env.EnvironmentName = EnvironmentName.Development;
                    break;
            }
        }
    }
}

Я надеюсь, что это может быть полезно для людей (в тех случаях, когда преобразование web.config нежелательно).

Ваше здоровье!

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

Мне не очень понравились обходные пути, которые я увидел в этой ветке, поэтому я выбрал другой подход. Я наткнулся на эту тему Переполнение стека: https://stackoverflow.com/questions/31049152/publish-to-iis-setting-environment-variable/36836533#36836533. В нем говорится об изменении ApplicationHost.config на сервере как о месте для хранения переменной ASPNETCORE_ENVIRONMENT.

Наши внутренние серверы IIS находятся под управлением нашей операционной группы, поэтому разработчики в нашей организации в любом случае не создают эти сайты. Операционная группа использует сценарий PowerShell для создания этих сайтов. Я просто попросил их изменить этот сценарий, чтобы он также вносил соответствующие изменения в ApplicationHost.config во время подготовки сайта. Теперь я могу просто развернуть там и не беспокоиться об управлении средой .NET Core. Хорошо сработало для нашей ситуации.

Я думаю, что в настоящей среде DevOps вы, вероятно, все равно будете использовать Azure, что позволяет очень легко установить переменную среды.

В последней версии Sdk вы можете просто передать свойство msbuild $(EnvironmentName) и инструменты позаботятся об установке этого значения для ASPNETCORE_ENVIRONMENT.

например, если для EnvironmentName задано промежуточное значение, тогда в файле web.config будет следующая запись:

      <aspNetCore processPath="dotnet" arguments=".\WebApplication242.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout">
        <environmentVariables>
          <environmentVariable name="ASPNETCORE_ENVIRONMENT" value="Staging" />
        </environmentVariables>
      </aspNetCore>

PR с исправлением:
https://github.com/aspnet/websdk/pull/377

@vijayrkn Похоже, начало многообещающее. Будет ли это в конечном итоге иметь встроенную поддержку в VS WebDeploy / профилях публикации и т. Д.?

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

Мы также рассмотрим возможность добавления поддержки пользовательского интерфейса для этого.

@vijayrkn Это решение только для тех, кто публикует файл web.config - это правильно?

@vijayrkn Да, поддержка формата pubxml будет моментом, когда это станет полезным для нашего варианта использования. На этом этапе мы могли бы отбросить все данные о преобразовании XML и просто указать соответствующие строки среды в каждом pubxml . Поддержка пользовательского интерфейса может появиться позже, но это будет лишь вишенкой на торте.

@challamzinniagroup - Нет, для этой функции вам не нужен web.config.
Все, что вам нужно сделать, это добавить следующее в файл pubxml, а инструменты публикации позаботятся обо всем остальном.

<EnvironmentName>YourCustomEnvironment</EnvironmentName>

@challamzinniagroup , @vijayrkn

Если у вас нет какой-либо конфигурации, которая может быть выполнена только в web.config и должна быть преобразована между средами, в противном случае оставьте web.config в покое. С помощью двух строк кода вы можете читать переменные среды из любого места. И вам не нужно никаких настроек в профиле публикации или опубликованном коде, просто список подходящих appsetting.XYZ.json

@ThisNoName

Вы имеете в виду строки подключения к базе данных, конечные точки служб, учетные данные или любое другое количество вещей, которые могут измениться при переходе от dev-> staging-> production.

Если вы запускаете несколько экземпляров в одной среде ( очень часто за пределами облака), вам абсолютно необходима гибкость преобразований web.config. Довольно смешно, что Microsoft не удовлетворила это требование из коробки с ядром dotnet, они просто предположили, что все размещаются в Azure и имеют отношение 1-1 между экземпляром и средой.

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

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

Теперь, к сожалению, в IIS переменные среды необходимо настроить в файле конфигурации, чтобы пул приложений мог их видеть. Я не думаю, что мы когда-либо хотели, чтобы люди настраивали конфигурацию всей машины на целевых машинах (хотя я видел, как люди это делали).

@willapp Почему бы вам не использовать appsettings.json ?

@willapp

У M $ есть идеальное решение, но большинство людей придерживаются концепции преобразования web.config.

Вот один из способов разместить несколько сайтов рядом. Вам просто нужно выбросить значение вашей среды в любом месте за пределами двоичного каталога IIS и прочитать / установить его из program.cs

• IISRoot
  
  
  
  • MySiteDEV
  
  
  • мусорное ведро
    
    
    
    
    
    • appsettings.json
    
    
    
    • appsettings.DEV.json
    
    
    
    • appsettings.PROD.json
    
    
    
    • web.config
    
    
    
  
  
  • журналы
  
  
  • env.DEV
  
  
  • MySitePROD
  
  
  • мусорное ведро
    
    
    
    
    
    • appsettings.json
    
    
    
    • appsettings.DEV.json
    
    
    
    • appsettings.PROD.json
    
    
    
    • web.config
    
    
    
  
  
  • журналы
  
  
  • env.PROD
  
  

@davidfowl

Вы говорите людям, что, к сожалению, ядро ​​ASP.NET не может хорошо работать с IIS? Как архитектор Microsoft .NET Core?

Здесь смена парадигмы с любым ядром является мультиплатформенным. Очевидно, что IIS - это служебная программа для Windows, поэтому следует ожидать некоторых проблем с развитием. В таком случае следует ожидать и принимать обходные пути по мере продвижения дела. Сделать преднамеренный выбор дизайна в Core для поддержки функции Windows было бы нелогично, imo.

Отредактируйте, чтобы добавить:
Это была мысль о том, должно ли Core иметь лучшую поддержку IIS из коробки. Несмотря на то, что обсуждение использования переменных среды является хорошей альтернативой ...

@davidfowl

И в этом как раз разница между архитектурой предприятия и SME. Я работаю на FTSE100, и да, отделение развертывания от кода имеет смысл, но я также запускаю несколько сайтов независимо, и просто проще и дешевле иметь один сервер, на котором я размещаю все свои сайты. Использование Web Deploy + Transforms - это проверенный и проверенный механизм изменения кода доставки, он просто работает. Я не говорю, что в некоторых случаях нет лучших альтернатив, но Microsoft следовало бы продолжить поддержку преобразований, зная, что большинству пользователей требуется знакомство при переходе с .NET Framework на ядро.

У меня есть решение, полученное ранее в этой ветке, так что я достаточно счастлив. Я просто думаю, что они немного упали, не считая этого стандартом.

@willapp

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

При новой настройке вы публикуете свой код только один раз, используя Release config. Все запущенные экземпляры являются идентичными двоичными копиями оригинала. Развертывание должно быть простой синхронизацией файлов со следующей средой DEV => TEST => Staging => PROD.

Вы говорите людям, что, к сожалению, ядро ​​ASP.NET не может хорошо работать с IIS? Как архитектор Microsoft .NET Core?

Я говорю, что люди не сразу задумываются о том, что переменные среды, используемые таким образом, должны использоваться для каждого процесса, а не для каждой машины. Исторически сложилось так, что в Windows люди идентифицируют переменные среды как масштабы всей машины, а не как процесс, и это вызывает путаницу. В IIS 10 добавлена ​​поддержка добавления переменных среды для каждого пула приложений. Модуль ASP.NET Core также поддерживает установку переменных среды для каждого процесса.

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

@challamzinniagroup хорошее резюме

Это была мысль о том, должно ли Core иметь лучшую поддержку IIS из коробки. Несмотря на то, что обсуждение использования переменных среды является хорошей альтернативой ...

Правильно. Рабочий процесс для настройки информации о среде должен по-прежнему относиться к конкретной среде. Вопрос в том, как этого добиться. Это часть развертывания?

С учетом всего сказанного, я считаю, что мы добавляем поддержку этого в инструменты в версии 2.2.

Копия: @vijayrkn

@davidfowl

Когда вы говорите: «Раньше в Windows люди определяли переменные среды для всей машины, а не для каждого процесса», вы имеете в виду переменные среды Windows, как в командной строке SET?

Потому что мое понимание «среды» в контексте ядра .NET - это всего лишь переменная. По умолчанию он читает ASPNETCORE_ENVIRONMENT из system или web.config. Но вы можете перезаписать и получить его из любого источника по любому соглашению.

Есть ли что-то неправильное в таком подходе? Потому что, если официальная позиция команды Microsoft .NET - не делать этого, нам придется серьезно пересмотреть свое мнение. Но в конечном итоге вы бы посоветовали людям запускать ядро ​​.NET под IIS, но, к сожалению, это нелегкий способ настроить эти приложения. Надеюсь, это не так.

Спасибо.

@ThisNoName

Когда вы говорите: «Раньше в Windows люди определяли переменные среды для всей машины, а не для каждого процесса», вы имеете в виду переменные среды Windows, как в командной строке SET?

Да, именно об этом и идет эта ветка. (См. Здесь ). Как говорит Дэвид, это может быть процесс, но, по моему опыту, большая часть документации по ядру dotnet предполагает, что вы устанавливаете их на уровне компьютера, поэтому у нас есть проблема, когда вы не можете легко развернуть несколько экземпляров приложения на одном сервере, как они будут получать одинаковые значения среды, поэтому вы не сможете различить dev / staging / prod.

Тот факт, что IIS10 поддерживает их настройку для каждого пула приложений, великолепен ... если у вас есть Server 2016. У меня 2012 год, так что это не вариант. Опять же, моя проблема не в том, что Microsoft пытается сдвинуть дело в лучшую сторону, а в том, что отказ от «устаревшей» поддержки чего-то, что многие люди считали само собой разумеющимся при развертывании приложений ASP.NET, кажется мне ошибкой. Во что бы то ни стало вводите новые шаблоны и поощряйте людей к их принятию, но не удаляйте устаревшее поведение, пока не будете уверены, что оно мало кому нужно. В противном случае все, что вы делаете, - это ставите барьеры для клиентов, которым требуется ядро ​​dotnet, но которые считают путь миграции слишком болезненным.

@willapp

Это просто заводская настройка по умолчанию. Вы можете читать и настраивать среду как хотите. По крайней мере, я так понимаю, разве кто-то укажет на какой-либо серьезный недостаток в этом подходе?

   public class Program   {
        public static void Main(string[] args)   {
            CreateWebHostBuilder(args).Build().Run();
        }

        public static IWebHostBuilder CreateWebHostBuilder(string[] args)   {
               return WebHost.CreateDefaultBuilder(args)
                .UseEnvironment(ReadEnvFromWherever())
                .UseStartup<Startup>()
        }

        private string ReadEnvFromWherever() { 
              // Get and return whatever by your own convention
              return "DEV";
        }
    }

@ThisNoName

Серьезный недостаток заключается в том, как заставить метод ReadEnvFromWherever возвращать другое значение при развертывании с использованием веб-публикации из VSTS в зависимости от конфигурации вашего решения? Я полагаю, вы могли бы использовать директивы препроцессора (#if RELEASE ...), но это выглядит довольно грязно.

В «старом мире» (полная платформа ASP.NET) вы создаете профиль публикации, и часть этого - выбор конфигурации решения для построения. На основе этой конфигурации он затем применил преобразование конфигурации, которое позволило вам указать другую конфигурацию в зависимости от того, публикуете ли вы в dev / staging / prod.

Я согласен с тем, что этот рабочий процесс не вписывается в современный конвейер CI, где вы берете один пакет сборки и проталкиваете его через каждую среду - в этом случае вы хотите, чтобы что-то вроде конвейера выпуска VSTS вводило параметры во время развертывания, или вы запускаете ваш экземпляр сервера с правильными переменными среды, и в этом случае вы просто бросаете пакет в коробку, и он автоматически срабатывает. Опять же, я думаю, что многих малых и средних предприятий и групп из одного человека здесь нет, и им нужен процесс развертывания из Visual Studio, который дает желаемый результат.

Просто добавлю, что это также важно для развертывания небольших проектов на платформах общего хостинга, которые работают на IIS и традиционно предлагают хостинг ASP.NET. У них нет возможности устанавливать переменные среды для каждого веб-сайта через панели управления хостингом, поэтому единственный реалистичный подход - использовать преобразования и web.config .

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

@willapp

Условно. Если вы воспользуетесь примером, который я опубликовал ранее, вы можете прочитать env.DEV из родительской папки и использовать расширение файла в качестве переменной среды. Но вы можете пойти по любому соглашению, например, назвать корневой каталог вашего приложения MySiteDEV, MySitePROD и т. Д. И проанализировать имя папки, чтобы получить имя среды.

Если ваш код зависит от среды, вы можете прочитать значение среды из IHostingEnvironment .EnvironmentName

Это ничем не отличается от чтения ASPNETCORE_ENVIRONMENT ядра .NET из системной переменной или web.config.

@ThisNoName

Но как получить _env.DEV_ в родительскую папку, кроме как скопировать его вручную? Я понимаю, что вы пытаетесь сказать, но я думаю, что вы упускаете суть: раньше было готовое решение, которое просто работало. Теперь его нет, потому что его поддержка инструментарием не рассматривалась как часть процесса развертывания ядра dotnet.

Я понимаю, почему он был удален (потому что есть альтернативы получше, если у вас есть приличный процесс CI), но я думаю, что это было довольно недальновидно, когда многие мигрирующие пользователи все равно захотят этого.

@willapp

Вы копируете его один раз во время начальной настройки, и все последующие развертывания попадают в папку bin. Ни перекомпиляции, ни публикации, ни преобразования. Так и должно быть, требуются дополнительные 3 строчки кода, и что? Это M $. Еще 3 месяца назад вы даже не могли вызвать Active Directory в .NET Core.

@ThisNoName : Вы рассчитываете, что вас серьезно

Ваше предложение не имеет смысла в контексте веб-развертывания на платформе общего хостинга. Я даже не уверен, за что вы аргументируете или против, эта функциональность добавляется в следующий выпуск ASP.NET Core, чтобы переменная среды могла быть указана в профиле публикации, без каких-либо преобразований или чего-то еще. Также нет необходимости в нестандартных подходах к именам папок, которые могут или не могут быть под вашим контролем.

@willapp , @svallis
Решение, которое я опубликовал чуть позже, в некоторых случаях работает. Вы можете вытащить URL-адрес и установить среду на основе этого. В любой среде хостинга у вас есть полный контроль над своими URL-адресами. Я понимаю, что это все еще "хакерский" способ и обходной путь, но обычно он должен работать большую часть времени. В случае моей хостинговой компании URL-адрес, который я получал, был localhost: port base ("127.0.0.1:7777"), поэтому он оказался не идеальным для меня. Но у меня также есть возможность устанавливать пути к корневым папкам в различных средах, поскольку они настроены как поддомены - и вытащить путь к корневому приложению также довольно просто:

        public static string DetectAndSet(this IHostingEnvironment env, ILogger logger)
        {
            switch (env.ContentRootPath)
            {
                case "h:\\root\\home\\www\\api":
                    env.EnvironmentName = EnvironmentName.Production;
                    break;
                case "h:\\root\\home\\www\\api-staging":
                    env.EnvironmentName = EnvironmentName.Staging;
                    break;
                default:
                    env.EnvironmentName = EnvironmentName.Development;
                    break;
            }

            logger.LogInformation($"Application root path discovered as '{env.ContentRootPath}'. Environment set to '{env.EnvironmentName}'");

            return env.EnvironmentName;
        }

Выбор того, должна ли среда определяться в коде, во время развертывания или заранее определена непосредственно в среде, не является тем обсуждением, которым я пытаюсь заняться - я просто предлагаю разумное решение для этих SME / лица, которые имеют ограниченный контроль над хостингом и нуждаются в исправлении. В моем случае это код «однажды и забыл» - именно то, что мне нужно.

Далее я могу легко извлечь значения конфигурации из файла appsettings.json без каких-либо преобразований, просто включив:

"{configName}.{environmentName}": "{value}"

в файле настроек и имеет 3 записи для каждой конфигурации - по одной для каждой среды. У меня в этом файле очень мало конфигураций, поэтому дублирование не представляет большого труда.

Надеюсь это поможет!

@challamzinniagroup По

@svallis Вся концепция состоит в том, чтобы опубликовать один раз и развернуть на двоичном уровне. Так что даже если вы можете установить переменную для каждого профиля публикации, это не выход.

@ThisNoName Возможно, для вас это проще, но не допускайте подобных вещей для других. В моем случае у меня есть настройки для очистки целевых каталогов перед публикацией / копированием - и поэтому для вашего решения мне придется каждый раз повторно загружать каждый файл среды вручную. Это определенно не проще.

@challamzinniagroup Согласен. Все ситуации разные. Суть в том, что среда - это просто переменная, вы можете контролировать ее так, как считаете нужным, вместо того, чтобы ждать, пока Microsoft предоставит следующую лучшую вещь. И что бы они ни придумали, в любом случае это просто еще одно решение, основанное на соглашении - чтение некоторого значения из system или web.config и установка окружения.

Кстати, вы все еще можете использовать соглашение. Нельзя сказать, что в настройках приложения должно использоваться одно среднее слово, а стадия / производство не имеют особого значения. Вы можете легко сделать что-то подобное и передать соответствующее имя папки.

appsettings.api.json
appsettings.api-staging.json

С помощью решения, основанного на соглашениях, вы можете запускать новые экземпляры без перекомпиляции и / или повторной публикации.

@vijayrkn, не могли бы вы подробнее рассказать об использовании pubxml?
Я обновил свой SDK до 2.1.302 (x64) изменил свой pubxml, но не вижу разницы в опубликованном web.config.

@wggley - исправление недоступно в версии 2.1.302. Он должен быть доступен в следующем выпуске.

Вы можете попробовать предварительную версию cli, содержащую исправление, отсюда - https://dotnetcli.blob.core.windows.net/dotnet/Sdk/release/2.1.4xx/dotnet-sdk-latest-win-x64.exe

Сообщите мне, если у вас возникнут какие-либо проблемы с указанной выше предварительной версией.

Спасибо @vijayrkn. Я подожду следующего релиза и попробую использовать его в новой публикации.
Хочу отметить, что решение @frankhoffy сработало для меня как шарм:
https://stackoverflow.com/questions/31049152/publish-to-iis-setting-environment-variable/36836533#36836533
Найдите первый ответ (ответ, получивший наибольшее количество голосов).

Поддержка преобразования веб-конфигурации во время публикации теперь доступна в предварительной версии 2.21 https://www.microsoft.com/net/download/dotnet-core/2.2

@vijayrkn есть где-нибудь базовый образец? Было бы здорово указать людям на эквивалент hello world, используя базовое преобразование, которое устанавливает ASPNETCORE_ENVIRONMENT.

Чтобы установить ASPNETCORE_ENVIRONMENT, пользователи могут установить свойство msbuild «$ (EnvironmentName)». Я добавлю образец, который показывает, как установить другие переменные env с помощью преобразований web.config.

Вот образец репо - https://github.com/vijayrkn/webconfigtransform

Readme содержит подробную информацию о том, как это работает:
https://github.com/vijayrkn/webconfigtransform/blob/master/README.md

Надеюсь это поможет!

@Eilon - Мы можем закрыть эту проблему. Это исправлено и доступно в последней предварительной версии.

@vijayrkn Непонятно, как настроить параметры публикации для настройки среды из диалогового окна параметров публикации? Что на самом деле можно изменить в этом диалоговом окне, чтобы отличить промежуточный сайт от рабочего, если оба сайта развертываются на одном сервере?

Этот аспект ядра .NET кажется очень запутанным. Необходимо значительно упростить определение среды для каждой папки. Переменная среды для всего сервера вообще не может работать в нашей ситуации. Не все могут запускать свои промежуточные сайты на серверах, отличных от производственных.

Настройка для каждого приложения.

Извините, но это не совсем ответ на мой вопрос. Возможно, я что-то недопонимаю.

Здесь есть псевдодокументация https://github.com/vijayrkn/webconfigtransform/blob/master/README.md ( @vijayrkn нам нужно

@vijayrkn Насколько это поддерживается в диалоговом окне публикации?

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

@ nmg196 - Если вы хотите просто установить «ASPNETCORE_ENVIRONMENT» в web.config, все, что вам нужно сделать, это добавить имя среды в опубликованный профиль.

пример:
https://github.com/vijayrkn/webconfigtransform/blob/master/Properties/PublishProfiles/FolderProfile.pubxml#L18

Для расширенных сценариев (кроме установки переменной среды ASPNETCORE_ENVIRONMENT) можно применить преобразования web.config, как указано в документации выше.

@davidfowl - У Ангелоса есть элемент для документирования поддержки преобразования web.config.

@vijayrkn Как использовать в CI / CD TFS? Я не мог использовать публикацию dotnet с p: CustomTransformFileName в TFS

Вы можете передать это свойство msbuild в dotnet publish.

Вы можете обратиться к этому образцу здесь - https://github.com/vijayrkn/webconfigtransform/blob/master/publish.cmd

Это передает свойство CustomTransformFileName для публикации в dotnet

dotnet publish /p:Configuration=Release /p:EnvironmentName=Staging /p:CustomTransformFileName=custom.transform

@vijayrkn
Я прочитал вашу документацию и не могу изменить файл web.config. Я испробовал практически все команды, которые есть в readme.md, и ни одна из них не привела к выполнению преобразования.

Однако мне удалось написать сценарий PowerShell, который использует Microsoft.Web.XmlTransform.dll для выполнения преобразования отдельно от операции публикации.

У меня вопрос: какую версию msbuild и dotnet вы используете?
Я использую:
dotnet - версия 2.1.104
dotnet msbuild -версия 15.6.84.34536

Спасибо

@ stephenarsenault1
Вам необходимо установить любую из сборок отсюда, чтобы функция загорелась - https://www.microsoft.com/net/download/dotnet-core/2.2

Последняя версия - https://www.microsoft.com/net/download/thank-you/dotnet-sdk-2.2.100-preview3-windows-x64-installer

@davidfowl написал:

Здесь есть псевдодокументация https://github.com/vijayrkn/webconfigtransform/blob/master/README.md ( @vijayrkn нам нужно

@vijayrkn Насколько это поддерживается в диалоговом окне публикации?

Вы знаете, добавлялось ли это когда-либо в настоящую документацию, если да, то есть ли у вас ссылка, пожалуйста?

Мы перешли к использованию <EnvironmentName> в наших профилях публикации. Хотя было бы неплохо иметь какой-нибудь пользовательский интерфейс поверх этого, чтобы он был более заметным. Полагаю, это будет позже?

Я думаю, что это критическое изменение, чтобы включить по умолчанию преобразование web.config в публикацию dotnet. После установки .NET Core SDK 2.2.101 он нарушил наш сценарий CI / CD. Наш конвейер настроен на создание опубликованного артефакта с использованием dotnet publish только один раз для любого выпуска ( правило сборки один раз ), преобразование применяется автоматически при реальном развертывании (выполняется Octopus). Я не нашел упоминания об этом изменении в документации. Потратил немного времени, пытаясь выяснить, в чем причина удвоения блоков конфигурации в web.config после развертывания. Судя по всему, трансформация применялась дважды: dotnet publish и инструментом управления релизами.

После отключения преобразований web.config параметром <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled> TransformWebConfig также пропускается (вместе с TransformXml), что приводит к тому, что переменные %LAUNCHER_PATH% и %LAUNCHER_ARGS% не заменяются в процессе публикации. Есть ли настройка для независимого управления этими шагами?

Работает ли это в консольном приложении с файлом App.Config?

Можем ли мы увидеть пример?

@dmitryshunkov вы можете установить для $ (RunXdt) значение false, чтобы просто пропустить запуск пользовательской трансформации Xml.

@auserx - если это проект в стиле sdk, то он должен работать.