Aspnetcore: Aktifkan transformasi web.config untuk proyek AspNetCore di VS

FWIW, saya setuju. Kami hanya perlu memperjelas bahwa itu untuk pengaturan IIS. Hal lainnya adalah fakta bahwa kita telah beralih dari memiliki default web.config dalam template sehingga perlu diketahui.

/cc @sayedihashimi

Apakah ini hanya untuk IIS? Saya pikir inti masalahnya adalah penggunaan variabel ASPNETCORE_ENVIRONMENT fullstop untuk memberi tahu situs web di lingkungan mana ia berada.

Saya pikir skenario yang cukup umum adalah untuk berbagai lingkungan pementasan/QA di-host di kotak yang sama dalam contoh IIS yang sama. Mungkin ada 3 tim semua dengan "lingkungan" mereka sendiri yang dapat mereka gunakan untuk menguji kode mereka (Katakanlah menyebarkan cabang tertentu), tetapi mereka semua menggunakan kotak yang sama.

Jika kita mengambil beberapa contoh kode bagaimana appsettings.json diaktifkan per lingkungan :

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(); }
Skenario di atas tidak akan berfungsi karena variabel lingkungan adalah sistem yang luas. Bisa jadi IIS, nginix dll duduk di depannya dan pertukaran konfigurasi tidak akan berfungsi.

Sering kali saya melihat hal di atas muncul, saran muncul untuk menggunakan Docker, atau menggunakan sesuatu seperti Wayang/Koki untuk mengelola konfigurasi aplikasi sehingga tidak ada pengaturan aplikasi.{env}.json, tapi saya pikir itu membuat path dari penuh kerangka MVC yang jauh lebih sulit.

@mindingdata Anda sebenarnya dapat mengontrol logika yang menentukan dari mana lingkungan berasal di Program.cs . Variabel lingkungan hanyalah salah satu cara untuk mendeklarasikannya (cara utama). Jika Anda ingin melakukan sesuatu yang lain berdasarkan beberapa file ajaib atau waktu, hubungi UseEnvironment(environmentName) di WebHostBuidler

Hanya untuk memperjelas, ini benar-benar hanya untuk konfigurasi IIS. Sistem konfigurasi JSON saat ini untuk pengaturan aplikasi cukup baik dan saya sangat merekomendasikannya.

Lebih jauh lagi: Saya menemukan bahwa ketika saya menggunakan web.config untuk mencoba mengganti pengaturan lingkungan sistem, itu tidak berfungsi. Ketika pengaturan lingkungan sistem saya diatur ke "Pengembangan" dan saya mencoba mengaturnya ke "Produksi" menggunakan web.config (seperti di bawah), aplikasi masih berpikir itu berjalan dalam Pengembangan. (Aplikasi ASP.NET Core berjalan di IIS).

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

Saya pikir ini adalah tempat yang tepat. Saya membangun demo N-tier dan sepertinya saya tidak tahu cara menyuntikkan IHostingEnvironment ke proyek lapisan akses data saya. Proyek itu adalah tempat saya mengakses database saya dan satu-satunya cara saya mendapatkan string koneksi ke lapisan itu adalah dengan mengganti metode OnConfiguring dengan string ajaib dari file konfigurasi.

Saya juga melihat cheetah lambat, tetapi sepertinya menggunakan metode "Debug, Rilis" atau "Pengembangan, Produksi" saat ini tergantung pada apakah Anda menggunakan metode VS atau variabel lingkungan.

Pasti ada informasi yang saya lewatkan. MS tidak ingin semua orang membangun aplikasi tingkat tunggal.

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);
        }

jadi apakah ada kemajuan dalam hal ini?

kita harus dapat mengatur env di konfigurasi untuk aplikasi tanpa menggunakan sihir

Ya, saya juga ingin beberapa kemajuan dalam hal ini. Saat ini tidak tahu bagaimana saya harus menerbitkan proyek terpisah ke kotak yang sama menggunakan variabel lingkungan yang berbeda.

Saya akhirnya menemukan solusi yang cukup sederhana. Di file appsettings.json utama, saya menentukan lingkungan yang saya inginkan:

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

Di Program.CS, saya kemudian membuat IConfiguration, dan menetapkan nama lingkungan ke nilai 'ActiveEnvironment', sebelum memuat file konfigurasi khusus lingkungan.

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();
}

Jelas, saat memublikasikan ke lingkungan yang berbeda, 'Lingkungan Aktif' perlu diubah.

@DaleMckeown Saya akan melakukan hal serupa tetapi saya punya pertanyaan tentang implementasi Anda. Saya melihat Anda menggunakan Microsoft.AspNetCore.WebHost untuk membuat konfigurasi default. Apakah pendekatan ini masih berlaku untuk aplikasi konsol tanpa komponen web?

@Swazimodo Saya belum mencoba solusi ini dalam konteks aplikasi konsol, jadi saya tidak yakin. Taruhan terbaik untuk melihat apakah ada cara alternatif untuk mengatur variabel lingkungan untuk aplikasi konsol.

Kami menangani ini dengan cara yang berbeda. Kami menyiapkan agen build kami untuk mengambil
file pengaturan khusus lingkungan dan menimpa file pengaturan root
dengan itu. Build kami membuat file zip terpisah untuk setiap lingkungan yang kami
menyebarkan ke.

Pada Kam, 26 Okt 2017 jam 12:48, Dale Mckeown [email protected]
menulis:

@Swazimodo https://github.com/swazimodo Saya belum mencoba solusi ini
int konteks aplikasi konsol, jadi saya tidak yakin. Taruhan terbaik untuk
lihat apakah ada cara alternatif untuk mengatur variabel lingkungan untuk
aplikasi konsol.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub
https://github.com/aspnet/Home/issues/2019#issuecomment-339728441 , atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/AAx4bT20JSb0XSzNBIAiiubq9mTVKbW5ks5swLf6gaJpZM4NMx25
.

Tampaknya semua solusi memerlukan semacam tweaking post build/publish? Saya akhirnya menjatuhkan file teks kosong di root aplikasi dan meneruskannya sebagai lingkungan. Apakah saya melewatkan sesuatu?

