Aspnetcore: Activer les transformations web.config pour les projets AspNetCore dans VS

FWI, je suis d'accord. Nous devons juste être clairs sur le fait que c'est pour les paramètres IIS. L'autre chose est le fait que nous nous sommes éloignés d'un web.config par défaut dans le modèle, il faudrait donc le déterminer.

/cc @sayedihashimi

Est-ce juste pour IIS ? Je pense que le nœud du problème est l'utilisation du point final de la variable ASPNETCORE_ENVIRONMENT pour faire savoir à un site Web dans quel environnement il se trouve.

Je pense qu'un scénario assez courant consiste à héberger divers environnements de préparation/AQ sur la même boîte dans la même instance IIS. Il peut y avoir 3 équipes, toutes avec leurs propres "environnements" sur lesquels elles peuvent se déployer pour tester leur code (par exemple, déployer une branche particulière), mais elles utilisent toutes la même boîte.

Si nous prenons un exemple de code pour savoir comment appsettings.json est commuté par environnement :

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(); }
Le scénario ci-dessus ne fonctionnera pas car la variable d'environnement est à l'échelle du système. Il peut s'agir d'IIS, de nginix, etc. assis devant et l'échange de configuration ne fonctionnera pas.

La plupart du temps, j'ai vu ce qui précède apparaître, des suggestions ont été faites pour utiliser Docker ou utiliser quelque chose comme Puppet/Chef pour gérer la configuration de l'application afin qu'il n'y ait pas de paramètres d'application.{env}.json, mais je pense que cela rend le chemin complet framework MVC d'autant plus difficile.

@mindingdata Vous pouvez réellement contrôler la logique qui détermine d'où vient l'environnement dans votre Program.cs . La variable d'environnement n'est qu'un moyen de le déclarer (le moyen principal). Si vous voulez faire autre chose en fonction d'un fichier magique ou d'une heure de la journée, appelez UseEnvironment(environmentName) sur le WebHostBuidler

Juste pour clarifier, c'est absolument juste pour la configuration IIS. Le système de configuration JSON actuel pour les paramètres d'application est assez bon et je le recommande pleinement.

