visual studio net deploy asp asp.net-mvc web-deployment one-click-web-publishing

asp.net mvc - studio - allowDefinition=Error ''MachineToApplication'' al publicar desde VS2010(pero solo despuĆ©s de una compilaciĆ³n anterior)



web deploy visual studio 2017 (10)

Borré todo de mi carpeta Obj / Debug y corrigió este error. Esto me permitió irme 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 simplemente usando el menú "Crear" -> "Reconstruir solución" (porque lo que realmente hace la reconstrucción es borrar la carpeta obj / Debug y luego construir la solución).

Puedo ejecutar mi aplicación Asp.Net MVC 2 sin problemas en mi computadora local. Solo Ejecutar / Depurar.

¡Pero si ya lo construí, no puedo publicarlo! Debo limpiar la solución y publicarla nuevamente. Sé que esto no es crítico para el sistema, pero es realmente molesto. "One Click Publish" no es "Solución limpia y luego One click publish"

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 el Web.Config en la carpeta de Vistas, pero ¿por qué solo después de que construí una vez anteriormente? Y solo para observar, la aplicación funciona bien una vez publicada.


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 la actualización 5 de VS 2013. (Consulte "Cuidado" a continuación, podría solucionarse en esta versión, pero no solo en mi caso particular). caso no estándar).

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

La solución consiste en incluir estas líneas en el proyecto de aplicación web (archivo .csproj ) que gestiona la eliminación 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í en el proyecto, mi objetivo de compilación para construir las vistas se llamaba "BuildViews" , en lugar de "MvcBuildViews" , así que tuve que modificar el atributo BeforeTargets consecuencia. También simplifiqué el objetivo eliminando PropertyGroup y 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>


En cuanto a la solución de jrummell, el ajuste:

DependsOnTargets="CleanWebsitesPackage;CleanWebsitesPackageTempDir;CleanWebsitesTransformParametersFiles;"

Funciona en VS 2010 , pero no en VS 2012 . En 2012 debes 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


En mi caso, vi que cuando tengo MvcBuildViews y PrecompileDuringPublish como 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.


Este problema se produce cuando hay salida de proyecto web (archivos web de configuración con plantilla o publicación temporal) en la carpeta obj. El compilador de 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 desarticular 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>

Esto eliminará todos los archivos web.configs en / obj, así como todas las carpetas de PackageTmp en / obj.


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 objetivo MvcBuildViews en su archivo de proyecto para que dependa de los objetivos que limpian los archivos de empaque que Visual Studio ha creado. Estos objetivos se incluyen automáticamente en proyectos de aplicaciones web.

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>


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

Había configurado "MvcBuildViews" como falso en el proyecto, borré todas las carpetas bin y obj y aún recibía 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ó.

Así que asegúrese de que si está cambiando su archivo csproj, también puede cambiar o eliminar el archivo ".csproj.user".


Si está utilizando Web Publish, puede establecer MvcBuildViews=false y PrecompileBeforePublish=true , que precompila después de la copia en la carpeta temporal (inmediatamente antes de publicar / paquete).

NOTA: PrecompileBeforePublish solo es compatible con la "nueva" pila de Pipeline de Publicación Web (VS2010 SP1 + Azure SDK o VS2012 RTM). Si usa VS2010 RTM, necesitará usar uno de los métodos alternativos.


También tuve este problema, así que creé un evento de ${projectPath}/bin,${projectPath}/obj/${ConfigurationName} 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 figuran en el archivo del proyecto:

<MvcBuildViews>true</MvcBuildViews>

Cambié el verdadero a falso, y ya no me quejé de ese error, pero aun así funcioné correctamente. No afirmaré que sé exactamente qué estaba causando el segundo error, pero al menos me hizo avanzar por el momento.


tuve el mismo problema con mis aplicaciones MVC. fue frustrante porque aún quería que se revisaran mis vistas, así que no quería apagar MvcBuildViews

Afortunadamente encontré una post que me dio la respuesta. Mantenga MvcBuildViews como verdadero , luego puede agregar la siguiente línea debajo en su archivo de proyecto:

<BaseIntermediateOutputPath>[SomeKnownLocationIHaveAccessTo]</BaseIntermediateOutputPath>

Y no hagas esa carpeta en la carpeta de tu proyecto. Funciona para mi. No es una solución perfecta, pero está bien por el momento. Asegúrese de eliminar la carpeta del paquete (que se encuentra dentro de la carpeta obj / Debug y / u obj / Release ) de la carpeta del proyecto, de lo contrario, seguirá recibiendo el error.

FWIW, MS sabe sobre este error ...