Aspnetcore: VS에서 AspNetCore 프로젝트에 대한 web.config 변환 사용

FWIW, 동의합니다. IIS 설정을 위한 것임을 분명히 하면 됩니다. 다른 것은 우리가 템플릿에 기본 web.config 를 사용하지 않도록 이동했기 때문에 이를 파악해야 한다는 사실입니다.

/cc @sayedihashimi

이것은 IIS에만 해당됩니까? 문제의 핵심은 ASPNETCORE_ENVIRONMENT 변수 fullstop을 사용하여 웹 사이트가 어떤 환경에 있는지 알려주는 것입니다.

꽤 일반적인 시나리오는 다양한 스테이징/QA 환경이 동일한 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이 없는 것을 제안했지만 이것이 전체 경로를 만드는 것이라고 생각합니다. 프레임워크 MVC는 훨씬 더 어렵습니다.

@mindingdata Program.cs 환경의 출처를 결정하는 논리를 실제로 제어할 수 있습니다. 환경 변수는 그것을 선언하는 한 가지 방법일 뿐입니다(주요 방법). 매직 파일이나 시간을 기반으로 다른 작업을 수행하려면 WebHostBuidler UseEnvironment(environmentName) 를 호출하세요.

명확히 하자면 이것은 전적으로 IIS 구성을 위한 것입니다. 앱 설정을 위한 현재 JSON 구성 시스템은 상당히 좋으며 완전 추천합니다.

더 혼란스럽게하려면 web.config를 사용하여 시스템 환경 설정을 재정의하려고 할 때 단순히 작동하지 않는다는 것을 알았습니다. 내 시스템 환경 설정이 "개발"로 설정되어 있고 web.config(아래 참조)를 사용하여 "프로덕션"으로 설정하려고 하면 응용 프로그램이 여전히 개발에서 실행 중이라고 생각합니다. (IIS에서 실행되는 ASP.NET Core 앱).

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

나는 이것이 올바른 장소라고 생각한다. N 계층 데모를 빌드했는데 데이터 액세스 계층 프로젝트에 IHostingEnvironment를 삽입하는 방법을 알 수 없는 것 같습니다. 그 프로젝트는 내 데이터베이스에 액세스하는 곳이며 해당 계층에 대한 연결 문자열을 얻는 유일한 방법은 구성 파일의 마법 문자열로 OnConfiguring 메서드를 재정의하는 것이었습니다.

슬로우치타도 봤는데 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);
        }

그래서 이에 대한 진전이 있었습니까?

마법에 의존하지 않고 앱 구성에서 환경을 설정할 수 있어야 합니다.

네 저도 이 부분에 진전이 있었으면 합니다. 현재 다른 환경 변수를 사용하여 동일한 상자에 별도의 프로젝트를 게시하는 방법을 모릅니다.

나는 꽤 간단한 해결책을 생각해 냈습니다. 기본 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 파일을 만듭니다.
에 배포합니다.

2017년 10월 26일 목요일 오후 12시 48분, Dale Mckeown 알림 @github.com
썼다:

@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에서 개발 환경을 설정했습니다. 그러나 게시하는 동안 프로덕션 또는 무엇이든 변경해야 합니다. 꽤 흔한 작업인 것 같아요. 불가능하다고 생각합니다. 맞죠? 원격 서버에서 web.config를 수동으로 편집해야 합니다.

이상적으로 설정 환경은 "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 에 로그를 기록해야 합니다. 저는 웹 배포를 사용하고 있으며 App_Data 아래의 로그 폴더와 함께 다음과 같은 web.config를 배포할 수 있기를 원합니다.

<?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.release.config 대신 web.config 파일에 넣는 것이 어떻습니까? processPath=".\<executable>.exe" 는 IIS Express에 대해 로컬로 개발할 때 실행 파일이 있는 곳이 아닙니다. 그래서 좋은 "HTTP 오류 502.5 - 프로세스 실패" 오류가 발생합니다.

Jenkins를 사용하여 빌드를 자동화하고 NetFramework 프로젝트에서 환경별로 vars 구성을 수행하는 기존 방법은 web.config 변환을 사용하는 것입니다. 그래서 닷넷에서도 할 수 있을 거라 생각했습니다.

