Creating a Hello World Module the Orchard way
So here we are ready to do the next part in our series of Orchard Discovery… Let’s make their Hello World module in the default installation, and then let’s see about implementing the Hello World in Visual Studio 2010, using no helpers. “Buckle Up Boys, it’s going to be a bumpy ride”
So to start with, Here is the link to the tutorial provided by Orchard website on how to do the “Hello World”. The first thing they tell you is before you get started to download and install the Code Generation feature Command-line Code Generation . To be totally fair I’m going to use the OrchardWpi we got running in WebMatrix to do this part… I start up WebMatrix, select Choose a Site option and Select my Orchard Site.
Now we click on the URL for the orchard website and open it up, get into Manage settings and from here on out we just follow the steps in the original article on installing the tools.
Tips for their instructions:
- first up, there are way too many modules in the gallery if you use the Feed: Any option
Be sure to drop that down and select the 
and click the Apply button.
- Gee wouldn’t it be nice if there was a sort order? don’t look for it there isn’t one as of 1.0
- Gee wouldn’t it be nice if there was a search function? Again don’t look for it, there isn’t one as of 1.0
- Quickest way to find your module is do a Ctrl+F (find function for your browser) and search for Code Generation
- Hey, if I install a module, how about we assume that I WANT to use it, other wise I probably wouldn’t have isntalled it. Can we make the default for installed modules as setting it to already being enabled? that would be helpful
With that done, we continue on our way with the Hello World Tutorial. And right off the bat we have our first question from their instructions: “Open the Orchard command-line”; so how do you open the command-line. Intuitive it is not, here is a link to the instructions on using the command-line interface. Basically you need to open a Command line in the bin directory of the Orchard website you want to work on… Hey, give them a break, this is version 1.0… Don’t forget to make sure you start up the command line as an administrator, to save yourself some grief, and making it a Visual Studio 2010 command prompt would probably be best, although supposedly not required.
You can find the bin directory by going back to WebMatrix and clicking on the path link for the website, and navigate down from there to the bin directory.
Ok, now that we got the command prompt open we continue on with our exercise from the Hello World Tutorial. First you need to get the Orchard Commandline tool started. I’ll save you the digging around in the documentation to find out how: from the command line in the bin directory run the Orchard.exe. That will initialize the Orchard Command line tools and then we basically just run the command codegen module HelloWorld.
I decided to follow the editing instructions using the built in editor in WebMatrix
Editorial: A txt file? you might as well have an INI file. AND you have a warning that I should be careful to use spaces and not tabs to indent? Come on Orchard developers, I know XML is verbose and over used, but in this case it seems a lot more intelligent, what we have now looks so VB 3 world type… (and for the record I started programming in VB3 so please don’t flame me too much).
Ok, I save my changes and move onto the next step, where they recommend that I put in a Routes.cs file in the HelloWorld Folder, let me show you how I did that in WebMatrix. (make sure to click on the “Files” header in the Un-outlook bar), I click on the HelloWorld folder and then click on the Create a new file link on the page.
The model dialog that opens has Common Selected for “File Types” none of which will give you the ability to create a class, click on the Suggested Category scroll down and find the Class (C#) item, click on it and in the Name box below set it to Routes.cs and click OK
Copy and paste the text from the tutorial and repeat the process as instructed for the HomeController.cs, then do the same for the View file.
Then the instructions tell you to add some lines manually to the HelloWorld.csproj file ( and this tutorial is obviously not for the newbie or someone who wants to ask questions. It tells you want to do, not so much on the how ). Just follow thru the instructions. So I did and this is what I got…
OK, so I can make Orchard say hello, I have no idea how that all comes together so let’s see if I can take it apart.
First things first, I think we need to know what the CodeGen did before we know how to proceed manually. Consequently I’m going to run CodeGen and create a new module called UMadeThis. I’ll follow the same steps as above from the command line.
Note: if you create a module in Orchard using command line and it doesn’t show up in WebMatrix, be sure to Right Mouse on the Modules Folder and Click the Refresh, your module should now show up.
Going again in the Files group, find the UMadeThis folder and let’s “expand” every folder; Now let’s go see what got made…
Not a whole bunch. The web.config for both the Scripts and the Styles is the following
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<appSettings>
<add key="webpages:Enabled" value="false" />
</appSettings>
<system.web>
<httpHandlers>
<!-- iis6 - for any request in this location, return via managed static file handler -->
<add path="*" verb="*" type="System.Web.StaticFileHandler" />
</httpHandlers>
</system.web>
<system.webServer>
<handlers accessPolicy="Script,Read">
<!--
iis7 - for any request to a file exists on disk, return it via native http module.
accessPolicy 'Script' is to allow for a managed 404 page.
-->
<add name="StaticFile" path="*" verb="*" modules="StaticFileModule" preCondition="integratedMode" resourceType="File" requireAccess="Read" />
</handlers>
</system.webServer>
</configuration>
The web.config is in the View Directory is a little more interesting
<?xml version="1.0"?>
<configuration>
<appSettings>
<add key="webpages:Enabled" value="false" />
</appSettings>
<system.web>
<httpHandlers>
</httpHandlers>
<!--
Enabling request validation in view pages would cause validation to occur
after the input has already been processed by the controller. By default
MVC performs request validation before a controller processes the input.
To change this behavior apply the ValidateInputAttribute to a
controller or action.
-->
<pages
validateRequest="false"
pageParserFilterType="System.Web.Mvc.ViewTypeParserFilter, System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"
pageBaseType="System.Web.Mvc.ViewPage, System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"
userControlBaseType="System.Web.Mvc.ViewUserControl, System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<controls>
<add assembly="System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" namespace="System.Web.Mvc" tagPrefix="mvc" />
</controls>
</pages>
</system.web>
<system.webServer>
<validation validateIntegratedModeConfiguration="false"/>
<handlers>
</handlers>
</system.webServer>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="2.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
At first glance seems pretty standard for an MVC View Web.config, but taking a closer look I noticed something else: just below the first block of code is from the code generated by the CodeGen in Orchard, the second block is from a normally generated MVC project.
<pages
validateRequest="false"
pageParserFilterType="System.Web.Mvc.ViewTypeParserFilter, System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"
pageBaseType="System.Web.Mvc.ViewPage, System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"
userControlBaseType="System.Web.Mvc.ViewUserControl, System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<pages
validateRequest="false"
pageParserFilterType="System.Web.Mvc.ViewTypeParserFilter, System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
pageBaseType="System.Web.Mvc.ViewPage, System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
userControlBaseType="System.Web.Mvc.ViewUserControl, System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
They look almost the same but I see a minor difference in the Orchard Stuff, The type engines for the Orchard have all had the processorArchitcture specified processorArchitecture=MSIL. basically if not specified your module would be built to what ever processorArchitecture was specified in the build settings, but this extra flag overrides that, and makes sure that your module is built to the MSIL, Microsoft Intermediate Language. MSIL can be viewed as the assembly code of the CLR. It means of course that your module is not optimised for the target processor architecture, but on the plus side, this means it will run correctly in CLR at run time.
Finally I noticed one other thing, the View web.config DID NOT include the section for razor web pages…
Now that was interesting, so where is that information for Razor pages located? it is located in base Orchard website web.config file. In a normal MVC generated project, the reverse is true. Let me do a quick comparison between the razor entry in the Orchard Web site’s base web.config
<system.web.webPages.razor>
<host factoryType="System.Web.Mvc.MvcWebRazorHostFactory, System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<pages pageBaseType="Orchard.Mvc.ViewEngines.Razor.WebViewPage">
<namespaces>
<add namespace="System.Web.Mvc" />
<add namespace="System.Web.Mvc.Ajax" />
<add namespace="System.Web.Mvc.Html" />
<add namespace="System.Web.Routing" />
<add namespace="System.Linq" />
<add namespace="System.Collections.Generic" />
<add namespace="Orchard.Mvc.Html" />
</namespaces>
</pages>
</system.web.webPages.razor>
And the razor entry in a standard MVC projects View Web.Config file
<system.web.webPages.razor>
<host factoryType="System.Web.Mvc.MvcWebRazorHostFactory, System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<pages pageBaseType="System.Web.Mvc.WebViewPage">
<namespaces>
<add namespace="System.Web.Mvc" />
<add namespace="System.Web.Mvc.Ajax" />
<add namespace="System.Web.Mvc.Html" />
<add namespace="System.Web.Routing" />
<add namespace="RecoveryAssist.Dal" />
</namespaces>
</pages>
</system.web.webPages.razor>
And if you look at the pageBaseType you see the real difference. In Orchard they want to make sure that the Page base type is based on the Orchard.Mvc.ViewEngines.Razor.WebViewPage, whereas a standard mvc project makes System.Web.Mvc.WebViewPage the page base type. Again, I’m not sure what impact that has, but I’d be willing to bet it isn’t insignificant.
Next time, we will do this all over again, but inside of Visual Studio 2010…