I recently encountered an ASP.Net deployment error with a Web Deploy package that had me banging my head against the wall and none of the online solutions worked. I learned a few valuable tidbits that any new .net web developer should find useful.
Long story short: ALWAYS fix the first error. This is CS 101 stuff. (But you can learn SO much more by attacking the problem from other angles and learning how things work.)
TL;DR: Solution at the bottom.
I’m trying to master ASP.Net MVC. My project was working fine locally with IIS Express and Visual Studio but at some point it has to go live. So I decided to move it to a server running IIS. I opted to try something new and chose Web Deploy Package.
Web Deploy Package
A Web Deploy package is essentially a zip file with a few supporting text files that you can copy to an IIS server and have Web Deploy extract the files at a later time. Here’s a screenshot of my staging directory.
I gave the readme.txt a quick once over, installed Web Deploy v3, created a website via the IIS Management console, copied the files to the website root directory, and launched “Stagger.deploy.cmd /y”
It failed with an error –
Retrying operation ‘Delete’ on object filePath (Stagger\Stagger.zip).
Error Code: ERROR_FILE_IN_USE.
So I thought it was no big deal – it’s just deleting stuff on cleanup and it left a zip file behind. Inconvenient but easily fixed.
I launch a local browser and get a Newtonsoft.Json binding error.
Could not load file or assembly ‘Newtonsoft.Json, Version=184.108.40.206, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
The web is littered with attempts to fix this problem. The only difference is my version is 220.127.116.11 and build 8.0.3. So I go through the list of attempted fixes.
- I verify the file versions and timestamps are the same in all places.
- I delete files from the temporary cache.
- I reinstall the package in Visual Studio.
- I make sure all other packages are up to date.
- I check and recheck the web.config settings.
I finally check the actual deployment directory. Many of my files are missing. It turns out that the Stagger.zip file wasn’t actually being deleted on cleanup – it was being deleting sequentially and once the deployment hit that failure it bombed out and stopped deploying.
The binding error was being thrown because the bindingRedirect wasn’t specified because the web.config file wasn’t copied.
That seems like a really poor design. I go back to Visual Studio and change the deploy settings to try outputting _Z.zip instead. This time it mostly works as expected but I still get the error deleting the zip file, it just happens to be the last file so THAT isn’t a problem. After the copies complete however the ACL’s aren’t applied. THAT could be a problem.
About now the coffee starts working (need to switch to espresso) and I realize that I’ve made an assumption that Web Deploy treats the zip file like an in-place extraction because I can’t actually specify the output directory. Wrong. Part of the setup wizard in Visual Studio is specifying the Site name. This value is saved in the SetParameters.xml file and it appears that Web Deploy searches IIS for this site name and extracts the zip to the site’s Physical Path.
Don’t copy the deploy files to the physical root of the website. Copy them to a staging folder and run the cmd file from there.
If you have a binding redirect failure in deployment that you don’t have in Visual Studio then you may be missing a web.config file.
Also, make sure the web.config file properties in Visual Studio are “Content” and “Do Not Copy.” “Content” indicates it’s an ‘inert’ file – not to be consumed by any tool, and the “Copy to Output Directory” options will control whether the file is additionally copied to the bin folder. Only the binary files should be in there. All of the views and scripts and images should be Content/Do Not Copy.
In contrast to a Web Deploy package, deploying the project to Azure was free and flawless and took about ten minutes, six of which was watching an intro video.