This project is read-only.

Building a developer-friendly development environment custom Orchard modules/themes

Topics: Customizing Orchard, Writing modules, Writing themes
Nov 19, 2013 at 7:23 PM
I'm working on setting up a development environment for a team of developers to develop custom modules/themes in MSVS 2012/13 with Orchard 1.7.1 . We use Subversion for version control. We use IIS 7.5 as a web server in production and IIS Express for development. We're not planning on making changes to the Orchard project code (at least for now) and we do not have an enlistment.

I've been trying to come up with a directory structure and solution file (.sln) structure that allows for easy upgrades of Orchard and allows us to keep our code segregated from the Orchard code. Unfortunately I'm coming up short on both objectives.

The physical perspective:

Since custom modules and themes are required to be in a subfolder of the ~\Modules or ~\Themes in the deployment (whether IIS Express for development or IIS for production) it appears to me that I will have to check the Orchard code into subversion. I can check it in using a versioned path e.g. "OrchardDev\Orchard\1.7.1" or unversioned path "OrchardDev\Orchard". I also have to check in our custom modules and themes into directories within the Orchard code.

When a new version of Orchard becomes available I have to do one of the following: If I used the unversioned path approach, then I will have to merge the new Orchard code into my repository. If I use the versioned path approach, then I will have to check in the new Orchard code into a new directory ("OrchardDev\Orchard\1.8.0") and merge my custom modules/themes into that new directory.

I suppose one alternative is to play some tricks and set up some links using the "mklink /J" command, but I'm not sure how well Subversion gets along with links.

The logical perspective:

As we know, the Solution file (.sln) is the way Visual Studio organizes all of the relevant components being worked on and worked with. I've seen developers simply add their custom components to Orchard.sln. Sometimes they are grouped in a separate solution folder within Orchard.sln. I guess any solution file needs to include Orchard.Web project and all dependencies to make Orchard work. I've built my own "OrchardDev.sln" which contains everything from Orchard.sln placed in a solution folder plus my own custom projects. This gets the job done, but if I use the versioned path approach, I'll have to make a ton of changes to the solution file when a new Orchard version is released to pick up all of the code from the new version's path.

My questions are:
  • Are any of my observations/conclusions incorrect?
  • How are you segregating your custom code from Orchard code (physically/logically)?
  • Are you using symlinks to get around the requirements that modules and themes must be in ~\Modules and ~\Themes?
Thanks for reading this rather long-winded question. Hopefully this question and your feedback will help future Orchard developers.
Nov 20, 2013 at 9:09 PM
I found some helpful comments that address my question on the Orchard Hungary site:
Nov 21, 2013 at 11:15 PM
Glad to see our post helped :-).