allowDefinition = Error 'MachineToApplication' al publicar desde VS2010 (pero solo después de una compilación anterior)


103

Puedo ejecutar mi aplicación Asp.Net MVC 2 sin problemas en mi computadora local. Simplemente ejecute / depure.

Pero si ya lo he construido, ¡no puedo publicarlo! Tengo que limpiar la solución y volver a publicarla. Sé que esto no es crítico para el sistema, pero es realmente molesto. "Publicar con un clic" no es "Solución limpia y luego publicar con un clic"

El error exacto es el siguiente:

Error 11 Es un error utilizar una sección registrada como allowDefinition = 'MachineToApplication' más allá del nivel de la aplicación. Este error puede deberse a que un directorio virtual no está configurado como una aplicación en IIS.

Sospecho que tiene algo que ver con Web.Config en la carpeta Vistas, pero entonces, ¿por qué solo después de compilar una vez anteriormente? Y solo para tener en cuenta, la aplicación funciona bien una vez publicada.


1
Si hay un web.config adicional en un directorio secundario, intente eliminarlo.
user1154664

Respuestas:


76

Tuve el mismo problema con mis aplicaciones MVC. fue frustrante porque todavía quería que se verificaran mis vistas, así que no quise apagar MvcBuildViews

afortunadamente me encontré con una publicación que me dio la respuesta. mantenga los MvcBuildViews como verdaderos , luego puede agregar la siguiente línea debajo en su archivo de proyecto:

<BaseIntermediateOutputPath>[SomeKnownLocationIHaveAccessTo]</BaseIntermediateOutputPath>

Y haga que esa carpeta no esté en la carpeta de su proyecto. Funciona para mi. No es una solución perfecta, pero es buena por el momento. Asegúrese de eliminar la carpeta del paquete (ubicada dentro de la carpeta obj \ Debug y / o obj \ Release ) de la carpeta de su proyecto; de lo contrario, seguirá recibiendo el error.

FWIW, MS conocen este error ...


1
phil haack tiene una actualización sobre este problema, para aquellos que ejecutan vs 2010 SP1: haacked.com/archive/2011/05/09/…
benpage

3
nb, la solución que Phil tiene en ese blog NO funciona para mí. la solución anterior es mi única solución.
benpage

9
Creo que eliminar la carpeta obj es una solución mucho más simple y menos para recordar / mantener sobre los cambios en el archivo del proyecto. Parece que esa debería ser la respuesta principal aquí. (a mediados de 2011)
RyanW

FWIW, esta entrada en realidad cambia la ruta de salida intermedia para la publicación (la \objruta), NO MvcBuildViews. La diferencia es sutil, pero significativa.
newmanth

40

Eliminé todo de mi carpeta obj / Debug y solucionó este error. Esto me permitió salir en el

<MvcBuildViews>true</MvcBuildViews>

opción en mi archivo de proyecto (que es útil con la plantilla T4MVC T4).

Editar: Esto se puede lograr mucho más fácilmente usando el menú "Construir" -> "Reconstruir solución" (porque lo que realmente hace la reconstrucción es borrar la carpeta obj / Debug y luego construir la solución).


26

Estoy usando esta solución en la página de MS Connect para este error. Limpia todos los archivos obj y temp de su proyecto (todas las configuraciones) antes de ejecutar AspNetCompiler.

Modifique el destino MvcBuildViews en su archivo de proyecto para que dependa de los destinos que limpian los archivos de empaquetado que Visual Studio ha creado. Estos destinos se incluyen en los proyectos de aplicaciones web de forma automática.

Todos los archivos de empaquetado se eliminarán cada vez que se ejecute el destino MvcBuildViews.

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

Funciona para mi. También comenté el siguiente objetivo para que funcione: <Target Name = "AfterBuild" Condition = "'$ (MvcBuildViews)' == 'true'"> <AspNetCompiler VirtualPath = "temp" PhysicalPath = "$ (ProjectDir)" /> < / Target>
kaptan

Actualización: la actualización de herramientas MVC 3 debería solucionar este problema. haacked.com/archive/2011/05/09/…
jrummell

3
Sí ... ¡agregar rmdir /S /Q "$(ProjectDir)\obj"a la sección de compilación posterior según Microsoft Ticket resolvió el problema!
Leniel Maccaferri

En 2012, los CleanWebsitesPackageTempDir y CleanWebsitesTransformParametersFiles de destino no existen y siguen apareciendo el error.
Dave

2
@jrummell interesante, obtengo este error MachineToApplication cuando las vistas de compilación están habilitadas en mi proyecto mvc4, pensé que estaba relacionado de alguna manera.
Dave

24

Este problema ocurre cuando hay un resultado de proyecto web (web.config con plantilla o archivos de publicación temporales) en la carpeta obj. El compilador ASP.NET utilizado no es lo suficientemente inteligente como para ignorar cosas en la carpeta obj, por lo que arroja errores en su lugar.

