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

103

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.

Dan
źródło
1
Jeśli w katalogu podrzędnym znajduje się dodatkowy plik web.config, spróbuj go usunąć.
user1154664

Odpowiedzi:

76

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

benpage
źródło
1
phil haack ma aktualizację dotyczącą tego problemu, dla tych, które działają w porównaniu z 2010 SP1: haacked.com/archive/2011/05/09/…
benpage
3
nb rozwiązanie, które phil ma na tym blogu NIE DZIAŁA dla mnie. powyższe rozwiązanie jest moim jedynym rozwiązaniem.
Benpage
9
Myślę, że usunięcie folderu obj jest znacznie prostszym rozwiązaniem i mniej do zapamiętania / utrzymania zmian w pliku projektu. Wydaje się, że to powinna być tutaj najlepsza odpowiedź. (stan na połowę 2011)
RyanW
FWIW, ten wpis faktycznie zmienia pośrednią ścieżkę wyjściową do publikacji ( \objścieżkę), a NIE MvcBuildViews. Różnica jest subtelna, ale znacząca.
newmanth
40

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

jimmay5469
źródło
26

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>
jrummell
źródło
Pracuje dla mnie. Skomentowałem również następujący cel do działania: <Target Name = "AfterBuild" Condition = "'$ (MvcBuildViews)' == 'true'"> <AspNetCompiler VirtualPath = "temp" PhysicalPath = "$ (ProjectDir)" /> < / Target>
kaptan
Aktualizacja - aktualizacja narzędzi MVC 3 powinna to naprawić. haacked.com/archive/2011/05/09/…
jrummell
3
Tak ... dodanie rmdir /S /Q "$(ProjectDir)\obj"do sekcji post build zgodnie z Microsoft Ticket rozwiązało problem!
Leniel Maccaferri
W 2012 roku docelowy CleanWebsitesPackageTempDir i CleanWebsitesTransformParametersFiles nie istnieje i nadal występuje błąd.
Dave
2
@jrummell ciekawe, otrzymuję ten błąd MachineToApplication, gdy widoki kompilacji są włączone w moim projekcie mvc4, myślę, że jest to w jakiś sposób powiązane.
Dave
24

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.

Chris Hynes
źródło
PLUS ONE wszystkie moje głosy za. W objteczce miałem jakieś resztki .
ta.speot.is
Redaktor narzeka, że ​​elementy wewnątrz <ItemGroup>są nieprawidłowe, ale zignoruj ​​to - i tak działa.
Kjell Rilbe
Działało świetnie i oszczędza mi bólu głowy związanego z usuwaniem folderu obj za każdym razem, gdy chcę zmienić konfigurację z debugowania na wydanie
Todd Skelton,
4

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.

Richard Szalay
źródło
Nie widzę tego rozwiązania budującego widoki. Celowo umieściłem błąd w moim widoku i ustawiłem PrecompileBeforePublish = True, a kompilacja nie zakończyła się niepowodzeniem. (Używam VS2012)
Hullah,
To rozwiązało problem podczas pracy w kompilacji VSO, w której próbowałem prekompilować z / p: PrecompileBeforePublish = true
Stephen McDowell
3

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

Paweł Gorczyński
źródło
3

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

nootn
źródło
1

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.

eppdog
źródło
1
Dzięki za to, ale tak naprawdę nie mogę oznaczyć MvcBuildViews jako False, ponieważ pomaga to rozwiązać problemy przed wdrożeniem.
Dan
0

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>
JotaBe
źródło
0

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.

wprowadź opis obrazu tutaj

MoXplod
źródło