Recently – like many others – I checked out Visual Studio 2012 to see what kind of problems a version jump would cause in my most important projects. I was too skeptical, all of my projects loaded and worked in the new version, even with building for .Net Framework 4.5. So far so good, but then I had to realize that the Web Deployment Projects plug-in won't be available from now on. VS2012 comes with a very cool publishing wizard, as long as your project is a Web Application. If you won't or can't upgrade from a Website Project then your only choice is the rather dumb Publish function which doesn't generate the best result and it can't merge assemblies created for the website project. Easy publishing to a specified folder and merging the randomly named App_whatever assemblies into a single assembly was the sole reason I used WDP. Unfortunately I can't really transform my projects into Web Application project types, it would cause too much work for too little gain, so I rolled out my own command line tool WebDeploy to solve this problem. :)
Key functionality is provided by MSBuild to build the Solution and ILMerge (latest version) to merge the project assemblies into a single assembly. WebDeploy configures and runs these, updates assembly references in your relevant project files and gives a helping hand in cleaning up and running additional tasks, doing it all by using the Settings XML file that you personalized for your project. To prove that I take dogfooding seriously, this website has been compiled and published by using WebDeploy.
Just to avoid a possible misunderstanding, I better clarify that you don't need to run Publish or anything in Visual Studio before running WebDeploy. Once your project is ready to upload (works, rebuilds without errors), just run WebDeploy.exe MySettings.xml (obviously with full paths if needed) and it will rebuild and fix up your website project using the provided Solution file and other settings. Aunt Edna mode off. :)
You may check out where the default Publish function is building your website, for me it always happens to be (Project folder)\PrecompiledWeb\myproject.local (the website's local URL for IIS in my system). Weirdly enough, if I change the Output Folder using Property Pages -> MSBuild Options, it doesn't actually change the AspNetCompiler.TargetPath values in the Solution (.sln) file, so if you're not satisfied with the default Output Folder, you may have to edit the solution file manually. It has to be done only once. WebDeploy can handle all variations of Updateable website and Use fixed names settings, in my setup these options are Updateable=true and FixedNames=false.
After building the project, your selected assemblies will be merged. In my experience all these assemblies are named in the pattern App_*.dll so the default entry in the Sample.xml file will be fine for most (if not all) cases. Choose a simple and unique assembly name for merging target and the references in project files (aspx, ascx, master – the list is editable in the app's .config file) and .compiled files will be updated to use the single assembly's name. Mind you, my Solutions contain 1 website project and multiple library projects, so you may have extra configuration needs if yours is more complicated, like it has multiple websites. You can set up plenty of things in the Settings.xml file, see the provided Sample.xml values and the MSBuild manual, if needed. No worries, chances are you won't need to do anything special above putting sensible values into the provided XML nodes.
You can set up a list of files that should be deleted after building and merging, and you can also set up a list of shell commands to execute before and after building. With this you can easily script a clean up so you won't upload not needed (or server dependent) files and compress, maybe even upload the prepared website.
Just make a copy of the Sample.xml file and change it around for your own projects, I'm pretty sure you'll be satisfied with the result. As it turned out, it's significantly faster than Web Deployment Projects on the same hardware, over twice the speed for me. ILMerge and the full source code is provided with the tool.