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 لإدارة تهيئة التطبيق حتى لا تكون هناك إعدادات تطبيقات. {env} .json ، لكنني أعتقد أن هذا يجعل المسار من كامل إطار 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-tier ولا يبدو لي أن أكتشف كيفية حقن 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);
        }

فهل كان هناك أي تقدم في هذا؟

يجب أن نكون قادرين على تعيين 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();
}

من الواضح ، عند النشر في بيئات مختلفة ، يجب تغيير "البيئة النشطة" وفقًا لذلك.

DaleMckeown كنت سأفعل شيئًا مشابهًا ولكن كان لدي سؤال حول التنفيذ. أرى أنك تستخدم Microsoft.AspNetCore.WebHost لإنشاء التكوين الافتراضي. هل لا يزال هذا النهج ساريًا على تطبيق وحدة التحكم الذي لا يحتوي على مكونات ويب؟

Swazimodo لم أجرب هذا الحل في سياق تطبيق وحدة التحكم ، لذلك لست متأكدًا. أفضل رهان هو معرفة ما إذا كانت هناك طريقة بديلة لتعيين متغيرات البيئة لتطبيقات وحدة التحكم.

لقد اعتنينا بهذا بطريقة مختلفة. نقوم بإعداد وكيل البناء لدينا
ملف الإعدادات الخاصة بالبيئة والكتابة فوق ملف إعدادات الجذر
معها. ينشئ بناؤنا ملفًا مضغوطًا منفصلاً لكل بيئة نقوم بها
نشر إلى.

يوم الخميس ، 26 أكتوبر ، 2017 الساعة 12:48 مساءً ، Dale Mckeown [email protected]
كتب:

Swazimodo https://github.com/swazimodo لم أجرب هذا الحل
في سياق تطبيق وحدة التحكم ، لذلك لست متأكدًا. أفضل رهان له
معرفة ما إذا كانت هناك طريقة بديلة لإعداد متغيرات البيئة ل
تطبيقات وحدة التحكم.

-
أنت تتلقى هذا لأنك مشترك في هذا الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على 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 لأن مشغل التطبيق لديه حق الوصول للقراءة / الكتابة إلى كل شيء ضمن. أنا أستخدم نشر الويب ، وأود أن أتمكن من نشر 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. لذلك حصلت على الخطأ الجيد ol '"خطأ HTTP 502.5 - فشل العملية".

نقوم بأتمتة الإنشاءات الخاصة بنا باستخدام Jenkins وطريقتنا الحالية للقيام بتكوين vars لكل بيئة في مشاريع NetFramework تكون من خلال تحويلات web.config. لذلك اعتقدنا أننا سنكون قادرين على القيام بذلك في dotnet أيضًا.

اتضح أن msbuild لا يزال متوافقًا مع aspnet core csproj للقيام بتحويلات web.config!

يمكننا إضافة مهمة النشر TransformXml في Asp.Net Core csproj:

<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. ولا ، لا أريد أن أضطر إلى تحرير متغير

ما زلت أرى مثالاً عمليًا بسيطًا لاستخدام ملفات _appsettings.XXXX.json_.
لا استطيع الانتظار حتى تنتهي هذه الأشياء في النهاية. (تنهد...)

نعم ، من فضلك أصلح هذا !!

لقد قمت للتو بنشر موقع dotnet الأساسي للإنتاج الخاص بي ، وأواجه الآن مشكلة أنه لا يمكنني بسهولة الحصول على مثيل مرحلي على نفس الخادم لأنني لا أعرف كيفية نشر تطبيقي على نفس المربع دون التقاط إعدادات الإنتاج.

أعتقد أنني سأحاول حل DaleMckeown في الوقت الحالي ، وأعتقد أنه سيعمل ولكنه يبدو وكأنه حل بديل وليس حلاً. تعد متغيرات البيئة رائعة ولكن فقط إذا كان لديك نسبة 1-1 من الخوادم إلى البيئات ، وخارج المؤسسة أشك في أن هذا يحدث كثيرًا.

