For years, I’ve been plagued with the following error message when I publish Visual Studio MVC/WEB Api projects:
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.
It doesn’t matter if I publish from Visual Studio, a Jenkins or TeamCity process, or command line. Always the error. In typical Microsoft fashion, the error message is cryptic and gives the user absolutely no guidance as to how it should be properly resolved. Stack Overflow and others pointed to a problem with the config on the remote machine causing the issue. Since my publish process wasn’t making it mast the compile and package phase, I knew it was a local problem. As the error suggest, I searched the project for any ancillary configs that could be causing the error. No luck there either.
The curious part is that this error only crops up the SECOND time I published a project after cloning an clean version. This lead me to believe that something in the build/publish process was dropping artifacts that caused MSBuild to choke. I’d later find out that this is exactly the case. There is nothing in the project template nor any files I explicitly added that are causing the error. When publishing the project, it prepares the deployment by copying all of the files to be deployed in the ./obj/$(Configuration) folder. Included in those files are copies of the project web config. The next time a publish is run it tries to include the duplicated configs into the build process and throws the error.
Now that I figured out what caused the issue, I needed to figure out a way to fix it. When I manually publishing from Visual Studio, simply deleting the ./obj/ did the trick and I could get on with life. When I tried to automate this process, it became much more of a nuisance. I thought about writing bash files to explicitly delete the folder before publish, but that just seemed like the wrong approach for some reason. Then I stumbled on a SO post that suggested moving the ./obj/ out of the project folder. A much more savory solution.
To do this, there’s a line that I need to add to every published project file. If you’ve never edited a Visual Studio project file or MSBuild script, it’s relatively easy.
- Right click on the Project (not the solution) in Visual Studio
- Click “Unload Project” from the context menu.
- Right click on the project again, and select Edit <Project Name>
In the top of the markup file you’ll find a <ProjectGroup> node that contains all of the details of your project followed by additional <ItemGroup> and <PropertyGroup> nodes that define the content and configuration of the project. At the bottom of the top <ProjectGroup> node, add the following line:
<BaseIntermediateOutputPath>..build$(AssemblyName)obj</BaseIntermediateOutputPath>
Example:
This tells Visual Studio to place the obj folder at a level above the current project and outside of the build scope. At the solution level you’ll now see a folder .build<Project Name>obj… and it is no longer in conflict with your project config.
** Be sure to exclude the new folder build from your source code repository! **
Publish again and voila! No more error.
Additional Notes:
- The Visual Studio Project file is a large standardized MSBuild project file. I recommend learning more about MSBuild scripts if you plan to automate publishing and deployment. https://msdn.microsoft.com/en-us/library/7z253716.aspx
- To be clear, I never like updating the project config directly, because it’s not obvious to others working on the project when changed like this are made. In this case, however, there doesn’t seem to be any other way to implement this change. If you have a better solution, let me know in the comments and I’ll be happy to update the article!
I hope this saves someone else some time and frustration. As always, thanks for reading!