This project is read-only.

Logic behind the 1.0 project file, development and continuous integration

Jan 14, 2011 at 5:37 PM

I just downloaded the 1.0 project file. It seems that a lot of files aren't included in the Orchard.Web project file, or they just don't exist at all. For example, Orchard.Blogs has all the files on disk, but only a few included in the project. I'm guessing that the ones included in the project are the only ones that need to be copied to a web directory, the others are only code files to create the Orchard.Blogs.dll which Orchard copies into the dependencies folder. However, some modules, such as CodeGeneration have a folder included in the Orchard.Web project, but there are no files in that folder on disk. Why?

I'm trying to figure out a good way to manage a development environment using the 1.0 release as a starting point. Ideally, I don't want to have to modify any of the existing modules. So, I don't need them in the project but I'm wondering how to manage continuous integration and deployment. I plan on having a separate solution for my own modules that I can have Team City pull can copy to the Modules folder of my deployed Orchard site. Is there then any need to have any files from my modules included in the Orchard.Web project?

Jan 14, 2011 at 5:55 PM
Scott, the modules all need to be deployed to the serveras source code, orchard dynamically compiles them at runtime (though of course there is caching so you don't keep taking the hit for that). Not sure if there is a story for deploying modules as dlls or not. I do know that including them in the orchard.web project leads to errors since the classes end up defined twice.
Jan 14, 2011 at 6:09 PM

Yes, deploying module as dlls + cshtml view files is doable. I recall doing that some time ago, and worked without problems. You just have to remember not to deploy .cs files and dlls (duplication)

- Piotr

Jan 14, 2011 at 6:13 PM

I'm using the Orchard.proj file in the repository to get an idea of how that builds a deployment. I think I'll be able to use that, we'll see. If I get it working in a reasonable manner, I'll post back her with my results.

Jan 14, 2011 at 9:38 PM

Scott: in your case, you should *not* start with the WebPI or the Orchard.Web release. You should get the full source code release, or even better a source code enlistment. This is the right configuration for doing development. You *could* do some lightweight module development with just the web site project but it's not going to be optimal.

The web project only contains what you need to run the application. The full source code has the multi-project solution that will enable you to have the full vision.

Jan 15, 2011 at 12:46 AM

What do you mean by a "source code enlistment"? I'd really like to be able to somehow depend on library files for Orchard so that when I need to update to a newer version in the future, I can replace those. An alternative would be acceptable, but I can't figure out a good way to pull from the repository and maintain a separate development environment that would allow me to pull updates from codeplex, as well as maintain my own local repository for my team's development and integration with team city. 

Jan 15, 2011 at 4:11 AM

I mean this:

For your own module's repository, first create a clone of your repository in a completely separate folder and then move it into the modules folder. That's what we do.

Mar 30, 2011 at 10:24 PM


Can you describe a little more what you mean by this last step: "Create a clone of your repository in a completely separate folder and then move it into the modules folder." ?

This aspect has been giving me a headache for the last few days.  Can you give an example of how we can set this up?

Mar 30, 2011 at 10:42 PM

So you're going to set-up or you already have a repository for your module, right? You should do that part first in a completely separate directory from your Orchard enlistment. Then you take that directory you prepared for your module, and you move that into the Modules folder of your src/Orchard.Web. When Mercurial works on your Orchard repo, it won't touch yours because it has its own hg info files. When it works on your repo, it will not affect what's above it.

Makes sense?

Mar 30, 2011 at 10:58 PM


Thanks for the quick response, Bertrand.

So you are assuming a setup where there is one repository per module?  Or is there a way to make it so that we can group all of our modules/themes into a single local repository and still do this?

Mar 30, 2011 at 11:09 PM

You are correct. For multiple modules, I don't have a good answer. We'll be building a doc topic around this but for the moment that's the best I have.

Mar 31, 2011 at 12:13 AM


Thank you.

Mar 31, 2011 at 5:53 AM

I saw another post recommending using NTFS hard links. So you have a repository with all your modules, and each module is also hard linked into Orchard.Web/Modules on your Orchard enlistment.

Mar 31, 2011 at 6:07 AM


That sounds nice except that your local clone of the Orchard repository probably won't know not to treat your modules separately from itself.  Additionally, working with your modules' repository would have to be done in the original directory, rather than from the hard links.

One thing I was thinking was that it would be nice if Orchard would source modules not directly from subdirectories of Modules/ but rather from any arbitrary number of subdirectories off of Modules/

For example:




      (standard modules that come with orchard, such as Orchard.Blogs, Orchard.jQuery)


      (modules released by company A)


      (modules released by company B)

and so on

That way, we would be able to root our repositories at the "CompanyA" level, and Mercurial would be able to know not to go any further.  Orchard just needs to know to look one level deeper but still to copy the resulting module DLL file to the same output directory as it does right now.

Themes/ could take the same structure too.

Mar 31, 2011 at 6:17 AM

"That sounds nice except that your local clone of the Orchard repository probably won't know not to treat your modules separately from itself."

At worst those files will show up as untracked. You can also tell HG to ignore them.

But I like your suggested folder structure, it would make things more manageable when there are a lot of modules!

Mar 31, 2011 at 7:26 AM

Actually I just thought about it some more...

Since for now the main types of modules we'd create are just modules and themes, it would be nice to have a structure where we can have Modules/ and Themes/ branch from a "plugins" directory.

For example,





        (Modules such as Orchard.Blogs and Orchard.jQuery)


        (Modules such as TheThemeMachine)



        (Modules released by company A)


        (Themes released by company A)


Doing it this way, the CompanyA, etc., directory can now be an HG Repository and house all modules and themes.

(And if additional types of plugins arise in the future they can be added alongside these the same way)


Maybe I can tweak around with the current solution files to realize such an organization of folders...