willapp اقتراحي هو بالتأكيد حل بديل. لكنها تعمل - لدي إصدارات متعددة من نفس التطبيق تعمل على نفس الخادم لفترة من الوقت الآن ولم أواجه أية مشكلات.

فقط تذكر تغيير إعداد "البيئة النشطة" قبل النشر ويجب أن تكون على ما يرام.

أواجه بالضبط ما ذكره dkent600:

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

لا يعمل على خادم الإنتاج. يستمر التطبيق في استخدام قيم "appsettings.Development.json" ، والتي تقضي في النهاية على فوائد تحويل xml عند النشر.

سأحاول الحل البديل الذي اقترحه DaleMckeown.

الطريقة الوحيدة المعقولة لتغيير ASPNETCORE_ENVIRONMENT هي استخدام web.config

ليس حقيقيا. إذا كنت بحاجة إلى تشغيل مثيلات متعددة من نفس الموقع على نفس الجهاز ، فإليك طريقة أبسط بكثير

• MyCoreSite
  
  
  
  • سلة مهملات
  
  
  • السجلات
  
  
• أيا كان

قم بتوجيه تطبيق IIS الخاص بك إلى bin وفي program.cs

.UseEnvironment(ReadEnvExtensionFromParentFolder())

هذا هو. يمكنك الحصول على العديد من المواقع التي تريدها ، ونشرها في سلة المهملات دون القلق بشأن التحويل ، وحتى تبديل البيئة عن طريق إعادة تسمية 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 ، لكنه يتطلب تكوين بناء لكل بيئة لبدء العمل وقد تعطل للتو بعد التحديث إلى الإصدار 2.1.0.

سيكون من الرائع معرفة ما إذا كانت هناك أية خطط في هذا المجال ، وإذا كان الأمر كذلك ، فما هي؟ إذا لم تكن هناك خطط ، أو أنها بعيدة المنال ، فمن المؤكد أن هناك حلًا مؤقتًا أفضل من الطرق الهشة / شبه اليدوية التي نضطر حاليًا لاستخدامها؟ خاصة بالنسبة للنشر في ضمان الجودة والإعداد المرحلي ، أود حقًا أن أكون قادرًا فقط على الضغط على زر في VS ومعرفة الشيء الصحيح الذي يحدث ، ولا يتعين علي الاعتماد على المعرفة الرئيسية والعمليات اليدوية.

ليس لدينا أي خطط حاليًا ولكن هذه الأداة https://github.com/nil4/xdt-samples/ بواسطة @ nil4 تبدو جيدة جدًا.

svallis هل جربته؟

هل الشيء الرئيسي الذي يريده الناس هو تهيئة البيئة؟

davidfowl نعم ، يستخدم الحل الحالي الأداة التي قمت بربطها ، ولكن بالنسبة لمشروع ذي وجهات متعددة للنشر عليه ، يتطلب تكوين بناء لكل بيئة. أنت بحاجة إلى تكوينات البناء المختلفة من أجل الحصول على شيء يمكن الإمساك به في الإعداد csproj ، ولأغراضي ، تكون بشكل عام علاقة 1 إلى 1 مع بيئاتك. فمثلا:

• تكوين التكوين: التصحيح = البيئة: التطوير
• تكوين التكوين: التدريج = البيئة: التدريج
• تكوين التكوين: الإصدار = البيئة: الإنتاج

بالنسبة للاثنين الأخيرين ، لديّ بعد ذلك 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 ، فسيؤدي ذلك إلى إزالة الحاجة إلى إدارة تكوينات الإنشاء ، XDTs ، إلخ يدويًا لحالات استضافة IIS التقليدية.

من داخل VS يبدو حاليًا مشكلة. لا يمكننا حاليًا النشر من داخل VS على الإطلاق ، وحتى عندما كان يعمل على الإصدار 2.0.0 ، كان علينا تحديد تكوين الإصدار الصحيح يدويًا قبل النشر.

davidfowl من وجهة نظري ، من الناحية المثالية ، أود تعيين البيئة كجزء من ملف تعريف النشر عند استخدام Web Deploy.

أود أن أوافق على ذلك ، سيكون خيار النشر مثاليًا. أنا لا أستخدم الحل البديل الذي وصفه svallis لأنني أفضل النشر عبر VS IDE وليس سطر الأوامر.