msbuild 는 web.config 변환을 수행하기 위해 aspnet core csproj와 여전히 호환됩니다!

Asp.Net Core csproj에 TransformXml 게시 작업을 추가할 수 있습니다.

<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>

예를 들어 web.dev.config 의 ASPNETCORE_ENVIRONMENT 변수에 대해 몇 가지 변환을 수행합니다.

<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>

게시를 실행하기 전에 msbuild 를 사용하여 web.config를 변환합니다.

msbuild Test.csproj /t:ConfigDev

"나는 web.config의 팬이 아니지만 IIS에 AspNetCore 앱을 게시한 경험은 정말 좋지 않습니다."

나는 이 스레드에 더 동의할 수 없었다.

일반 ASP.Net에서 구성 변환의 단순성 이후에 시스템 전체의 ASPNETCORE_ENVIRONMENT 변수에 대한 이 전체 종속성은 악취가 납니다.

Microsoft의 자체 예제에서도 이 줄을 추가하기만 하면 _appsettings.Production.json_ 파일을 사용할 수 있다고 말합니다...

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

...하지만 우리가 선택한 구성의 NAME에는 주의를 기울이지 않습니다. 따라서 프로덕션 구성을 선택한 경우에도 여전히 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를 사용하는 것입니다.

설마. 동일한 시스템에서 동일한 사이트의 여러 인스턴스를 실행해야 하는 경우 훨씬 간단한 방법이 있습니다.

• 마이코어사이트
  
  
  
  • 큰 상자
  
  
  • 로그
  
  
• 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에서 버튼을 누르고 올바른 일이 일어나고 있다는 것을 알 수 있고 헤드 지식과 수동 프로세스에 의존할 필요가 없는 것을 정말 원합니다.

현재 계획은 없지만 @nil4의 https://github.com/nil4/xdt-samples/ 도구는 꽤 좋아 보입니다.

@svallis 해봤어?

사람들이 환경을 설정하는 데 가장 중요한 것은 무엇입니까?

@davidfowl 예, 현재 솔루션은 연결한 도구를 사용하고 있지만 게시할 대상이 여러 개인 프로젝트의 경우 환경별 빌드 구성이 필요합니다. csproj 설정에서 래치할 무언가를 가지려면 다른 빌드 구성이 필요하며 제 목적을 위해 일반적으로 환경과의 1:1 관계입니다. 예를 들어:

• 빌드 구성: 디버그 = 환경: 개발
• 빌드 구성: 스테이징 = 환경: 스테이징
• 빌드 구성: 릴리스 = 환경: 프로덕션

후자의 경우 해당 web.{Build configuration}.config 및 appsettings.{Environment}.json 가 있고 web.{Build configuration}.config 는 말 그대로 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 변환됩니다. 그래도 단순화할 수 있을 것 같습니다. dotnet publish 에 -iisenvironment 스위치가 있어 이 작업을 수행한 다음 VS 게시에서 간단한 텍스트 상자로 노출되면 빌드 구성, XDT, 등 기존 IIS 호스팅 상황에서 수동으로.

하지만 VS 내에서 현재 문제가 있는 것 같습니다. 우리는 현재 VS 내에서 게시할 수 없으며 v2.0.0에서 작동하더라도 게시하기 전에 올바른 빌드 구성을 수동으로 선택해야 했습니다.

@davidfowl 내 관점에서 이상적으로는 Web Deploy를 사용할 때 환경을 게시 프로필의 일부로 설정하고 싶습니다.

둘째, 출판 옵션이 이상적일 것입니다. 명령줄이 아닌 VS IDE를 통해 게시하는 것을 선호하므로 @svallis 에서 설명한 해결 방법을 사용

@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에서 생성한 것에서 복사). 그런 다음 ASPNETCORE_ENVIRONMENT를 Development로 설정하는 변환을 사용하여 Web.Debug.config를 만들었습니다. 프레스토 악장! 변환된 구성을 배포하고 이제 사이트가 올바르게 시작됩니다.

이에 대한 지원이 공식화되면 좋겠지만 현재로서는 이것이 제 역할을 하고 있습니다.

