This project is read-only.

Include installed module or theme in visual studio solution

Topics: Customizing Orchard, Writing modules, Writing themes
Oct 10, 2012 at 8:38 AM

I've cloned the Orchard source code and i'm running Orchard from Visual Studio. When I install modules and themes from the gallary inside Orchard Dashboard, the modules and themes do not show up in visual studio. I need this because I often want to look at the sourcecode of a installed module, edit it, and run it through the debugger.

Is there a smooth way to get this done? Until now I have been manually editing the Orchard solution file to get the modules to show up in Visual Studio.

Oct 10, 2012 at 1:33 PM

That is how you do it -- open the Orchard solution in VS, right click the "Modules" folder -> Add Existing Project. 

A lot of people also copy the Orchard.sln under a different name for their project so they can customize the solution as you are doing. I used to do this, but now I moved to maintaining my project with a fork of Orchard as a subrepo, so I'd rather modify the original Orchard.sln. This way I can merge changes in from the main Orchard repo. 

Oct 12, 2012 at 8:06 AM

Worked like a charm!

Interessting thing you write about your setup with a fork! I'm about to write a few modules and themes and need to source control them. Even though changes to the Orchard source code are not so likely I guess the best way would be to source control the entire Orchard solution? If not I guess I would have to create a repository for every module/theme?

Could you point me in the right direction for how I could create a fork like you? I guess I have to use Medicurial? My company is using TFS, and that would be preferable if possible. 


Oct 12, 2012 at 2:03 PM
Edited Oct 12, 2012 at 4:06 PM

I don't know how to do it using TFS. I'll post some details about my source control process in another post, but essentially you go to "Source Code" tab in, and click "Fork". Create the fork, and clone it to your local machine. Create your own "default" branch, perhaps named "vgille-default" (hg branch vgille-default, hg commit -m "Created 'vgille-default' branch"). Make your modifications in the vgille-default branch, and when you want to pull updates from orchard source, you can do:

cd c:\projects\vgilles-orchard\

hg pull     // Pulls new changesets from the main Orchard repo, but doesn't modify your working dir, or your vgille-default branch

hg update vgille-default    // switch to your private branch, if you aren't already there

hg merge default  // merge changes from the public 'default' branch into your 'vgille-default' branch


The only modifications I make to the private fork are minor things like .sln, .csproj, and web.config updates and adding sub-repos for my modules and theme. Anything else, I try to push directly into orchard as a patch, which will eventually trickle back into my project when I do an "hg pull". 

For your modules and theme, you could add the code directly into the Orchard.Web/Theme and Orchard.Web/Modules folders in your private fork, and add 3rd party modules as subrepos (since you most likely won't change the code for these). Ideally I'd to keep my main module/theme out of the Orchard fork to avoid potential mistakes when merging in changes. It would also keep a layer of protection in case Orchard ever moves to Git. 

Oct 12, 2012 at 3:10 PM

Avoid TFS, we started with it, but encountered numerous problems, specially with dependencies!

What we use now is a hybrid of mercurial (codeplex) for the main orchard trunk, and git hub for our version on the same local repo. Like TheMonarch we don't modify the core code, but we do have changes to the .SLN, build scripts and some bug fixes we applied to modules we use.

This setup has been great so far, upgrading orchard has been smooth but the initial setup of git was a bit tricky with custom .gitignore files. Once i'm done with today's contribs I will post a guide on how to configure git.

@TheMonarch, noticed you're using subrepos? Don't you have admin overheads when commiting? I think that's the reason the new 1.x branch has moved away from subrepos in the main trunk.

Oct 12, 2012 at 4:04 PM

Can you describe a bit more about how you use both git and hg? I don't understand what you  mean by "and git hub for our version on the same local repo". 

Yes, there is a little overhead, mainly that pushes take a little longer. Commits are fine. I haven't had any merge issues, but that's because our main site's module and theme are just added to our private branch in our private orchard fork (so NOT subrepos). I use subrepos for example, for combinator, content slider, and other modules that I pull from codeplex or bitbucket. This lets me pull updates from those and have my releases point to specific changesets in those subrepos. I don't know of any way of getting around that. It's not a problem because we rarely touch code in those 3rd party modules.

It makes sense to get rid of subrepos in the Orchard core because those modules were going to eventually become part of the Orchard source anyway. The added overhead of putting them as subrepos wasn't worth it.

I'm very curious to hear your git/hg process. Maybe that's better than what I'm using at the moment.