willapp يعمل الحل الذي أستخدمه في Visual Studio ، لكن لدي مشكلات أخرى مع الحل الذي csproj ، والتي يجب أن يحترمها كل من سطر الأوامر و VS.

أخيرًا ، تمكنا من davidfowl وهي تعمل! 👍

فقط اتبعت التعليمات الواردة هنا https://github.com/nil4/dotnet-transform-xdt ضمن قسم "أداة مستوى المشروع" (حيث إنني لست على 2.1.0 حتى الآن). اضطررت إلى إنشاء Web.config افتراضي بنفسي لأنه لم يكن لديّ (فقط نسخه من الذي ينشئه VS عند النشر) ، ثم قمت بإنشاء Web.Debug.config مع تحويل لتعيين ASPNETCORE_ENVIRONMENT إلى التطوير ، المعزوفة! ينشر التكوين المحول ويبدأ الموقع الآن بشكل صحيح.

سيكون من الرائع أن يتم دعم ذلك رسميًا ، ولكن في الوقت الحالي هذا يؤدي المهمة.

davidfowl الارتباط الذي

@ 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 تنشر درجات الامتياز لاسم البيئة -

$ (اسم البيئة)

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

في الوقت الحالي ، عند تعيين هذه الخاصية ، كل ما نقوم به هو إنشاء appsettings.$(EnvironmentName).json وإضافة معلومات سلسلة الاتصال إلى هذا الملف (إذا طلب ذلك).

من الآن فصاعدًا ، عند تعيين هذه الخاصية أثناء النشر ، يمكننا أيضًا تحديث web.config المنشور للحصول على الإدخال التالي أيضًا:

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

هل سينجح هذا مع معظم السيناريوهات المذكورة هنا؟

بالنسبة للسيناريوهات خارج إعداد البيئةمتغير ، سننظر في جدوى نقل تحويلات web.config (

لقد توصلت إلى حل يبدو أنه يغطي السيناريوهات التي أطلبها - أردت نشره هنا في حال كان مفيدًا لأي شخص آخر.

في حالتي ، حصلت على بيئة التطوير الخاصة بي محليًا وكلا بيئات التدريج والإنتاج الخاصة بي على خادم بعيد (نفس الخادم). لقد تمكنت من سحب عنوان 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 غير مرغوب فيه).

هتافات!

أضع علامة على هذه المشكلة كمناقشة لأنه لم يتم التخطيط لميزات / إصلاحات متعلقة بذلك في الوقت الحالي. إذا كان لا يزال لدى الأشخاص طلبات ميزات محددة ، فيرجى تقديم مشكلات لهم وسنمنح الأولوية.

لم أكن راضيًا حقًا عن الحلول التي رأيتها في هذا الموضوع ، لذلك اتخذت نهجًا مختلفًا. لقد عثرت على هذا الموضوع Stack Overflow: 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>

العلاقات العامة مع الإصلاح:
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 بمفرده. باستخدام سطرين من التعليمات البرمجية ، يمكنك قراءة متغيرات البيئة من أي مكان. ولا تحتاج إلى أي تعديل في ملف تعريف النشر أو التعليمات البرمجية المنشورة ، فقط قائمة بإعدادات التطبيقات المطابقة.

تضمين التغريدة

تقصد مثل سلاسل اتصال قاعدة البيانات أو نقاط نهاية الخدمة أو بيانات الاعتماد أو أي عدد من الأشياء الأخرى التي قد تتغير من dev-> staging-> production.

إذا كنت تقوم بتشغيل مثيلات متعددة في نفس البيئة (شائعة جدًا خارج السحابة) ، فأنت بحاجة ماسة إلى مرونة تحويلات web.config. إنه لأمر مثير للسخرية أن Microsoft لم تلب هذا المطلب خارج الصندوق مع dotnet core ، لقد افترضوا فقط أن كل شخص كان يستضيف في 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
    
    
    
  
  
  • السجلات
  
  
  • البيئة
  
  
  • MySitePROD
  
  
  • سلة مهملات
    
    
    
    
    
    • appsettings.json
    
    
    
    • appsettings.DEV.json
    
    
    
    • appsettings.PROD.json
    
    
    
    • web.config
    
    
    
  
  
  • السجلات
  
  
  • ENV.PROD
  
  

