104

I can run my Asp.Net MVC 2 application without an issue on my local computer. Just Run / Debug.

But if I have already built it, I can't publish it! I have to clean the solution and publish it again. I know this is not system critical, but it's really annoying. "One Click Publish" is not "Clean solution and then One click publish"

The exact error is as follows:

Error 11 It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.

I suspect it's something to do with the Web.Config in the Views folder, but then why only after I build once previously. And just to note, the app works fine once published.

1
  • 1
    If there is an extra web.config in a child directory, try removing it. Commented Nov 5, 2012 at 15:12

10 Answers 10

76

i had the same problem with my MVC apps. it was frustrating because i still wanted my views to be checked, so i didn't want to turn off MvcBuildViews

luckily i came across a post which gave me the answer. keep the MvcBuildViews as true, then you can add the following line underneath in your project file:

<BaseIntermediateOutputPath>[SomeKnownLocationIHaveAccessTo]</BaseIntermediateOutputPath>

And make that folder not in your project's folder. Works for me. It's not a perfect solution, but it's good for the moment. Make sure you remove the package folder (located inside the obj\Debug and/or obj\Release folder) from your project folder otherwise you'll keep getting the error.

FWIW, MS know about this error...

4
  • 1
    phil haack has an update on this issue, for those that run vs 2010 SP1: haacked.com/archive/2011/05/09/…
    – benpage
    Commented May 10, 2011 at 1:54
  • 3
    nb the solution that phil has on that blog DOES NOT work for me. the above solution is my only solution.
    – benpage
    Commented May 18, 2011 at 23:14
  • 10
    I think the deleting of the obj folder is a much simpler solution and less to remember/maintain about changes in the project file. Seems like that should be the top answer here. (as of mid 2011)
    – RyanW
    Commented Aug 24, 2011 at 14:16
  • FWIW, this entry actually changes the intermediate output path for publishing (the \obj path) , NOT MvcBuildViews. The difference is subtle, but significant.
    – newmanth
    Commented May 7, 2015 at 17:27
40

I deleted everything out of my obj/Debug folder and it fixed this error. This allowed me to leave in the

<MvcBuildViews>true</MvcBuildViews>

option in my project file (which comes in handy with the T4MVC T4 template).

Edit: This can be achieved much easier by simply using the "Build" -> "Rebuild Solution" menu (because what rebuild actually does is clear the obj/Debug folder and then build solution).

0
26

I'm using this workaround on the MS Connect page for this error. It cleans all obj and temp files under your project (all configurations) before running AspNetCompiler.

Modify the MvcBuildViews target in your project file so that it depends on the targets that clean up the packaging files that Visual Studio has created. These targets are included in web application projects automatically.

All packaging files will be deleted every time that the MvcBuildViews target executes.

<Target Name="MvcBuildViews" AfterTargets="AfterBuild" Condition="'$(MvcBuildViews)'=='true'" DependsOnTargets="CleanWebsitesPackage;CleanWebsitesPackageTempDir;CleanWebsitesTransformParametersFiles;">
    <AspNetCompiler VirtualPath="temp" PhysicalPath="$(MSBuildProjectDirectory)" />
</Target>
7
  • Works for me. I also commented the following target to work: <Target Name="AfterBuild" Condition="'$(MvcBuildViews)'=='true'"> <AspNetCompiler VirtualPath="temp" PhysicalPath="$(ProjectDir)" /> </Target>
    – kaptan
    Commented Jun 1, 2011 at 23:53
  • Update - The MVC 3 Tools Update should fix this. haacked.com/archive/2011/05/09/…
    – jrummell
    Commented Oct 6, 2011 at 19:23
  • 3
    Yes... adding rmdir /S /Q "$(ProjectDir)\obj" to the post build section as per the Microsoft Ticket solved the problem! Commented May 3, 2012 at 21:16
  • In 2012, the target CleanWebsitesPackageTempDir and CleanWebsitesTransformParametersFiles does not exist, and still get the error.
    – David
    Commented Aug 24, 2012 at 16:14
  • 2
    @jrummell interesting, I am getting this MachineToApplication error when build views is enabled in my mvc4 project, thought it was somehow related.
    – David
    Commented Aug 27, 2012 at 13:17