Setuju banget sama postingan pertama. Secara desain cukup fleksibel tetapi pada akhirnya ternyata sangat sulit untuk diotomatisasi. Misalnya saya memiliki aplikasi yang saya publikasikan ke IIS di server lain. Juga berjalan di IIS lokal (melalui folder publish). Jadi saya mengatur lingkungan Pengembangan di web.config. Tapi kemudian saya perlu mengubahnya ke Produksi atau apa pun selama penerbitan. Tugas yang cukup umum kurasa. Saya percaya itu tidak mungkin, kan? Saya harus mengedit web.config secara manual di server jarak jauh.

Idealnya pengaturan Lingkungan harus didukung melalui "dotnet publish" (untuk target publikasi apa pun):

dotnet publish ... -environment=Production

dotnet publish dapat mencari file web.%Enviroment%.config (Web.Production.config, Web.Development.config) dan menggabungkan (mengubahnya) dengan web.config. Pada akhirnya kami akan memiliki nilai ASPNETCORE_ENVIRONMENT yang benar:

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

@evil-shrike lihat https://github.com/nil4/dotnet-transform-xdt untuk build/publish time config transforms.

Sebuah kasus penggunaan, mungkin. Saya perlu log untuk ditulis ke .\App_Data karena pelari aplikasi saya memiliki akses baca/tulis ke semua yang ada di bawah .\App_Data, tetapi hanya bisa membaca yang lainnya di bawah .\ . Saya menggunakan penyebaran web, dan ingin dapat menggunakan web.config seperti ini dengan folder log di bawah 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>

Anda mungkin bertanya, mengapa tidak meletakkan pengaturan tersebut di file web.config alih-alih web.release.config? Yah processPath=".\<executable>.exe" bukan tempat executable hidup ketika saya mengembangkan secara lokal melawan IIS Express. Jadi saya mendapatkan kesalahan "Kesalahan HTTP 502.5 - Kegagalan Proses" yang bagus.

Kami mengotomatiskan build kami menggunakan Jenkins dan cara kami yang ada untuk melakukan konfigurasi vars per lingkungan dalam proyek NetFramework adalah melalui transformasi web.config. Jadi kami pikir kami akan dapat melakukannya di dotnet juga.

Ternyata msbuild masih kompatibel dengan aspnet core csproj untuk melakukan transformasi web.config!

Kita dapat menambahkan tugas penerbitan TransformXml di csproj Asp.Net Core:

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

Tambahkan target transformasi spesifik:

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

Lakukan beberapa transformasi, misalnya pada variabel ASPNETCORE_ENVIRONMENT pada 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>

Transform web.config menggunakan msbuild sebelum menjalankan publish:

msbuild Test.csproj /t:ConfigDev

"Biarkan saya mengawali ini dengan mengatakan bahwa saya bukan penggemar web.config tetapi pengalaman menerbitkan aplikasi AspNetCore ke IIS benar-benar buruk."

Saya sangat setuju dengan utas ini.

Setelah kesederhanaan transformasi konfigurasi di ASP.Net biasa, seluruh ketergantungan pada variabel ASPNETCORE_ENVIRONMENT di seluruh

Bahkan contoh Microsoft sendiri mengatakan bahwa kita dapat menggunakan, katakanlah, file _appsettings.Production.json_, hanya dengan menambahkan baris ini...

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

...tetapi tidak memperhatikan NAMA dari konfigurasi yang kita pilih. Jadi, bahkan ketika saya telah memilih konfigurasi Produksi saya, itu masih akan mencoba untuk membuka appsettings.development.json. Dan tidak, saya tidak ingin harus mengedit sendiri variabel ASPNETCORE_ENVIRONMENT secara manual setiap kali saya mempublikasikan ke lingkungan yang berbeda. Itu hanya meminta masalah.

Saya belum melihat contoh kerja sederhana menggunakan file _appsettings.XXXX.json_.
Saya tidak sabar menunggu barang-barang ini akhirnya selesai. (Mendesah...)

Ya, tolong perbaiki ini !!

Saya baru saja menerapkan situs inti dotnet produksi pertama saya, dan sekarang menghadapi masalah bahwa saya tidak dapat dengan mudah memiliki instance pementasan di server yang sama karena saya tidak tahu cara memublikasikan aplikasi saya ke kotak yang sama tanpa mengambilnya pengaturan produksi.

Saya pikir saya akan mencoba solusi @DaleMckeown untuk saat ini, saya pikir itu akan berhasil tetapi rasanya seperti solusi daripada solusi. Variabel lingkungan sangat bagus tetapi HANYA jika Anda memiliki rasio 1-1 server terhadap lingkungan, dan di luar perusahaan saya ragu itu sering terjadi.

@willapp Saran saya jelas merupakan solusi. Tapi itu berhasil - Saya memiliki beberapa versi aplikasi yang sama yang berjalan di server yang sama untuk sementara waktu sekarang dan tidak memiliki masalah apa pun.

Ingatlah untuk mengubah pengaturan 'Environment Aktif' sebelum Anda mempublikasikan dan Anda akan baik-baik saja.

Saya menghadapi persis apa yang disebutkan dkent600:

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

tidak bekerja pada server produksi. Aplikasi terus menggunakan nilai "appsettings.Development.json", yang pada akhirnya mengalahkan manfaat transformasi xml saat memublikasikan.

Saya akan mencoba solusi yang disarankan oleh DaleMckeown.

satu-satunya cara yang masuk akal untuk mengubah ASPNETCORE_ENVIRONMENT adalah menggunakan web.config

Tidak juga. Jika Anda perlu menjalankan beberapa instance dari situs yang sama pada mesin yang sama, berikut ini cara yang lebih sederhana

• Situs Inti Saya
  
  
  
  • tempat sampah
  
  
  • log
  
  
• env.Terserah

Arahkan aplikasi IIS Anda ke bin dan di program.cs

.UseEnvironment(ReadEnvExtensionFromParentFolder())

Itu dia. Anda dapat memiliki situs sebanyak yang Anda inginkan, menyebarkan ke bin tanpa khawatir tentang transformasi, dan bahkan beralih lingkungan dengan mengganti nama env.Whenver.

Saya mendukung ini. Saya memiliki penulisan ulang URL yang dikonfigurasi untuk server produksi yang tidak berfungsi di lingkungan pengujian. Saya belum menemukan cara untuk mempublikasikan untuk memilih file web.config yang tepat untuk penyebaran, saya harus menyalinnya secara manual.

