allowDefinition = 'MachineToApplication'-Fehler beim Veröffentlichen von VS2010 (jedoch nur nach einem vorherigen Build)

Ich kann meine Asp.Net MVC 2-Anwendung ohne Probleme auf meinem lokalen Computer ausführen. Einfach ausführen / debuggen.

Aber wenn ich es bereits gebaut habe, kann ich es nicht veröffentlichen! Ich muss die Lösung bereinigen und erneut veröffentlichen. Ich weiß, dass dies nicht systemkritisch ist, aber es ist wirklich ärgerlich. "One Click Publish" ist nicht "Clean Solution und dann One Click Publish".

Der genaue Fehler lautet wie folgt:

Fehler 11 Es ist ein Fehler, einen Abschnitt zu verwenden, der als allowDefinition = 'MachineToApplication' außerhalb der Anwendungsebene registriert ist. Dieser Fehler kann dadurch verursacht werden, dass ein virtuelles Verzeichnis in IIS nicht als Anwendung konfiguriert ist.

Ich vermute, es hat etwas mit der Web.Config im Ordner "Ansichten" zu tun, aber warum dann erst, nachdem ich sie einmal erstellt habe? Und nur zu beachten, die App funktioniert gut, sobald sie veröffentlicht wurde.

Ich hatte das gleiche Problem mit meinen MVC-Apps. Es war frustrierend, weil ich immer noch wollte, dass meine Ansichten überprüft werden, also wollte ich MvcBuildViews nicht deaktivieren

Zum Glück bin ich auf einen Beitrag gestoßen, der mir die Antwort gab. Behalten Sie die MvcBuildViews als true bei , dann können Sie die folgende Zeile darunter in Ihre Projektdatei einfügen :

<BaseIntermediateOutputPath>[SomeKnownLocationIHaveAccessTo]</BaseIntermediateOutputPath>

Und machen Sie diesen Ordner nicht im Ordner Ihres Projekts. Funktioniert bei mir. Es ist keine perfekte Lösung, aber es ist im Moment gut. Achten Sie darauf , das entfernen Paket - Ordner (befindet sich im Inneren des obj \ Debug und / oder obj \ Release - Ordner) aus Ihrem Projektordner sonst werden Sie behalten , um den Fehler zu bekommen.

FWIW, MS wissen um diesen Fehler ...

Ich habe alles aus meinem obj / Debug-Ordner gelöscht und diesen Fehler behoben. Dies erlaubte mir, in der zu verlassen

<MvcBuildViews>true</MvcBuildViews>

Option in meiner Projektdatei (die mit der T4MVC T4-Vorlage nützlich ist).

Bearbeiten: Dies kann viel einfacher erreicht werden, indem Sie einfach das Menü "Erstellen" -> "Lösung neu erstellen" verwenden (da die Wiederherstellung tatsächlich den Ordner obj / Debug löscht und dann die Lösung erstellt).

Ich verwende diese Problemumgehung auf der MS Connect- Seite für diesen Fehler. Es bereinigt alle obj- und temporären Dateien unter Ihrem Projekt (alle Konfigurationen), bevor AspNetCompiler ausgeführt wird.

Ändern Sie das MvcBuildViews-Ziel in Ihrer Projektdatei so, dass es von den Zielen abhängt, mit denen die von Visual Studio erstellten Paketdateien bereinigt werden. Diese Ziele werden automatisch in Webanwendungsprojekte aufgenommen.

Alle Verpackungsdateien werden jedes Mal gelöscht, wenn das MvcBuildViews-Ziel ausgeführt wird.

<Target Name="MvcBuildViews" AfterTargets="AfterBuild" Condition="'$(MvcBuildViews)'=='true'" DependsOnTargets="CleanWebsitesPackage;CleanWebsitesPackageTempDir;CleanWebsitesTransformParametersFiles;">
    <AspNetCompiler VirtualPath="temp" PhysicalPath="$(MSBuildProjectDirectory)" />
</Target>

Dieses Problem tritt auf, wenn im obj-Ordner eine Webprojektausgabe (Vorlage web.config oder temporäre Veröffentlichungsdateien) vorhanden ist. Der verwendete ASP.NET-Compiler ist nicht intelligent genug, um Dinge im obj-Ordner zu ignorieren, und wirft stattdessen Fehler aus.

Eine weitere Lösung besteht darin, die Veröffentlichungsausgabe unmittelbar vor dem Aufruf von <AspNetCompiler> zu nuklearisieren. Öffnen Sie Ihre .csproj und ändern Sie dies:

<Target Name="MvcBuildViews" AfterTargets="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
  <AspNetCompiler VirtualPath="temp" PhysicalPath="$(WebProjectOutputDir)" />
</Target>

dazu:

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