24

This problem occurs when there is web project output (templated web.config or temporary publish files) in the obj folder. The ASP.NET compiler used isn't smart enough to ignore stuff in the obj folder, so it throws errors instead.

Another fix is to nuke the publish output right before calling <AspNetCompiler>. Open your .csproj and change this:

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

to this:

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

That will delete all web.configs under \obj, as well as all PackageTmp folders under \obj.

3
  • PLUS ONE all my upvotes. I had some detritus in the obj folder. Commented Dec 16, 2014 at 6:36
  • The editor complains that the elements inside the <ItemGroup> are invalid, but ignore that – it works anyway. Commented Mar 22, 2016 at 16:19
  • Worked great and saves me from the headache of deleting the obj folder every time I want to switch my config from debug to release Commented Oct 25, 2017 at 13:54
4

If you are using Web Publish, you can set MvcBuildViews=false and PrecompileBeforePublish=true, which precompiles after the copy to the temporary folder (immediately before publish/package).

NOTE: PrecompileBeforePublish is only supported by the "new" Web Publishing Pipeline stack (VS2010 SP1 + Azure SDK or VS2012 RTM). If you're using VS2010 RTM, you'll need use one of the alternative methods.

2
  • I don't see this solution building the views. I purposely put an error in my view and set PrecompileBeforePublish=True and it did not fail the build. (I'm using VS2012)
    – Hullah
    Commented Jun 10, 2013 at 13:22
  • This solved it for me working in a VSO build where I was attempting to precompile with /p:PrecompileBeforePublish=true Commented May 1, 2018 at 17:22
3

Regarding the solution by jrummell, the setting:

DependsOnTargets="CleanWebsitesPackage;CleanWebsitesPackageTempDir;CleanWebsitesTransformParametersFiles;"

It works in VS 2010, but not in VS 2012. In 2012 you have to put:

DependsOnTargets="CleanWebsitesPackage;CleanWebsitesWPPAllFilesInSingleFolder;CleanWebPublishPipelineIntermediateOutput"

Source:

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

0
3

I know this has been answered but I just wanted to add something interesting I found.

I had set the "MvcBuildViews" to false in the project, deleted all bin and obj folders and I was still getting the error. I found that there was a ".csproj.user" file that still had "MvcBuildViews" set to true.

I deleted the ".csproj.user" file and then it all worked.

So make sure if you are changing your csproj file that you either change or delete the ".csproj.user" file also.

1

I had this problem as well, so I created a Pre-Build Event in the project properties to Clean the output directories(${projectPath}\bin,${projectPath}\obj\${ConfigurationName}). On another project I was also getting this error, even with the cleaning event in place. On the second project I was compiling the views as listed in the project file:

<MvcBuildViews>true</MvcBuildViews>

I changed the true to false, and it no longer complained about that error, but still ran correctly. I won't claim I know exactly what was causing the second error, but at least it got me moving forward for the time being.

1
  • 1
    Thanks for that, but I can't really mark the MvcBuildViews as False as it helps fix issues before I deploy.
    – Dan
    Commented Apr 26, 2010 at 8:16
0

The problem has to do with the intermediate files, but there is another solution which consist in cleaning up those intermediate files before builnding the views.

This solution has been included in some version of VS, but I can only say that I had the problem in VS 2013 Update 5. (See the "Beware" below, it could be fixed in this version, but not working only in my particular non-standard case).

I borrowed the soltuion from Error: allowDefinition='MachineToApplication' beyond application level on Visual Studio Connect.

The solution consist in including these lines to the web application project (.csproj file) which handle the deletion of the offedning intermediate files:

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

Beware: for some reason, probably because I included it myself in the project, my build target for building the views was named "BuildViews", instead of "MvcBuildViews", so I had to modify the BeforeTargets attribute accordingly. I also simplified the target, by removing the PropertyGroup and simplifying the condition, like this:

  <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

In my case i saw that when i have MvcBuildViews and PrecompileDuringPublish as both true - was what was causing this issue.

So i removed the PrecompileDuringPublish and that solution worked for me and i have not faced this problem since.

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.