Lihat https://github.com/nil4/xdt-samples/ , dan alat CLI untuk menerapkan transformasi pada waktu publikasi .

Apakah ada kemajuan dalam hal ini? Sudah 13 bulan sejak laporan awal, 2.1.0 ada di sini sekarang, dan semuanya masih sangat buruk dengan hosting IIS tradisional. Segalanya bekerja dengan sangat baik jika Anda menggunakan Azure, tetapi saat ini itu bukan pilihan untuk sebagian besar situs yang saya hosting.

Tampaknya untuk hosting IIS tradisional akan bermanfaat untuk mengatur lingkungan yang diinginkan pada baris perintah (seperti yang dijelaskan @evil-shrike di atas), dan juga dalam profil publikasikan .pubxml . Seperti yang dikatakan @davidfowl , perlu jelas bahwa ini hanya akan berfungsi menggunakan web.config dan IIS, tetapi itu pasti masih mencakup sebagian besar basis instalasi.

Saat ini saya memiliki solusi yang sangat rapuh menggunakan terjemahan Microsoft.DotNet.Xdt.Tools dan web.config , tetapi memerlukan konfigurasi build per lingkungan agar berfungsi dan baru saja rusak setelah memperbarui ke v2.1.0.

Akan sangat menyenangkan untuk mendengar jika ada rencana di area ini dan, jika ya, apa rencana itu? Jika tidak ada rencana, atau masih jauh, maka pasti ada solusi sementara yang lebih baik daripada cara rapuh/semi-manual yang saat ini terpaksa kita terapkan? Khusus untuk penerapan ke QA dan pementasan, saya benar-benar ingin dapat menekan tombol di VS dan mengetahui hal yang benar sedang terjadi, dan tidak harus bergantung pada pengetahuan kepala dan proses manual.

Kami tidak memiliki rencana saat ini tetapi alat ini https://github.com/nil4/xdt-samples/ oleh @ nil4 terlihat cukup bagus.

@svallis sudahkah anda mencobanya?

Apakah hal utama orang ingin mengatur lingkungan?

@davidfowl Ya, solusi saya saat ini menggunakan alat yang Anda csproj , dan untuk tujuan saya ini umumnya merupakan hubungan 1 banding 1 dengan lingkungan Anda. Sebagai contoh:

• Konfigurasi build: Debug = Lingkungan: Pengembangan
• Konfigurasi build: Staging = Lingkungan: Staging
• Konfigurasi build: Rilis = Lingkungan: Produksi

Untuk dua yang terakhir, saya kemudian memiliki web.{Build configuration}.config dan appsettings.{Environment}.json , dan web.{Build configuration}.config secara harfiah hanya XDT untuk memberi tahu web.config agar berakhir dengan variabel lingkungan ASPNETCORE_ENVIRONMENT . Jadi misalnya, melanjutkan contoh di atas, web.Release.config terlihat seperti ini:

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

Ini sebenarnya semua bekerja dengan cukup baik dari baris perintah. Menjalankan dotnet publish -c Staging atau apa pun yang menghasilkan folder dengan output yang benar dan web.config diubah sesuai kebutuhan. Itu memang terasa seperti itu bisa disederhanakan. Jika ada tombol -iisenvironment pada dotnet publish yang melakukan ini untuk kami, dan kemudian ditampilkan sebagai kotak teks sederhana dalam penerbitan VS, itu akan menghilangkan kebutuhan untuk mengelola konfigurasi build, XDT, dll secara manual untuk situasi hosting IIS tradisional.

Namun, dari dalam VS saat ini tampaknya bermasalah. Saat ini kami tidak dapat memublikasikan dari dalam VS sama sekali, dan bahkan ketika berhasil pada v2.0.0 kami harus secara manual memilih konfigurasi build yang benar sebelum memublikasikan.

@davidfowl Dari sudut pandang saya, Idealnya, saya ingin mengatur lingkungan sebagai bagian dari profil publikasikan saat menggunakan Web Deploy.

Saya setuju bahwa, opsi penerbitan akan ideal. Saya bahkan tidak menggunakan solusi yang dijelaskan oleh @svallis karena saya lebih suka mempublikasikan melalui VS IDE dan bukan baris perintah.