@davidfowl 지적한 링크는 명령줄을 사용하여 게시해야 합니다. VS GUI 도구를 사용하여 게시하고 싶습니다. 내 개발자가 프로젝트 게시를 위해 cli 도구를 설치하는 것을 원하지 않습니다. 변환이 지원되지 않으면 web.config에서 ASPNETCORE_ENVIRONMENT를 지정할 수 없습니다. 이 문제에 얼마나 많은 찬성표가 있는지 확인하면 백로그로 이동해야 합니다.

@orobert91 VS는 명령줄 도구를 둘러싼 GUI일 뿐입니다. VS 내에서 게시하는 동안 https://github.com/nil4/xdt-samples/ 를 사용하여 web.config 를 성공적으로 변환하고 있습니다. 프로젝트에 대해 올바르게 구성하면 명령줄과 IDE 내에서 모두 올바르게 변환됩니다.

@svallis 실제로 문서를 잘못 읽었습니다. 간단한 복사 작업으로 문제를 해결했습니다.

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

환경 이름에 대한 명예를 게시하는 msbuild 속성이 있습니다.

$(환경 이름)

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

지금 이 속성이 설정되면 appsettings.$(EnvironmentName).json 를 만들고 해당 파일에 연결 문자열 정보를 추가하기만 하면 됩니다(요청된 경우).

앞으로 이 속성이 게시 중에 설정되면 게시된 web.config를 업데이트하여 다음 항목도 포함할 수 있습니다.

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

여기에서 언급한 대부분의 시나리오에서 작동합니까?

environmentVariable 설정 이외의 시나리오의 경우 핵심 프로젝트에 대한 web.config 변환( Xdt ) 이식 가능성을 살펴보겠습니다.

내가 필요한 시나리오를 다루는 것처럼 보이는 솔루션을 생각해 냈습니다. 다른 사람에게 도움이 되는 경우에 여기에 게시하고 싶었습니다.

제 경우에는 개발 환경이 로컬에 있고 스테이징 및 프로덕션 환경이 모두 원격 서버(동일한 서버)에 있습니다. IApplicationBuilder 에서 애플리케이션 URL을 가져와 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. ASPNETCORE_ENVIRONMENT 변수를 저장할 장소로 서버의 ApplicationHost.config를 수정하는 방법에 대해 설명합니다.

내부 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>

수정 사항이 있는 홍보:
https://github.com/aspnet/websdk/pull/377

@vijayrkn 유망한 시작처럼 보입니다. 이것은 결국 VS WebDeploy/게시 프로필 등에 내장된 지원을 갖게 될까요?

지금은 이 환경 이름 선택을 위한 UI가 VS에 없지만 이것이 프로젝트 파일이나 pubxml에 추가되면 VS와 명령줄에서 게시할 때 모두 이를 적용합니다.

이에 대한 UI 지원도 추가할 예정입니다.

@vijayrkn web.config 파일로 퍼블리싱하는 분들을 위한 솔루션입니다 - 맞나요 ?

@vijayrkn 네, pubxml 형식으로 지원을 받는 것은 이것이 우리의 사용 사례에 유용하게 될 순간이 될 것입니다. 그 시점에서 우리는 모든 XML 변환 항목을 삭제하고 각 pubxml 적절한 환경 문자열을 지정할 수 있습니다. UI 지원은 나중에 제공될 수 있지만 그것은 케이크의 장식일 뿐입니다.

@challamzinniagroup - 아니요, 이 기능에는 web.config가 필요하지 않습니다.
다음을 pubxml 파일에 추가하기만 하면 나머지는 게시 도구에서 처리합니다.

<EnvironmentName>YourCustomEnvironment</EnvironmentName>

@challamzinniagroup , @vijayrkn

web.config에서만 수행할 수 있고 환경 간에 변환해야 하는 일부 구성이 없으면 web.config를 그대로 두십시오. 2줄의 코드로 어디서나 환경 변수를 읽을 수 있습니다. 그리고 게시 프로필이나 게시된 코드를 조정할 필요가 없으며 일치하는 appsetting.XYZ.json 목록만 있으면 됩니다.

