Deploying Orchard from Code, including .cs files

Topics: Installing Orchard
Jul 14, 2012 at 4:19 AM

I have the source code compiling locally.  When I go to "Publish" and look at the files it is deploying a lot of .cs files.

Generally when I publish a site in Visual Studio it puts all of that in a dll.  Any reason I am not seeing that now?

Coordinator
Jul 14, 2012 at 1:07 PM
Edited Jul 14, 2012 at 1:07 PM

That's by design: modules in Orchard are dynamically compiled. You deploy the source code, not dlls.

Jul 17, 2012 at 6:35 PM

I understand the dynamic compilation in Orchard, but I did have a question in this vein. We've been setting up an enterprise deployment of Orchard, and the current tool is set up to exclude .cs and .csproj files. It does however run a build to construct assemblies for each module. When I first learned about this, I didn't think it would work, but it seems that deploying with only assemblies and no .cs files does work by in large.

My question is, are there any unforeseen consequences to doing this? Should I push for our team to deploy .cs files and .csproj files even though the deploy seems to work without them.

Coordinator
Jul 17, 2012 at 6:59 PM

My opinion is that it's not worth the trouble. Why is the tool set-up this way?

Jul 21, 2012 at 1:53 AM
Edited Jul 21, 2012 at 1:56 AM

Actually its pretty common for enterprise-y type organizations to not want to deploy code files to servers, and use assemblies instead. I always thought that was a reason .Net and Java were so popular in the enterprise... I mean, I know I'm corresponding with a MS engineer, and I don't want to sound condescending, but its quite common. I work with both enterprises and startups and enterprises usually want to deploy .dll or .jar files. Some if it is a security concern, sometimes its just that deploying and synchronizing many code files across a network or balanced environment takes longer (more files to copy).

As for project files, until Orchard came along, these were strictly design time files. When I tell people that Orchard uses them during runtime, you should see the looks I get- incredulity. In any event, I'm not the one who enforces these policies or even an employee of these organizations, I'm just a freelancer working for them.

The good news is that Orchard is designed to work either way according to this:

http://docs.orchardproject.net/Documentation/Orchard-module-loader-and-dynamic-compilation#LoaderDisambiguation

And indeed it does. In the case where we had a problem I got a report from IT that someone manually copied some .cs and .csproj files, so they were overriding the compiled assemblies we were deploying. At least that is what we think- they nuked the site and deployed from scratch (without .cs and .csproj files), and the site is working fine.

Jul 21, 2012 at 2:00 AM

Yeah, I'm not a fan of this setup.  Just feels dirty deploying all those code files.

Coordinator
Jul 23, 2012 at 12:16 PM
Edited Jul 23, 2012 at 12:17 PM

The enterprise has never been the target for Orchard (and probably never will be). We aimed for maximum flexibility instead.

Also, if there are claims that this setup is less secure, I'd like to see them substantiated by, for example, an exploit based on it that wouldn't be possible otherwise.

Jul 24, 2012 at 10:24 AM
Even with some of the learning curve and quirks involved, Orchard is the most extensible, developer empowering, and admin friendly CMS I have ever used. The heavy use of DI alone make it my preferred CMS for development, and you can customize more through the admin UI than any other system I know of, thanks mainly to the dynamic runtime objects afforded by the latest and greatest C# code (my favorite language).

Simply stated, Orchard CMS is awesome in many, many ways, and in my humble opinion is the best open source (and possibly proprietary) CMS on the planet. I get how the design strives to make things just "work" like that very popular PHP system which I will not name. But in fact that rather inflexible, aging system IS used by Enterprises today in a variety of capacities. I wholeheartedly endorse Orchard CMS as the next generation and a great improvement on it.

So, I would humbly ask that, even if the enterprise isn't your "target", you don't turn your back on it or deny it the awesome power of Orchard CMS. Within my sphere of influence, I've been one of the most vocal and enthusiastic evangelists of your system. As an implementer I sometimes need to find ways for Orchard CMS to play by the rules a particular organization sets up- i.e. I don't make a habit of debating my client's IT departments. I rather try and make my code conform- and there hasn't been a challenge yet (including this one) that Orchard hasn't been able to surpass.

