This project is read-only.

Binary only / precompiled modules

Dec 20, 2010 at 12:57 PM

I am planning on running Orchard on Azure, and as such, I am going to be building azure packages on my local machine (with the modules / themes etc that I need) and then deploying it.

As far as I can tell all the modules are currently packaged / deployed in source form and then dynamically compiled. Given the actual deployed instance will never be updated (as such) is it possible to use binary / precompiled modules??




Dec 20, 2010 at 3:56 PM

Good question, wanted to ask the same thing:) It's a "must-have" functionality - think about commercial/closed-source modules...

- Piotr

Dec 20, 2010 at 6:57 PM

That's only the default. You can already deploy a module in binary form (except for views naturally).

Dec 20, 2010 at 11:40 PM

Is there (or will there be) any documentation on how to do so??  Particularly for the scenario of taking a source only module and creating a compiled version (I presume it a case of drop the dll in the bin folder and copy the view files etc to the correct location).

Dec 21, 2010 at 12:35 AM

We have no plans for such documentation at the moment, but you are correct about the steps that you need to follow: essentially, if you remove the cs and csproj files from the deployed package the module should still run exactly the same.

Dec 21, 2010 at 12:47 PM


Dec 21, 2010 at 7:24 PM

I noticed that by default the packages created are binary-only (no .cs files), only .cshtml files are left, so this is good. I wonder if it is possible to compile also the .cshtml shape files? I know that .cshtml files can be compiled into dll by the Razor engine (as opposed to .aspx views, which needed the placeholder files).

I think adding some switches in 'package create' command in the future to make more complex scenarios possible is a good idea.

- Piotr

Dec 21, 2010 at 7:26 PM
Edited Dec 21, 2010 at 7:32 PM

We're not supporting that and frankly I don't see the point unless you really want to annoy the users of your module: why would you want to prevent them from skinning your stuff?

Also, I'm wondering why you're saying packages are created without cs files. That is not what I observe on my own enlistments.

Dec 21, 2010 at 8:16 PM

I understand your point and I agree - it'd prevent users from skinning and in the common scenario (Orchard as a site CMS) would be annoying and pointless. I thought about different scenario though - writing modules to some custom, closed system built on top of Orchard (with predefined skin/s). In such case you don't need to give users the possibility to skin, as skins are predefined. Possible performance gain of having the whole module compiled is of greater value.

Sorry, my mistake - you are right, the .cs files are there... I looked by mistake into my theme package, which doesn't have any .cs files:)

- Piotr

Dec 21, 2010 at 8:34 PM

Well, we don't support compiling the views at this point.

Jan 22, 2011 at 2:01 AM

The logic I can see for compiling views would be in production use where you are trying to get every drop of performance out of the system, but at this stage in the project, it would be a low priority at best.

Jan 22, 2011 at 9:10 PM

There is no real performance advantage to compiling views into a DLL, as they get compiled into a DLL when the web page is accessed the first time. The only minor performance advantage would be that the web server won't have to check the date/time stamp of the view files to see if they have changed, but that is negligible compared to the database operations going on in the models. So the only reason to pre-compile a view would be if you really need to close off ALL the source code; but views are just view code and should not contain any business logic, so it would be doubtful that the view logic is going to contain anything 'secret' that someone probably couldn't work out from the generated HTML code anyway.

Jan 22, 2011 at 9:19 PM

Low volume traffic sites have their application pools recycled and experience the "first time access" loading times by default unless the user is going to change the application pool settings so it would still be a valid condition I suppose. I notice it on my sandbox, only using it every few hours and getting to wait for the build time. I did try Bertrand's advice above and it reduced the wait time about 70% so I wouldn't discard it completely.

Jan 22, 2011 at 9:36 PM

Yes, I can see that would be a problem, but the wait times I am pretty sure come from the Orchard module compiling system and spinning up the application again, rather than from compiling views? The 70% reduction in wait time you achieved had to do with making sure all the CS code was pre-compiled, which is a big win. Not so much for the views?

Jan 22, 2011 at 9:38 PM

For performance though, you should just pre-compile the site in place on the deployed server:

Jan 22, 2011 at 9:39 PM

Yeah, I don't think it is compiling the views. I should have clarified I was only commenting on the original first part of the equation, precompiling the modules rather than the views.

Jan 22, 2011 at 9:57 PM

Yes, of course. Pre-compiling the rest of the site is a huge performance win :)

Jan 23, 2011 at 6:16 PM

There is also a second reason why do we want to precompile .cshtml files. It is not only about views - but with the latest updates on Razor you can very quickly define new helpers in .cshtml files. And it would be great to have them compiled (for various reasons - redistribution for instance).

- Piotr

Jan 23, 2011 at 11:10 PM

Did you know that any shape can be rendered by either a template or a C# method with the name of the shape and a shape attribute. Look for base shapes for examples of that. Do it from a theme with a csproj and you'll get the ability to compile everything including UI.

Jan 28, 2011 at 7:19 AM

I have just updated Orchard.Packaging to support building precompiled packages.

I have a stub for sealed (100% compiled) packages. This isn't finished as it is needed to modify the .csproj file on the fly to compile .cshtml files, and then execute msbuild.

I dont use Hg, as I have my own TFS setup that better suits my development needs. Considering that, what would be the best way to submit my changes back?

Jan 28, 2011 at 7:31 AM

You can install Hg even if you have TFS. Mercurial is fairly lightweight and that's what we use. Thanks for your cooperation.

Jan 28, 2011 at 7:56 AM

Will TFS PowerTools and TortiseHg play nice bound to the same location? Or do I need to have 2 copies of the source, which i do not intend to do.

Jan 28, 2011 at 8:04 AM

I don't know but I think it should be alright.

Jan 28, 2011 at 8:48 AM

Slightly painful to setup, but it seems to be good. I like that I can work in TFS mode, then attempt to easily reconsile with Hg. Too bad VStudio wont let you have nultiple source control providers hooked up at once. Anyway, new fork created and updated.

Jan 28, 2011 at 8:50 AM


Dec 14, 2011 at 8:15 AM

I think it's a good thing that there's a option to create a pre-compiled module package but i hope that's not gonna be a trend/default behavior because i learned so much from looking at the sources of other modules! This maked sure that i could built modules too and pushed it the the gallery.