This project is read-only.

Including referenced project binaries in module package

Topics: Writing modules
Nov 23, 2012 at 6:48 AM


I've got solution with several projects which are referenced by module project. I've deployed this module through MsDeploy mechanism so far. Now i've tried to make a nuget package by command of packaging feature in Orchard. But package hasn't contains all necessary binaries.


I've got solution with two projects

1. AwesomeFeature.OrchardModule

2. AwesomeFeature.Domain - referenced project by OrchardModule

3. AwesomeFeature.DataAccess - referenced project by OrchardModule


package create command doesn't include AwesomeFeature.Domain.dll and AvesomeFeature.DataAccess.dll in nuget package.


Is it normal behavior ?

Nov 23, 2012 at 7:55 AM

If the project is only used by your Orchard module, why isn't it an Orchard module itself, or why isn't it just part of your module? If it's used elsewhere, then you can keep it as a non-Orchard module, but I would add a post-build action to copy the dlls to a lib folder under your module. Have your module reference that copied dll. If your project correctly references the dll, it should get included in the package.

Nov 23, 2012 at 8:08 AM

When Visual Studio compiles solution then AwesomeFeature.OrchardModule/bin already contains:

  • AwesomeFeature.OrchardModule.dll
  • AwesomeFeature.Domain.dll
  • AwesomeFeature.DataAccess.dll

When I copy AwesomeFearure.OrchardModule folder to Orchard Modules and then try to create package create from Orchard console .. then created nuget package doesnt contains above dll's.

I cannot include code Domain dll to Orchard Module

Nov 23, 2012 at 8:59 AM

Lib, not bin.

Nov 23, 2012 at 10:25 AM

I think I got it. I'm not happy with that solution but I can live with that.


Nov 24, 2012 at 1:21 AM

I have had the same problem, but I got around it using the solution Bertrand offered.  What turns out to be most important is that your .csproj file for the module NOT include any references to projects that are not also Orchard modules or standard Orchard assemblies.  This is because the same .csproj file is used to dynamically compile your module once it is deployed as a package, and that compilation will fail when it cannot find all referenced projects.

If you wish to debug your project, you can include the .PDB files when you copy your non-Orchard libraries to the "lib" directory.  A good way to keep your file separate is to create a subdirectory underneath "Orchard\lib" for all related non-Orchard assemblies in the same pattern as other Orchard 3rd party libraries.

Finally, it is critically important to ensure that your non-Orchard assemblies bind to Orchard's versions of system assemblies (e.g., for ASP.NET MVC, WebApi, etc.) and NOT the system provided ones.  If they do (or any of their dependencies do), those versions will conflict with Orchard's and also cause dynamic compilation to fail after deployment.  To prevent this, you can create a separate "Orchard-friendly" .csproj file for your non-Orchard code that references all your same code files but also references Orchard's version of system assemblies.  This might be a pain to do, but it avoids trying to track hard-to-find errors when your package gets deployed to Azure Web Sites, Azure Web Roles, or some other environment where those system assemblies are not in the GAC (and Orchard's are the only version available).

We have been through this pain a lot lately, so I hope these tips help.

Nov 24, 2012 at 10:31 AM

Thank you for sharing this tips. 

As I said before, I was deploying by MSDeploy whole module folder with its bin folder which contains all needed dlls copied there by build process. I would like to deploy by nuget package now.

I think I will have to create my own procedure for creating nuget package by rake or msbuild