ASP.NET MVC Project Build Failure When Switching Between Configurations
Recently I set up multiple different configurations for my ASP.NET project with different
.config file transformations for different environments. After I started switching between them on a regular basis, the following build error started showing up every time I changed to a different configuration:
...\obj\debug\web.config(40): error ASPCONFIG: 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.
As you can see the error points to the
web.config file inside
obj folder. It always belonged to a configuration which I was building before switching to the current one. The issue could of course be resolved by manually deleting the offending file, but I soon got tired of this and decided to investigate further.
I quickly noticed that the problem was limited to the ASP.NET MVC project only. The other web project in the solution, hosting a WCF web service also contained multiple configurations, but there were no build errors after switching between them. This was finally enough information to find that others were already writing about it. It turned out that the problem would go away if I disabled building of views by removing the following property from the project file:
By disabling this feature I would loose the build time check of view validity against their current models, therefore I didn't want to do it and had to find a different solution. In the end I settled with just deleting the problematic files inside the
obj folder before each build, by adding the following command to the ASP.NET MVC project pre-build event:
del "$(ProjectDir)obj\*.*" /s /q
I could have deleted just the
web.config files, but this would mean having a delete command for each configuration and also remembering to add another command each time a new configuration was added. Since files in
obj folder are regenerated each time any way, this seemed a more pragmatic solution.