Pour compliquer davantage les choses : je constate que lorsque j'utilise web.config pour essayer de remplacer le paramètre d'environnement système, cela ne fonctionne tout simplement pas. Lorsque mon paramètre d'environnement système est défini sur "Développement" et que j'essaie de le définir sur "Production" à l'aide de web.config (comme ci-dessous), l'application pense toujours qu'elle s'exécute en développement. (application ASP.NET Core s'exécutant dans IIS).

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

Je pense que c'est le bon endroit. Je construis une démo N-tier et je n'arrive pas à comprendre comment injecter IHostingEnvironment dans mon projet de couche d'accès aux données. Ce projet est l'endroit où j'accède à ma base de données et la seule façon d'obtenir la chaîne de connexion à cette couche était de remplacer la méthode OnConfiguration par une chaîne magique du fichier de configuration.

J'ai également examiné le slow-cheetah, mais cela ressemble à la méthode actuelle de "Debug, Release" ou "Development, Production" selon que vous utilisez la méthode VS ou les variables d'environnement.

Il doit y avoir des informations qui me manquent. MS ne peut pas vouloir que tout le monde crée des applications à un seul niveau.

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

donc y a-t-il eu des progrès à ce sujet?

on devrait pouvoir mettre l'env dans la config d'une app sans recourir à la magie

Oui, j'aimerais aussi progresser là-dessus. Je n'ai actuellement aucune idée de la façon dont je suis censé publier des projets séparés dans la même boîte en utilisant différentes variables d'environnement.

J'ai fini par trouver une solution assez simple. Dans le fichier principal appsettings.json, je précise mon environnement souhaité :

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

Dans Program.CS, je crée ensuite une IConfiguration et définit le nom de l'environnement sur la valeur de 'ActiveEnvironment', avant de charger le fichier de configuration spécifique à l'environnement.

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

De toute évidence, lors de la publication dans différents environnements, l'« Environnement actif » doit être modifié en conséquence.

@DaleMckeown J'allais faire quelque chose de similaire mais j'avais une question sur votre implémentation. Je vois que vous utilisez Microsoft.AspNetCore.WebHost pour créer la configuration par défaut. Cette approche s'applique-t-elle toujours à une application console sans composants Web ?

@Swazimodo Je n'ai pas essayé cette solution dans le contexte d'une application console, donc je ne suis pas sûr. Le mieux est de voir s'il existe un autre moyen de définir les variables d'environnement pour les applications de console.

Nous nous sommes occupés de cela d'une manière différente. Nous configurons notre agent de construction pour prendre
le fichier de paramètres spécifiques à l'environnement et écraser le fichier de paramètres racine
avec ça. Notre build crée un fichier zip séparé pour chaque environnement que nous
déployer sur.

Le jeu. 26 octobre 2017 à 12:48, Dale Mckeown [email protected]
a écrit:

@Swazimodo https://github.com/swazimodo Je n'ai pas essayé cette solution
dans le contexte d'une application console, donc je ne suis pas sûr. Le meilleur pari c'est
voir s'il existe un autre moyen de définir les variables d'environnement pour
applications consoles.

-
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/aspnet/Home/issues/2019#issuecomment-339728441 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/AAx4bT20JSb0XSzNBIAiiubq9mTVKbW5ks5swLf6gaJpZM4NMx25
.

Il semble que toutes les solutions nécessitent une sorte d'ajustement après la construction/la publication ? J'ai fini par déposer un fichier texte vide dans la racine de l'application et le transmettre en tant qu'environnement. Est-ce que j'ai manqué quelque chose?

Tout à fait d'accord avec le premier post. C'est par conception assez flexible, mais à la fin, il s'est avéré très difficile à automatiser. Par exemple, j'ai une application que je publie sur IIS sur un autre serveur. Il fonctionne également sur IIS local (via la publication de dossier). J'ai donc défini l'environnement de développement dans web.config. Mais ensuite, je dois le changer en Production ou autre pendant la publication. Tâche assez courante je suppose. Je crois que c'est impossible, non? Je dois éditer manuellement web.config sur des serveurs distants.

Idéalement, la configuration de l'environnement doit être prise en charge via "dotnet publish" (pour toute cible de publication) :

dotnet publish ... -environment=Production

dotnet publish pourrait rechercher des fichiers web.%Enviroment%.config (Web.Production.config, Web.Development.config) et les fusionner (transformer) avec web.config. À la fin, nous aurions la valeur correcte de ASPNETCORE_ENVIRONMENT :

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

@evil-shrike jetez un œil à https://github.com/nil4/dotnet-transform-xdt pour les transformations de configuration de temps de build/publish.

Un cas d'utilisation, peut-être. J'ai besoin que les journaux soient écrits dans .\App_Data car mon exécuteur d'application a un accès en lecture/écriture à tout sous .\App_Data, mais ne peut lire que tout le reste sous .\ . J'utilise le déploiement Web et j'aimerais pouvoir déployer un fichier web.config comme celui-ci avec le dossier des journaux sous 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>

Vous pourriez vous demander pourquoi ne pas simplement mettre ces paramètres dans un fichier web.config au lieu de web.release.config ? Eh bien, processPath=".\<executable>.exe" n'est pas là où réside l'exécutable lorsque je développe localement contre IIS Express. J'obtiens donc la bonne vieille erreur "Erreur HTTP 502.5 - Échec du processus".

Nous automatisons nos builds à l'aide de Jenkins et notre façon actuelle de configurer vars par environnement dans les projets NetFramework consiste à utiliser les transformations web.config. Nous avons donc pensé que nous pourrons également le faire dans dotnet.

Il s'avère que msbuild est toujours compatible avec aspnet core csproj pour effectuer des transformations web.config !

Nous pouvons ajouter la tâche de publication TransformXml dans le csproj Asp.Net Core :

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

Ajoutez les cibles de transformation spécifiques :

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

Faites quelques transformations, par exemple sur la variable ASPNETCORE_ENVIRONMENT dans le 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>

Transformez web.config en utilisant msbuild avant d'exécuter la publication :

msbuild Test.csproj /t:ConfigDev

« Laissez-moi préfixer cela en disant que je ne suis pas un fan de web.config mais que l'expérience de la publication d'applications AspNetCore sur IIS est vraiment médiocre. »

Je ne pourrais pas être plus d'accord avec ce fil.

Après la simplicité des transformations de configuration dans ASP.Net ordinaire, toute cette dépendance à une variable ASPNETCORE_ENVIRONMENT à l' échelle de la

Même les propres exemples de Microsoft disent que nous pouvons utiliser, disons, un fichier _appsettings.Production.json_, simplement en ajoutant cette ligne...

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

...mais il ne fait aucune attention au NOM de la configuration que nous avons choisie. Ainsi, même lorsque j'ai choisi ma configuration de production, il essaiera toujours d'ouvrir appsettings.development.json. Et non, je ne veux pas avoir à modifier manuellement la variable ASPNETCORE_ENVIRONMENT moi-même chaque fois que je publie dans un environnement différent. C'est juste demander des ennuis.

Je n'ai pas encore vu d'exemple simple et fonctionnel d'utilisation des fichiers _appsettings.XXXX.json_.
J'ai hâte que ce truc soit enfin terminé. (Soupir...)

Oui, corrigez ça s'il vous plait !!

Je viens de déployer mon premier site principal dotnet de production et je suis maintenant confronté au problème que je ne peux pas facilement avoir une instance de transfert sur le même serveur car je ne sais pas comment publier mon application sur la même boîte sans qu'elle ne récupère le paramètres de fabrication.

Je pense que je vais essayer la solution @DaleMckeown pour le moment, je pense que cela fonctionnera mais cela ressemble à une solution de contournement plutôt qu'à une solution. Les variables d'environnement sont excellentes, mais UNIQUEMENT si vous avez un ratio de serveurs par environnement de 1 à 1, et en dehors de l'entreprise, je doute que cela se produise souvent.

@willapp Ma suggestion est certainement une solution de contournement. Mais cela fonctionne - j'ai plusieurs versions de la même application exécutées sur le même serveur depuis un certain temps maintenant et je n'ai eu aucun problème.

N'oubliez pas de modifier le paramètre « Environnement actif » avant de publier et tout devrait bien se passer.

Je suis confronté exactement à ce que dkent600 a mentionné :

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

ne fonctionne pas sur le serveur de production. L'application continue d'utiliser les valeurs "appsettings.Development.json", ce qui, en fin de compte, annule les avantages de la transformation XML lors de la publication.

Je vais essayer la solution de contournement suggérée par DaleMckeown.

le seul moyen raisonnable de changer ASPNETCORE_ENVIRONMENT est d'utiliser web.config

Pas vraiment. Si vous devez exécuter plusieurs instances du même site sur la même machine, voici un moyen beaucoup plus simple

• MonSiteCore
  
  
  
  • poubelle
  
  
  • journaux
  
  
• env.Peu importe

Pointez votre application IIS sur bin et dans program.cs

.UseEnvironment(ReadEnvExtensionFromParentFolder())

C'est ça. Vous pouvez avoir autant de sites que vous le souhaitez, les déployer dans bin sans vous soucier de la transformation et même changer d'environnement en renommant env.Whenver.

Je vote pour ça. J'ai des réécritures d'URL configurées pour le serveur de production qui ne fonctionnent pas dans l'environnement de test. Je n'ai pas trouvé de moyen de publier pour sélectionner le bon fichier web.config pour le déploiement, je dois le copier manuellement.

Jetez un œil à https://github.com/nil4/xdt-samples/ et à l' outil CLI pour appliquer les transformations au moment de la publication .

Y a-t-il des progrès à ce sujet? Cela fait 13 mois depuis le rapport initial, 2.1.0 est là maintenant, et les choses sont encore assez pauvres avec l'hébergement IIS traditionnel. Les choses fonctionnent à merveille si vous utilisez Azure, mais ce n'est actuellement pas une option pour une grande partie des sites que j'héberge.

Il semble que pour l'hébergement IIS traditionnel, il serait avantageux de définir l'environnement souhaité sur la ligne de commande (comme @evil-shrike présenté ci-dessus), ainsi que dans tous les profils de publication .pubxml . Comme @davidfowl l'a dit, il devrait être clair que cela ne fonctionnerait web.config et IIS, mais cela couvre sûrement encore une partie substantielle de la base d'installation.

Pour le moment, j'ai une solution très fragile utilisant la traduction de Microsoft.DotNet.Xdt.Tools et web.config , mais elle nécessite une configuration de build par environnement pour fonctionner et vient de se briser après la mise à jour vers la v2.1.0.

Ce serait formidable de savoir s'il existe des projets dans ce domaine et, si oui, quels sont-ils ? S'il n'y a pas de plans, ou s'ils sont loin, alors il y a sûrement une meilleure solution provisoire que les moyens fragiles/semi-manuels que nous sommes actuellement obligés d'employer ? Surtout pour le déploiement vers l'assurance qualité et la mise en scène, j'aimerais vraiment pouvoir appuyer simplement sur un bouton dans VS et savoir que la bonne chose se passe, et ne pas avoir à dépendre des connaissances en chef et des processus manuels.

Nous n'avons aucun projet pour le moment, mais cet outil https://github.com/nil4/xdt-samples/ de @nil4 a l' air plutôt bien.

@svallis as-tu essayé?

Est-ce que la principale chose que les gens veulent définir l'environnement?

@davidfowl Oui, ma solution actuelle utilise l'outil que vous avez lié, mais pour un projet avec plusieurs destinations à publier, il faut une configuration de build par environnement. Vous avez besoin des différentes configurations de construction afin d'avoir quelque chose sur quoi vous accrocher dans la configuration csproj , et pour mes besoins, il s'agit généralement d'une relation 1 à 1 avec vos environnements. Par example:

• Configuration de build : Débogage = Environnement : Développement
• Configuration de build : Staging = Environnement : Staging
• Configuration de build : Release = Environnement : Production

Pour les deux derniers, j'ai alors les web.{Build configuration}.config et appsettings.{Environment}.json , et le web.{Build configuration}.config est littéralement juste un XDT pour dire au web.config de se retrouver avec le variable d'environnement ASPNETCORE_ENVIRONMENT appropriée. Ainsi, par exemple, en poursuivant l'exemple ci-dessus, web.Release.config ressemble à ceci :

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

En fait, tout fonctionne assez bien à partir de la ligne de commande. L'exécution de dotnet publish -c Staging ou autre produit un dossier avec la sortie correcte et le web.config transformé selon les besoins. On a quand même l'impression que cela pourrait être simplifié. S'il y avait un commutateur -iisenvironment sur dotnet publish qui faisait cela pour nous, et qu'il était ensuite exposé comme une simple zone de texte dans la publication VS, cela supprimerait le besoin de gérer les configurations de build, XDT, etc manuellement pour les situations d'hébergement IIS traditionnelles.

Cependant, au sein de VS, cela semble actuellement problématique. Cependant, nous ne sommes actuellement pas du tout en mesure de publier à partir de VS, et même lorsque cela fonctionnait sur la version 2.0.0, nous devions sélectionner manuellement la configuration de construction correcte avant la publication.

@davidfowl De mon point de vue, idéalement, j'aimerais définir l'environnement dans le cadre du profil de publication lors de l'utilisation de Web Deploy.

J'appuierais cela, une option sur la publication serait idéale. Je n'utilise même pas la solution de contournement décrite par @svallis car je préfère publier via l'IDE VS et non la ligne de commande.

@willapp La solution que j'utilise fonctionne dans Visual Studio, mais j'ai d'autres problèmes avec la solution avec laquelle je teste qui causent des problèmes dans VS (https://github.com/aspnet/Home/issues/3190) . Désolé si je n'ai pas été clair. Tout est configuré à l'aide d'outils dans le csproj , que la ligne de commande et VS doivent respecter.

J'ai enfin essayé l'outil suggéré ci-dessus par

Il suffit de suivre les instructions ici https://github.com/nil4/dotnet-transform-xdt dans la section "Outil au niveau du projet" (puisque je ne suis pas encore sur 2.1.0). J'ai dû créer moi-même un Web.config par défaut car je ne l'avais pas (je l'ai juste copié à partir de celui que VS génère lorsque vous déployez), puis j'ai créé un Web.Debug.config avec une transformation pour définir ASPNETCORE_ENVIRONMENT sur Development, et hé presto! Il déploie la config transformée et le site démarre maintenant correctement.

Ce serait bien si le soutien pour cela était officialisé, mais pour l'instant, cela fait le travail.

@davidfowl Le lien que vous avez indiqué nécessite une publication à l'aide de la ligne de commande. Je souhaite publier à l'aide de l'outil GUI VS. Je ne veux pas que mes développeurs aient besoin d'installer des outils CLI pour publier le projet. Il ne sert à rien de pouvoir spécifier ASPNETCORE_ENVIRONMENT dans web.config si les transformations ne sont pas prises en charge. En voyant combien de votes positifs ce problème a, il devrait aller dans le backlog.

@orobert91 VS n'est qu'une interface graphique enroulée autour des outils de ligne de commande. J'utilise avec succès https://github.com/nil4/xdt-samples/ pour transformer le web.config lors de la publication à partir de VS. Si vous le configurez correctement pour votre projet, il se transformera correctement à la fois depuis la ligne de commande et dans votre IDE.

@svallis En effet,

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

Il existe une propriété msbuild qui publie les honneurs pour le nom de l'environnement -

$(EnvironmentName)

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

À l'heure actuelle, lorsque cette propriété est définie, tout ce que nous faisons est de créer appsettings.$(EnvironmentName).json et d'ajouter les informations de chaîne de connexion à ce fichier (si demandé).

À l'avenir, lorsque cette propriété est définie lors de la publication, nous pouvons également mettre à jour le fichier web.config publié pour avoir également l'entrée suivante :

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

Cela fonctionnerait-il pour la plupart des scénarios mentionnés ici ?

Pour les scénarios en dehors de la définition de la variable d' environnement, nous examinerons la faisabilité du portage des transformations web.config (

J'ai trouvé une solution qui semble couvrir les scénarios dont j'ai besoin - je voulais la poster ici au cas où elle serait utile à quelqu'un d'autre.

Dans mon cas, j'ai mon environnement de développement localement et mes environnements de développement et de production sur un serveur distant (même serveur). J'ai pu extraire l'URL de l'application du IApplicationBuilder et l'utiliser dans une instruction switch pour définir la EnvironmentName .

Cela semble beaucoup moins "solution de contournement" que certaines des autres solutions proposées, mais dépend certainement de la préférence.

En Startup.cs :

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

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

La méthode ci-dessus est une extension que j'ai créée en fonction de la collection de propriétés dans le IApplicationBuilder . La méthode d'extension (et la classe) ressemblent à ceci :

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

J'espère que cela pourra être utile aux gens (dans les cas où une transformation web.config n'est pas souhaitable).