@ThisNoName

데이터베이스 연결 문자열, 서비스 끝점, 자격 증명 또는 dev->staging->production에서 변경되는 기타 여러 가지를 의미합니다.

동일한 환경에서 여러 인스턴스를 실행하는 경우(클라우드 외부에서 매우 일반적임) web.config 변환의 유연성이 절대적으로 필요합니다. Microsoft가 dotnet 코어를 사용하여 즉시 이 요구 사항을 충족하지 않았다는 것은 매우 우스꽝스럽습니다. 모든 사람이 Azure에서 호스팅하고 인스턴스와 환경 간에 1-1 관계가 있다고 가정했습니다.

환경 변수는 앱과 별도의 구성으로 끝나기 때문에 클라우드 외부에서 실제로 좋지 않아 배포를 완전히 관리하기가 더 어렵습니다.

여기서 주요 변경 사항은 이러한 비밀을 소스 제어에 저장해서는 안 되며 대신 환경 자체에서 구성해야 한다는 것입니다. Transforms는 항상 그런 것은 아니지만(특히 여러 환경이 있는 경우) 게시 시 배포 대상을 이해한다고 가정하기 때문에 모범 사례에 직면해 있습니다. N개의 배포 중 하나에 대한 구성 설정을 변경할 때 정말로 다시 배포해야 합니까?

이제 불행한 부분은 IIS에서 앱 풀이 볼 수 있도록 환경 변수를 구성 파일에 설정해야 한다는 것입니다. 나는 우리가 사람들이 대상 머신에 머신 전체 구성을 설정하도록 의도한 적이 없다고 생각합니다(사람들이 그렇게 하는 것을 보았지만).

@willapp 왜 appsettings.json 를 사용하지 않습니까?

@윌앱

M$는 완벽한 솔루션을 가지고 있지만 대부분의 사람들은 web.config 변환의 개념을 고수합니다.

다음은 여러 사이트를 나란히 배치할 수 있는 한 가지 방법입니다. IIS 바이너리 디렉토리 외부의 아무 곳에나 환경 값을 던지고 program.cs에서 읽기/설정하기만 하면 됩니다.

• IIS루트
  
  
  
  • MySiteDEV
  
  
  • 큰 상자
    
    
    
    
    
    • 앱 설정.json
    
    
    
    • 앱 설정.DEV.json
    
    
    
    • appsettings.PROD.json
    
    
    
    • web.config
    
    
    
  
  
  • 로그
  
  
  • 환경 DEV
  
  
  • MySitePROD
  
  
  • 큰 상자
    
    
    
    
    
    • 앱 설정.json
    
    
    
    • 앱 설정.DEV.json
    
    
    
    • appsettings.PROD.json
    
    
    
    • web.config
    
    
    
  
  
  • 로그
  
  
  • env.PROD
  
  

@davidfowl

ASP.NET 코어가 IIS와 잘 작동하지 않는다는 사실이 사람들에게 불행하다고 말하고 있습니까? Microsoft .NET Core Architect로서?

Core의 패러다임 전환은 멀티 플랫폼입니다. IIS는 분명히 Windows 유틸리티이므로 약간의 성장통을 예상해야 합니다. 이와 같은 경우 해결 방법을 예상하고 상황이 진행됨에 따라 수용해야 합니다. Windows 기능을 지원하기 위해 Core에서 의도적으로 디자인을 선택했다면 직관적이지 않았을 것입니다.

추가하려면 편집:
이것은 Core가 IIS에 대해 기본적으로 더 나은 지원을 제공해야 하는지에 대한 생각입니다. 그럼에도 불구하고 환경 변수를 사용하는 것이 좋은 대안이라는 논의는 ...

@davidfowl

이것이 바로 엔터프라이즈 아키텍처와 SME의 차이점입니다. 저는 FTSE100에서 일하고 있으며 코드에서 배포를 분리하는 것이 합리적이지만 여러 사이트를 독립적으로 실행하기도 합니다. 모든 사이트를 호스팅하는 단일 서버를 갖는 것이 더 쉽고 비용 효율적입니다. Web Deploy + Transforms를 사용하는 것은 배달 코드 변경을 위한 검증된 메커니즘이며 제대로 작동합니다. 어떤 경우에는 더 나은 대안이 없다고 말하는 것은 아니지만 대부분의 사용자가 .net 프레임워크에서 코어로 마이그레이션할 때 친숙함을 원한다는 것을 알고 Microsoft는 변환을 계속 지원해야 했습니다.

