Isolated development environment

Topics: Customizing Orchard, General
Jul 26, 2013 at 7:38 PM
Edited Jul 26, 2013 at 8:52 PM
I am new to an ongoing Orchard project. This project involves about 50 custom modules running along with the standard Orchard modules. The task I have been given is to create a development environment for our implementers that has as few source files as possible, but still allows them to create their own custom Orchard modules. I've spent about 2 days on this and keep running into problems. Currently, I'm getting errors from Orchard.Environment.Extensions.Compilers.DefaultExtensionCompiler complaining that it can't find the .cs file which I removed. Is there anyone with experience doing this kind of thing? Or is it just a rule that all source code must be available when compiling modules?

Thanks for any help you can provide.
Coordinator
Jul 26, 2013 at 7:55 PM
Why do they want "a development environment [...] that has as few source files as possible". That doesn't seem to make any sense. Of course if you remove source files it won't compile.
Jul 26, 2013 at 8:01 PM
They want the implementers to be able to build their own custom modules, but not modify any of the existing modules. I'm not removing the Orchard.Web source, and I'm trying to use references to DLLs and the like to get it to run. My problem seems to be with the dynamically loaded modules needing to have source code present at run time (when running in VS). As I said, I am fairly new to Orchard so I may be overlooking some standard way of doing this.
Coordinator
Jul 26, 2013 at 8:18 PM
While it is possible to build modules with the runtime distribution only, it is not recommended. The full source code is recommended for developers. In any case, you need your own source code in order to be able to build your module. What references are you talking about?
Jul 26, 2013 at 8:43 PM
Thank you for such rapid responses.

The references I'm talking about are like how Orchard.Web references Orchard.Core, Orchard.Framework, and Orchard.WarmupStarter. Instead of using Project references, I changed these to just point to the dlls in a \lib folder I created for this purpose. I also put all the module dlls in there. I'm not sure what you mean about my own modules. Our custom modules certainly have to be compiled, but the hope is that they'll be built, and then the environment for the implementers will just use the dlls. Is there any information online about building modules with the runtime distribution only? I understand it is not recommended, but if the documentation contains explanations of why, they might help us understand what we should be doing instead.

James
Coordinator
Jul 26, 2013 at 8:45 PM
I really think you're going into entirely the wrong direction. Developing with the source code is the way to go. I don't understand why you'd want to do otherwise.
Jul 26, 2013 at 9:39 PM
You should handle this at the build / deploy process level. Let everyone use the sources the way Orchard was meant to be used. Set up a TeamCity or other similar build server that will check out a clean version of the Orchard core (or your own fork of it), and have the build process check out the modules. That way even if people modified core, the build system won't pick up those modifications.
Developer
Jul 27, 2013 at 12:32 AM
Edited Jul 27, 2013 at 12:33 AM
Bertrand's entirely right - you should use full source at dev time. Going the 'static dll' way means opening a can of worms. Not every (almost none) module can be easily compiled to a single dll only. There are files like views, scripts, stylesheets, images, manifest file etc. that are not put into the dll. What you could do is to keep those modules that are not supposed to be changed precompiled and outside of the dev solution. This way those won't be built each time, resulting with faster builds.
Coordinator
Jul 27, 2013 at 4:58 AM
This being said, Orchard builds in seconds on a modern machine so that's not worth the trouble.