Referencing custom assemblies in Orchard module

Tags: orchard, module, assembly, tip

This is one of the common problems you can run into at module development time.

In the most usual (and preferred) dev setup you work in VS 2010 on a single Orchard.sln solution containing full Orchard source and add your custom modules as an additional  projects. This setup works perfectly fine unless you try to use additional assemblies not listed in /lib folder (under the full Orchard source code root, as downloaded from Codeplex).

If you try to add a custom assembly reference to your module project it’s inevitable that sooner or later you’ll run into:

"The type or namespace name 'yyy' does not exist in the namespace 'xxx' (are you missing an assembly reference?)"

exception when debugging from Visual Studio. The reason is fairly simple. As Orchard is a sophisticated platform, it’s still an ASP.NET MVC application though and needs all of the assemblies used placed in the Orchard.Web /bin folder (apart from those coming from GAC)! [EDIT] Orchard has also a second directory for holding custom assemblies - /AppData/Dependencies - and this is the place where all of non-core dlls land. Renaud Paquay from the Orchard Team wrote about the reasons behind that below.

When you install a module from NuGet package, the necessary assemblies contained in this package get copied to the Orchard.Web application’s /AppData/Dependencies folder and everything is fine. But when you debug the whole app from VS, the modules are already there and no installation (and file copying) happens…

The workaround to this problem is to add all assemblies referenced by your module(s) to the Orchard.Web project too.

[EDIT] There is also a different workaround. You can store all your necessary assemblies in a single folder, and point Orchard to look into that folder at runtime (when the dynamic compilation happens). To achieve that just add the path to that folder to Web.config file in Orchard.Web project. The path should be placed in /runtime/assemblyBinding/probing privatePath property, separated with semi-colon from others.

As I stated above, this is only necessary at development time. When you deploy your module as NuGet package (via package create command) and install it – everything is perfectly fine. Your custom assemblies get packaged together with the module source and Orchard copies them to the appropriate locations.

And btw, I’d like to give you a tip at the end of this articleUĊ›miech

When using custom assemblies in your modules, check if they exist in /lib folder under the Orchard listing root. If so, make use of them – those assemblies won’t get packaged within your module NuGet package, so you’ll end up with a much lighter file. Remember though that for this to happen you MUST use exactly the same version of assemblies as in /lib folder.

Hope you find it helpful!

blog comments powered by Disqus