allowDefinition = błąd 'MachineToApplication' podczas publikowania z VS2010 (ale tylko po poprzedniej kompilacji)

Mogę uruchomić moją aplikację Asp.Net MVC 2 bez problemu na moim komputerze lokalnym. Po prostu uruchom / debuguj.

Ale jeśli już go zbudowałem, nie mogę go opublikować! Muszę wyczyścić rozwiązanie i ponownie je opublikować. Wiem, że to nie jest krytyczne dla systemu, ale jest naprawdę denerwujące. „Publikowanie jednym kliknięciem” to nie „czyste rozwiązanie, a następnie publikowanie jednym kliknięciem”

Dokładny błąd jest następujący:

Błąd 11 Błędem jest użycie sekcji zarejestrowanej jako allowDefinition = 'MachineToApplication' poza poziomem aplikacji. Ten błąd może być spowodowany tym, że katalog wirtualny nie jest skonfigurowany jako aplikacja w usługach IIS.

Podejrzewam, że ma to coś wspólnego z Web.Config w folderze Views, ale dlaczego dopiero po wcześniejszym skompilowaniu. Pamiętaj, że po opublikowaniu aplikacja działa dobrze.

miałem ten sam problem z moimi aplikacjami MVC. to było frustrujące, ponieważ nadal chciałem, aby moje widoki były sprawdzane, więc nie chciałem wyłączać MvcBuildViews

na szczęście trafiłem na post, który dał mi odpowiedź. zachowaj MvcBuildViews jako true , możesz dodać następujący wiersz poniżej w pliku projektu:

<BaseIntermediateOutputPath>[SomeKnownLocationIHaveAccessTo]</BaseIntermediateOutputPath>

I niech ten folder nie będzie w folderze twojego projektu. Pracuje dla mnie. To nie jest idealne rozwiązanie, ale na razie jest dobre. Upewnij się, że usunąłeś folder pakietu (znajdujący się w folderze obj \ Debug i / lub obj \ Release ) z folderu projektu, w przeciwnym razie błąd będzie nadal występował.

FWIW, MS wie o tym błędzie ...

Usunąłem wszystko z mojego folderu obj / Debug i naprawiłem ten błąd. To pozwoliło mi wyjść w

<MvcBuildViews>true</MvcBuildViews>

opcja w moim pliku projektu (która jest przydatna z szablonem T4MVC T4).

Edycja: można to osiągnąć znacznie łatwiej, używając po prostu menu „Build” -> „Rebuild Solution” (ponieważ to, co faktycznie robi odbudowa, to wyczyszczenie folderu obj / Debug, a następnie rozwiązanie kompilacji).

Używam tego obejścia na stronie MS Connect dla tego błędu. Czyści wszystkie pliki obj i tymczasowe w projekcie (wszystkie konfiguracje) przed uruchomieniem AspNetCompiler.

Zmodyfikuj element docelowy MvcBuildViews w pliku projektu, tak aby zależał od elementów docelowych, które oczyszczają pliki pakowania utworzone przez program Visual Studio. Te cele są automatycznie uwzględniane w projektach aplikacji internetowych.

Wszystkie pliki pakietów zostaną usunięte za każdym razem, gdy zostanie wykonany element docelowy MvcBuildViews.

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

Ten problem występuje, gdy w folderze obj znajdują się dane wyjściowe projektu sieci Web (szablon web.config lub tymczasowe pliki publikowania). Używany kompilator ASP.NET nie jest wystarczająco inteligentny, aby ignorować elementy w folderze obj, więc zamiast tego generuje błędy.

Inną poprawką jest nuke na wyjściu publikacji tuż przed wywołaniem <AspNetCompiler>. Otwórz plik .csproj i zmień to:

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

do tego:

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

Spowoduje to usunięcie wszystkich plików web.config w katalogu \ obj, a także wszystkich folderów PackageTmp w katalogu \ obj.

Jeśli korzystasz z funkcji Web Publish, możesz ustawić MvcBuildViews=falseiPrecompileBeforePublish=true , które prekompilują po skopiowaniu do folderu tymczasowego (bezpośrednio przed publikacją / pakietem).

UWAGA: PrecompileBeforePublishjest obsługiwany tylko przez „nowy” stos potoku publikowania w sieci Web (VS2010 SP1 + Azure SDK lub VS2012 RTM). Jeśli używasz VS2010 RTM, musisz użyć jednej z alternatywnych metod.

Jeśli chodzi o rozwiązanie autorstwa jrummell, ustawienie:

DependsOnTargets="CleanWebsitesPackage;CleanWebsitesPackageTempDir;CleanWebsitesTransformParametersFiles;"

To działa w VS 2010 , ale nie w VS 2012 . W 2012 roku trzeba postawić:

DependsOnTargets="CleanWebsitesPackage;CleanWebsitesWPPAllFilesInSingleFolder;CleanWebPublishPipelineIntermediateOutput"

Źródło:

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

Wiem, że otrzymałem odpowiedź, ale chciałem tylko dodać coś interesującego, co znalazłem.

W projekcie ustawiłem „MvcBuildViews” na false, usunąłem wszystkie foldery bin i obj i nadal otrzymywałem błąd. Okazało się, że istnieje plik „.csproj.user”, który nadal ma ustawioną wartość „MvcBuildViews” na true.

Usunąłem plik „.csproj.user” i wszystko działało.

Dlatego upewnij się, że zmieniasz plik csproj, aby zmienić lub usunąć również plik „.csproj.user”.

Miałem również ten problem, więc utworzyłem zdarzenie przed kompilacją we właściwościach projektu, aby wyczyścić katalogi wyjściowe ( ${projectPath}\bin,${projectPath}\obj\${ConfigurationName}). W innym projekcie również otrzymywałem ten błąd, nawet po przeprowadzeniu czyszczenia. W drugim projekcie kompilowałem widoki wymienione w pliku projektu:

<MvcBuildViews>true</MvcBuildViews>

Zmieniłem prawdę na fałsz i nie narzekał już na ten błąd, ale nadal działał poprawnie. Nie twierdzę, że wiem dokładnie, co spowodowało drugi błąd, ale przynajmniej na razie posunąłem się naprzód.

Problem dotyczy plików pośrednich, ale istnieje inne rozwiązanie polegające na wyczyszczeniu tych plików pośrednich przed zbudowaniem widoków.

To rozwiązanie zostało zawarte w niektórych wersjach VS, ale mogę tylko powiedzieć, że miałem problem w VS 2013 Update 5. (Zobacz "Uwaga" poniżej, można to naprawić w tej wersji, ale nie działa tylko w moim przypadek niestandardowy).

Rozwiązanie pożyczyłem od Error: allowDefinition = 'MachineToApplication' poza poziomem aplikacji w Visual Studio Connect.

Rozwiązanie polega .csprojna dołączeniu tych wierszy do projektu ( pliku) aplikacji internetowej, które obsługują usuwanie gotowych plików pośrednich:

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

Uwaga: z jakiegoś powodu, prawdopodobnie dlatego, że włączyłem go sam do projektu, mój cel kompilacji do budowania widoków został nazwany "BuildViews"zamiast "MvcBuildViews", więc musiałem odpowiednio zmodyfikować BeforeTargetsatrybut. Uprościłem też cel, usuwając PropertyGroupi upraszczając warunek, na przykład:

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

W moim przypadku widziałem, że kiedy mam MvcBuildViews i PrecompileDuringPublish jako oba prawdziwe - to był ten problem.

Usunąłem więc PrecompileDuringPublish i to rozwiązanie zadziałało i od tego czasu nie napotkałem tego problemu.