Install / Setup Orchard for Module Development Question

Topics: Writing modules
Mar 27, 2011 at 9:11 PM

I performed the following steps to setup an Orchard development environment for module development:

1. Downloaded Orchard Source code
2. Extracted the source code into a folder
3. Fired-up Visual Studio 2010 Professional and opened the Orchard solution/project (Orchard) under the src folder
4. Build the solution in Visual Studio
5. Run the solution - entered the info: site name / password / database
6. From the command-line performed a 'codegen module MyModule /IncludeInSolution:true' (for a new module)

Problems I have/had (until now):
1 - No intellisense for MVC 3 -> I unloaded my module/project added the following to .csproj file
<ProjectTypeGuids>{e53f8fea-eae0-44a6-8774-ffd645390401} ...
Should I do this or not?
2 - Get error: 'The Name "Script" Does not exist in the current context.' when adding to a View
@Script.Require("jQuery")
@Script.Require("jQueryUI")
3 - Error messages in existing Orchard module views: "There is no build provider for the extension 'cshtml'"
4 - Analogous to error 2 "The name "Display" does not exist in the current context.": in eg
@Display(Model.Header)
@Display(Model.Actions)

 

 

 

What am i missing to avoid all these problems?

Thanks.

Mar 28, 2011 at 2:12 PM
Edited Mar 28, 2011 at 2:12 PM

Can someone please explain how to setup a workable dev environment. Or are the mentioned problems all bugs?

Thanks.

Mar 28, 2011 at 3:20 PM
Edited Mar 28, 2011 at 3:22 PM

I think the errors you are describing are all basically the same intellisense issue. Your project should still run fine - I have no problem building and running the current dev / 1.x enlistment and developing modules in it.

To improve the intellisense situation, you can add the following Web.config into your module project root directory. Then build your solution, and close and reopen Visual Studio. I originally got this from another thread on these forums, where there is more explanation if you want to search for it.

A couple of things to make sure of;

  • You should be working from a full source enlistment if you want to do any serious development
  • You should stay up-to-date with the latest dev branch, small issues are regularly getting fixed and 1.1 will be out very soon - so you want to make sure you're compatible (although keep a 1.0.20 instance handy for backwards compatibility testing if that's also a concern)

I know the dev team are looking at a number of things to improve developer workflow once 1.1 is out but I've had personally had no trouble developing 3 working modules and 2 themes on the current codebase. Yes there are a few niggles at this stage (and things that will make your head hurt!) but it really is worth it, so many things become very easy once you get your head round it. I recommend reading as much as you can in these forums, and also blogs of people like Bertrand Le Roy and Piotr Szmyd as they offer a lot of useful tutorials and insights.

Module Web.config as follows:

 

<?xml version="1.0"?>
<configuration>
  
  <configSections>
    <sectionGroup name="system.web.webPages.razor" type="System.Web.WebPages.Razor.Configuration.RazorWebSectionGroup, System.Web.WebPages.Razor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
      <remove name="host" />
      <remove name="pages" />
      <section name="host" type="System.Web.WebPages.Razor.Configuration.HostSection, System.Web.WebPages.Razor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" />
      <section name="pages" type="System.Web.WebPages.Razor.Configuration.RazorPagesSection, System.Web.WebPages.Razor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" />
    </sectionGroup>
  </configSections>

  <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>

  <system.web>
    <compilation targetFramework="4.0">
      <assemblies>
        <add assembly="System.Web.Abstractions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
        <add assembly="System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
        <add assembly="System.Data.Linq, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
        <add assembly="System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
      </assemblies>
    </compilation>
  </system.web>

</configuration>

Mar 28, 2011 at 4:10 PM
Edited Mar 28, 2011 at 4:20 PM

Thanks.

It works now with the modification of the web.config in my module.

So not using the 'standard' source download from Codeplex (zip-file) but downlaoding the code with Tortoise?
Guy

 

Mar 28, 2011 at 4:56 PM

I'm not sure if you mean the 'standard' 1.0.20 release source, or if you're downloading the latest dev branch. But if you set up a TortoiseHG enlistment instead, you can regularly pull down new changes and merge with any of your own modifications. It also means you can version control your own work locally.

Mar 28, 2011 at 5:11 PM

Thanks.
yes i meant the release source. i suppose there's backward compatibility when using/developing with the latest dev branch (when deploying modules to the web Orchard.Web version)?

Mar 28, 2011 at 5:28 PM

Compatibility is pretty decent. All the stuff I've made has been fine with both, but I have seen some modules that break in 1.1. This close to the release it's kind of preferable to be compatible with the upcoming version in my opinion. Enough things are being improved that the majority of users will want to switch very quickly and by targetting only 1.0 you'd just be creating potential upgrade headaches for yourself and anyone using your module if you released it. I'm using 1.1 on my own live site and it's been running fine, although of course if it was a customer's site I'd be more careful which version I used. The only real problem I've had is 1.0 modules that haven't yet released a compatible version. Basically if you're building a new site or module now, you might as well target 1.1 because it'll be out by the time you're finished. I hope :)

The only way to make sure is to develop against the latest dev, and also have a 1.0.20 installation to also test on. If you absolutely need to ensure compatibility with both versions then you simply have to test on both.

Mar 28, 2011 at 6:08 PM
Edited Mar 28, 2011 at 6:08 PM

Thanks.

Maybe a stupid question but is the v1.1 version (alpha, beta) already available/downloadable? Or is this the version you automatically get when downloading the latest development branch?

 

Mar 28, 2011 at 8:20 PM

Dev branch is the latest code and basically is moving towards the 1.1 release. It's being steadily merged in batches into the 1.x branch. So you can go with 1.x branch for stability, or dev for latest changes; but there's little difference. Either have a lot of changes from 1.0.20. Most importantly, Shape Tracing, which is basically the Firebug for Orchard :)

Coordinator
Mar 28, 2011 at 8:32 PM

The latest in the integration branch usually is a good compromise between stable and up-to-date.