This project is read-only.

Having my Modules src outside of the Orchard.Web\Modules folder?

Topics: Writing modules
Sep 12, 2012 at 5:19 AM

I want to be able to build my modules in any folder totally outside of the orchard structure and then have the compilation build into orchard.web

Is that even possible?

For example, I have c:\Orchard\src\Orchard.Web\...

and my modules are in: c:\MyDevelopment\modules\...

What has to be deployed into Orchard.Web and where?

Sep 12, 2012 at 5:40 PM

You would have to write your own module loader. There is one built-in that deals with loading modules from /Core for example.

Sep 12, 2012 at 5:54 PM

Well I thought the solution to this would be to have VS2012 publish directly into Orchard.Web\Modules. The Publish did create Orchard.Web\Modules\HelloWorld but when running orchard it still didn't work. (yes I did enable the module :) )

Interestingly, if I copy the source ans .csproj file into that folder it will then work.

Here is the error that I am getting:

{"The controller for path '/OrchardLocal/HelloWorld' was not found or does not implement IController."}

   at System.Web.Mvc.DefaultControllerFactory.GetControllerInstance(RequestContext requestContext, Type controllerType)
   at System.Web.Mvc.DefaultControllerFactory.CreateController(RequestContext requestContext, String controllerName)
   at System.Web.Mvc.MvcHandler.ProcessRequestInit(HttpContextBase httpContext, IController& controller, IControllerFactory& factory)
   at System.Web.Mvc.MvcHandler.BeginProcessRequest(HttpContextBase httpContext, AsyncCallback callback, Object state)
   at System.Web.Mvc.MvcHandler.BeginProcessRequest(HttpContext httpContext, AsyncCallback callback, Object state)
   at System.Web.Mvc.MvcHandler.System.Web.IHttpAsyncHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData)
   at Orchard.Mvc.Routes.ShellRoute.HttpAsyncHandler.BeginProcessRequest(HttpContext context, AsyncCallback cb, Object extraData) in c:\atrieveERP\workspace\Orchard\src\Orchard\Mvc\Routes\ShellRoute.cs:line 140
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

Sep 12, 2012 at 5:57 PM

Now I'm confused about what you're trying to do. Why don't you let dynamic compilation do its job?

Sep 12, 2012 at 6:07 PM

ok, The scenareo is for development only.

I have two GIT projects. One for each company. Company A has some modules and Company B has some Modules. I cannot download both from GIT into Orchard.Web\Modules. Therefore I installed c:\GitSource\CompanyA\modules and c:\GitSource\CompanyB\modules. These two companies do share modules or at least they will share modules in the future.

So, I either write a module loader that looks into the two new folders as you originally suggested or I just compile the code in c:\GitSource\CompanyA\modules and c:\GitSource\CompanyB\modules and then use VS2012's publish to compile and publish the modules into c:\Orchard\Orchard.web\Modules

I tried the publish from vs2012 but then I get the error you see in the previous post.

Sep 12, 2012 at 6:09 PM

Why can't you have your git repos in /Modules? I don't get it.

Sep 12, 2012 at 6:17 PM

Wouldn't the .git folders between the two repos clobber each other then?

Can the /Modules folder have subfolders? If so I suppose i could create a companyA folder and a CompanyB folder under the /Modules folder

Sep 12, 2012 at 6:19 PM

Why would they?

What we usually do is have one repository per module: no, the only subfolders that should be in Modules are the module folders.

Sep 12, 2012 at 6:24 PM

Hmm, one repository per module. I could end up with 100 repositories. That doesn't sound very easy to maintain not to mention that github only gives me 10.

Why doesn't the precompiled publish idea work? Aside from that, what Module is it that does the module loading for either core or modules folders? I may have to write one that points to my other folders.

Sep 12, 2012 at 6:33 PM

Well, if you have 100 custom modules, you have another problem. But yes, that is a valid concern, that we are trying to address:

I don't understand your precompiled idea.

Sep 12, 2012 at 6:38 PM

I thought that if the Modules\HelloWorld\bin folder already had a HelloWorld.dll and the Modules\HelloWorld folder did NOT have a csproj file then that was considered precompiled and Orchard would try and use it without compiling it. However I get the stack trace specified above.

Sep 12, 2012 at 6:40 PM

Not exactly. Did you read this?

Sep 12, 2012 at 6:51 PM

From that document:

"Precompiled Module" Loader

If "module.txt" indicates a module from the "~/Modules" folder, the PrecompiledExtensionLoader looks for an assembly named "<ModuleName>" in the "~/Modules/<ModuleName>/bin" folder. If the file exists, it's is copied to the "~/App_Data/Dependencies" folder, which is a special folder used to ASP.NET to look for additional assemblies outside of the traditional "~/bin" folder.

I tried this and I don't think it is working.

Sep 12, 2012 at 6:56 PM

Well, this is very new. Are you sure you're using the latest? Did you disable dynamic compilation? If you have been following the instructions exactly and you have the right version, I would file a bug. It may get fixed in time for 1.6.

Sep 12, 2012 at 7:04 PM

I didn't realize I had to disable dynamic compilation. Is that on a per module basis? It did copy my helloworld.dll to the app_data\dependencies folder

Sep 12, 2012 at 7:16 PM

No it's not, it's for the whole site.

Sep 12, 2012 at 7:21 PM

Are you saying I need to turn off dynamic compilation for this to work? My helloWorld.dll was copied to the app_data\Dependencies folder and the dependencies xml files did have my dll in it. So it sounds like it is partially working?

Could there be something with how I compiled my helloWorld.dll? I compiled it with .net 4.0. Oh I am using Orchard 1.5.1 by the way.


Sep 12, 2012 at 7:34 PM

The new precompiled loader won't do anything unless dynamic compilation is off.

Sep 12, 2012 at 8:26 PM

ah, I found some interesting things. First of all the Precompiled loader does work regardless of dynamic compilation.

To prove this I added the source code to Orchard.Web\Modules\HelloWorld and let dynamic compilation do it's thing. That worked great. Then I added the helloWorld.csproj to Orchard and rebuilt the HelloWorld module. I then went to Orchard.Web\Modules\HelloWorld and deleted the source files and the csproj file.

The HelloWorld module worked using the precompiled code!

However, when I compile c:\CompanyA\Modules\HelloWorld and copy the dll the module fails. So it must be something to do with how I am compiling the helloWorld externally.

Sep 12, 2012 at 9:19 PM

I'm not sure what's happening is what you think is happening. It would be interesting to find out by putting a breakpoint in the precompiled loader.

Sep 12, 2012 at 11:45 PM

I've given up and gone to the 1 repo per module concept that you guys use.

Sep 12, 2012 at 11:47 PM

We'll make it better...

Sep 12, 2012 at 11:49 PM

I created this: Vote it up!