allowDefinition = Erreur msbuild 'MachineToApplication'
Nous avons un ASP.NET MVC avec 4-5 différentes configurations de construction. Chaque fois que nous modifions la configuration de construction, nous devons supprimer le dossier obj du projet Web, car nous obtenons l'erreur 'allowDefinition =' MachineToApplication '. Un problème, mais nous avons réussi en supprimant le dossier dans les événements pré/post-build. Maintenant, je dois configurer notre CI pour construire des packages de déploiement. Cela signifie que je ne peux pas supprimer le dossier obj. Chaque fois que je compile, par exemple avec les paramètres msbuild suivants
/ p: CreatePackageOnPublish = true/p: DeployOnBuild = true
Je reçois l'erreur:
web.config (123): erreur ASPCONFIG: utiliser une section enregistrée en tant que allowDefinition = "MachineToApplication" au-delà du niveau de l'application est une erreur. Cette erreur peut être provoquée par le fait qu'un répertoire virtuel n'est pas configuré en tant qu'application dans IIS.
Autant que je sache, le problème est qu'il existe plusieurs fichiers .config dans le projet - dans notre cas, il n'y en a pas. Je pourrais vraiment avoir besoin d’aide pour trouver une explication et trouver une solution permanente (no-hack).
Edit: Cette question est marquée comme un doublon, mais les réponses correspondantes et la ou les causes correspondantes dans les 2 discussions sont clairement différentes les unes des autres. Je ne sais pas trop à quoi sert cette balise. J'ai lu ce message en particulier avant de poster cette question, car cela ne répondait pas à ma question. Ce message d'erreur a plusieurs causes. C'est 'similaire', mais certainement pas un doublon!
Moi aussi, je supprimais le dossier obj jusqu'à ce que je sois entré en conflit avec un script de construction qui l'exigeait. Catch-22, j'ai utilisé la réponse acceptée sur le lien SO suivant pour déplacer l'emplacement du dossier Obj vers C:\Temp\BUILD. Vous devez le faire par fichier csproj, mais c'est une excellente solution.
Voici le lien: VisualStudio: Comment enregistrer le dossier obj ailleurs
Notez que j'utilise une variable pour le nom de projet . R:\Temp\Build\Debug\$ (MSBuildProjectName)
J'ai la ligne ci-dessus dans les sections de débogage et de publication pour tous mes projets, y compris les projets de classe. Mon chemin de construction est un lecteur de vitesse pour la vitesse. Voir ceci SO pour plus d’informations: Comment accéder aux variables de macro dans le fichier csproj?
Il existe une question similaire ici sur SO avec quelques bonnes solutions à ce problème.
Le problème est que la construction d'un package de déploiement crée une copie du fichier web.config dans un sous-dossier de/obj. Cela sera normalement effacé si vous effectuez une reconstruction ou un nettoyage. Toutefois, si vous créez un package de déploiement dans une configuration (par exemple, Debug), puis basculez vers une autre configuration (par exemple, Release), le dossier obj/Debug n'est pas effacé et le fichier web.config y pose des problèmes.
La solution rapide consiste à nettoyer toutes les configurations, puis à effectuer une (re) construction. Vous pouvez également supprimer le dossier/obj de votre projet . Pour résoudre définitivement le problème, vous pouvez déplacer la sortie intermédiaire (/ obj) hors de votre dossier de projet ou modifier le projet pour forcer le nettoyage de toutes les configurations lors de la reconstruction.
Je viens de répondre à une question similaire ici . Pour récapituler, j'ai rencontré ce problème dans l'un de nos projets MVC, en raison de la propriété MvcBuildViews dans le fichier de projet définie sur true. La définition de la propriété sur false a résolu le problème.
<MvcBuildViews>false</MvcBuildViews>
J'ai aussi trouvé cette réponse qui décrit une alternative qui n'exige pas d'éteindre la vue.
Je ne sais pas s'il existe un correctif "officiel", car il semblait simplement que plusieurs de mes projets commençaient sans raison que je puisse trouver dans Visual Studio Premium 2012 (cela ne s'est jamais produit dans les versions précédentes de VS).
Comme solution de rechange pour automatiser la suppression du répertoire obj, comme d’autres l’ont déjà dit, semblable à une réponse de l’utilisateur Casual dans ce message VisualStudio: Comment enregistrer le dossier obj ailleurs , où, malheureusement, il n’a fait que déplacer le Le dossier obj ne semble pas toujours fonctionner.
Au lieu de cela, j'ai ajouté quelques commandes sous Build Events dans la ligne de commande de l'événement Pre-build:
rd "$(ProjectDir)obj" /S /Q
md "$(ProjectDir)obj"
md "$(ProjectDir)obj\Debug"
md "$(ProjectDir)obj\Release"
Vous pouvez modifier/ajouter/supprimer des sous-dossiers pour correspondre à vos configurations de construction personnalisées à l'aide de la ligne où buildConfigName correspond au nom de la configuration de construction que vous utilisez:
md "$(ProjectDir)obj\buildConfigName"
J'espère que cela t'aides!
J'ai eu la même erreur, mais avec une page déployée .. Puis, j'ai réalisé que l'horloge de mon serveur Web était réglée sur 2010 pour une raison quelconque. régler la date correcte résoudre mon problème
Cette erreur indique que vous essayez d'utiliser quelque chose de spécifique à une application au niveau d'une arborescence IIS qui n'est pas définie en tant qu'application. Par exemple, si vous essayez d'effectuer des fonctions de niveau application dans un fichier web.config situé dans un répertoire virtuel, vous obtiendrez cette erreur. Vous devez rechercher le chemin sur lequel vous déployez et vous assurer qu'il est défini dans IIS en tant qu'application par rapport à un dossier ou à un dossier vdir.
Nettoyer la solution (clic droit sur Solution dans VS, nettoyer) a fonctionné pour moi.
J'ai un peu un problème similaire, j'ai eu la config principale comme Copier toujours donc il a copié la config dans le répertoire bin. Quand j'ai republié le projet principal, j'ai eu l'erreur MachineToApplication. Ma solution consistait donc simplement à modifier la configuration en Ne pas copier et à supprimer la configuration supplémentaire dans le dossier bin.
conseil 1: nettoyez et reconstruisez.
conseil 2: fermez VS et ouvrez-le à nouveau.
conseil 3: le projet téléchargé peut se trouver dans un autre sous-dossier ... ouvrez le dossier contenant vos fichiers .net.
c:/demo1/demo/(tous les fichiers)
Vous devriez avoir à ouvrir la démo de vs ... not demo1.
Nettoyez votre projet Supprimez le dossier/obj (en utilisant probablement publier et déployer? - il contient un bogue)
Bien que le problème soit expliqué et résolu d'une manière dans la réponse acceptée, je voulais montrer une solution qui pourrait être meilleure pour les autres cas. Cette solution a été incluse dans certaines versions de VS, mais je peux seulement dire que le problème se trouvait dans VS 2013 Update 5. (Voir le "Attention" ci-dessous, il pourrait être résolu dans cette version, ne fonctionne pas uniquement dans mon cas particulier).
J'ai emprunté la solution à Erreur: allowDefinition = 'MachineToApplication' au-delà du niveau de l'application sur Visual Studio Connect.
La solution consiste à inclure ces lignes dans le projet d’application Web (fichier .csproj) qui gère la suppression des fichiers intermédiaires en attente (qui ne constitue pas une solution pour la réponse acceptée, car il avait besoin de ces fichiers intermédiaires):
<!--Deal with http://connect.Microsoft.com/VisualStudio/feedback/details/779737/error-allowdefinition-machinetoapplication-beyond-application-level,
we will need to clean up our temp folder before MVC project starts the pre-compile-->
<PropertyGroup>
<_EnableCleanOnBuildForMvcViews Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='' ">true</_EnableCleanOnBuildForMvcViews>
</PropertyGroup>
<Target Name="CleanupForBuildMvcViews" Condition=" '$(_EnableCleanOnBuildForMvcViews)'=='true' and '$(MVCBuildViews)'=='true' " BeforeTargets="MvcBuildViews">
<ItemGroup>
<_PublishTempFolderNamesToCleanup Include="Database;TransformWebConfig;CSAutoParameterize;InsertAdditionalCS;ProfileTransformWebConfig;Package;AspnetCompileMerge" />
</ItemGroup>
<!--Force msbuild to expand all the wildcard characters so to get real file paths-->
<CreateItem Include="@(_PublishTempFolderNamesToCleanup->'$(BaseIntermediateOutputPath)**\%(identity)\**\*')">
<Output TaskParameter="Include" ItemName="_EvaluatedPublishTempFolderNamesToCleanup" />
</CreateItem>
<Delete Files="@(_EvaluatedPublishTempFolderNamesToCleanup)" />
</Target>
Attention: pour une raison quelconque, probablement parce que je l'ai inclus moi-même dans le projet, ma cible de construction pour créer les vues s'appelait "BuildViews", au lieu de "MvcBuildViews"; j'ai donc dû modifier l'attribut BeforeTargets en conséquence.
Ce n’est pas forcément exactement la même chose, et pour être honnête, probablement à cause d’un pur manque de connaissances de ma part, mais j’ai eu la même erreur lorsque:
- J'ai mis en place un nouveau projet asp.net standard qui vient en fait d'être utilisé pour HTML5, donc rien d'autre que la structure de projet habituelle
- J'ai ensuite (sans y penser peut-être!) Ajouté un nouveau projet WCF REST (qui n'était en réalité qu'un autre projet asp.net de base utilisant de très bons exemples de http://www.codeproject.com/Articles/128478/ Consomming-WCF-REST-Services-Using-jQuery-AJAX-Call? Fid = 1597004 & df = 90 & mpp = 25 & noise = 3 & prof = False & sort = Position & view = Rapide & fr = 26 # xx0xx et http://geekswithblogs.net/michelotti/ archive/2010/08/21/reposful-wcf-services-with-no-fichier-svc-and-no-config.aspx
Le problème était que j'avais ajouté le projet WCF REST (n ° 2) en tant que sous-répertoire du projet principal (n ° 1), puis que j'essayais de le construire! même si j’ai nettoyé le projet bien sûr .. J’ai également fait utiliser les deux projets avec IISexpress parce que j’imaginais qu’un problème était lié à l’utilisation du même port ou de quelque chose de ce genre.
Bien sûr, le processus de construction a vu web.config de # 1, puis un sous-répertoire avec un autre web.config # 2 ..
Je me rends compte que cela devrait probablement être un principe de base compris gotcha et cela m’a surpris, mais il s’agit parfois des erreurs les plus simples qui font vraiment mal!
Pourrait aider les autres… qui n'ont peut-être pas bu leur café du matin….