Also, access to to you, Bertrand, and the ever helpful and awesome Sebastian Ros has made my adoption and continuing development on the Orchard CMS easier and better (I've bragged about this to my clients even saying "you don't get that kind of attention from the developers at WordPress" (there, I said it)). So when I post on this forum, please realize I'm not some naysayer here to second guess you or unfairly criticize. I love Orchard. I want Orchard to be my company's "go-to" CMS. Even for corporate "enterprise" clients.

On Jul 23, 2012, at 8:27 AM, "bertrandleroy" <notifications@codeplex.com> wrote:

From: bertrandleroy

The enterprise has never been the target for Orchard (and probably never will be). We aimed for maximum flexibility instead.

Also, if there are claims that this setup is less secure, I'd like to see them substantiated by, for example, an exploit based on it that wouldn't be possible otherwise.

Coordinator
Jul 24, 2012 at 1:05 PM

Let me clarify further then. We know from experience what it takes to get that "enterprise" label on software. My position is that aiming at that is the best way to actively screw your platform and make it a horrible (but certified) mess. What IT departments usually mean by "enterprise" is a laundry list of "features" that they think ensure good architecture, often without subtlety or attention to context. Lots of companies make a lot of money selling more or less useful certification labels that ensure the enterprisyness of your software but not at all that it will work for you. It kinda works for its proponents because, as the old saying goes, one never gets fired for buying IBM. And of course, there's a lot of consulting money to be made by fixing your own mess...

What I mean when I say that we don't aim for the enterprise is that we are not and will not be driven by that sort of goal. We have been and will continue to aim for robustness, performance, flexibility, etc., all goals that are justified by real usage of the platform. Our approach is realistic and evidence-based, not indirect and based on generic external assumptions.

We will accept a claim that deploying the source code is insecure if it's substantiated by, for example, an exploit. If such a claim is made and substantiated, we will fix the bug, provide a mitigation, or if that's not possible, as a last resort, we would cut the feature. But we will not accept the claim based just on the hunch of some IT engineer.

But of course, in this particular case, it's perfectly possible to deploy only binaries and not source code, so I'm not sure what we're talking about.

Jul 24, 2012 at 8:46 PM

@ckincincy Bertrand is right, we digressed a bit- the bottom line is that you don't have to deploy code files if you set up your deployment correctly (YOU must build, cause at that point Orchard can't). Then your deployed modules are just assemblies in the bin, cshtml view files, and of course the important Module.txt and Placement.info files.

The thing to watch for is if you accidentally get some .cs files or .csproj files deployed in addition to assemblies you build, oddities may ensue. Like in our case, there were differences in the code between the two. If that does indeed happen, Orchard will be using the code files, and not the assemblies you've built.

Coordinator
Jul 26, 2012 at 1:35 PM
Edited Jul 26, 2012 at 1:36 PM

And let me retract what I said up there about it not being worth the trouble. I was still under the impression that there was little benefit in disabling dynamic compilation as the perf difference had been made very small through some perf improvements made a few releases ago. From more recent experiments, there seems to be a real benefit, in particular in terms of memory occupation. If that's confirmed, we may want to provide an easier deployment story from local dynamically compiled dev environment to statically-compiled production server (one that's clearly documented and doesn't involve deploying 800MB of stuff).

Jul 26, 2012 at 1:46 PM

@bertrandleroy, thanks for following back up on this.  I'm ultimately not going to get into a big flame war about the benefits or lack of benefits to having a compiled deployment. 

There is absolutely no way I can be convinced, without a proper bit of testing, that the Orchard default is more efficient than the "standard" way of doing business.  By having it compiled you are obviously saving some time in the start up.  Then the ability to track changes and upload them via Visual Studio is painful.  The great thing about having everything compiled is that your "upload story" is so much cleaner.

Regarding security.  Open source code is not more secure than compiled DLLS.  If an unauthorized person gets onto your server with the Orchard default any proprietary code is exposed with little effort.  With compiled DLLS there would at least have to be some work to decompile them.

Coordinator
Jul 26, 2012 at 2:24 PM

Well, I hope there is some way to convince you: evidence. This is a very complex set-up, and you'd be surprised by the counter-intuitive results you can get if you actually measure things. You should never make assumptions about performance, but always measure first. Everything I said was based on actual measurements. My mistake, if I made one, was to rely on data that may be too old.

Nobody said anything so far about security by opening the source, but come on, you know how trivial it is to decompile a dll. It doesn't take more time than opening a text file. And if somebody can get to your cs files, your site is already compromised, you're already screwed and that people can read your code is the least of your worries.

Jul 26, 2012 at 2:29 PM

You just said at 8:35 that some testing is showing a decrease in memory efficiency...

So I'm confused, is there a measurable performance issue or not?

Even with the security, the "upload story" still lacks.  That is when I first noticed this, when I went to upload a published site and saw it was 800MB's. 

Coordinator
Jul 26, 2012 at 3:01 PM

I said "From more recent experiments, there seems to be a real benefit, in particular in terms of memory occupation. If that's confirmed, [...]". Notice the "seems" and "if that's confirmed". That should give you a hint about whether I know for certain or not at this point and whether we intend to pursue further investigation ;)

You don't have to upload 800MB, but the procedure has not been obvious to everyone, so there is room for improvement in terms of documentation, and maybe implementation of the deployment build.

I hope this clarifies.