이 스레드의 앞부분에서 지금 내 솔루션이 있으므로 충분히 만족합니다. 나는 그들이 이것을 표준으로 포함하지 않고 공을 약간 떨어 졌다고 생각합니다.

@윌앱

변환은 소스에서 컴파일하고 각 환경에 대해 별도로 게시한다는 아이디어를 기반으로 한다고 생각합니다. 대안이 훨씬 더 우아하기 때문에 M$가 삭제한 것이 기쁩니다.

새 설정에서는 릴리스 구성을 사용하여 한 번만 코드를 게시합니다. 실행 중인 모든 인스턴스는 원본의 동일한 바이너리 복사본입니다. 배포는 다음 환경 DEV=>TEST=>Staging=>PROD에 대한 단순한 파일 동기화여야 합니다.

ASP.NET 코어가 IIS와 잘 작동하지 않는다는 사실이 사람들에게 불행하다고 말하고 있습니까? Microsoft .NET Core Architect로서?

사람들은 이와 같이 사용되는 환경 변수가 시스템이 아닌 프로세스별로 사용되어야 한다는 사실을 즉시 생각하지 않는다는 것을 말하는 것입니다. 역사적으로 Windows에서 사람들은 환경 변수를 프로세스별이 아니라 시스템 전체로 식별하여 혼란을 야기했습니다. IIS 10은 앱 풀 환경 변수별 추가 지원을 추가했습니다. ASP.NET Core 모듈은 프로세스당 환경 변수 설정도 지원합니다.

그래도 이 기능은 있었습니다. 저는 여기서 생각의 철학적 변화가 가장 많이 일어났다고 생각합니다. 우리는 개발 시 비밀을 더 쉽게 지정할 수 있는 어떤 것도 하고 싶지 않습니다.

@challamzinniagroup 좋은 요약

이것은 Core가 IIS에 대해 기본적으로 더 나은 지원을 제공해야 하는지에 대한 생각입니다. 그럼에도 불구하고 환경 변수를 사용하는 것이 좋은 대안이라는 논의는 ...

오른쪽. 환경별 정보를 구성하기 위한 워크플로는 여전히 특정 환경에 있어야 합니다. 문제는 그것을 어떻게 거기에서 얻느냐 하는 것입니다. 배포의 일부입니까?

이 모든 것은 2.2의 도구에서 이에 대한 지원을 추가한다고 생각합니다.

참조: @vijayrkn

@davidfowl

"역사적으로 Windows에서 사람들은 환경 변수를 프로세스당이 아닌 시스템 전체로 식별합니다"라고 말할 때 명령줄 SET에서와 같이 Windows 환경 변수를 의미합니까?

.NET 핵심 컨텍스트 내의 "환경"에 대한 이해는 변수일 뿐입니다. 기본적으로 system 또는 web.config에서 ASPNETCORE_ENVIRONMENT를 읽습니다. 그러나 모든 규칙에 따라 모든 소스에서 덮어쓰고 가져올 수 있습니다.

그 접근 방식에 본질적으로 잘못된 것이 있습니까? Microsoft .NET 팀의 공식 입장이 하지 말라는 것이라면 심각하게 재고해야 하기 때문입니다. 그러나 사람들에게 IIS에서 .NET Core를 실행하라고 말하게 되지만 불행히도 이러한 앱을 구성하는 쉬운 방법은 없습니다. 그렇지 않기를 바랍니다.

감사 해요.

@ThisNoName

"역사적으로 Windows에서 사람들은 환경 변수를 프로세스당이 아닌 시스템 전체로 식별합니다"라고 말할 때 명령줄 SET에서와 같이 Windows 환경 변수를 의미합니까?

