This issue describes the background and reason for the pull request "Role content folders" located here:
As you all know, for packaging Orchard for deployment to Windows Azure there is a custom MSBuild file (AzurePackage.proj) in the root folder. This file duplicates the entire compilation and packaging process and circumvents the corresponding default processes
built into the SDK. It does this for one simple reason: to get all the content files of themes and modules into the final package. (The Orchard.Azure.Web has assembly references to all modules so their DLL files will be included, but since they reside in a
different place in the directory structure, their content files won't automatically be included).
This comes at a price, in that the Azure SDK tooling and build process is completely circumvented, so many enhancements made to the SDK after this custom MSBuild file was created simply don't apply to Orchard because Orchard is packaged completely separately,
outside the SDK and Visual Studio. The custom MSBuild file basically represents a snapshot of how the build and packaging process used to work at the time when it was created (probably around the time Azure SDK 1.3 was released - a long time ago).
Anyway, the good news is: since Azure SDK 1.7 this is no longer necessary.
There is now a mechanism called "role content folders" that can be used to dynamically add arbitrary content to the final package at build time. More information
I have refactored the Orchard.Azure.CloudService and Orchard.Azure.Web projects to utilize this mechanism.
- We can use the Azure tooling! Deploying Orchard to Windows Azure is now a simple one-click operation from within Visual Studio. This greatly simplifies things such as creating cloud service, creating and uploading the necessary certificates, etc. since
all this is automated in newer versions of the tooling.
- Features that depend on role content folders now work. Example: adding a diagnostics configuration file to a role using the VS tooling had no effect when using AzurePackage.proj, but now it works properly. This also made it possible to move the ConfigureIIS.cmd
startup task into the role content folder in the cloud service project, where it belongs.
- The AzurePackage.proj solution was hard coded for Release build configuration. Now, we have the ability to deploy a Debug build to Windows Azure if we want - simply select the appropriate build config when doing Package/Publish.
- The AzurePackage.proj solution contained hard coded modifications of Web.config and Log4net.config for a release mode deployment. Now these changes are handled through config transformations instead (better because you can now deploy those files with debug
values if you want).
- Continuous deployment from TFS to Windows Azure should now "just work". It should no longer be necessary to do any cumbersome workarounds to set this up, such as
http://www.cloudconstruct.com/blog/continuous-delivery-for-an-orchard-cloud-service-in-windows-azure. (I have not tested this part out yet though.)
- For advanced projects where Orchard is part of a larger cloud service architecture, more roles can now be added to the Azure project simply by adding them in VS. Before, they also had to be carefully worked into the AzurePackage.proj file (which was not
trivial, believe me). For example, adding an Azure Cache role to the service.
I also upgraded the Azure project to the latest SDK version 2.1. While not necessary for these improvements, I thought it made sense to bring it up to date at the same time.
I left the AzureProject.proj and ClickToBuildAzure.cmd files around for now, and they still work, but we will probably want to remove those as well to avoid confusion.