تضمين التغريدة

هل تخبر الناس أنه من المؤسف أن نواة ASP.NET لا تعمل بشكل جيد مع IIS؟ كمهندس Microsoft .NET Core؟

التحول النموذجي هنا مع أي شيء Core هو متعدد المنصات. من الواضح أن IIS هو أداة مساعدة لنظام التشغيل Windows - ولذا ينبغي توقع بعض الآلام المتزايدة. الحلول البديلة ، في مثل هذه الحالة ، يجب توقعها وقبولها مع تقدم الأمور. إن القيام بخيارات تصميم مقصودة في Core لدعم ميزة Windows كان من شأنه أن يكون أمرًا غير بديهي.

تحرير للإضافة:
هذه فكرة حول ما إذا كان يجب أن يكون لدى Core دعم أفضل خارج الصندوق لـ IIS. على الرغم من مناقشة استخدام متغيرات البيئة كبديل جيد ...

تضمين التغريدة

وهذا هو بالضبط الفرق بين هندسة المؤسسة والشركات الصغيرة والمتوسطة. أنا أعمل مع FTSE100 ونعم ، فإن فصل النشر عن الكود أمر منطقي ، لكنني أيضًا أدير عدة مواقع بشكل مستقل ، ومن الأسهل والأكثر فعالية من حيث التكلفة أن يكون لدي خادم واحد أقوم باستضافة جميع مواقعي عليه. يعد استخدام Web Deploy + Transforms آلية مجربة ومختبرة لتغييرات رمز التسليم ، فهي تعمل فقط. لا أقول أنه لا توجد بدائل أفضل في بعض الحالات ، ولكن كان على Microsoft أن تستمر في دعم التحويلات مع العلم أن معظم المستخدمين يريدون الإلمام عند الترحيل من إطار عمل .net إلى أساسي.

لدي الحل الآن من وقت سابق في هذا الموضوع ، لذلك أنا سعيد بما فيه الكفاية. أعتقد أنهم أسقطوا الكرة قليلاً دون تضمين هذا كمعيار.

willapp

أعتقد أن التحويل يعتمد على فكرة التجميع من المصدر والنشر بشكل منفصل لكل بيئة. أنا سعيد لأن M $ أسقطته لأن البديل أكثر أناقة.

من خلال الإعداد الجديد ، لا تنشر الكود الخاص بك إلا مرة واحدة باستخدام Release config. جميع مثيلات التشغيل هي نسخ ثنائية متطابقة من الأصل. يجب أن يكون النشر مجرد مزامنة ملف بسيطة مع البيئة التالية DEV => TEST => Staging => PROD.

هل تخبر الناس أنه من المؤسف أن نواة ASP.NET لا تعمل بشكل جيد مع IIS؟ كمهندس Microsoft .NET Core؟

أنا أقول إن الناس لا يفكرون على الفور في حقيقة أن متغيرات البيئة المستخدمة مثل هذا من المفترض أن تكون لكل عملية بدلاً من كل آلة. من الناحية التاريخية ، يقوم الأشخاص بتحديد متغيرات البيئة على أنها آلة واسعة النطاق بدلاً من كل عملية ، وقد تسبب ذلك في حدوث ارتباك. أضاف IIS 10 دعمًا لإضافة متغيرات بيئة تجمع التطبيقات. تحتوي الوحدة النمطية ASP.NET Core أيضًا على دعم لإعداد متغيرات البيئة لكل عملية.

لا تزال هذه القدرة موجودة. أعتقد أنه كان هناك غالبًا تحول فلسفي في التفكير هنا. لا نريد فعل أي شيء يسهل تحديد الأسرار في وقت التطوير.

challamzinniagroup ملخص جيد

هذه فكرة حول ما إذا كان يجب أن يكون لدى Core دعم أفضل خارج الصندوق لـ IIS. على الرغم من مناقشة استخدام متغيرات البيئة كبديل جيد ...