예, 이것이 바로 이 스레드의 모든 것입니다. ( 여기 참조). David가 말했듯이 이는 프로세스당일 수 있지만 내 경험상 dotnet core에 대한 대부분의 문서는 시스템 수준에서 설정했다고 가정하므로 동일한 서버에 여러 앱 인스턴스를 쉽게 배포할 수 없는 이 문제가 있습니다. 그들은 동일한 환경 값을 선택하므로 dev/staging/prod를 구별할 수 없습니다.

IIS10이 앱 풀별로 설정을 지원한다는 사실은 훌륭합니다... Server 2016을 사용할 수 있다면. 나는 2012를 실행 중이므로 이것은 옵션이 아닙니다. 다시 말하지만 내 문제는 Microsoft가 더 나은 방향으로 일을 옮기려고 하는 것이 아니라 많은 사람들이 ASP.NET 응용 프로그램을 배포할 때 당연하게 여겼던 것에 대한 '레거시' 지원을 중단하는 것이 실수처럼 느껴진다는 것입니다. 반드시 새로운 패턴을 도입하고 사람들이 이를 채택하도록 장려하되, 필요로 하는 사람이 거의 없다는 확신이 들 때까지 기존 동작을 제거하지 마십시오. 그렇지 않으면 dotnet core를 원하지만 마이그레이션 경로가 너무 고통스럽다고 생각하는 고객을 위해 장벽을 설정하는 것뿐입니다.

@윌앱

그것은 바로 기본 설정입니다. 원하는 방식으로 환경을 읽고 설정할 수 있습니다. 누군가가이 접근 방식의 심각한 결함을 지적하지 않는 한 적어도 그것은 내 이해입니다.

   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