@willapp Solusi yang saya gunakan berfungsi di Visual Studio, tetapi saya memiliki masalah lain dengan solusi yang saya uji yang menyebabkan masalah di VS (https://github.com/aspnet/Home/issues/3190) . Maaf jika saya tidak menjelaskannya. Semuanya diatur menggunakan alat di csproj , yang harus dihormati oleh baris perintah dan VS.

Akhirnya berhasil mencoba alat yang disarankan di atas oleh @davidfowl dan berhasil! 👍

Cukup ikuti instruksi di sini https://github.com/nil4/dotnet-transform-xdt di bawah bagian "Alat tingkat proyek" (karena saya belum menggunakan 2.1.0). Saya harus membuat Web.config default sendiri karena saya tidak memilikinya (cukup salin dari yang dihasilkan VS saat Anda menerapkan), kemudian buat Web.Debug.config dengan transformasi untuk mengatur ASPNETCORE_ENVIRONMENT ke Pengembangan, dan hei cepat! Ini menyebarkan konfigurasi yang diubah dan situs sekarang dimulai dengan benar.

Akan lebih baik jika dukungan untuk ini dibuat resmi, tetapi untuk saat ini ini sedang berjalan.

@davidfowl Tautan yang Anda tunjuk membutuhkan penerbitan menggunakan baris perintah. Saya ingin mempublikasikan menggunakan alat VS GUI. Saya tidak ingin pengembang saya perlu menginstal alat cli untuk menerbitkan proyek. Tidak ada gunanya menentukan ASPNETCORE_ENVIRONMENT di web.config jika transformasi tidak didukung. Melihat berapa banyak suara positif yang dimiliki masalah ini, itu harus pergi ke jaminan simpanan.

@orobert91 VS hanyalah GUI yang melilit alat baris perintah. Saya berhasil menggunakan https://github.com/nil4/xdt-samples/ untuk mengubah web.config selama publikasi dari dalam VS. Jika Anda mengonfigurasinya dengan benar untuk proyek Anda, maka itu akan berubah dengan benar baik dari baris perintah maupun dalam IDE Anda.

@svallis Memang, salah membaca dokumen. Saya telah memecahkan masalah saya dengan tugas penyalinan sederhana:

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

Ada properti msbuild yang menerbitkan penghargaan untuk nama Lingkungan -

$(NamaLingkungan)

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

Saat ini, ketika properti ini disetel, yang kita lakukan hanyalah membuat appsettings.$(EnvironmentName).json dan menambahkan info string koneksi ke file itu (jika diminta).

Ke depannya, Ketika properti ini disetel selama publikasi, kami juga dapat memperbarui web.config yang dipublikasikan agar memiliki entri berikut juga:

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

Apakah ini akan berfungsi untuk sebagian besar skenario yang disebutkan di sini?

Untuk skenario di luar pengaturan environmentVariable, kita akan melihat kelayakan porting transformasi web.config ( Xdt ) untuk proyek inti.

Saya telah menemukan solusi yang tampaknya mencakup skenario yang saya butuhkan - saya ingin mempostingnya di sini jika itu bermanfaat bagi orang lain.

Dalam kasus saya, saya memiliki lingkungan pengembangan saya secara lokal dan lingkungan pementasan dan produksi saya di server jauh (server yang sama). Saya dapat menarik url aplikasi dari IApplicationBuilder dan menggunakannya dalam pernyataan switch untuk menetapkan nilai EnvironmentName .

Tampaknya jauh lebih sedikit "solusi-ish" daripada beberapa solusi lain yang ditawarkan tetapi tentu saja tergantung pada preferensi.

Dalam Startup.cs :

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

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

Metode di atas adalah ekstensi yang saya kumpulkan berdasarkan koleksi properti di dalam IApplicationBuilder . Metode ekstensi (dan kelas) terlihat seperti ini:

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

Saya harap ini dapat bermanfaat bagi orang-orang (dalam kasus di mana transformasi web.config tidak diinginkan).

Bersulang!

Saya menandai masalah ini sebagai diskusi karena tidak ada fitur/perbaikan yang terkait dengan ini yang direncanakan saat ini. Jika orang masih memiliki permintaan fitur tertentu, harap ajukan masalah untuk itu dan kami akan memprioritaskannya.

Saya tidak terlalu puas dengan solusi yang saya lihat di utas ini, jadi saya mengambil pendekatan yang berbeda. Saya menemukan utas ini Stack Overflow: https://stackoverflow.com/questions/31049152/publish-to-iis-setting-environment-variable/36836533#36836533 . Ini berbicara tentang memodifikasi ApplicationHost.config di server sebagai tempat untuk menyimpan variabel ASPNETCORE_ENVIRONMENT.

Server IIS internal kami dikelola oleh tim operasi kami, jadi para pengembang di organisasi kami tetap tidak membuat situs tersebut. Tim operasi menggunakan skrip PowerShell untuk membuat situs ini. Saya hanya meminta mereka untuk memodifikasi skrip itu sehingga juga membuat perubahan yang relevan pada ApplicationHost.config pada saat situs disediakan. Sekarang saya dapat menerapkannya di sana dan tidak khawatir tentang pengelolaan lingkungan .NET Core. Bekerja dengan baik untuk situasi kami.

Saya akan berpikir bahwa dalam lingkungan DevOps yang sebenarnya Anda mungkin akan tetap menggunakan Azure, yang membuatnya sangat mudah untuk mengatur variabel lingkungan.

Dengan SDK terbaru, Anda cukup meneruskan properti msbuild $(EnvironmentName) & tooling akan mengatur pengaturan ASPNETCORE_ENVIRONMENT ke nilai ini.

misalnya: Jika EnvironmentName diatur ke staging, maka web.config akan memiliki entri berikut:

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

PR dengan perbaikan:
https://github.com/aspnet/websdk/pull/377

@vijayrkn Sepertinya awal yang menjanjikan. Akankah ini pada akhirnya memiliki dukungan yang dibangun ke dalam VS WebDeploy/publikasikan profil, dll?

Saat ini kami tidak memiliki UI di VS untuk membuat pemilihan nama Lingkungan ini tetapi jika ini ditambahkan ke file proyek atau pubxml, baik publikasikan dari VS dan commandline akan menghormatinya.

Kami akan mempertimbangkan untuk menambahkan dukungan UI untuk ini juga.

@vijayrkn Ini hanya solusi bagi mereka yang menerbitkan dengan file web.config - apakah itu benar?

@vijayrkn Ya, mendapatkan dukungan ke dalam format pubxml akan menjadi momen di mana ini akan berguna untuk kasus penggunaan kami. Pada saat itu kami dapat menghapus semua hal transformasi XML dan hanya menentukan string lingkungan yang sesuai di setiap pubxml . Dukungan UI bisa datang di kemudian hari, tapi itu hanya lapisan gula pada kue.

@challamzinniagroup - Tidak, Anda tidak memerlukan web.config untuk fungsi ini.
Yang perlu Anda lakukan adalah menambahkan yang berikut ini ke file pubxml dan alat penerbitan akan mengurus sisanya.

<EnvironmentName>YourCustomEnvironment</EnvironmentName>

@challamzinniagroup , @vijayrkn

Kecuali Anda memiliki beberapa konfigurasi yang hanya dapat dilakukan di web.config dan harus diubah antar lingkungan, jika tidak, biarkan web.config saja. Dengan 2 baris kode, Anda dapat membaca variabel lingkungan dari mana saja. Dan Anda tidak perlu mengutak-atik dalam mempublikasikan profil, atau kode yang diterbitkan, cukup daftar appsetting yang cocok.XYZ.json

@IniNoName

Maksud Anda seperti string koneksi database, titik akhir layanan, kredensial, atau sejumlah hal lain yang akan berubah dari dev->staging->production.

Jika Anda menjalankan beberapa instance di lingkungan yang sama ( sangat umum di luar cloud), Anda benar-benar membutuhkan fleksibilitas transformasi web.config. Sangat konyol bahwa Microsoft tidak memenuhi persyaratan ini di luar kotak dengan inti dotnet, mereka hanya berasumsi semua orang meng-hosting di Azure dan memiliki hubungan 1-1 antara instance dan lingkungan.

Variabel lingkungan benar-benar payah di luar cloud, karena Anda berakhir dengan konfigurasi yang terpisah dari aplikasi Anda, sehingga lebih sulit untuk mengelola penerapan sepenuhnya.

Perubahan besar di sini adalah bahwa rahasia tersebut tidak boleh disimpan dalam kontrol sumber dan sebaliknya, harus dikonfigurasi pada lingkungan itu sendiri. Transformasi berjalan cepat dalam menghadapi praktik yang baik karena mengasumsikan bahwa Anda memahami target penerapan pada waktu publikasi yang tidak selalu demikian (terutama ketika Anda memiliki banyak lingkungan). Apakah Anda benar-benar perlu menerapkan ulang saat Anda mengubah pengaturan konfigurasi untuk salah satu penerapan N tersebut?

Sekarang bagian yang disayangkan adalah bahwa dengan IIS, variabel lingkungan perlu diatur dalam file konfigurasi sehingga kumpulan aplikasi dapat melihatnya. Saya tidak berpikir kami pernah bermaksud agar orang-orang mengatur konfigurasi lebar mesin pada mesin target (meskipun saya telah melihat orang melakukan itu).

@willapp Mengapa Anda tidak menggunakan appsettings.json ?

@willapp

M$ memiliki solusi sempurna, tetapi kebanyakan orang terjebak dengan konsep transformasi web.config.

Inilah salah satu cara Anda dapat memiliki beberapa situs secara berdampingan. Anda hanya perlu membuang nilai lingkungan Anda di mana saja di luar direktori biner IIS, dan membaca/mengaturnya dari program.cs

• IISRoot
  
  
  
  • Situs SayaDEV
  
  
  • tempat sampah
    
    
    
    
    
    • pengaturan aplikasi.json
    
    
    
    • pengaturan aplikasi.DEV.json
    
    
    
    • pengaturan aplikasi.PROD.json
    
    
    
    • web.config
    
    
    
  
  
  • log
  
  
  • env.DEV
  
  
  • Situs SayaPROD
  
  
  • tempat sampah
    
    
    
    
    
    • pengaturan aplikasi.json
    
    
    
    • pengaturan aplikasi.DEV.json
    
    
    
    • pengaturan aplikasi.PROD.json
    
    
    
    • web.config
    
    
    
  
  
  • log
  
  
  • env.PROD
  
  

@davidfowl

Apakah Anda memberi tahu orang-orang bahwa sangat disayangkan bahwa inti ASP.NET tidak dapat bekerja dengan baik dengan IIS? Sebagai Arsitek Inti Microsoft .NET?

Pergeseran paradigma di sini dengan apa pun Core adalah multi-platform. IIS jelas merupakan utilitas Windows - dan beberapa rasa sakit yang tumbuh harus diharapkan. Solusi, dalam kasus seperti ini, harus diharapkan dan diterima saat segala sesuatunya bergerak maju. Untuk membuat pilihan desain yang disengaja di Core untuk mendukung fitur Windows akan menjadi kontra-intuitif imo.

Sunting untuk menambahkan:
Ini menjadi pemikiran apakah Core harus memiliki dukungan out-of-the-box yang lebih baik untuk IIS. Diskusi menggunakan variabel lingkungan menjadi alternatif yang baik meskipun...

@davidfowl

Dan inilah perbedaan antara arsitektur perusahaan dan UKM. Saya bekerja untuk FTSE100 dan ya, memisahkan penerapan dari kode masuk akal, tetapi saya juga menjalankan beberapa situs secara independen dan lebih mudah dan lebih hemat biaya untuk memiliki satu server tempat saya meng-host semua situs saya. Menggunakan Web Deploy + Transforms adalah mekanisme yang telah dicoba dan diuji untuk perubahan kode pengiriman, itu hanya berfungsi. Saya tidak mengatakan tidak ada alternatif yang lebih baik dalam beberapa kasus, tetapi Microsoft seharusnya terus mendukung transformasi karena mengetahui bahwa sebagian besar pengguna menginginkan keakraban saat bermigrasi dari .net framework ke core.

Saya punya solusi sekarang dari sebelumnya di utas ini, jadi saya cukup senang. Saya hanya berpikir mereka menjatuhkan bola sedikit tidak termasuk ini sebagai standar.

@willapp

Saya pikir transformasi didasarkan pada gagasan kompilasi dari sumber dan publikasikan secara terpisah untuk setiap lingkungan. Saya senang M$ menjatuhkannya karena alternatifnya jauh lebih elegan.

Dengan pengaturan baru, Anda hanya memublikasikan kode Anda sekali menggunakan konfigurasi Rilis. Semua instance yang berjalan adalah salinan biner identik dari aslinya. Penerapan seharusnya hanya sinkronisasi file sederhana ke lingkungan berikutnya DEV=>TEST=>Staging=>PROD.

Apakah Anda memberi tahu orang-orang bahwa sangat disayangkan bahwa inti ASP.NET tidak dapat bekerja dengan baik dengan IIS? Sebagai Arsitek Inti Microsoft .NET?

Saya mengatakan bahwa orang tidak langsung memikirkan fakta bahwa variabel lingkungan yang digunakan seperti ini seharusnya per proses, bukan per mesin. Secara historis di windows orang mengidentifikasi variabel lingkungan sebagai lebar mesin alih-alih per proses dan itu telah menyebabkan kebingungan. IIS 10 menambahkan dukungan untuk menambahkan per variabel lingkungan kumpulan aplikasi. Modul ASP.NET Core juga memiliki dukungan untuk mengatur variabel lingkungan per proses.

Masih kemampuan ini telah ada. Saya pikir sebagian besar telah terjadi pergeseran filosofis dalam berpikir di sini. Kami tidak ingin melakukan apa pun yang membuatnya lebih mudah untuk menentukan rahasia pada waktu pengembangan.

@challamzinniagroup ringkasan yang bagus

Ini menjadi pemikiran apakah Core harus memiliki dukungan out-of-the-box yang lebih baik untuk IIS. Diskusi menggunakan variabel lingkungan menjadi alternatif yang baik meskipun...

Benar. Alur kerja untuk mengonfigurasi informasi khusus lingkungan harus tetap berada di lingkungan tertentu. Pertanyaannya adalah bagaimana Anda mendapatkannya di sana. Apakah itu bagian dari penyebaran?

Semua itu mengatakan, saya yakin kami menambahkan dukungan untuk ini dalam perkakas di 2.2.

cc: @vijayrkn

@davidfowl

Ketika Anda mengatakan "Secara historis di windows orang mengidentifikasi variabel lingkungan sebagai lebar mesin alih-alih per proses", maksud Anda variabel lingkungan Windows, seperti pada baris perintah SET?

Karena pemahaman saya tentang "lingkungan" di dalam konteks inti .NET, hanyalah sebuah variabel. Secara default, ia membaca ASPNETCORE_ENVIRONMENT dari sistem atau web.config. Tetapi Anda dapat menimpa dan mendapatkannya dari sumber mana pun dengan konvensi apa pun.

Apakah ada yang salah dengan pendekatan itu? Karena jika posisi resmi tim Microsoft .NET tidak melakukannya, kami harus mempertimbangkan kembali secara serius. Tetapi Anda akhirnya akan memberi tahu orang-orang untuk menjalankan .NET core di bawah IIS, tetapi sayangnya, tidak ada cara mudah untuk mengonfigurasi aplikasi tersebut. Semoga bukan itu masalahnya.

Terima kasih.

@IniNoName

Ketika Anda mengatakan "Secara historis di windows orang mengidentifikasi variabel lingkungan sebagai lebar mesin alih-alih per proses", maksud Anda variabel lingkungan Windows, seperti pada baris perintah SET?

Ya, inilah tepatnya yang dimaksud dengan utas ini. (Lihat di sini ). Seperti yang dikatakan David, ini bisa per proses, tetapi menurut pengalaman saya, sebagian besar dokumentasi di dotnet core mengasumsikan Anda mengaturnya di tingkat mesin, oleh karena itu kami memiliki masalah ini di mana Anda tidak dapat dengan mudah menerapkan beberapa instance aplikasi ke server yang sama, seperti mereka akan mengambil nilai lingkungan yang sama sehingga Anda tidak dapat membedakan antara dev/staging/prod.

Fakta bahwa IIS10 mendukung pengaturannya per kumpulan aplikasi sangat bagus ... jika Anda memiliki Server 2016 yang tersedia. Saya menjalankan 2012 jadi ini bukan pilihan. Sekali lagi, masalah saya bukanlah bahwa Microsoft mencoba untuk memindahkan hal-hal ke arah yang lebih baik, tetapi menjatuhkan dukungan 'warisan' untuk sesuatu yang banyak orang anggap remeh dalam menyebarkan aplikasi ASP.NET terasa seperti kesalahan bagi saya. Dengan segala cara, perkenalkan pola baru dan dorong orang untuk mengadopsinya, tetapi jangan hilangkan perilaku lama sampai Anda yakin bahwa hanya sedikit orang yang membutuhkannya. Jika tidak, yang Anda lakukan hanyalah memasang penghalang bagi pelanggan yang menginginkan inti dotnet tetapi menganggap jalur migrasi terlalu menyakitkan.

@willapp

Itu hanya pengaturan default di luar kotak. Anda dapat membaca dan mengatur lingkungan dengan cara apa pun yang Anda inginkan. Setidaknya itulah pemahaman saya, kecuali seseorang menunjukkan kelemahan serius dalam pendekatan ini?

   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";
        }
    }