حق. يجب أن يظل سير العمل لتكوين معلومات خاصة بالبيئة على البيئة المحددة. السؤال هو كيف تحصل عليه هناك. هل هو جزء من النشر؟

كل ما قيل ، أعتقد أننا نضيف دعمًا لهذا في الأدوات في 2.2.

نسخة إلى :

تضمين التغريدة

عندما تقول "تاريخيًا على نظام التشغيل Windows ، يحدد الأشخاص متغيرات البيئة على أنها واسعة النطاق للجهاز بدلاً من كل عملية" ، هل تقصد متغيرات بيئة Windows ، كما هو الحال في سطر الأوامر SET؟

لأن فهمي لـ "البيئة" داخل سياق .NET الأساسي ، هو مجرد متغير. بشكل افتراضي ، يقرأ ASPNETCORE_ENVIRONMENT من النظام أو web.config. ولكن يمكنك الكتابة فوقه والحصول عليه من أي مصدر بأي اتفاقية.

هل هناك أي خطأ بطبيعته في هذا النهج؟ لأنه إذا كان الموقف الرسمي لفريق Microsoft .NET هو عدم القيام بذلك ، فسيتعين علينا إعادة النظر بجدية. ولكن سينتهي بك الأمر بإخبار الأشخاص بتشغيل .NET core ضمن IIS ، ولكن لسوء الحظ ، لا توجد طريقة سهلة لتكوين هذه التطبيقات. آمل أن يكون هذا ليس هو الحال.

شكرا.

تضمين التغريدة

عندما تقول "تاريخيًا على نظام التشغيل Windows ، يحدد الأشخاص متغيرات البيئة على أنها واسعة النطاق للجهاز بدلاً من كل عملية" ، هل تقصد متغيرات بيئة Windows ، كما هو الحال في سطر الأوامر SET؟

نعم ، هذا هو بالضبط ما يدور حوله هذا الموضوع. (انظر هنا ). كما يقول David ، يمكن أن تكون هذه لكل عملية ، ولكن في تجربتي ، تفترض معظم الوثائق على dotnet core أنك قمت بتعيينها على مستوى الجهاز ، وبالتالي لدينا هذه المشكلة حيث لا يمكنك بسهولة نشر مثيلات تطبيق متعددة على نفس الخادم ، مثل سوف يلتقطون نفس قيم البيئة بحيث لا يمكنك التمييز بين dev / staging / prod.

حقيقة أن IIS10 يدعم تعيينها لكل مجموعة تطبيقات أمر رائع ... إذا كان لديك خادم 2016 متاحًا. أنا أقوم بتشغيل 2012 لذا هذا ليس خيارًا. مرة أخرى ، لم تكن مشكلتي هي أن Microsoft تحاول نقل الأشياء في اتجاه أفضل ، ولكن إسقاط الدعم "القديم" لشيء اعتبره الكثير من الأشخاص أمرًا مفروغًا منه في نشر تطبيقات ASP.NET يبدو لي وكأنه خطأ. بكل الوسائل ، أدخل أنماطًا جديدة وشجع الناس على تبنيها ، لكن لا تقم بإزالة السلوك القديم حتى تكون واثقًا من أن قلة من الناس يحتاجون إليه. وإلا فإن كل ما تفعله هو وضع حواجز للعملاء الذين يريدون dotnet core لكنهم يجدون مسار الترحيل مؤلمًا للغاية.

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

تضمين التغريدة

العيب الخطير هو ، كيف تجعل طريقة "ReadEnvFromWherever" ترجع قيمة مختلفة عند النشر باستخدام Web Publish من 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

هذا لا يختلف عن .NET core الذي يقرأ ASPNETCORE_ENVIRONMENT من متغير النظام أو web.config.

تضمين التغريدة

ولكن كيف تحصل على _env.DEV_ في المجلد الأصلي ، بخلاف نسخه يدويًا؟ أرى ما كنت أحاول أن أقول، ولكن أعتقد أنك في عداد المفقودين النقطة هنا: هناك تستخدم ليكون حلا خارج المربع، والتي عملت فقط. الآن ليس هناك لأنه لم يتم اعتبار دعم الأدوات الخاص به جزءًا من عملية نشر dotnet الأساسية.