심각한 결함은 솔루션 구성을 기반으로 VSTS에서 웹 게시를 사용하여 배포할 때 "ReadEnvFromWherever" 메서드가 어떻게 다른 값을 반환하도록 합니까? 전처리기 지시문(#if RELEASE ...)을 사용할 수 있다고 가정하지만 꽤 더럽게 느껴집니다.

"이전 세계"(ASP.NET 전체 프레임워크)에서 게시 프로필을 만들고 그 중 일부는 빌드할 솔루션 구성을 선택하는 것입니다. 해당 구성을 기반으로 dev/staging/prod에 게시하는지 여부에 따라 다른 구성을 지정할 수 있는 구성 변환을 적용했습니다.

이 워크플로가 단일 빌드 패키지를 가져와 각 환경을 통해 푸시하는 최신 CI 파이프라인에 맞지 않는다는 점을 인정합니다. 이 경우 VSTS 릴리스 파이프라인과 같은 것이 배포 시 설정을 주입하거나 프라임 패키지를 상자에 놓기만 하면 자동으로 작동하는 올바른 환경 변수가 있는 서버 인스턴스입니다. 다시 말하지만, 많은 SME와 1인 밴드가 이 위치에 없으며 원하는 결과를 생성하는 Visual Studio에서 배포하는 프로세스를 원합니다.

이것은 IIS에서 실행되고 전통적으로 ASP.NET 호스팅을 제공하는 공유 호스팅 플랫폼에 소규모 프로젝트를 배포하는 데에도 중요합니다. 그들은 호스팅 제어판을 통해 웹 사이트별로 환경 변수를 설정할 수 있는 기능이 없으므로 유일한 현실적인 접근 방식은 변환 및 web.config 입니다.

이 모든 것이 다음 릴리스에서 적절한 솔루션을 갖게 될 것이며 VS 지원이 내장되어 조금 더 나아질 것 같습니다. 호스팅 제공업체 및 레거시 시스템을 업그레이드하거나 개선할 수 있을 때까지 이 기능에 의존하는 기존 워크플로를 가진 사람들을 지원할 수 있기를 바랍니다.

@윌앱

관례상. 이전에 게시한 예제로 이동하면 상위 폴더에서 env.DEV를 읽고 파일 확장자를 환경 변수로 사용할 수 있습니다. 그러나 앱 루트의 이름을 MySiteDEV, MySitePROD 등으로 지정하고 폴더 이름을 구문 분석하여 환경 이름을 얻는 것과 같은 규칙에 따라 이동할 수 있습니다.

환경에 따라 코드가 다른 경우 IHostingEnvironment .EnvironmentName에서 환경 값을 읽을 수 있습니다.

이것은 시스템 변수 또는 web.config에서 ASPNETCORE_ENVIRONMENT를 읽는 .NET 코어와 차이가 없습니다.

@ThisNoName

그러나 수동으로 복사하지 않고 _env.DEV_를 상위 폴더로 가져오는 방법은 무엇입니까? 내가 무슨 말을 하려는지 볼 수 있지만, 난 당신이 여기에 포인트를 누락 생각 : 그냥 일한 아웃 - 오브 - 박스 솔루션으로도 사용된다. 이제 도구 지원이 dotnet 핵심 배포 프로세스의 일부로 간주되지 않았기 때문에 없습니다.

제거된 이유는 알지만(충분한 CI 프로세스가 있는 경우 더 나은 대안이 있기 때문에) 마이그레이션하는 사용자가 여전히 많이 원할 때 근시안적이었다고 생각합니다.

@윌앱

초기 설정 중에 한 번 복사하고 모든 향후 배포는 bin 폴더로 이동합니다. 재컴파일, 게시, 변환이 없습니다. 그래야만 하고 추가로 3줄의 코드가 필요하므로 어떻게 해야 할까요? M$입니다. 3개월 전까지만 해도 .NET Core에서 Active Directory를 호출할 수 없었습니다.

@ThisNoName 당신은 이 M$ 물건을 진지하게 받아들일 것으로 예상합니까? 2018년인거 아시죠?

귀하의 제안은 웹을 공유 호스팅 플랫폼에 배포하는 맥락에서 의미가 없습니다. 나는 당신이 무엇을 찬성하거나 반대하는지 잘 모르겠습니다. 환경 변수가 게시 프로필에 지정될 수 있도록 기능이 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가 차선책을 제공하기를 기다리는 대신 적절하다고 판단되는 방식으로 제어할 수 있다는 것입니다. 그리고 그것들이 무엇이든지 간에, 어쨌든 시스템이나 web.config 및 설정 환경에서 일부 값을 읽는 또 다른 규칙 기반 솔루션입니다.

BTW, 여전히 규칙을 사용할 수 있습니다. appsettings는 단일 중간 단어를 사용해야 하고 Staging/Production은 특별한 의미가 없다는 말은 없습니다. 이와 같은 작업을 쉽게 수행하고 일치시킬 폴더 이름을 전달할 수 있습니다.

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.2 미리 보기1 https://www.microsoft.com/net/download/dotnet-core/2.2 에서 사용할 수 있습니다.

@vijayrkn 어딘가에 기본 샘플이 있습니까? ASPNETCORE_ENVIRONMENT를 설정하는 기본 변환을 사용하여 hello world에 해당하는 사람들을 가리키는 것이 좋습니다.

ASPNETCORE_ENVIRONMENT를 설정하기 위해 사용자는 msbuild 속성 '$(EnvironmentName)'을 설정할 수 있습니다. web.config 변환을 사용하여 다른 환경 변수를 설정하는 방법을 보여주는 샘플을 추가하겠습니다.

다음은 샘플 리포지토리입니다. https://github.com/vijayrkn/webconfigtransform

Readme에는 작동 방식에 대한 세부 정보가 있습니다.
https://github.com/vijayrkn/webconfigtransform/blob/master/README.md

도움이 되었기를 바랍니다!

@Eilon - 이 문제를 종료할 수 있습니다. 이것은 수정되었으며 최신 미리 보기에서 사용할 수 있습니다.

@vijayrkn 게시 설정 대화 상자에서 환경을 설정하도록 게시 설정을 구성하는 방법이 명확하지 않습니까? 두 사이트가 동일한 서버에 배포되는 경우 스테이징 사이트와 프로덕션 사이트를 구별하기 위해 이 대화 상자에서 실제로 변경할 수 있는 것은 무엇입니까?

.NET Core의 이러한 측면은 매우 지저분해 보입니다. 폴더별로 환경을 지정하는 것이 훨씬 쉬워야 합니다. 전체 서버 환경 변수는 우리 상황에서 전혀 작동하지 않습니다. 모든 사람이 프로덕션 사이트와 다른 서버에서 스테이징 사이트를 실행할 수 있는 것은 아닙니다.

설정은 애플리케이션별입니다.

죄송하지만 제 질문에 대한 답변은 아닙니다. 아마도 내가 뭔가를 오해하고 있는 것 같습니다.

https://github.com/vijayrkn/webconfigtransform/blob/master/README.md ( @vijayrkn 우리는 이것을 실제 문서에

@vijayrkn 게시 대화 상자에서 이에 대한 지원이 얼마나 됩니까?

현재 게시 대화 상자에는 게시 환경 설정이 지원되지 않지만 게시 프로필에서 환경을 수동으로 설정하거나 특정 변환을 적용할 수 있습니다.

@nmg196 - web.config에서 'ASPNETCORE_ENVIRONMENT'를 설정하려면 publishprofile에 환경 이름을 추가하기만 하면 됩니다.

예시:
https://github.com/vijayrkn/webconfigtransform/blob/master/Properties/PublishProfiles/FolderProfile.pubxml#L18

고급 시나리오(ASPNETCORE_ENVIRONMENT 환경 변수 설정 제외)의 경우 위 문서에서 언급한 대로 web.config 변환을 적용할 수 있습니다.

@davidfowl - Angelos에는 web.config 변환 지원을 문서화하는 항목이 있습니다.

@vijayrkn TFS의 CI/CD에서 어떻게 사용하나요? TFS에서 p:CustomTransformFileName과 함께 dotnet publish를 사용할 수 없습니다.

이 msbuild 속성을 dotnet publish에 전달할 수 있습니다.

이 샘플은 https://github.com/vijayrkn/webconfigtransform/blob/master/publish.cmd 에서 참조할 수 있습니다.

그러면 CustomTransformFileName 속성이 dotnet publish에 전달됩니다.

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

@vijayrkn
귀하의 문서를 읽었으며 web.config를 변환할 수 없습니다. 기본적으로 readme.md에 있는 모든 명령을 시도했지만 그 중 어느 것도 변환이 수행되지 않았습니다.

그러나 Microsoft.Web.XmlTransform.dll을 사용하여 게시 작업과 별도로 변환을 수행하는 powershell 스크립트를 작성할 수 있었습니다.

제 질문은 어떤 버전의 msbuild와 dotnet을 사용하고 있습니까?
나는 사용하고 있습니다 :
닷넷 --버전 2.1.104
닷넷 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> 했습니다. 그래도 좀 더 잘 보이도록 이 위에 UI가 있으면 좋을 것입니다. 나는 이것이 나중에 올 것이라고 생각합니까?

dotnet publish에서 기본적으로 web.config 변환을 활성화하는 것이 주요 변경 사항이라고 생각합니다. .NET Core SDK 2.2.101을 설치한 후 CI/CD 시나리오가 중단되었습니다. 모든 릴리스에 대해 dotnet publish 한 번만 사용하여 게시된 아티팩트를 생성하도록 구성된 파이프라인( 한 번 빌드 규칙 ), 변환은 실제 배포에 자동으로 적용됩니다(Octopus에서 수행). 문서에서 이 변경 사항에 대한 언급을 찾을 수 없습니다. 배포 후 web.config에서 구성 블록이 두 배로 된 이유를 파악하는 데 약간의 시간을 보냈습니다. 분명히 변환은 dotnet publish 및 릴리스 관리 도구에 의해 두 번 적용되었습니다.

<IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled> 설정으로 web.config 변환을 비활성화한 후 TransformWebConfig도 건너뛰었습니다(TransformXml과 함께). 결과적으로 %LAUNCHER_PATH% 및 %LAUNCHER_ARGS% 변수가 게시 프로세스 중에 대체되지 않습니다. 이러한 단계를 독립적으로 제어하는 ​​설정이 있습니까?

App.Config 파일이 있는 콘솔 앱에서 작동합니까?

예를 볼까요?

@dmitryshunkov $(RunXdt)를 false로 설정하여 사용자 지정 Xml 변환 실행을 건너뛸 수 있습니다.

@auserx - sdk 스타일 프로젝트인 경우 작동해야 합니다.