allowDefinition = Erreur 'MachineToApplication' lors de la publication à partir de VS2010 (mais uniquement après une version précédente)

Je peux exécuter mon application Asp.Net MVC 2 sans problème sur mon ordinateur local. Exécuter / déboguer simplement.

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 ennuyeux. "Publication en un clic" n'est pas "Solution propre puis publication en un clic"

L'erreur exacte est la suivante:

Erreur 11 C'est une erreur d'utiliser une section enregistrée comme allowDefinition = 'MachineToApplication' au-delà du niveau de l'application. Cette erreur peut être provoquée par un répertoire virtuel qui n'est pas configuré en tant qu'application dans IIS.

Je soupçonne que c'est quelque chose à voir avec le Web.Config dans le dossier Views, 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 opinions soient vérifiées, donc je ne voulais pas désactiver MvcBuildViews

heureusement, je suis tombé sur un message qui m'a donné la réponse. gardez le MvcBuildViews comme vrai , vous pouvez alors ajouter la ligne suivante en dessous dans votre fichier de projet:

<BaseIntermediateOutputPath>[SomeKnownLocationIHaveAccessTo]</BaseIntermediateOutputPath>

Et ne faites 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 du package (situé dans le dossier obj \ Debug et / ou obj \ Release ) de votre dossier de projet, sinon vous continuerez à obtenir l'erreur.

FWIW, MS connaît cette erreur ...

J'ai tout supprimé de mon dossier obj / Debug et cela a corrigé cette erreur. Cela m'a permis de partir dans le

<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" (car ce que la reconstruction fait réellement est d'effacer 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 projet afin qu'elle dépende des cibles qui nettoient les fichiers d'empaquetage que Visual Studio a créés. Ces cibles sont automatiquement incluses dans les projets d'application Web.

Tous les fichiers d'empaquetage seront supprimés chaque fois que la cible MvcBuildViews 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 (modèle web.config ou fichiers de publication temporaires) dans le dossier obj. Le compilateur ASP.NET utilisé n'est pas assez intelligent pour ignorer des éléments du dossier obj, il génère donc des erreurs à la place.

Un autre correctif consiste à détruire la sortie de publication juste avant d'appeler <AspNetCompiler>. Ouvrez votre .csproj et modifiez 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(&quot;$(BaseIntermediateOutputPath)&quot;, &quot;PackageTmp&quot;, 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 la publication Web, vous pouvez définir MvcBuildViews=falseetPrecompileBeforePublish=true , qui précompile après la copie dans le dossier temporaire (juste avant la publication / le package).

REMARQUE: PrecompileBeforePublishest uniquement pris en charge par la "nouvelle" pile de pipeline de publication Web (VS2010 SP1 + Azure SDK ou VS2012 RTM). Si vous utilisez VS2010 RTM, vous devrez utiliser l'une des méthodes alternatives.

Concernant la solution de jrummell, le paramètre:

DependsOnTargets="CleanWebsitesPackage;CleanWebsitesPackageTempDir;CleanWebsitesTransformParametersFiles;"

Cela 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

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 "MvcBuildViews" sur false dans le projet, supprimé tous les dossiers bin et obj et j'obtenais toujours l'erreur. J'ai trouvé qu'il y avait un fichier ".csproj.user" qui avait toujours "MvcBuildViews" réglé sur true.

J'ai supprimé le fichier ".csproj.user" et tout a fonctionné.

Assurez-vous donc que si vous modifiez votre fichier csproj, vous modifiez ou supprimez également le fichier ".csproj.user".

J'ai également eu ce problème, j'ai donc 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'obtenais également cette erreur, même avec l'événement de nettoyage en place. Sur le deuxième projet, je compilais les vues répertoriées dans le fichier de projet:

<MvcBuildViews>true</MvcBuildViews>

J'ai changé le vrai en faux, et il ne se plaignait plus de cette erreur, mais fonctionnait toujours correctement. Je ne prétendrai pas savoir exactement ce qui causait la deuxième erreur, mais au moins cela m'a fait 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 construire les vues.

Cette solution a été incluse dans certaines versions de VS, mais je peux seulement dire que j'ai eu le problème dans VS 2013 Update 5. (Voir le "Attention" ci-dessous, il pourrait être corrigé dans cette version, mais ne fonctionne pas uniquement dans mon cas particulier cas non standard).

J'ai emprunté la solution à Error: 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 ( .csprojfichier) qui gère la suppression des fichiers intermédiaires proposés:

<!--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 construire les vues a été nommée "BuildViews", au lieu de "MvcBuildViews", donc j'ai dû modifier l' BeforeTargetsattribut en conséquence. J'ai également simplifié la cible, en supprimant PropertyGroupet 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 vu que lorsque MvcBuildViews et PrecompileDuringPublish étaient tous les deux vrais, c'était ce qui causait 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.