J'ai configuré un nouveau rôle ouvrier et configurez un couple de nouvelle config les transforme pour elle via Slowcheetah. Lorsque je construit le projet avec l'une des nouvelles configues sélectionnées, je vois en fait que les configurations sont créées dans le dossier \ bin, comme vous l'attendez (pour ex. \ Bin \ production).
Lorsque je emballer un service de cloud pour le déploiement à l'aide de l'une des nouvelles configures, mes projets Web obtiennent leurs configurations transformées de manière appropriée mais mon rôle de travailleur (qui n'est qu'une bibliothèque) ne voit même pas que je vois sous le dossier \ bin. \ bin \ production.
Il apparaît que l'outil d'emballage Azure ignore l'ensemble de configuration pour la bibliothèque de rôle de travailleur. Comment puis-je l'obtenir pour choisir le fichier de configuration à partir de la configuration appropriée?
4 Réponses :
Assurez-vous que vos configurations de service en nuage sont configurées. Cliquez avec le bouton droit sur le projet Cloud et vous devez voir les configurations que vous essayez de coller. Par exemple, je renommerai et utilise des configurations locales, de test et de produit. Votre projet de service Cloud doit alors contenir 3 fichiers de configuration:
Cliquez avec le bouton droit sur le projet de service de cloud et sélectionnez "Package" et sélectionnez les configurations de service et de construction correctes pour votre déploiement.
Remarque: app.configs ne sont pas transformés dans le processus de construction, à moins que vous ajoutez une MS - Voir ceci. pour une technique pour faire une transformation dans le processus de construction. HOperver, pour les déploiements en nuage, vous ferez mieux d'utiliser Serviceconfiguration. *. CSCFG Fichiers en combinaison avec CloudConfigurationManager.getting ("ScheckKey") - CloudconfigurationManager.Getting a été ajouté à la SDK 1.7 - En cas de rôle, Obtient la valeur de Serviceconfig sinon obtenir de web.config / app.config appSettings
Cela ne fonctionne pas. Les configurations de service n'ont aucun effet sur l'app.config.
Je recommanderais d'utiliser Serviceconfiguration. *. Fichier CSCFG au lieu d'appSettings. Ceux-ci peuvent être mis à jour dans le portail sans redéployer vos rôles. Réponse modifiée.
Oui, vous pouvez le faire - et c'est même très facile une fois que vous savez comment. Vous trouverez ci-dessous les lignes dont vous avez besoin pour mettre dans votre projet qui rendra cela juste travailler. Cela ne devrait pas prendre plus de cinq minutes. Veuillez noter que ce n'est pas un piratage - Toute l'ensemble du processus de déploiement azur est conçu pour soutenir ce genre de chose. Si vous voulez en savoir plus, il existe des liens avec des articles connexes en bas. La façon dont nous pouvons résoudre ce problème est d'accrocher dans le processus de construction du projet Cloud. Lorsque vous déployez le projet à Azure, le projet Cloud sera construit à l'aide d'un processus de construction que vous pouvez accrocher. En bref, le projet Cloud crée les rôles Web et travailleurs et les met sous le dossier Obj sous votre projet Cloud. Il exécute ensuite un processus qui ferme essentiellement tout cela et enfin de mettre le résultat dans le dossier bin. À partir de là, le fichier "zip" et un fichier de configuration sont téléchargés sur Azure. est de modifier manuellement votre fichier cloud.CsProj (si vous le faites à partir de Visual Studio Vous devez d'abord décharger le projet).
Ajoutez ensuite ce droit au-dessus de la fermeture
App.config n'est pas transformé par design mais heureusement, l'équipe Azure a rendu le processus de construction / de déploiement très extensible exactement pour ce type de scénarios. Ce que vous devez faire est raisonnablement bien documenté, bien que de manière très rond-point et que la plupart des articles supposent que vous connaissez déjà les scripts Msbuild et similaires. quelques points conceptuels
La solution
tag: notes
Avez-vous une configuration de construction de la production et bâtissez-vous en utilisant cela?
En fait, j'ai web.production.config (dans mvc), serviceconfiguration.production.cscfg (dans le projet Cloud), app.production.config (dans le rôle de travailleur) mais uniquement l'application . Production.config n'a pas été transformé. Mais app.debug.config et app.Release.config transformer correctement. Je pensais donc à supprimer toute configuration de production et à transférer les valeurs en débogage et libération. Toute suggestion?
J'ai fait de supprimer toutes les Production CONFIG et Placez les valeurs appropriées sur Débogage et publication config. Tout fonctionne en utilisant votre code de configuration ci-dessus. Mais ce serait plus préférable que votre code ci-dessus puisse transformer également la configuration personnalisée comme app.production.config
Ça peut - je l'utilise comme ça moi-même. La clé est que la configuration de construction du projet n'est pas la même que la configuration de déploiement Azure.
Hmm .. Je suis tellement intéressé par la façon dont vous le faites. Mais c'est comme ça que je le fais habituellement. Lorsque je crée un package à déployer, I-cliquez sur le bouton droit de la souris sur le projet de cloud -> Package -> (un formulaire affichera avec deux liste déroulante, une pour Configuration du service et l'autre est < Code> Construire la configuration ). Pour SC i "code> production même avec bc , mais bc config ( app.production.config < / code>) dans le rôle des travailleurs ne se transforme pas. Il ne se transforme que si je choisis débogage ou libération pour bc . Mais pas de problème transformant web.production.config.
BTW, un autre problème que j'ai trouvé. Lorsque j'effectue la solution, appconfigoriginal cause une erreur. Il dit qu'il ne peut pas trouver le fichier. Si je vous retire de votre configuration personnalisée et de créer un package pour le projet Cloud, le fichier est revenu. Ensuite, je vais ajouter votre configuration à nouveau. Créez à nouveau un package et transformez les travaux (pour débogage et libération). Mais si je nettoie / reconstruit la solution, l'erreur de fichier manquant ci-dessus revient à nouveau. J'essayais de comprendre votre code de configuration, de sorte qu'il ne ressemblera pas à l'intérieur du dossier Obj Cloud Project, mais plutôt sur le dossier de projet de Workererrole pour Workerrole.dll.config.
Bonjour, je pense que j'ai manqué quelques points ici La manière recommandée d'atteindre ce type de chose à Azure est de ne pas utiliser web.config et app.config, mais utilisez plutôt le cloudconfigurationManager et utilisez les paramètres de rôle. J'ai fait. Comme vous le dites, tout fonctionne bien. Merci beaucoup. +1
Heureux que vous ayez fait fonctionner en utilisant les autres options. Je ne sais pas pourquoi la transformation ne fonctionnait pas. La seule chose à laquelle je puisse penser, c'est que la production de niveau de la solution BC n'utilise pas la production de la BC pour tous les projets? Nous utilisons cela en production tous les jours, donc j'en suis assez confiant :) bonne chance!
Je trouve @frans Réponse trop compliqué, et ci-dessous est le code que j'ai trouvé dans Internet . Étant donné que vous avez déjà votre apport de transformation APP.Config, ouvrez votre projet Cloud (.ccproj) dans Editeur de texte, trouvez cette ligne:
<Target Name="CopyWorkerRoleConfigurations" AfterTargets="CopyWorkerRoleFiles">
<PropertyGroup>
<RootFolder>$([System.IO.Path]::GetDirectoryName($(MSBuildProjectDirectory)))</RootFolder>
</PropertyGroup>
<Copy SourceFiles="$(RootFolder)\%(ProjectName)\bin\$(Configuration)\%(EntryPoint).config" DestinationFolder="%(WorkerRoleReferences.OutputDir)" OverwriteReadOnlyFiles="true" />
</Target>
J'ai trouvé que j'ai besoin de modifier légèrement cela pour le faire fonctionner à l'aide de services de construction TFS si vous avez votre modèle défini sur la venteLocation = un seul fichier unique. J'ai changé les fichiers sources vers
Il y a un tour. Peut-être que quelqu'un va venir utile. Azure Worker Room Builder comprend des fichiers marqués comme "copie". Mais app.config se transformera dans trainerrole1.dll.config (ou autre), qui n'existe pas dans le temps de conception. Pour tromper VS:
Décharger le projet de rôle .CSPROJ.
Recherche de la section Clémentgroup avec des fichiers inclus dans le projet. J'ai les quelques prochains: puis défini avant ou après: Ce truc écrit à Builder "Workerrole1.dll .config "existe sous la forme d'un lien , celui-ci sera obtenu après la construction (et les transformations) et inclure dans le forfait Workerrole.
Légère solution pour résoudre les problèmes de reconstruction (lorsque le bac a été nettoyé). Builder essaie de copier le fichier qui n'existe pas et ne reconstruis pas en échec. Pour résoudre ce problème, insérez un fichier factice avec nomerrole1.dll.config dans la racine de projet avec Content \ Copier toujours des paramètres. Builder copiera un mannequin d'abord, puis copiera avec succès. Azur Rôle Deployer lit la propriété "Contenu" de ce fichier et copie un nouveau fichier transformé. Cela fonctionne sans copier et légèrement plus clair.
CSPACK (outil d'emballage Azure) ne dépend pas de la configuration de l'application (app.config) Utiliser la définition de service, comme décrit ici ici msdn.microsoft.com/en-us/library/gg432988.aspx . Si vous pouvez fournir plus d'informations sur les paramètres de configuration de l'application, vous souhaitez inclure dans la configuration de Build et la manière dont ils sont définis, je peux vous aider. Comment pouvez-vous construire votre colis, votre ligne de commande ou votre UI.
VIA VS UI. J'essaie de porter une application à Azure et je ne veux pas avoir à ré-écrire de gros morceaux de celui-ci pour ignorer l'app.config. Des choses comme System.net.Mail configurations que je transformerai normalement via la configuration Transforms.
J'ai utilisé Slowcheetah dans le passé et j'ai constaté que cela ne fonctionne que pour les développeurs qui l'ont installé - cela ne fonctionne pas pour les développeurs qui ne l'ont pas installés. En d'autres termes, les modifications apportées à votre
.csproj ne suffisent pas pour le faire "Work" pour tout le monde - quelque chose supplémentaire est requis. Je ne sais pas ce que quelque chose supplémentaire est cependant. :-(Ceci est tout non pertinent maintenant. Slowcheetah prend désormais en charge la transformation de la configuration de Azure Travailleur. Hourra!
@Jamesalexander Slowcheetah ne transforme pas app.Production.config lors de la création d'un package est Azure. Comment l'avez-vous fait?
@fiberoptics Ils ont ajouté un soutien pour cela il y a plus d'un an par mon dernier commentaire. Je l'utilise souvent