AllowDefinition=Erro 'MachineToApplication' ao publicar no VS2010 (mas somente após uma compilação anterior)

Question

Posso executar meu aplicativo Asp.Net MVC 2 sem problemas em meu computador local.Basta executar/depurar.

Mas se já o construí, não posso publicá-lo!Tenho que limpar a solução e publicá-la novamente.Eu sei que isso não é crítico para o sistema, mas é realmente irritante."Publicação com um clique" não é "Solução limpa e publicação com um clique"

O erro exato é o seguinte:

ERRO 11 É um erro usar uma seção registrada como allowDefinition = 'MachinetoApplication' além do nível do aplicativo.Este erro pode ser causado por um diretório virtual não ser configurado como um aplicativo no IIS.

Suspeito que tenha algo a ver com o Web.Config na pasta Views, mas por que só depois de construir uma vez anteriormente.E só para observar, o aplicativo funciona bem depois de publicado.

Answer 1

Eu tive o mesmo problema com meus aplicativos MVC. Foi frustrante porque eu ainda queria que minhas opiniões fossem verificadas, então não queria desligar MVCBuildViews

Felizmente eu me deparei com um publicar o que me deu a resposta. Mantenha as visualizações MVCBuild como verdadeiro, então você pode adicionar a seguinte linha embaixo do seu arquivo de projeto:

<BaseIntermediateOutputPath>[SomeKnownLocationIHaveAccessTo]</BaseIntermediateOutputPath>

E faça essa pasta não na pasta do seu projeto. Funciona para mim. Não é uma solução perfeita, mas é bom para o momento. Certifique -se de remover o pacote pasta (localizada dentro do Obj Debug e/ou OBJ Release pasta) na pasta do projeto, caso contrário, você continuará recebendo o erro.

Fwiw, MS sabe sobre este erro...

Answer 2

Excluí tudo da minha pasta obj/Debug e isso corrigiu esse erro.Isso me permitiu sair no

<MvcBuildViews>true</MvcBuildViews>

opção no meu arquivo de projeto (que é útil com o modelo T4MVC T4).

Editar:Isso pode ser conseguido de maneira muito mais fácil simplesmente usando o menu "Build" -> "Rebuild Solution" (porque o que a reconstrução realmente faz é limpar a pasta obj/Debug e então construir a solução).

Answer 3

Estou usando esta solução alternativa no MS CONNECT página para este erro. Ele limpa todos os arquivos OBJ e Temp em seu projeto (todas as configurações) antes de executar aspnetCompiler.

Modifique a meta MVCBuildViews no seu arquivo de projeto, para que dependa das metas que limpam os arquivos de embalagem que o Visual Studio criou. Essas metas estão incluídas nos projetos de aplicativos da Web automaticamente.

Todos os arquivos de embalagem serão excluídos toda vez que o MVCBuildViews Target é executado.

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

Answer 4

Esse problema ocorre quando há saída de projeto da Web (modelo web.config ou arquivos de publicação temporários) na pasta obj.O compilador ASP.NET usado não é inteligente o suficiente para ignorar coisas na pasta obj, então gera erros.

Outra correção é destruir a saída da publicação antes de chamar <AspNetCompiler>.Abra seu .csproj e altere isto:

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

para isso:

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

Isso excluirá todos os web.configs em \obj, bem como todas as pastas PackageTmp em \obj.

Answer 5

Se você estiver usando a publicação da web, pode definir MvcBuildViews=false e PrecompileBeforePublish=true, que pré -compile após a cópia para a pasta temporária (imediatamente antes da publicação/pacote).

NOTA: PrecompileBeforePublish é suportado apenas pela pilha de pipeline da Web Publishing "New" (vs2010 SP1 + Azure SDK ou VS2012 RTM). Se você estiver usando o VS2010 RTM, precisará usar um dos métodos alternativos.

Answer 6

Em relação à solução de Jrummell, a configuração:

DependsOnTargets="CleanWebsitesPackage;CleanWebsitesPackageTempDir;CleanWebsitesTransformParametersFiles;"

Isto trabalha em vs 2010, mas não em vs 2012. Em 2012, você tem que colocar:

DependsOnTargets="CleanWebsitesPackage;CleanWebsitesWPPAllFilesInSingleFolder;CleanWebPublishPipelineIntermediateOutput"

Fonte:

VS 2010: C: Arquivos de Programas (x86) Msbuild Microsoft VisualStudio V10.0 Web Microsoft.web.publishing.targets

VS 2012: C: Arquivos de Programas (x86) Msbuild Microsoft VisualStudio V11.0 Web Microsoft.Web.publishing.Targets

Answer 7

Eu sei que isso foi respondido, mas eu só queria adicionar algo interessante que encontrei.

Eu havia definido as "MVCBuildViews" como false no projeto, excluí todas as pastas de lixeira e OBJ e ainda estava recebendo o erro. Descobri que havia um arquivo ".csproj.user" que ainda tinha "mvcbuildviews" definido como true.

Excluí o arquivo ".csproj.user" e então tudo funcionou.

Portanto, verifique se você está alterando seu arquivo csproj, também altera ou exclua o arquivo ".csproj.user".

Answer 8

Eu também tive esse problema, então criei um evento de pré-construção nas propriedades do projeto para limpar os diretórios de saída (${projectPath}\bin,${projectPath}\obj\${ConfigurationName}).Em outro projeto também estava recebendo esse erro, mesmo com o evento de limpeza em vigor.No segundo projeto eu estava compilando as visualizações listadas no arquivo do projeto:

<MvcBuildViews>true</MvcBuildViews>

Alterei true para false e ele não reclamou mais desse erro, mas ainda funcionou corretamente.Não vou afirmar que sei exatamente o que estava causando o segundo erro, mas pelo menos isso me fez seguir em frente por enquanto.

Answer 9

O problema tem a ver com os arquivos intermediários, mas existe outra solução que consiste em limpar esses arquivos intermediários antes de construir as visualizações.

Esta solução foi incluída em algumas versões do VS, mas só posso dizer que tive o problema na Atualização 5 do VS 2013.(Veja o "Cuidado" abaixo, poderia ser corrigido nesta versão, mas não funcionaria apenas no meu caso particular não padrão).

Peguei emprestada a solução de Erro:allowDefinition='MachineToApplication' além do nível do aplicativo no Visual Studio Connect.

A solução consiste em incluir estas linhas no projeto da aplicação web (.csproj arquivo) que trata da exclusão dos arquivos intermediários ofendidos:

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

Cuidado: por algum motivo, provavelmente porque eu mesmo o incluí no projeto, meu alvo de construção para construir as visualizações foi nomeado "BuildViews", em vez de "MvcBuildViews", então tive que modificar o BeforeTargets atribua adequadamente.Também simplifiquei o alvo, removendo o PropertyGroup e simplificando a condição, assim:

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

Answer 10

No meu caso, vi que, quando tenho MVCBuildViews e pré -compilado, como ambos - era o que estava causando esse problema.

Então, removi o Publish pré -compilado e essa solução funcionou para mim e não enfrentei esse problema desde então.