wake-up-neo.net

allowDefinition = 'MachineToApplication' Fehler beim Veröffentlichen von VS2010 (aber 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 schon 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 nervig. "One Click Publish" ist nicht "Lösung bereinigen und dann One Click Publish".

Der genaue Fehler lautet wie folgt:

Fehler 11 Es ist ein Fehler, eine .__ zu verwenden. Abschnitt registriert als allowDefinition = 'MachineToApplication' jenseits der Anwendungsebene. Dieser Fehler kann durch ein virtuelles Verzeichnis verursacht werden nicht als Anwendung konfiguriert sein in IIS.

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

102
Dann

ich hatte das gleiche Problem mit meinen MVC-Apps. es war frustrierend, weil ich immer noch wollte, dass meine Ansichten überprüft werden, und ich wollte MvcBuildViews nicht ausschalten.

zum Glück stieß ich auf einen Beitrag , der mir die Antwort gab. Behalten Sie die MvcBuildViews als true bei, und Sie können darunter folgende Zeile 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 für den Moment gut. Stellen Sie sicher, dass Sie den Ordner package (im Ordner obj\Debug und/oder obj\Release) aus Ihrem Projektordner entfernen. Andernfalls wird der Fehler weiterhin angezeigt.

FWIW, MS kennen diesen Fehler ...

75
benpage

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

<MvcBuildViews>true</MvcBuildViews>

option in meiner Projektdatei (was bei der T4MVC-T4-Vorlage hilfreich ist).

Edit: Dies ist viel einfacher zu erreichen, indem Sie einfach das Menü "Build" -> "Solution neu erstellen" verwenden (da bei der Neuerstellung der Ordner obj/Debug gelöscht wird und die Lösung erstellt wird).

40
jimmay5469

Ich verwende diese Problemumgehung auf der Seite MS Connect für diesen Fehler. Es säubert alle obj- und temp-Dateien in Ihrem Projekt (alle Konfigurationen), bevor Sie AspNetCompiler ausführen.

Ändern Sie das MvcBuildViews-Ziel in Ihre Projektdatei, so dass es darauf ankommt auf die Ziele, die die .__ bereinigen. Verpackungsdateien, die Visual Studio enthält erstellt. Diese Ziele sind in .__ enthalten. Webanwendungsprojekte automatisch.

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

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

Dieses Problem tritt auf, wenn sich im Obj-Ordner Webprojektausgabe (Templates mit dem Namen web.config oder temporäre Veröffentlichungsdateien) befindet. Der verwendete ASP.NET-Compiler ist nicht intelligent genug, um Objekte im Ordner obj zu ignorieren, sodass er stattdessen Fehler ausgibt.

Ein weiterer Fix ist, die Publish-Ausgabe kurz vor dem Aufruf von <AspNetCompiler> zu nuke. Öffne dein .csproj und ändere das:

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

zu diesem:

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

24
Chris Hynes

Wenn Sie Web Publish verwenden, können Sie MvcBuildViews=false und PrecompileBeforePublish=true festlegen, die nach der Kopie in den temporären Ordner (unmittelbar vor dem Veröffentlichen/Paket) vorkompiliert werden.

HINWEIS: PrecompileBeforePublish wird 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.

4
Richard Szalay

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

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

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

Stellen Sie daher sicher, dass Sie die Datei ".csproj.user" ebenfalls ändern oder löschen, wenn Sie Ihre csproj-Datei ändern.

3
nootn

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

DependsOnTargets="CleanWebsitesPackage;CleanWebsitesPackageTempDir;CleanWebsitesTransformParametersFiles;"

Es funktioniert in VS 2010, aber nicht in VS 2012. Im Jahr 2012 müssen Sie:

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

3

Ich hatte auch dieses Problem, also habe ich ein Pre-Build-Ereignis in den Projekteigenschaften erstellt, um die Ausgabeverzeichnisse zu bereinigen (${projectPath}\bin,${projectPath}\obj\${ConfigurationName}). Bei einem anderen Projekt bekam ich auch diesen Fehler, obwohl das Reinigungsereignis stattgefunden hatte. Beim zweiten Projekt habe ich die Ansichten wie in der Projektdatei aufgeführt zusammengestellt:

<MvcBuildViews>true</MvcBuildViews>

Ich habe das true in false geändert, und es wurde nicht mehr über diesen Fehler geklagt, es wurde aber trotzdem korrekt ausgeführt. Ich kann nicht behaupten, dass ich genau weiß, was den zweiten Fehler verursacht hat, aber zumindest hat es mich vorerst weiter gebracht.

2
eppdog

Das Problem hat mit den Zwischendateien zu tun, aber es gibt eine andere Lösung, die darin besteht, diese Zwischendateien zu bereinigen, bevor die Ansichten erstellt werden. 

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 "Beware" unten. Es könnte jedoch in dieser Version behoben werden funktioniert nicht nur in meinem speziellen, nicht standardmäßigen Fall).

Ich habe mir die Lösung aus Error: allowDefinition = 'MachineToApplication' über die Anwendungsebene von Visual Studio Connect geliehen.

Die Lösung besteht darin, diese Zeilen in das Webanwendungsprojekt (.csproj-Datei) aufzunehmen, die das Löschen der abgelegten Zwischendateien ausführen:

<!--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, hieß mein Build-Ziel für das Erstellen der Ansichten "BuildViews" und nicht "MvcBuildViews". Daher musste ich das BeforeTargets-Attribut entsprechend ändern. Ich habe auch das Ziel vereinfacht, indem ich die Variable PropertyGroup entfernte und die Bedingung vereinfachte:

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

In meinem Fall habe ich gesehen, dass, wenn ich MvcBuildViews und PrecompileDuringPublish habe, beide zutreffend sind - was dieses Problem verursacht hat.

Also entfernte ich das PrecompileDuringPublish und diese Lösung funktionierte für mich und ich bin seitdem nicht mehr mit diesem Problem konfrontiert.

 enter image description here

0
MoXplod