لقد حصلت على _لماذا_ تمت إزالته (نظرًا لوجود بدائل أفضل إذا كان لديك عملية CI مناسبة) ، ولكن أعتقد أنه كان قصير النظر جدًا عندما لا يزال الكثير من المستخدمين المرحلين يرغبون في ذلك.

willapp

يمكنك نسخه مرة واحدة أثناء الإعداد الأولي وتنتقل جميع عمليات النشر المستقبلية إلى مجلد bin. لا إعادة تجميع ، لا نشر ، لا تحويل. هذا ما يجب أن يكون عليه الأمر ، يتطلب 3 أسطر إضافية من التعليمات البرمجية ، فماذا في ذلك؟ إنه M $. حتى قبل 3 أشهر ، لا يمكنك الاتصال بـ Active Directory في .NET Core.

ThisNoName هل تتوقع أن يتم التعامل بجدية مع هذه الأشياء M $. أنت تدرك أنه 2018 ، أليس كذلك؟

لا معنى لاقتراحك في سياق نشر الويب على نظام استضافة مشترك. لست متأكدًا حتى مما تجادل معه أو ضده ، تتم إضافة الوظيفة إلى الإصدار التالي من ASP.NET Core بحيث يمكن تحديد متغير البيئة في ملف تعريف النشر ، دون الحاجة إلى أي تحويلات أو أي شيء. ليست هناك حاجة أيضًا إلى الأساليب غير القياسية مع أسماء المجلدات ، والتي قد تكون أو لا تكون تحت سيطرتك.

willapp ،svallis
الحل الذي نشرته قليلاً يعمل في بعض الحالات. يمكنك سحب عنوان URL وتعيين البيئة بناءً على ذلك. في أي بيئة استضافة لديك سيطرة كاملة على عناوين المواقع الخاصة بك. أدرك أن هذا لا يزال "اختراقًا" ، وهو حل بديل - ولكن يجب أن يعمل بشكل عام معظم الوقت. في حالة شركة الاستضافة الخاصة بي ، كان عنوان Url الذي كنت أستقبله مضيفًا محليًا: قاعدة

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

إن اختيار ما إذا كان يجب تحديد البيئة أم لا ضمن التعليمات البرمجية ، أو في وقت النشر ، أو تحديده مسبقًا مباشرة في البيئة في وقت مبكر ليس هو المناقشة التي أحاول معالجتها - أنا ببساطة أقدم حلًا معقولًا لتلك الشركات الصغيرة والمتوسطة / الأفراد الذين لديهم سيطرة محدودة على الاستضافة ويحتاجون إلى إصلاح. في حالتي ، هذا رمز مرة واحدة وانسى - بالضبط ما أحتاجه.

علاوة على ذلك ، يمكنني بسهولة سحب قيم التكوين من ملف appsettings.json دون الحاجة إلى أي تحويلات ، بما في ذلك:

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

في ملف الإعدادات وبه 3 إدخالات لكل تكوين - واحد لكل بيئة. لدي فقط عدد قليل جدًا من التكوينات في هذا الملف ، وبالتالي فإن التكرار ليس مشكلة كبيرة.

أتمنى أن يساعدك هذا!

challamzinniagroup من الأسهل استخدام مسار المجلد النسبي والاسم حسب الاصطلاح.

svallis المفهوم بأكمله هو النشر مرة واحدة والنشر على المستوى الثنائي. لذلك حتى إذا كان بإمكانك تعيين متغير لكل ملف تعريف للنشر ، فهذه ليست الطريقة المثلى.

ThisNoName بالنسبة لك ، ربما يكون الأمر أسهل - لكن لا تفترض مثل هذه الأشياء للآخرين. في حالتي ، لدي إعدادات مطبقة لمسح أدلة الوجهة قبل النشر / النسخ - ولذا بالنسبة للحل الخاص بك ، سأضطر إلى إعادة تحميل كل ملف بيئة يدويًا ، في كل مرة. هذا بالتأكيد ليس أسهل.

