Source Code Organization
Notice: This page is deprecated and may contain information that is out-of-date. We've moved our docs to our new project website wiki,
Please visit that site for the most up-to-date information.
This section describes the project structure when the Orchard solution is opened in Visual Studio.
- Orchard.Web is an MVC Web Application project. This is the application that you'll run. It is the startup project of the application.
It contains the Orchard CMS core platform, aka Orchard CMS Host application.
- Orchard.Framework (previously Orchard) is a class library project containing the Orchard CMS framework.
- A set of core modules and content types for Orchard, such as feeds, theming, navigation or the common, routable and body content parts.
- Modules is a Visual Studio solution folder containing Orchard module projects.
- Integrates the TinyMCE HTML editor into Orchard.
- Orchard.Media is an MVC Web Application project containing the Orchard Module responsible for managing and rendering Media.
- Orchard.Users is an MVC Web Application project that contains the Orchard module responsible for managing users.
- Orchard.Roles is an MVC Web Application project that contains the Orchard module responsible for managing user roles.
- Orchard.Sandbox is an MVC Web Application project that is not active in Orchard by default (the module.txt file is renamed _module.txt) and that implements a sample content type.
- Orchard.Blogs is an MVC Web Application project that contains the Orchard module responsible for managing and rendering blogs and blog posts.
- Orchard.Comments is an MVC Web Application project that contains the Orchard module responsible for managing and rendering comments on content items.
- Orchard.DevTools is an MVC Web Application project that is not active in Orchard by default (the module.txt file is renamed _module.txt) and that contains some development and debugging tools for Orchard content types.
- Orchard.Tags is an MVC Web Application project that contains the Orchard module responsible for managing and rendering tags on content items.
- Orchard.Pages is an MVC Web Application project containing the Orchard Module responsible for managing and rendering CMS Pages.
- Orchard.Setup is an MVC Web Application project containing the Orchard Module responsible for initial setup of the application.
the following projects can be found under the Test folder:
- Orchard.Web.Tests is the test project for the Orchard.Web project.
- Orchard.Tests.Modules is the test project for Orchard modules. It contains subfolders for different modules.
- Orchard.Core.Tests is the test project for the Orchard.Core project.
- Orchard.Framework.Tests is the test project for the Orchard.Framework project.
- Orchard.Specs contains integration tests written with a
SpecFlow style (see *.feature files).
This folder contains the source code for tools that are used to build the Orchard solution.
It also contains the Orchard project, which builds the orchard.exe command-line tool that you can use to run commands defined in an Orchard web site in order to perform and automate administrative tasks.
Projects in the Futures folder are considered experimental.
- Futures.Widgets is a preliminary implementation of widgets, including a simple HTML global widget.
- Orchard.Web is set as the "Startup Project" of the solution when using Visual Studio debugging. Orchard.Web dynamically loads all Orchard modules and discovers module extensibilty points (MVC routes, admin pages. etc.)
- The projects in the "Modules" folder are physically located under the "Ochard.Web\Modules" folder. This allows modules to contain ASP.NET views (aspx, ascx) and static content without having to copy files between projects to be
able to run the project.
- The Orchard.Web project has project references to the various modules. This is simply to enable automatic copying of the output assemblies into the "bin" directory of Orchard.Web. Orchard.Web has
no type dependency to types in the Modules assemblies, as the Orchard.Web project is not supposed to have a compile time knowledge of which modules are loaded at run-time (even thought this is not entirely true at the current stage of development).
- The projects in the "Modules" folder have a project reference to the "Orchard" project. This allows modules to have access to the base orchard services.
- Why are Core modules modules? The difference is similar to OS concepts of monolithic vs micro-kernel: it was pretty obvious during high level design of Orchard that an extensibility point such as modules was needed. Everything else would constitute the
core framework. Take the Common module for example, which introduces the BodyAspect, a core concept common to many types of content types, such as blog posts or pages. Now we could've implemented this as part of the Orchard framework dll, and have modules
depend on it. But then it wouldn't get the benefit of being a module, such as being able to hook up handlers, drivers, views, routes etc. This also relates to MVC and areas, where everything that belongs to an area is under the same directory. It was pretty
clear that the right choice was to get some core concepts out of the framework dll into a separate dll, and have them be modules. This is very similar to non-monolithic operating systems where parts of the core functionality is implemented as modules outside
the kernel, talking to it via the same exact interfaces as the more higher level modules.
- Why are Core modules core modules? Now that we want core concepts to be implemented as modules, why not put them into the modules directory along with the rest of the more obvious Orchard modules, such as the comments module. Well, this time it's about
dependencies. In Orchard, modules that are in the modules directory can be disabled, uninstalled or otherwise updated in a breaking way. We don't really want modules to depend on other modules : that's part of the entire dynamism behind the content
type architecture. Pages and Blog posts, which belong to Pages and Blog modules, don't reference Comments or Tags modules, but it's possible to attach comments or tags to pages and blogposts. This decoupled behavior is ensured by the underlying content
type architecture and not by direct reference from one or the other modules. Core modules are part of the Orchard framework and it's ok for modules to depend on them. They will be distributed by us and for all practical purposes are integral parts of the
Orchard framework. Modules can depend on them and directly access their public surface.