This project is read-only.

Development best practices for Orchard?

Topics: Customizing Orchard, Writing modules
Oct 26, 2011 at 2:47 PM
Edited Oct 26, 2011 at 2:48 PM

I am about to start a project that will basically use Orchard as the application shell for a number of application components (widgets, modules). Most of these application components will use an existing datasource (non-Orchard) 

During our proof of concept phase, we played with a number of scenarios for developing on Orchard, does anyone have any suggestions as to what works best for them? Does the Orchard team have any suggestions on best practices for structuring projects that are designed to integrate with Orchard?




Scenario 1: Keeping our Application module code separate and copying to Orchard


  •  Keeps Orchard clean until you're ready to push
  •  Allows you to potentially backup Orchard (DB, Modules folder, etc) before pushing changes
  • Keeps your Project code more organized as it can be in a different directory that the Orchard modules.
  •  No need to Keep Orchard code in your CVS Repo (we use GitHub)


  •  More difficult to debug as you have to attach the debugger every time
  •  Slows down build if you have a script that copies to the Orchard Modules folder for each compile.



Scenario 2: Build directly into the Orchard Solution


  •  Easier and faster to debug as all code and pdb's exists in one place
  •  Faster to build (you don't need a Post-Build  event event to copy the files to Orchard)


  •  Forces you to have your custom modules alongside the Orchard or third party modules, so less organized, less obvious to a new developer 
  •  Can corrupt Orchard if a build corrupts the Orchard database in some way 
    •  we had this happen numerous times earlier in our POC (Orchard 1.0)  which is why we opted for Scenario 1 at the time
  •  Less clean for managing your source control. You need a number of Ignore rules to eliminate all the stuff that you don't want to track in your VCS




any suggestions would be appreciated.



Oct 27, 2011 at 12:10 AM

I do #2 routinely, except that I do it with separate repositories for each of my modules. I don't have the issues you mention.

Nov 7, 2011 at 10:36 PM

We do #2 - using svn externals to separate our code from the Orchard code. We have our modules in directories elsewhere from the Orchard code, then use svn externals to map those folders into orchard/orchard.web/modules. It is really nice because we can run everything from the VS debugger with a simple f5. By using svn externals (or separate repos like previous poster) you can replace the Orchard code with very little hassle. We did this when 1.3.9 was released. We just swapped out the orchard code with no problems.

The only one of your complaints that I've experienced is the maintenance of the ignore rules. It is true that you have to add ignore rules for all the bin and obj folders under the Orchard folder. However it is not a huge task and only had to be done once.


Nov 12, 2011 at 1:08 PM

I'm interested in this. So, Is't good to use Orchard source solution for devel modules ( debug too )? Codegen put module skeleton under modules folder. Is't ok?

Nov 13, 2011 at 9:44 AM

I solved in this mode:

1) Download Orchard source

2) Open with Vs2010 and run project 

3) With CodeGen, I create a module. So, the module skeleton will be under modules folder.

4) Put in Orchard references.

5) Stop and rerun Orchard project

6) Enable the new module

7) Stop Orchard and develop your module. Then you can made debug

The only hassle is that you must run all Orchard project. If you use Orchard binary, you open them in Vs2010 as web site and attach module project, but you don't made debug ( I think ).

Nov 13, 2011 at 11:39 AM

Im #2

Nov 14, 2011 at 2:41 PM
Edited Nov 14, 2011 at 2:41 PM

I found this

Nov 15, 2011 at 10:49 AM

Thanks for your responses :)


We've opted for Scenario #2 with a Git repo and solid ignore rules for the Orchard folders and files that I don't want in Git. So far, seems to work well !