allowDefinition='MachineToApplication' msbuild error

Question

We have a ASP.NET MVC with 4-5 different build configurations. Whenever we change the build configuration, we need to delete the obj folder for the web project, since we get

Answer 1

I too was deleting the obj folder until I had a conflict with a build script which required it. Catch-22, I used the accepted answer on the following SO link to move the location of the Obj folder to C:\Temp\BUILD. You have to do it per csproj file, but it is a great solution.

Here is the link: VisualStudio: How to save the obj folder somewhere else

Note that I am using a variable for the project name. R:\Temp\Build\Debug\$(MSBuildProjectName)

I have the above line in both debug and release sections for all my projects, including class projects. My build path is a ram drive for speed. See this SO for more info: How to access macro variables within csproj file?

Answer 2

This is not necessarily the exact same issue, and to be honest, probably down to pure lack of knowledge on my part, however I had this same error when:

1. I set up a standard asp.net new project actually just used for HTML5 stuff so nothing other than the usual project structure
2. I then (not thinking perhaps!) added a new WCF REST project (which actually was just another base asp.net project using very good examples from http://www.codeproject.com/Articles/128478/Consuming-WCF-REST-Services-Using-jQuery-AJAX-Call?fid=1597004&df=90&mpp=25&noise=3&prof=False&sort=Position&view=Quick&fr=26#xx0xx and http://geekswithblogs.net/michelotti/archive/2010/08/21/restful-wcf-services-with-no-svc-file-and-no-config.aspx

The problem was I added the WCF REST project (#2) as a SUB-DIRECTORY of the main project (#1) and then tried to build! even if I cleaned the project of course.. I also made both projects use IISexpress because I thought there was an issue using the same port or something.

Of course the build process saw the web.config from #1 and then a sub-dir with another web.config #2..

I realise this probably should be a very basic understood gotcha and it has caught me out a while ago, however sometimes it's the simplest of mistakes that are a real pain!

Might help others... who perhaps haven't had their morning coffee..

Answer 3

There is a similar question here on SO with some good solutions for this issue.

The problem is that building a deployment package creates a copy of the web.config in a subfolder of /obj. That will normally be be cleared out if you do a rebuild or a clean. However, if you build a deployment package in one configuration (e.g. Debug) and then switch to another confguration (e.g. Release) the obj/Debug folder is not cleared out and the web.config file there causes problems.

The quick solution is to clean all configurations and then do a (re)build. Alternatively you could delete the /obj folder in your project. To permanently resolve the issue you can either move the intermediate output (/obj) out of your project folder or modify the project to force a clean of all configurations on rebuild.

Answer 4

That error indicates that you are trying to something specific to an application at an IIS tree level that isn't defined as an application. For example if you try to do app-level functions in a web.config in a virtual directory, you will get that error. You need to find the path you are deploying to and make sure that it is defined in IIS as an application vs a folder or vdir.

Answer 5

I just answered a similar question here. To recap, I ran into this problem in one of our MVC projects, and it was due to having the MvcBuildViews property in the project file set to true. Setting the property to false fixed the problem.

<MvcBuildViews>false</MvcBuildViews>

I also found this answer which outlines an alternative that does not require turning off view building.

Answer 6

Althoug the problem is explained and solved in one way in the accepted answer, I wanted to show a solution which can be better for other cases. 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 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 (which wans't a solution for the accepted answer, as he needed those 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.