allowDefinition = erreur 'MachineToApplication' lors de la publication à partir de VS2010 (uniquement après une construction précédente)
Je peux exécuter mon application Asp.Net MVC 2 sans problème sur mon ordinateur local. Il suffit de lancer/déboguer.
Mais si je l'ai déjà construit, je ne peux pas le publier! Je dois nettoyer la solution et la publier à nouveau. Je sais que ce n'est pas critique pour le système, mais c'est vraiment ennuyant. "One Click Publish" n'est pas "Nettoyer la solution, puis One Click Publier"
L'erreur exacte est la suivante:
Erreur 11 C'est une erreur d'utiliser un section enregistrée en tant que allowDefinition = 'MachineToApplication' au-delà du niveau d'application. Cette erreur peut être causé par un répertoire virtuel ne pas être configuré comme une application dans IIS.
Je soupçonne que cela a quelque chose à voir avec Web.Config dans le dossier Vues, mais alors pourquoi seulement après avoir construit une fois auparavant Et juste pour noter, l'application fonctionne bien une fois publiée.
j'ai eu le même problème avec mes applications MVC. c'était frustrant parce que je voulais toujours que mes vues soient vérifiées, donc je ne voulais pas désactiver MvcBuildViews
heureusement je suis tombé sur un post qui m'a donné la réponse. conservez les MvcBuildViews sous la forme true, vous pouvez ensuite ajouter la ligne suivante dans le fichier de projet:
<BaseIntermediateOutputPath>[SomeKnownLocationIHaveAccessTo]</BaseIntermediateOutputPath>
Et ne placez pas ce dossier dans le dossier de votre projet. Travaille pour moi. Ce n'est pas une solution parfaite, mais c'est bon pour le moment. Assurez-vous de supprimer le dossier package (situé dans le dossier obj\Debug et/ou obj\Release) du dossier de votre projet, faute de quoi l'erreur continuera de se produire.
FWIW, MS sait à propos de cette erreur ...
J'ai tout supprimé de mon dossier obj/Debug et cette erreur a été corrigée. Cela m'a permis de partir dans la
<MvcBuildViews>true</MvcBuildViews>
option dans mon fichier de projet (qui est pratique avec le modèle T4MVC T4).
Edit: Ceci peut être réalisé beaucoup plus facilement en utilisant simplement le menu "Build" -> "Rebuild Solution" (parce que ce qui est reconstruit, c’est de vider le dossier obj/Debug puis de construire la solution).
J'utilise cette solution de contournement sur la page MS Connect pour cette erreur. Il nettoie tous les fichiers obj et temporaires de votre projet (toutes les configurations) avant d’exécuter AspNetCompiler.
Modifiez la cible MvcBuildViews dans votre fichier de projet pour que cela dépend sur les cibles qui nettoient le Empaquetage des fichiers que Visual Studio a créé. Ces cibles sont incluses dans projets d'application web automatiquement.
Tous les fichiers d’emballage seront supprimés chaque fois que le MvcBuildViews la cible s'exécute.
<Target Name="MvcBuildViews" AfterTargets="AfterBuild" Condition="'$(MvcBuildViews)'=='true'" DependsOnTargets="CleanWebsitesPackage;CleanWebsitesPackageTempDir;CleanWebsitesTransformParametersFiles;">
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(MSBuildProjectDirectory)" />
</Target>
Ce problème se produit lorsqu'il existe une sortie de projet Web (fichier web.config basé sur un modèle ou fichiers de publication temporaires) dans le dossier obj. Le compilateur ASP.NET utilisé n'est pas assez intelligent pour ignorer les éléments du dossier obj, aussi génère-t-il des erreurs.
Une autre solution consiste à analyser la sortie de publication juste avant d'appeler <AspNetCompiler>. Ouvrez votre .csproj et changez ceci:
<Target Name="MvcBuildViews" AfterTargets="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(WebProjectOutputDir)" />
</Target>
pour ça:
<Target Name="MvcBuildViews" AfterTargets="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
<ItemGroup>
<ExtraWebConfigs Include="$(BaseIntermediateOutputPath)\**\web.config" />
<ExtraPackageTmp Include="$([System.IO.Directory]::GetDirectories("$(BaseIntermediateOutputPath)", "PackageTmp", System.IO.SearchOption.AllDirectories))" />
</ItemGroup>
<Delete Files="@(ExtraWebConfigs)" />
<RemoveDir Directories="@(ExtraPackageTmp)" />
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(WebProjectOutputDir)" />
</Target>
Cela supprimera tous les web.configs sous\obj, ainsi que tous les dossiers PackageTmp sous\obj.
Si vous utilisez Web Publish, vous pouvez définir MvcBuildViews=false et PrecompileBeforePublish=true, qui précompilent après la copie dans le dossier temporaire (immédiatement avant la publication/le package).
REMARQUE: PrecompileBeforePublish est uniquement pris en charge par la "nouvelle" pile de pipeline de publication Web (SDK VS2010 SP1 + Azure ou VS2012 RTM). Si vous utilisez VS2010 RTM, vous devrez utiliser l'une des méthodes alternatives.
Je sais que cela a été répondu, mais je voulais juste ajouter quelque chose d'intéressant que j'ai trouvé.
J'avais défini le paramètre "MvcBuildViews" sur false dans le projet, supprimé tous les dossiers bin et obj et j'avais toujours l'erreur. J'ai trouvé qu'il y avait un fichier ".csproj.user" dans lequel "MvcBuildViews" était toujours défini sur true.
J'ai supprimé le fichier ".csproj.user", puis tout a fonctionné.
Vérifiez donc si vous modifiez votre fichier csproj que vous modifiez ou supprimez également le fichier ".csproj.user".
En ce qui concerne la solution de jrummell, le réglage:
DependsOnTargets="CleanWebsitesPackage;CleanWebsitesPackageTempDir;CleanWebsitesTransformParametersFiles;"
Il fonctionne dans VS 2010 _, mais pas dans VS 2012_. En 2012, vous devez mettre:
DependsOnTargets="CleanWebsitesPackage;CleanWebsitesWPPAllFilesInSingleFolder;CleanWebPublishPipelineIntermediateOutput"
La source:
VS 2010: C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets
VS 2012: C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets
J'ai eu ce problème aussi, alors j'ai créé un événement de pré-construction dans les propriétés du projet pour nettoyer les répertoires de sortie (${projectPath}\bin,${projectPath}\obj\${ConfigurationName}). Sur un autre projet, j'avais également cette erreur, même avec l'événement de nettoyage en place. Sur le deuxième projet, je compilais les vues énumérées dans le fichier de projet:
<MvcBuildViews>true</MvcBuildViews>
J'ai changé le vrai en faux, et il ne s'est plus plaint de cette erreur, mais a quand même fonctionné correctement. Je ne prétends pas connaître exactement la cause de la deuxième erreur, mais au moins, cela m'a permis d'avancer pour le moment.
Le problème concerne les fichiers intermédiaires, mais il existe une autre solution qui consiste à nettoyer ces fichiers intermédiaires avant de créer les vues.
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 non standard).
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èrent la suppression des fichiers intermédiaires en démarrage:
<!--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. J'ai aussi simplifié la cible, en supprimant le PropertyGroup et en simplifiant la condition, comme ceci:
<Target Name="CleanupForBuildMvcViews" Condition="'$(MVCBuildViews)'=='true' " BeforeTargets="BuildViews">
<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>
Dans mon cas, j’ai constaté que lorsque j’ai MvcBuildViews et PrecompileDuringPublish comme étant vrais, c’est ce qui était à l’origine de ce problème.
J'ai donc supprimé PrecompileDuringPublish et cette solution a fonctionné pour moi et je n'ai pas rencontré ce problème depuis.