Acclamations!

Je marque ce problème comme une discussion car aucune fonctionnalité/correction liée à cela n'est prévue pour le moment. Si des personnes ont encore des demandes de fonctionnalités spécifiques, veuillez signaler les problèmes pour celles-ci et nous donnerons la priorité.

Je n'étais pas vraiment satisfait des solutions de contournement que j'ai vues sur ce fil, j'ai donc adopté une approche différente. Je suis tombé sur ce fil Stack Overflow : https://stackoverflow.com/questions/31049152/publish-to-iis-setting-environment-variable/36836533#36836533. Il parle de modifier ApplicationHost.config sur le serveur comme un endroit pour stocker la variable ASPNETCORE_ENVIRONMENT.

Nos serveurs IIS internes sont gérés par notre équipe d'exploitation, de sorte que les développeurs de notre organisation ne créent de toute façon pas ces sites. L'équipe des opérations utilise un script PowerShell pour créer ces sites. Je leur ai juste demandé de modifier ce script afin qu'il apporte également les modifications pertinentes à ApplicationHost.config au moment où le site est mis en service. Maintenant, je peux simplement déployer là-bas et ne pas me soucier de la gestion de l'environnement .NET Core. A bien fonctionné pour notre situation.

Je pense que dans un véritable environnement DevOps, vous utiliseriez probablement Azure de toute façon, ce qui facilite la définition de la variable d'environnement.