Dadurch werden alle web.configs unter \ obj sowie alle PackageTmp-Ordner unter \ obj gelöscht.

Wenn Sie mit Web veröffentlichen, können Sie einstellen , MvcBuildViews=falseund PrecompileBeforePublish=true, die Vorkompilierung nach dem Kopieren in den temporären Ordner (unmittelbar vor Publish / Paket).

HINWEIS: PrecompileBeforePublishWird nur vom "neuen" Web Publishing-Pipeline-Stack (VS2010 SP1 + Azure SDK oder VS2012 RTM) unterstützt. Wenn Sie VS2010 RTM verwenden, müssen Sie eine der alternativen Methoden verwenden.

In Bezug auf die Lösung von jrummell ist die Einstellung:

DependsOnTargets="CleanWebsitesPackage;CleanWebsitesPackageTempDir;CleanWebsitesTransformParametersFiles;"

Es funktioniert in VS 2010 , aber nicht in VS 2012 . 2012 muss man sagen:

DependsOnTargets="CleanWebsitesPackage;CleanWebsitesWPPAllFilesInSingleFolder;CleanWebPublishPipelineIntermediateOutput"

Quelle:

VS 2010: C: \ Programme (x86) \ MSBuild \ Microsoft \ VisualStudio \ v10.0 \ Web \ Microsoft.Web.Publishing.targets

VS 2012: C: \ Programme (x86) \ MSBuild \ Microsoft \ VisualStudio \ v11.0 \ Web \ Microsoft.Web.Publishing.targets

Ich weiß, dass dies beantwortet wurde, aber ich wollte nur etwas Interessantes hinzufügen, das ich gefunden habe.

Ich hatte die "MvcBuildViews" im Projekt auf false gesetzt, alle bin- und obj-Ordner gelöscht und immer noch den Fehler erhalten. Ich fand heraus, dass es eine ".csproj.user" -Datei gab, in der "MvcBuildViews" immer noch auf "true" gesetzt war.

Ich habe die Datei ".csproj.user" gelöscht und dann hat alles funktioniert.

Stellen Sie daher sicher, dass Sie beim Ändern Ihrer csproj-Datei auch die Datei ".csproj.user" ändern oder löschen.

Ich hatte auch dieses Problem, also habe ich in den Projekteigenschaften ein Pre-Build-Ereignis erstellt, um die Ausgabeverzeichnisse ( ${projectPath}\bin,${projectPath}\obj\${ConfigurationName}) zu bereinigen . Bei einem anderen Projekt wurde dieser Fehler auch dann angezeigt, wenn das Reinigungsereignis vorhanden war. Beim zweiten Projekt habe ich die Ansichten wie in der Projektdatei aufgeführt kompiliert:

<MvcBuildViews>true</MvcBuildViews>

Ich habe das True in False geändert und es hat sich nicht mehr über diesen Fehler beschwert, ist aber trotzdem korrekt gelaufen. Ich werde nicht behaupten, dass ich genau weiß, was den zweiten Fehler verursacht hat, aber es hat mich zumindest vorerst vorwärts gebracht.

Das Problem hat mit den Zwischendateien zu tun, aber es gibt eine andere Lösung, die darin besteht, diese Zwischendateien vor dem Erstellen der Ansichten zu bereinigen.

Diese Lösung wurde in einige Versionen von VS aufgenommen, aber ich kann nur sagen, dass ich das Problem in VS 2013 Update 5 hatte. (Siehe "Vorsicht" unten, es könnte in dieser Version behoben werden, funktioniert aber nicht nur in meiner Version nicht standardmäßiger Fall).

Ich habe die Lösung von Error: allowDefinition = 'MachineToApplication' über die Anwendungsebene in Visual Studio Connect hinaus ausgeliehen.

Die Lösung besteht darin, diese Zeilen in das Webanwendungsprojekt ( .csprojDatei) aufzunehmen, die das Löschen der angebotenen Zwischendateien behandeln:

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

Achtung: Aus irgendeinem Grund, wahrscheinlich weil ich es selbst in das Projekt aufgenommen habe, wurde mein Erstellungsziel zum Erstellen der Ansichten "BuildViews"anstelle von benannt "MvcBuildViews", sodass ich das BeforeTargetsAttribut entsprechend ändern musste . Ich habe auch das Ziel vereinfacht, indem ich PropertyGroupdie Bedingung wie folgt entfernt und vereinfacht habe:

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

In meinem Fall habe ich gesehen, dass MvcBuildViews und PrecompileDuringPublish beide als wahr gelten - was dieses Problem verursacht hat.

Also habe ich PrecompileDuringPublish entfernt und diese Lösung hat bei mir funktioniert und ich bin seitdem nicht mehr mit diesem Problem konfrontiert.