@IniNoName

Kelemahan seriusnya adalah, bagaimana Anda membuat metode "ReadEnvFromWherever" mengembalikan nilai yang berbeda saat menggunakan menggunakan Web Publish dari VSTS, berdasarkan Konfigurasi Solusi Anda? Saya kira Anda bisa menggunakan arahan preprocessor (#if RELEASE ...) tetapi itu terasa sangat kotor.

Di "dunia lama" (kerangka kerja lengkap ASP.NET) Anda membuat profil publikasi, dan bagian dari itu adalah memilih konfigurasi solusi untuk dibangun. Berdasarkan konfigurasi itu, ia kemudian menerapkan transformasi konfigurasi yang memungkinkan Anda menentukan konfigurasi berbeda berdasarkan apakah Anda memublikasikan ke dev/staging/prod.

Saya menerima bahwa alur kerja ini tidak cocok dengan pipa CI modern, di mana Anda mengambil satu paket build dan mendorongnya melalui setiap lingkungan - dalam hal ini Anda ingin sesuatu seperti pipa rilis VSTS untuk menyuntikkan pengaturan pada waktu penerapan, atau Anda prime contoh server Anda dengan variabel lingkungan yang tepat dalam hal ini Anda hanya menjatuhkan paket ke dalam kotak dan itu akan bekerja secara otomatis. Sekali lagi, saya pikir banyak UKM dan one-man-band tidak berada di tempat ini, dan menginginkan proses penerapan dari Visual Studio yang menghasilkan hasil yang mereka inginkan.

Sekadar menambahkan bahwa ini juga penting untuk menyebarkan proyek kecil ke platform hosting bersama yang berjalan di IIS dan hosting ASP.NET yang ditawarkan secara tradisional. Mereka tidak memiliki fasilitas untuk mengatur variabel lingkungan per situs web melalui panel kontrol hosting mereka, sehingga satu-satunya pendekatan realistis adalah menggunakan transformasi dan web.config .

Kedengarannya seperti ini semua akan memiliki solusi yang layak di rilis berikutnya, dan dengan dukungan VS bawaan mengikuti sedikit lebih jauh ke depan. Mudah-mudahan itu akan mendukung orang-orang dengan alur kerja yang ada yang mengandalkan fungsi ini hingga penyedia hosting dan sistem lama dapat ditingkatkan atau ditingkatkan.

@willapp

Dengan perjanjian. Jika Anda mengikuti contoh yang saya posting sebelumnya, Anda dapat membaca env.DEV dari folder induk dan menggunakan ekstensi file sebagai variabel lingkungan Anda. Tetapi Anda dapat menggunakan konvensi apa pun, seperti memberi nama root aplikasi Anda sebagai MySiteDEV, MySitePROD, dll. dan mengurai nama folder untuk mendapatkan nama lingkungan.

Jika kode Anda bervariasi menurut lingkungan, Anda dapat membaca nilai lingkungan dari IHostingEnvironment .EnvironmentName

Ini tidak ada bedanya dengan .NET core membaca ASPNETCORE_ENVIRONMENT dari variabel sistem atau web.config.

@IniNoName

Tetapi bagaimana Anda memasukkan _env.DEV_ ke folder induk, selain menyalinnya secara manual? Saya mengerti apa yang ingin Anda katakan, tetapi saya pikir Anda kehilangan intinya di sini: dulu ada solusi out-of-the-box yang baru saja berhasil. Sekarang tidak ada karena dukungan perkakas untuk itu tidak dianggap sebagai bagian dari proses penyebaran inti dotnet.

Saya mendapatkan _why_ itu dihapus (karena ada alternatif yang lebih baik jika Anda memiliki proses CI yang layak), tetapi saya pikir itu cukup picik ketika banyak pengguna yang bermigrasi masih menginginkannya.

@willapp

Anda menyalinnya sekali selama penyiapan awal dan semua penerapan di masa mendatang masuk ke folder bin. Tidak ada kompilasi ulang, tidak ada publikasi, tidak ada transformasi. Begitulah seharusnya, membutuhkan tambahan 3 baris kode, jadi apa? Ini M$. Hingga 3 bulan yang lalu, Anda bahkan tidak dapat memanggil Active Directory di .NET Core.

@ThisNoName Apakah Anda berharap dianggap serius dengan barang-barang M$ ini. Kamu sadar ini tahun 2018, kan?

Saran Anda tidak masuk akal dalam konteks penerapan web ke platform hosting bersama. Saya bahkan tidak yakin apa yang Anda perdebatkan atau lawan, fungsionalitasnya ditambahkan ke rilis berikutnya dari ASP.NET Core sehingga variabel lingkungan dapat ditentukan dalam profil publikasikan, tidak perlu ada transformasi atau apa pun. Juga tidak perlu pendekatan non-standar dengan nama folder, yang mungkin atau mungkin tidak di bawah kendali Anda.

@willapp , @svallis
Solusi yang saya posting sedikit lebih jauh berfungsi dalam beberapa kasus. Anda dapat menarik Url dan mengatur lingkungan berdasarkan itu. Di lingkungan hosting mana pun, Anda memiliki kendali penuh atas Url Anda. Saya menyadari ini masih "peretasan", dan solusi - tetapi umumnya harus berfungsi sebagian besar waktu. Dalam kasus perusahaan hosting saya, Url yang saya terima adalah localhost:port base ("127.0.0.1:7777") - jadi ternyata tidak ideal untuk saya. Tetapi saya juga memiliki kemampuan untuk mengatur jalur folder root di berbagai lingkungan saya karena saya telah mengaturnya sebagai subdomain - dan menarik jalur aplikasi root juga cukup sederhana:

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

Pilihan apakah lingkungan harus ditentukan atau tidak dalam kode, pada waktu penerapan, atau ditentukan sebelumnya secara langsung di lingkungan sebelumnya bukanlah diskusi yang saya coba atasi - saya hanya menawarkan perbaikan yang masuk akal untuk UKM/ individu yang memiliki kontrol hosting terbatas dan perlu diperbaiki. Dalam kasus saya ini adalah kode-sekali-dan-lupa - persis apa yang saya butuhkan.

Lebih jauh ke hilir saya dapat dengan mudah menarik nilai konfigurasi dari file appsettings.json tanpa perlu transformasi dengan sederhana termasuk:

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

dalam file pengaturan dan memiliki 3 entri per konfigurasi - satu untuk setiap lingkungan. Saya hanya memiliki sejumlah kecil konfigurasi dalam file ini sehingga duplikasi bukanlah masalah besar.

Semoga ini membantu!

@challamzinniagroup Lebih mudah menggunakan jalur dan nama folder relatif berdasarkan konvensi.

@svallis Seluruh konsep adalah untuk mempublikasikan sekali dan menyebarkan pada tingkat biner. Jadi, bahkan jika Anda dapat mengatur variabel per profil publikasi, bukan itu caranya.

@ThisNoName Untuk Anda, mungkin lebih mudah - tetapi jangan berasumsi seperti itu untuk orang lain. Dalam kasus saya, saya memiliki pengaturan untuk menghapus direktori tujuan sebelum menerbitkan/menyalin - jadi untuk solusi Anda, saya harus mengunggah ulang setiap file lingkungan secara manual, setiap saat. Itu pasti _tidak_ lebih mudah.

@challamzinniagroup Setuju. Setiap situasi berbeda. Intinya adalah bahwa lingkungan hanyalah sebuah variabel, Anda dapat mengontrolnya sesuai keinginan Anda, daripada menunggu Microsoft untuk memberikan hal terbaik berikutnya. Dan apa pun yang muncul, hanyalah solusi berbasis konvensi lainnya -- membaca beberapa nilai dari sistem atau web.config dan mengatur lingkungan.

BTW, Anda masih dapat menggunakan konvensi. Tidak ada yang mengatakan bahwa pengaturan aplikasi harus menggunakan kata tengah tunggal dan Staging/Production tidak memiliki arti khusus. Anda dapat dengan mudah melakukan sesuatu seperti ini dan memasukkan nama folder yang cocok.

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

Dengan solusi berbasis konvensi, Anda dapat menjalankan instance baru tanpa harus mengkompilasi ulang dan/atau menerbitkan ulang.

@vijayrkn dapatkah Anda menjelaskan lebih lanjut tentang penggunaan pubxml?
Saya memutakhirkan SDK saya ke 2.1.302 (x64) mengubah pubxml saya tetapi tidak dapat melihat perbedaan apa pun di web.config yang diterbitkan.

@wggley - Perbaikan tidak tersedia di 2.1.302. Ini harus tersedia dalam rilis mendatang berikutnya.

Anda dapat mencoba versi pratinjau cli yang berisi perbaikan dari sini - https://dotnetcli.blob.core.windows.net/dotnet/Sdk/release/2.1.4xx/dotnet-sdk-latest-win-x64.exe

Beri tahu saya jika Anda mengalami masalah dengan versi pratinjau di atas.

Terima kasih @vijayrkn, saya akan menunggu rilis berikutnya dan mencoba menggunakan publikasi baru.
Saya ingin menunjukkan bahwa solusi @frankhoffy bekerja untuk saya seperti pesona:
https://stackoverflow.com/questions/31049152/publish-to-iis-setting-environment-variable/36836533#36836533
Carilah jawaban pertama (jawaban yang paling banyak dipilih).

Dukungan transformasi konfigurasi web selama publikasi sekarang tersedia di 2.2 preview1 https://www.microsoft.com/net/download/dotnet-core/2.2

@vijayrkn apakah ada sampel dasar di suatu tempat? Akan sangat bagus untuk mengarahkan orang ke halo dunia yang setara menggunakan transformasi dasar yang menetapkan ASPNETCORE_ENVIRONMENT.

Untuk menyetel ASPNETCORE_ENVIRONMENT, pengguna dapat menyetel properti msbuild '$(EnvironmentName)'. Saya akan menambahkan contoh yang menunjukkan cara mengatur variabel env lainnya menggunakan transformasi web.config.

Berikut ini contoh repo - https://github.com/vijayrkn/webconfigtransform

Readme memiliki detail tentang cara kerjanya:
https://github.com/vijayrkn/webconfigtransform/blob/master/README.md

Semoga ini membantu!

@Eilon - Kami dapat menutup masalah ini. Ini diperbaiki dan tersedia di pratinjau terbaru.

@vijayrkn Tidak jelas cara mengonfigurasi pengaturan Publikasikan untuk mengatur lingkungan dari dialog pengaturan Publikasikan? Apa yang sebenarnya dapat diubah dalam dialog ini untuk membedakan situs Staging dari situs Produksi, jika kedua situs disebarkan ke server yang sama ?

Aspek inti .NET ini tampaknya sangat berantakan. Perlu dibuat lebih mudah untuk menentukan lingkungan berdasarkan per-folder. Variabel lingkungan seluruh server tidak dapat bekerja untuk situasi kita sama sekali. Tidak semua orang dapat menjalankan situs pementasan mereka di server yang berbeda ke situs produksi mereka.

Pengaturannya adalah per aplikasi.

Maaf tapi itu tidak benar-benar menjawab pertanyaan saya. Mungkin aku salah paham tentang sesuatu.

Ada beberapa dokumentasi semu di sini https://github.com/vijayrkn/webconfigtransform/blob/master/README.md ( @vijayrkn kita perlu memasukkan ini ke dalam dokumen asli).

@vijayrkn Berapa banyak dukungan yang ada untuk ini dalam dialog publikasikan?

Saat ini dialog publikasikan tidak memiliki dukungan apa pun untuk mengatur lingkungan publikasikan tetapi lingkungan dapat diatur secara manual di profil publikasikan atau transformasi tertentu dapat diterapkan.

@nmg196 - Jika Anda hanya ingin mengatur 'ASPNETCORE_ENVIRONMENT' di web.config, yang harus Anda lakukan adalah menambahkan nama lingkungan ke publishprofile.

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

Untuk skenario lanjutan (selain menyetel variabel lingkungan ASPNETCORE_ENVIRONMENT) transformasi web.config dapat diterapkan seperti yang disebutkan dalam dokumentasi di atas.

@davidfowl - Angelos memiliki item untuk mendokumentasikan dukungan transformasi web.config.

@vijayrkn Bagaimana cara menggunakan CI/CD dari TFS? Saya tidak dapat menggunakan dotnet publish dengan p:CustomTransformFileName di TFS

Anda dapat meneruskan properti msbuild ini ke dotnet publish.

Anda dapat merujuk ke sampel ini di sini - https://github.com/vijayrkn/webconfigtransform/blob/master/publish.cmd

Ini meneruskan properti CustomTransformFileName ke dotnet publish

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

@vijayrkn
Saya telah membaca dokumentasi Anda dan tidak dapat mengubah web.config. Saya sudah mencoba pada dasarnya semua perintah yang Anda miliki di readme.md dan tidak satupun dari mereka menghasilkan transformasi yang dilakukan.

Namun saya telah mampu menulis skrip PowerShell yang menggunakan Microsoft.Web.XmlTransform.dll untuk melakukan transformasi terpisah dari operasi publikasikan.

Pertanyaan saya adalah versi msbuild dan dotnet apa yang Anda gunakan?
Saya menggunakan:
dotnet --versi 2.1.104
dotnet msbuild -versi 15.6.84.34536

Terima kasih

@stephenarsenault1
Anda perlu menginstal salah satu build dari sini agar fitur menyala - https://www.microsoft.com/net/download/dotnet-core/2.2

Terbaru - https://www.microsoft.com/net/download/thank-you/dotnet-sdk-2.2.100-preview3-windows-x64-installer

@davidfowl menulis:

Ada beberapa dokumentasi semu di sini https://github.com/vijayrkn/webconfigtransform/blob/master/README.md ( @vijayrkn kita perlu memasukkan ini ke dalam dokumen asli).

@vijayrkn Berapa banyak dukungan yang ada untuk ini dalam dialog publikasikan?

Apakah Anda tahu apakah ini pernah ditambahkan ke dokumen asli, jika demikian, apakah Anda memiliki tautannya?

Kami telah beralih menggunakan <EnvironmentName> di profil publikasi kami sekarang. Akan lebih baik untuk memiliki beberapa UI di atas ini sehingga lebih terlihat. Saya kira ini akan datang di kemudian hari?

Saya pikir ini adalah perubahan besar untuk mengaktifkan transformasi web.config default di dotnet publish. Setelah menginstal .NET Core SDK 2.2.101, skenario CI/CD kami rusak. Pipa kami dikonfigurasi untuk membuat artefak yang diterbitkan menggunakan dotnet publish hanya sekali untuk rilis apa pun ( aturan build sekali ), transformasi diterapkan secara otomatis pada penerapan nyata (dilakukan oleh Octopus). Saya tidak dapat menemukan penyebutan apa pun dalam dokumentasi tentang perubahan ini. Menghabiskan sedikit waktu mencoba mencari tahu apa alasan untuk menggandakan blok konfigurasi di web.config setelah penerapan. Rupanya, transformasi diterapkan dua kali: oleh dotnet publish dan oleh alat manajemen rilis.

Setelah menonaktifkan transformasi web.config dengan pengaturan <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled> , TransformWebConfig juga dilewati (bersama dengan TransformXml), yang mengakibatkan variabel %LAUNCHER_PATH% dan %LAUNCHER_ARGS% tidak diganti selama proses publikasi. Apakah ada pengaturan untuk mengontrol langkah-langkah ini secara mandiri?

Apakah ini berfungsi di aplikasi konsol dengan file App.Config?

Bisakah kita melihat contohnya?

@dmitryshunkov Anda dapat mengatur $(RunXdt) ke false untuk melewatkan menjalankan transformasi Xml khusus.

@auserx - jika ini adalah proyek gaya SDK, maka itu akan berfungsi.