Avec le dernier Sdk, vous pouvez simplement passer la propriété msbuild $(EnvironmentName) et les outils se chargeront de définir ASPNETCORE_ENVIRONMENT sur cette valeur.

par exemple : si EnvironmentName est défini sur staging, alors web.config aura l'entrée suivante :

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

PR avec le correctif :
https://github.com/aspnet/websdk/pull/377

@vijayrkn Cela ressemble à un début prometteur. Cela finira-t-il par avoir une prise en charge intégrée dans les profils VS WebDeploy/publish, etc. ?

À l'heure actuelle, nous n'avons pas d'interface utilisateur dans VS pour faire cette sélection de nom d'environnement, mais si cela est ajouté au fichier de projet ou au pubxml, la publication à partir de VS et de la ligne de commande l'honorera.

Nous allons également envisager d'ajouter la prise en charge de l'interface utilisateur pour cela.

@vijayrkn Ceci n'est qu'une solution pour ceux qui publient avec un fichier web.config - est-ce correct ?

@vijayrkn Oui, obtenir un support dans le format pubxml serait le moment où cela deviendrait utile pour notre cas d'utilisation. À ce stade, nous pourrions supprimer tous les éléments de transformation XML et spécifier simplement les chaînes d'environnement appropriées dans chaque pubxml . Le support de l'interface utilisateur pourrait arriver à une date ultérieure, mais ce ne serait que la cerise sur le gâteau.

@challamzinniagroup - Non, vous n'avez pas besoin de web.config pour cette fonctionnalité.
Tout ce que vous avez à faire est d'ajouter ce qui suit au fichier pubxml et les outils de publication s'occuperont du reste.

<EnvironmentName>YourCustomEnvironment</EnvironmentName>

@challamzinniagroup , @vijayrkn

À moins que vous n'ayez une configuration qui ne peut être effectuée que dans web.config et doit être transformée entre les environnements, sinon, laissez web.config seul. Avec 2 lignes de code, vous pouvez lire les variables d'environnement de n'importe où. Et vous n'avez pas besoin de peaufiner le profil de publication ou le code publié, juste la liste des appsetting.XYZ.json correspondants

@ThisNoName

Vous voulez dire comme les chaînes de connexion à la base de données, les points de terminaison de service, les informations d'identification ou tout autre nombre d'autres éléments qui pourraient changer de dev->staging->production.

Si vous exécutez plusieurs instances sur le même environnement ( très courant en dehors du cloud), vous avez absolument besoin de la flexibilité des transformations web.config. Il est assez ridicule que Microsoft n'ait pas répondu à cette exigence avec dotnet core, ils ont simplement supposé que tout le monde hébergeait dans Azure et avait une relation 1-1 entre l'instance et l'environnement.

