What exactly is needed when deploying an Orchard website

Topics: General
Jun 27, 2012 at 9:49 AM

Currently, to deploy Orchard, we do a full build of the whole solution, run it once locally, copy/paste everything (from Orchard.Web) to a separate folder and remove all the folders from the App_Data (minus Dependencies sometimes).

We then run a custom made tool on it that copies all files to a 2nd folder, while copying duplicate files only once. Then it generates a bat files that, once executed, copies the duplicate files into position.

We then create a rar SFX archive that once executed and unpacked, runs the .bat file (that will copy the duplicate files back in place)

This way we can upload ~1.16GB of data (plenty of duplicate DLL files..) as a single ~30mbyte self-unpacking executable.

Is this a valid approach? Or don't I need all those duplicate dll files (in their bin folders) in the first place?

This method is OK for us at the moment, but we're just wondering if there is another (read: better) alternative.

Coordinator
Jun 27, 2012 at 6:08 PM

You can also double click "ClickToBuild.cmd" and it will do everything you described by itself ;)

You can also customize your own build step to remove tests or packaging ...

Mar 28, 2013 at 1:23 AM
When I run 'ClickToBuild.cmd' it still creates the full gamut of duplicate DLLs and the build folder is over 900mb.

AimOrchard - did you manage to replicate your desired behaviour using 'ClickToBuild.cmd'?
Developer
Mar 28, 2013 at 2:43 AM
Edited Mar 28, 2013 at 2:44 AM
Are you looking in the correct folder? Stage for example should be somewhere between 70 and 100 MB (depending on the size of other modules and assets that are included).
Mar 29, 2013 at 1:56 PM
I always use the visual studio command prompt, go to the folder with the build cmd files then type:
Build "compile; package"

Then ijust copy the stage folder that is in the build folder.
Like sfmskywalker my folder is then around the 70mb size
Apr 3, 2013 at 11:16 PM
Edited Apr 3, 2013 at 11:20 PM
It appears there were some compile errors which were ignored by 'publish', that were picked up by 'ClickTobuild.cmd'.
rper's Build "compile; package" idea works great if you want to omit the unit tests, otherwise ClickTobuild.cmd is the way to go.
All is well again. Thanks to all for the feedback :)