Multiple Developers Against a Single Instance of Orchard

Topics: Installing Orchard, Troubleshooting
Sep 6, 2012 at 9:22 PM
Edited Sep 7, 2012 at 2:15 PM

I have my Orchard site sitting in TFS Source Control so that several developers can code against it at one time. If I don't include the App_Data Settings in source control, each dev is prompted to configure a new Orchard instance. If I *do* include the App_Data Settings, I get mixed results because of the cache.dat file and Settings.txt Hash and Encryption Keys. 

Does anyone have any insight on having multiple developers work against a single Orchard code base and db cleanly?

  • and no, getting rid of TFS isn't an option =)
  • I'd prefer to use a full SQL Server setup instead of a shared SQL CE

See the Answer below

Sep 7, 2012 at 11:54 AM

We use TFS and everyone has their own separate sql server instance running on their local pc.

Once every while we take a dump of our live environment and use that to work on.

We also have a dev server where we test new builds on before pushing it live.

Sep 7, 2012 at 1:05 PM

With everyone working off of their on SQL Server instance, how does your team stay in sync between "refreshes"? I could see issues of DevA making a schema change that DevB needs, but because they are on separate SQL instances, DevB has to wait on DevA to migrate their changes. Possibly a lot of overhead.

I guess I was wondering about concurrent development against a singe Orchard code base that hits a single SQL Server instance.

Sep 7, 2012 at 1:12 PM

Use TFS to lock the migration class whenever you do something like that?

" I could see issues of DevA making a schema change that DevB needs"

Soo DevB will NEED a schema change that DevA made but didn't commit yet? That seems weird..

Anyhow, we didn't run in any big issues yet so this works for us.

If you want to use a shared database (with the risk that any of the devs could break it by making a db change that requires new code that he didn't commit yet) - be my guest ^^

Sep 7, 2012 at 1:27 PM

Good point. I guess we could lock down Migrations and make intermittent updates. Thanks for the feedback.

Sep 7, 2012 at 1:29 PM

Np, sorry if I sounded bit hars:, I usually have a good point behind what I say, but I sometimes have troubles explaining myself ;)

Sep 7, 2012 at 2:14 PM
Edited Sep 7, 2012 at 2:17 PM

AimOrchard presented a nice solution, but after a little digging, I think I found something closer to what I was originally looking for. Hopefully the solution will help someone else.

The Original Problem

TFS places a lock on your local files. When Orchard.Web is built, it needs \App_Data\ to be writable in order to do what it does best - otherwise you'll get 404 errors when you attempt to run your site. Ordinarily, you wouldn't include the App_Data folder in source because this is auto-generated, but in our case, we needed the site's Settings.txt to be persisted so that anyone that pulls the Orchard source down will automatically be up and running against the Orchard SQL Server instance that is already configured. Settings.txt has all of that information, but it's deep inside of App_Data.

The Answer

Visual Studio Build Events (or Pre-build Events in our case). 

attrib -r $(ProjectDir)App_Data\*.* /s /d

By adding this Pre-build Event command line to the Orchard.Web project, anytime Orchard.Web is built, all read-only attributes are removed from all files within App_Data. This allows the various files within App_Data to be written and updated locally without the developer having to remember to change the folder/file permissions.

The only semi-gotcha to this is if you get latest from TFS, and then try to manually navigate to the URL of your site before building. Though, I'm not sure why you would normally do this.

Hope this helps.