Les variables d'environnement sont en fait nulles en dehors du cloud, car vous vous retrouvez avec une configuration distincte de votre application, ce qui rend plus difficile la gestion des déploiements à l'arrêt.

Le changement majeur ici est que ces secrets ne doivent jamais être stockés dans le contrôle de source et doivent plutôt être configurés sur l'environnement lui-même. Les transformations vont à l'encontre des bonnes pratiques car elles supposent que vous compreniez la cible de déploiement au moment de la publication, ce qui n'est pas toujours le cas (surtout lorsque vous avez plusieurs environnements). Avez-vous vraiment besoin de redéployer lorsque vous modifiez un paramètre de configuration pour l'un de ces N déploiements ?

Maintenant, la partie malheureuse est qu'avec IIS, les variables d'environnement doivent être configurées dans le fichier de configuration afin que le pool d'applications puisse les voir. Je ne pense pas que nous ayons jamais voulu que les gens configurent une configuration à l'échelle de la machine sur des machines cibles (bien que j'aie vu des gens le faire).

@willapp Pourquoi n'utilisez-vous pas appsettings.json ?

@willapp

M$ a la solution parfaite, mais la plupart des gens s'en tiennent au concept de transformation web.config.

Voici une façon d'avoir plusieurs sites côte à côte. Il vous suffit de lancer votre valeur d'environnement n'importe où en dehors du répertoire binaire IIS et de la lire/définir à partir de program.cs

• IISRoot
  
  
  
  • MonSiteDEV
  
  
  • poubelle
    
    
    
    
    
    • appsettings.json
    
    
    
    • appsettings.DEV.json
    
    
    
    • appsettings.PROD.json
    
    
    
    • web.config
    
    
    
  
  
  • journaux
  
  
  • env.DEV
  
  
  • MonSitePROD
  
  
  • poubelle
    
    
    
    
    
    • appsettings.json
    
    
    
    • appsettings.DEV.json
    
    
    
    • appsettings.PROD.json
    
    
    
    • web.config
    
    
    
  
  
  • journaux
  
  
  • env.PROD
  
  

@davidfowl

Êtes-vous en train de dire aux gens qu'il est regrettable que le noyau ASP.NET ne fonctionne pas correctement avec IIS ? En tant qu'architecte Microsoft .NET Core ?

Le changement de paradigme ici avec tout ce que Core est multi-plateforme. IIS est clairement un utilitaire Windows - et il faut donc s'attendre à des difficultés de croissance. Des solutions de contournement, dans un cas comme celui-ci, doivent être attendues et acceptées à mesure que les choses avancent. Avoir fait des choix de conception intentionnels dans Core pour prendre en charge une fonctionnalité Windows aurait été contre-intuitif imo.

Modifier pour ajouter :
Ceci étant une réflexion sur la question de savoir si Core devrait avoir un meilleur support prêt à l'emploi pour IIS. La discussion sur l'utilisation de variables d'environnement étant une bonne alternative malgré...

@davidfowl

Et c'est exactement la différence entre l'architecture d'entreprise et les PME. Je travaille pour un FTSE100 et oui, séparer le déploiement du code a du sens, mais je gère également plusieurs sites indépendamment et c'est juste plus facile et plus rentable d'avoir un seul serveur sur lequel j'héberge tous mes sites. L'utilisation de Web Deploy + Transforms est un mécanisme éprouvé pour les modifications du code de livraison, cela fonctionne tout simplement. Je ne dis pas qu'il n'y a pas de meilleures alternatives dans certains cas, mais Microsoft aurait dû continuer à prendre en charge les transformations, sachant que la plupart des utilisateurs veulent se familiariser lors de la migration du framework .net vers le noyau.

J'ai maintenant ma solution du début de ce fil, donc je suis assez content. Je pense juste qu'ils ont un peu laissé tomber la balle sans inclure cela par défaut.

@willapp

Je pense que la transformation est basée sur l'idée de compiler à partir de la source et de publier séparément pour chaque environnement. Je suis content que M$ l'ait abandonné car l'alternative est tellement plus élégante.

Avec la nouvelle configuration, vous ne publiez votre code qu'une seule fois à l'aide de Release config. Toutes les instances en cours d'exécution sont des copies binaires identiques de l'original. Le déploiement doit être une simple synchronisation de fichiers avec l'environnement suivant DEV=>TEST=>Staging=>PROD.

Êtes-vous en train de dire aux gens qu'il est regrettable que le noyau ASP.NET ne fonctionne pas correctement avec IIS ? En tant qu'architecte Microsoft .NET Core ?

Je dis que les gens ne pensent pas immédiatement au fait que les variables d'environnement utilisées comme celle-ci sont censées être par processus au lieu de par machine. Historiquement, sur Windows, les utilisateurs identifient les variables d'environnement comme étant à l'échelle de la machine plutôt que par processus, ce qui a causé de la confusion. IIS 10 a ajouté la prise en charge de l'ajout de variables d'environnement par pool d'applications. Le module ASP.NET Core prend également en charge la définition de variables d'environnement par processus.

Pourtant, cette capacité a été là. Je pense qu'il y a surtout eu un changement philosophique dans la pensée ici. Nous ne voulons rien faire qui facilite la spécification des secrets au moment du développement.

@challamzinniagroup bon résumé

Ceci étant une réflexion sur la question de savoir si Core devrait avoir un meilleur support prêt à l'emploi pour IIS. La discussion sur l'utilisation de variables d'environnement étant une bonne alternative malgré...

À droite. Le flux de travail pour la configuration des informations spécifiques à l'environnement doit toujours être sur l'environnement spécifique. La question est de savoir comment y parvenir. Cela fait-il partie du déploiement ?

Cela dit, je pense que nous ajoutons un support pour cela dans l'outillage dans 2.2.

cc: @vijayrkn

@davidfowl

Lorsque vous dites « Historiquement sur Windows, les utilisateurs identifient les variables d'environnement comme étant à l'échelle de la machine au lieu de par processus », voulez-vous dire les variables d'environnement Windows, comme dans la ligne de commande SET ?

Parce que ma compréhension de "l'environnement" dans le contexte de base .NET n'est qu'une variable. Par défaut, il lit ASPNETCORE_ENVIRONMENT à partir du système ou de web.config. Mais vous pouvez l'écraser et l'obtenir à partir de n'importe quelle source par n'importe quelle convention.

Y a-t-il quelque chose de fondamentalement mauvais dans cette approche? Parce que si la position officielle de l'équipe Microsoft .NET est de ne pas le faire, nous devrions sérieusement reconsidérer. Mais vous finiriez par dire aux gens d'exécuter .NET core sous IIS, mais malheureusement, il n'y a pas de moyen simple de configurer ces applications. J'espère que ce n'est pas le cas.

Merci.

@ThisNoName

Lorsque vous dites « Historiquement sur Windows, les utilisateurs identifient les variables d'environnement comme étant à l'échelle de la machine au lieu de par processus », voulez-vous dire les variables d'environnement Windows, comme dans la ligne de commande SET ?

Oui, c'est exactement le sujet de ce fil. (Voir ici ). Comme le dit David, ceux-ci peuvent être par processus, mais d'après mon expérience, la plupart de la documentation sur dotnet core suppose que vous les définissez au niveau de la machine, nous avons donc ce problème où vous ne pouvez pas facilement déployer plusieurs instances d'application sur le même serveur, comme ils récupéreront les mêmes valeurs d'environnement, vous ne pourrez donc pas faire la distinction entre dev/staging/prod.

Le fait qu'IIS10 prenne en charge leur configuration par pool d'applications est génial... si vous avez Server 2016 disponible. Je cours 2012 donc ce n'est pas une option. Encore une fois, mon problème n'est pas que Microsoft essaie de faire avancer les choses dans une meilleure direction, mais abandonner la prise en charge « héritée » de quelque chose que beaucoup de gens tenaient pour acquis lors du déploiement d'applications ASP.NET me semble être une erreur. Par tous les moyens, introduisez de nouveaux modèles et encouragez les gens à les adopter, mais ne supprimez pas le comportement hérité jusqu'à ce que vous soyez sûr que peu de personnes en ont besoin. Sinon, tout ce que vous faites, c'est mettre des barrières pour les clients qui veulent dotnet core mais trouvent le chemin de migration trop pénible.

@willapp

C'est juste le paramètre par défaut prêt à l'emploi. Vous pouvez lire et définir l'environnement comme vous le souhaitez. C'est du moins ce que j'ai compris, à moins que quelqu'un ne signale une faille sérieuse dans cette approche ?

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

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

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

@ThisNoName

La faille sérieuse est la suivante : comment faire en sorte que la méthode "ReadEnvFromWherever" renvoie une valeur différente lors du déploiement à l'aide de la publication Web à partir de VSTS, en fonction de la configuration de votre solution ? Je suppose que vous pourriez utiliser des directives de préprocesseur (#if RELEASE ...) mais cela semble assez sale.

Dans le « vieux monde » (framework complet ASP.NET), vous créez un profil de publication, dont une partie consiste à sélectionner une configuration de solution à créer. Sur la base de cette configuration, il a ensuite appliqué une transformation de configuration qui vous a permis de spécifier une configuration différente selon que vous publiiez ou non sur dev/staging/prod.

J'accepte que ce workflow ne rentre pas dans un pipeline CI moderne, où vous prenez un seul package de build et le poussez dans chaque environnement - dans ce cas, vous voulez quelque chose comme le pipeline de version VSTS pour injecter des paramètres au moment du déploiement, ou vous amorcez votre instance de serveur avec les bonnes variables d'environnement, auquel cas vous déposez simplement le package sur la boîte et cela fonctionnera automatiquement comme par magie. Encore une fois, je pense que beaucoup de PME et de groupes individuels ne sont pas à cet endroit et souhaitent un processus de déploiement à partir de Visual Studio qui produit le résultat souhaité.

Juste pour ajouter que cela est également important pour le déploiement de petits projets sur des plates-formes d'hébergement partagé qui s'exécutent sur IIS et offrent traditionnellement un hébergement ASP.NET. Ils n'ont aucune possibilité de définir des variables d'environnement par site Web via leurs panneaux de contrôle d'hébergement, et la seule approche réaliste consiste donc à utiliser des transformations et le web.config .

Il semble que tout cela aura une solution décente dans la prochaine version, et avec la prise en charge intégrée de VS un peu plus loin. Espérons que cela soutiendra les personnes ayant des flux de travail existants qui reposent sur cette fonctionnalité jusqu'à ce que les fournisseurs d'hébergement et les systèmes hérités puissent être mis à niveau ou améliorés.

@willapp

Par convention. Si vous suivez l'exemple que j'ai posté plus tôt, vous pouvez lire env.DEV à partir du dossier parent et utiliser l'extension de fichier comme variable d'environnement. Mais vous pouvez utiliser n'importe quelle convention, comme nommer la racine de votre application comme MySiteDEV, MySitePROD, etc. et analyser le nom du dossier pour obtenir le nom de l'environnement.

Si votre code varie selon l'environnement, vous pouvez lire la valeur de l'environnement à partir de IHostingEnvironment .EnvironmentName

Il n'y a aucune différence par rapport au noyau .NET qui lit ASPNETCORE_ENVIRONMENT à partir de la variable système ou de web.config.

@ThisNoName

Mais comment obtenir _env.DEV_ dans le dossier parent, à part le copier manuellement ? Je vois ce que vous essayez de dire, mais je pense que vous manquez le point ici : il y avait autrefois une solution prête à l'emploi qui fonctionnait tout simplement. Maintenant, il n'y en a plus car la prise en charge des outils n'a pas été considérée comme faisant partie du processus de déploiement de dotnet core.

Je comprends _pourquoi_ il a été supprimé (parce qu'il existe de meilleures alternatives si vous avez un processus CI décent), mais je pense que c'était assez myope alors que de nombreux utilisateurs migrant le voudraient toujours.

@willapp

Vous le copiez une fois lors de la configuration initiale et tous les futurs déploiements vont dans le dossier bin. Pas de recompilation, pas de publication, pas de transformation. C'est comme ça que ça devrait être, ça prend 3 lignes de code supplémentaires, et alors ? C'est M$. Jusqu'à il y a 3 mois, vous ne pouviez même pas appeler Active Directory dans .NET Core.

@ThisNoName Vous attendez-vous à être pris au sérieux avec ce truc M$. Tu te rends compte que c'est 2018, n'est-ce pas ?

Votre suggestion n'a aucun sens dans le contexte d'un déploiement Web sur une plate-forme d'hébergement partagé. Je ne sais même pas ce que vous argumentez pour ou contre, la fonctionnalité est ajoutée dans la prochaine version d'ASP.NET Core afin qu'une variable d'environnement puisse être spécifiée dans le profil de publication, sans avoir besoin de transformations ou quoi que ce soit. Il n'y a pas non plus besoin d'approches non standard avec des noms de dossier, qui peuvent ou non être sous votre contrôle.

@willapp , @svallis
La solution que j'ai postée un peu plus haut fonctionne dans certains cas. Vous pouvez extraire l'URL et définir l'environnement en fonction de cela. Dans n'importe quel environnement d'hébergement, vous avez le contrôle total de vos URL. Je me rends compte que c'est toujours "hackish", et une solution de contournement - mais cela devrait généralement fonctionner la plupart du temps. Dans le cas de ma société d'hébergement, l'URL que je recevais était une base localhost:port ("127.0.0.1:7777") - cela s'est donc avéré ne pas être idéal pour moi. Mais j'ai également la possibilité de définir des chemins de dossier racine sur mes différents environnements car je les ai configurés en tant que sous-domaines - et extraire le chemin de l'application racine est également assez simple :

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

Le choix de savoir si l'environnement doit être déterminé ou non dans le code, au moment du déploiement ou prédéfini directement dans l'environnement à l'avance n'est pas la discussion que j'essaie d'aborder - j'offre simplement une solution raisonnable pour les PME/ les personnes qui ont un contrôle limité sur l'hébergement et ont besoin d'un correctif. Dans mon cas, il s'agit d'un code à usage unique - exactement ce dont j'ai besoin.

Plus loin en aval, je peux facilement extraire les valeurs de configuration d'un fichier appsettings.json sans avoir besoin de transformations en incluant simplement :

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

dans le fichier de paramètres et ayant 3 entrées par configuration - une pour chaque environnement. Je n'ai qu'un très petit nombre de configs dans ce fichier et donc la duplication n'est pas un gros problème.

J'espère que cela t'aides!

@challamzinniagroup Il est plus facile d'utiliser le chemin et le nom relatifs du dossier par convention.

@svallis Le concept est de publier une fois et de déployer au niveau binaire. Donc, même si vous pouvez définir une variable par profil de publication, ce n'est pas la voie à suivre.

@ThisNoName Pour vous, c'est peut-être plus facile - mais ne supposez pas de telles choses pour les autres. Dans mon cas, j'ai mis en place des paramètres pour effacer les répertoires de destination avant de publier/copier - et donc pour votre solution, je devrais télécharger à nouveau chaque fichier d'environnement manuellement, à chaque fois. Ce n'est certainement _pas_ plus facile.

@challamzinniagroup D'accord. Chaque situation est différente. L'essentiel est que l'environnement n'est qu'une variable, vous pouvez le contrôler comme bon vous semble, au lieu d'attendre que Microsoft fournisse la prochaine meilleure chose. Et quoi qu'ils arrivent, ce n'est de toute façon qu'une autre solution basée sur des conventions - lire une valeur à partir du système ou de web.config et définir l'environnement.

BTW, vous pouvez toujours utiliser la convention. Rien ne dit que les paramètres d'application doivent utiliser un seul mot intermédiaire et que la mise en scène/production n'a pas de signification particulière. Vous pouvez facilement faire quelque chose comme ceci et transmettre le nom du dossier correspondant.

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

Avec une solution basée sur les conventions, vous pouvez lancer de nouvelles instances sans avoir à recompiler et/ou republier.

@vijayrkn pourriez-vous s'il vous plaît en dire plus sur l'utilisation de pubxml ?
J'ai mis à niveau mon SDK vers 2.1.302 (x64) j'ai changé mon pubxml mais je ne vois aucune différence sur web.config publié.

@wggley - Le correctif n'est pas disponible dans 2.1.302. Il devrait être disponible dans la prochaine version à venir.

Vous pouvez essayer la version d'aperçu du cli contenant le correctif à partir d'ici - https://dotnetcli.blob.core.windows.net/dotnet/Sdk/release/2.1.4xx/dotnet-sdk-latest-win-x64.exe

Faites-moi savoir si vous rencontrez des problèmes avec la version d'aperçu ci-dessus.

Merci @vijayrkn J'attendrai la prochaine version à venir et j'essaierai de l'utiliser sur une nouvelle publication.
Je tiens à souligner que la solution @frankhoffy a fonctionné pour moi comme un charme :
https://stackoverflow.com/questions/31049152/publish-to-iis-setting-environment-variable/36836533#36836533
Recherchez la première réponse (réponse la plus votée).

La prise en charge de la transformation de la configuration Web pendant la publication est désormais disponible dans l'aperçu 2.21 https://www.microsoft.com/net/download/dotnet-core/2.2

@vijayrkn existe-t-il un échantillon de base quelque part ? Ce serait formidable de diriger les gens vers l'équivalent hello world en utilisant une transformation de base qui définit ASPNETCORE_ENVIRONMENT.

Pour définir ASPNETCORE_ENVIRONMENT, les utilisateurs peuvent définir la propriété msbuild '$(EnvironmentName)'. J'ajouterai un exemple qui montre comment définir d'autres variables d'environnement à l'aide des transformations web.config.

Voici un exemple de dépôt - https://github.com/vijayrkn/webconfigtransform

Lisez-moi a des détails sur la façon dont cela fonctionne :
https://github.com/vijayrkn/webconfigtransform/blob/master/README.md

J'espère que cela t'aides!

@Eilon - Nous pouvons clore ce problème. Ceci est corrigé et disponible dans le dernier aperçu.

@vijayrkn Il n'est pas clair comment configurer les paramètres de publication pour définir l'environnement à partir de la boîte de dialogue Paramètres de publication ? Que peut-on réellement changer dans cette boîte de dialogue pour distinguer un site intermédiaire d'un site de production, si les deux sites sont déployés sur le même serveur ?

Cet aspect du noyau .NET semble très désordonné. Il doit être beaucoup plus facile de spécifier l'environnement dossier par dossier. Une variable d'environnement de serveur entier ne peut pas du tout fonctionner pour notre situation. Tout le monde ne peut pas exécuter ses sites de transfert sur des serveurs différents de ses sites de production.

Le réglage est par application.

Désolé mais cela ne répond pas vraiment à ma question. Peut-être que j'ai mal compris quelque chose.

Il y a une pseudo documentation ici https://github.com/vijayrkn/webconfigtransform/blob/master/README.md ( @vijayrkn nous devons l'

@vijayrkn Quelle est la prise en charge de cela dans la boîte de dialogue de publication ?

Actuellement, la boîte de dialogue de publication ne prend pas en charge la définition des environnements de publication, mais les environnements peuvent être définis manuellement dans le profil de publication ou des transformations spécifiques peuvent être appliquées.

@nmg196 - Si vous souhaitez simplement définir 'ASPNETCORE_ENVIRONMENT' dans web.config, il vous suffit d'ajouter le nom de l'environnement au profil de publication.

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

Pour les scénarios avancés (autres que la définition de la variable d'environnement ASPNETCORE_ENVIRONMENT), les transformations web.config peuvent être appliquées comme mentionné dans la documentation ci-dessus.

@davidfowl - Angelos a un élément pour documenter la prise en charge de la transformation web.config.

@vijayrkn Comment utiliser dans CI/CD de TFS ? Je ne pouvais pas utiliser la publication dotnet avec p:CustomTransformFileName dans TFS

Vous pouvez transmettre cette propriété msbuild à dotnet publish.

Vous pouvez vous référer à cet exemple ici - https://github.com/vijayrkn/webconfigtransform/blob/master/publish.cmd

Cela transmet la propriété CustomTransformFileName à la publication dotnet

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

@vijayrkn
J'ai lu votre documentation et je n'arrive pas à transformer le fichier web.config. J'ai essayé pratiquement toutes les commandes que vous avez dans le fichier readme.md et aucune d'entre elles n'entraîne l'exécution de la transformation.

J'ai cependant pu écrire un script powershell qui utilise Microsoft.Web.XmlTransform.dll pour effectuer la transformation séparément de l'opération de publication.

Ma question est quelle version de msbuild et dotnet utilisez-vous ?
J'utilise:
dotnet --version 2.1.104
dotnet msbuild -version 15.6.84.34536

Merci

@stephenarsenault1
Vous devez installer l'une des versions à partir d'ici pour que la fonctionnalité s'allume - https://www.microsoft.com/net/download/dotnet-core/2.2

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

@davidfowl a écrit :

Il y a une pseudo documentation ici https://github.com/vijayrkn/webconfigtransform/blob/master/README.md ( @vijayrkn nous devons l'

@vijayrkn Quelle est la prise en charge de cela dans la boîte de dialogue de publication ?

Savez-vous si cela a déjà été ajouté aux vrais docs, si oui, avez-vous le lien s'il vous plaît ?

Nous sommes maintenant passés à l'utilisation de <EnvironmentName> dans nos profils de publication. Ce serait bien d'avoir une interface utilisateur en plus de cela afin qu'elle soit plus visible, cependant. Je suppose que cela viendra à une date ultérieure?

Je pense que c'est un changement radical d'activer par défaut les transformations web.config sur la publication dotnet. Après avoir installé .NET Core SDK 2.2.101, il a cassé notre scénario CI/CD. Notre pipeline configuré pour créer un artefact publié à l'aide de dotnet publish une seule fois pour chaque version ( règle de construction unique ), transformation appliquée automatiquement lors du déploiement réel (effectué par Octopus). Je n'ai trouvé aucune mention dans la documentation de ce changement. J'ai passé un peu de temps à essayer de comprendre la raison des blocs de configuration doublés dans web.config après le déploiement. Apparemment, la transformation a été appliquée deux fois : par dotnet publish et par l'outil de gestion des versions.

Après avoir désactivé les transformations web.config avec le paramètre <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled> , TransformWebConfig a également été ignoré (avec TransformXml), ce qui fait que les variables %LAUNCHER_PATH% et %LAUNCHER_ARGS% ne sont pas remplacées pendant le processus de publication. Existe-t-il un paramètre pour contrôler ces étapes indépendamment ?

Cela fonctionne-t-il dans une application de console avec le fichier App.Config ?

Peut-on voir un exemple ?

@dmitryshunkov, vous pouvez définir $(RunXdt) sur false pour simplement ignorer l'exécution de la transformation Xml personnalisée.

@auserx - s'il s'agit d'un projet de style sdk, cela devrait fonctionner.