Otra solución es destruir la salida de publicación justo antes de llamar a <AspNetCompiler>. Abra su .csproj y cambie esto:

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

a esto:

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

Eso eliminará todos los web.configs en \ obj, así como todas las carpetas PackageTmp en \ obj.


MÁS UNO todos mis votos a favor. Tenía algunos detritos en la objcarpeta.
ta.speot.is

El editor se queja de que los elementos dentro del <ItemGroup>no son válidos, pero ignórelo, funciona de todos modos.
Kjell Rilbe

Funcionó muy bien y me ahorra el dolor de cabeza de eliminar la carpeta obj cada vez que quiero cambiar mi configuración de depuración a versión
Todd Skelton

4

Si está utilizando Web Publish, puede configurar MvcBuildViews=falsey PrecompileBeforePublish=true, que se precompila después de la copia en la carpeta temporal (inmediatamente antes de publicar / empaquetar).

NOTA: PrecompileBeforePublishsolo es compatible con la "nueva" pila de canalización de publicación web (VS2010 SP1 + Azure SDK o VS2012 RTM). Si está utilizando VS2010 RTM, deberá utilizar uno de los métodos alternativos.


No veo esta solución construyendo las vistas. Puse intencionalmente un error en mi vista y configuré PrecompileBeforePublish = True y no falló la compilación. (Estoy usando VS2012)
Hullah

Esto me resolvió trabajando en una compilación de VSO donde estaba intentando precompilar con / p: PrecompileBeforePublish = true
Stephen McDowell

3

En cuanto a la solución de jrummell, la configuración:

DependsOnTargets="CleanWebsitesPackage;CleanWebsitesPackageTempDir;CleanWebsitesTransformParametersFiles;"

Se trabaja en VS 2010 , pero no en VS 2012 . En 2012 tienes que poner:

DependsOnTargets="CleanWebsitesPackage;CleanWebsitesWPPAllFilesInSingleFolder;CleanWebPublishPipelineIntermediateOutput"

Fuente:

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

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


3

Sé que esto ha sido respondido, pero solo quería agregar algo interesante que encontré.

Establecí "MvcBuildViews" en falso en el proyecto, eliminé todas las carpetas bin y obj y seguía recibiendo el error. Descubrí que había un archivo ".csproj.user" que todavía tenía "MvcBuildViews" establecido en verdadero.

Eliminé el archivo ".csproj.user" y luego todo funcionó.

Por lo tanto, asegúrese de que si está cambiando su archivo csproj, cambie o elimine también el archivo ".csproj.user".


1

También tuve este problema, así que creé un evento de precompilación en las propiedades del proyecto para limpiar los directorios de salida ( ${projectPath}\bin,${projectPath}\obj\${ConfigurationName}). En otro proyecto, también recibí este error, incluso con el evento de limpieza en su lugar. En el segundo proyecto, estaba compilando las vistas que se enumeran en el archivo del proyecto:

<MvcBuildViews>true</MvcBuildViews>

Cambié el verdadero a falso y ya no se quejó de ese error, pero aún se ejecutó correctamente. No diré que sé exactamente qué estaba causando el segundo error, pero al menos me hizo avanzar por el momento.


1
Gracias por eso, pero realmente no puedo marcar MvcBuildViews como False, ya que ayuda a solucionar problemas antes de implementarlo.
Dan

0

El problema tiene que ver con los archivos intermedios, pero hay otra solución que consiste en limpiar esos archivos intermedios antes de construir las vistas.

Esta solución se ha incluido en alguna versión de VS, pero solo puedo decir que tuve el problema en VS 2013 Update 5. (Ver la sección "Cuidado" continuación, podría solucionarse en esta versión, pero no funciona solo en mi caso no estándar).

Tomé prestada la solución de Error: allowDefinition = 'MachineToApplication' más allá del nivel de aplicación en Visual Studio Connect.

La solución consiste en incluir estas líneas en el proyecto ( .csprojarchivo) de la aplicación web que gestiona el borrado de los archivos intermedios de salida:

<!--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 alguna razón, probablemente porque lo incluí yo mismo en el proyecto, mi objetivo de compilación para construir las vistas fue nombrado "BuildViews", en lugar de "MvcBuildViews", así que tuve que modificar el BeforeTargetsatributo en consecuencia. También simplifiqué el objetivo, eliminando PropertyGroupy simplificando la condición, así:

  <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

En mi caso, vi que cuando tengo MvcBuildViews y PrecompileDuringPublish ambos verdaderos, era lo que estaba causando este problema.

Así que eliminé PrecompileDuringPublish y esa solución funcionó para mí y no he enfrentado este problema desde entonces.

ingrese la descripción de la imagen aquí

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.