تضمين التغريدة كل حالة مختلفة. خلاصة القول هي أن البيئة مجرد متغير ، يمكنك التحكم فيها بأي طريقة تراها مناسبة ، بدلاً من انتظار Microsoft لتقديم أفضل شيء تالي. وأيًا كان ما يتم التوصل إليه ، فهو مجرد حل آخر قائم على الاتفاقية على أي حال - قراءة بعض القيمة من النظام أو 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 ، سأنتظر الإصدار القادم القادم وأحاول استخدامه في إصدار جديد.
أود أن أشير إلى أن حل Frankoffy @ يعمل معي مثل السحر:
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 هل هناك عينة أساسية في مكان ما؟ سيكون من الرائع توجيه الأشخاص إلى ما يعادل hello world باستخدام تحويل أساسي يحدد ASPNETCORE_ENVIRONMENT.

لتعيين ASPNETCORE_ENVIRONMENT ، يمكن للمستخدمين تعيين خاصية msbuild '$ (EnvironmentName)'. سأضيف عينة توضح كيفية تعيين متغيرات env أخرى باستخدام تحويلات web.config.

هنا نموذج الريبو - https://github.com/vijayrkn/webconfigtransform

يحتوي المستند التمهيدي على تفاصيل حول كيفية عمل ذلك:
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 - إذا كنت تريد فقط تعيين "ASPNETCORE_ENVIRONMENT" في web.config ، فكل ما عليك فعله هو إضافة اسم البيئة إلى ملف publishprofile.

مثال:
https://github.com/vijayrkn/webconfigtransform/blob/master/Properties/PublishProfiles/FolderProfile.pubxml#L18

بالنسبة للسيناريوهات المتقدمة (بخلاف إعداد متغير بيئة ASPNETCORE_ENVIRONMENT) ، يمكن تطبيق تحويلات web.config كما هو مذكور في الوثائق أعلاه.

davidfowl - لدى Angelos عنصرًا لتوثيق دعم تحويل web.config.

vijayrkn كيفية استخدامها في CI / CD من TFS؟ لم أتمكن من استخدام dotnet publish مع p: CustomTransformFileName في TFS

يمكنك تمرير هذه الخاصية msbuild لنشر dotnet.

يمكنك الرجوع إلى هذا النموذج هنا - https://github.com/vijayrkn/webconfigtransform/blob/master/publish.cmd

هذا يمرر خاصية CustomTransformFileName إلى نشر dotnet

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

تضمين التغريدة
لقد قرأت وثائقك ولا يمكنني تحويل web.config. لقد جربت بشكل أساسي جميع الأوامر التي لديك في readme.md ولم ينتج عن أي منها التحويل الذي يتم إجراؤه.

ومع ذلك ، فقد تمكنت من كتابة برنامج نصي بوويرشيل يستخدم Microsoft.Web.XmlTransform.dll لإجراء التحويل بشكل منفصل عن عملية النشر.

سؤالي هو ما هو
انا استخدم:
دوت نت - الإصدار 2.1.104
dotnet msbuild - الإصدار 15.6.84.34536

شكرا

تضمين التغريدة
تحتاج إلى تثبيت أي من الإصدارات من هنا حتى تضيء الميزة - 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 مرة واحدة فقط لأي إصدار ( قاعدة الإنشاء dotnet publish وبواسطة أداة إدارة الإصدار.

بعد تعطيل تحويلات web.config باستخدام إعداد <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled> ، تم تخطي TransformWebConfig أيضًا (مع TransformXml) ، مما أدى إلى عدم استبدال المتغيرات %LAUNCHER_PATH% و %LAUNCHER_ARGS% أثناء عملية النشر. هل هناك إعداد للتحكم في هذه الخطوات بشكل مستقل؟

هل يعمل هذا في تطبيق وحدة التحكم مع ملف App.Config؟

هل يمكننا رؤية مثال؟

dmitryshunkov ، يمكنك تعيين $ (RunXdt) على خطأ لتخطي تشغيل تحويل Xml المخصص.

auserx - إذا كان مشروعًا بنمط sdk ، فيجب أن يعمل.