Using Visual Studio and Project References when creating modules

Topics: Writing modules
Oct 12, 2012 at 9:26 AM

Hi Folks,

We are using visual studio (2012) to develop our Orchard modules. We have around 6 modules, supported by about 8 class library projects, all within the same solution (along with a copy of the orchard 1.5 source). This works fine when running the project from visual studio, or deploying direct from VS, but we have several solution management issues to overcome when packaging our modules and deploying them to fresh installations

Having reviewed several other posts in stack overflow etc could I first confirm my understanding of how Orchard works with regards to packaging and references.

"The command line orchard tool will package a module including all file based references, but will ignore visual studio "project references" when  identifying which dlls to package in the module"


If this is true, does this not create an extra complexity when working with visual studio? I've had to add post build commands to my class libraries to copy the binaries to a lib location, and altered what were project references to instead by file based references to the lib location.

Am I missing a trick here? Presumably it would be possible to amend the module packager to understand project based references for dlls. Would it be worth raising a feature request for this, or is there a simpler way to achieve this with VS?



Oct 12, 2012 at 4:47 PM

No, all you have to do is make sure the manifest declares the dependencies on other modules. There should be no need to copy dlls around.

Oct 12, 2012 at 4:50 PM

Hi Bertrand,

these are not dependencies on other modules, rather other class library projects within the visual studio solution. All my dependencies between modules are handled in the module.txt file

Oct 12, 2012 at 4:54 PM

Ah, I see. Well, that's not how we do things around here ;) Make modules instead, or include those as binary dependencies.

Oct 12, 2012 at 5:15 PM

lol - was that reply basically "sucks to be you"? 

As the dlls are shared across multiple systems (Orchard CMS Modules only being one of the consumers of the libraries), this is sadly not likely to happen. A real shame really, as it makes it much more difficult to run build testing on our remote tfspreview server. Still, at least armed with that knowledge I know that working on making sure the build server sees everything is the thing to focus on.


Oct 12, 2012 at 6:00 PM

No :) It's just that this is not a supported scenario.

Oct 12, 2012 at 10:12 PM

Just out of interest....what kind of effort might be needed to make that support? Presumably adding an extra layer of "intelligence" to the packaging process, based on inspection of project references?

I'm thinking of writing up some blog posts on solution management with Orchard, as there are some gotchas from people coming from traditional projects - I feel like I've learnt rather a lot from these forums in the last 2 months :)

Oct 13, 2012 at 12:47 AM

Well, I'm not sure how that would even work. After all, Orchard knows nothing about your solution. So either you want it to get into dynamic compilation and then it's a module for all intents and purposes, or you just want it to be picked up as a binary dependency by your module, and it's just a question of making sure the build action for your library puts the dll in a place where the module can pick it up (as a binary dependency). See, if it was a non-module library but you wanted your module to work correctly, you'd need a way for dynamic compilation to go and follow the csproj and compile that too. Unfortunately, the people who get your module from the gallery won't have the source code for your library (as it's not a module) so that following of the project just won't work, they will need a binary.

Maybe I'm lacking imagination here but I really don't see how that could work.

Oct 13, 2012 at 11:09 AM
Edited Oct 13, 2012 at 11:14 AM

From what I understand, the only time this causes an issue is at packaging time. You are correct that once you hand the module out, then consumers have no knowledge of the projects that they can from. I guess the "problem" is how the dynamic compilation looks for the binary references. It's not beyond the bounds of possibility to change the packaging process to understand project references (even by simple inspection of the csproj file, build what is required, and place copies in the bin folder. I guess the issue comes when dynamic compilation for the module consumer does not understand that there is a module to copy to the dependencies folder.

Is this right? If so, then again it would be "possible" to alter the .csproj file being put into the module package to use a binary reference and place the required binaries in a predictable location (bin for instance or a "dependencies" folder for the project). It would certainly leave the classic visual studio experience intact, while allowing packages to work correctly when deployed elsewhere. I guess the question is, how many people would benefit from the change, and how complex is it really (given I haven't really thought through the effect it may/may not have on dynamic compilation.

Oct 13, 2012 at 6:04 PM

But there is currently no difference between the packaged module and the module in your dev environment. You would be creating that difference. You would also need to create a distinction between a module project reference and a class library project reference. Not worth the additional complexity, as there are two perfectly fine workarounds: make it a module or depend on the binary.

Your second paragraph does not in fact require anything from Orchard, and can be done today. Just have a post-build step that is to copy the dll into the lib folder of your module and have your module depend on that. That's what I was suggesting above.