Making orchard command-line more robust

Topics: General, Troubleshooting
Apr 15, 2011 at 4:06 PM

Currently when one invokes Orchard from the command line the program goes through each of the module folders and may perform dynamic compilation. If any of the modules fail to compile properly, the program aborts.

For a non-core module the workaround is relatively simple in that the folder containing the offending module can often be simply deleted and the command re-run, thus alleviating the problem, at least temporarily.

One of the supported deployment methods for Orchard modules is to simply copy the new module's folder to the Modules folder. Therefore it is quite likely that when deploying at least some new modules that have not been exhaustively tested that this type of failure may occur, thus preventing Orchard (from the command line) from running until the offending folder is deleted.

Maybe I am just too enamored with Try-Catch blocks in C#, but what would it take to have Orchard simply skip the offending module and bring up the command line anyway instead of failing?

Below is a sample of the kind of error I am referring to:

=================================================================================================================

c:\WebRoot\LocalUser\OTest_com\Modules\Orchard.Indexing\Services\IndexService.cs(56): error CS1061: 'Orchard.Indexing.IIndexProvider' does not contain a definition for 'GetLastIndexUtc' and no extension method 'GetLastIndexUtc' accepting a first argument of type 'Orchard.Indexing.IIndexProvider' could be found (are you missing a using directive or an assembly reference?)

 

Exception Details: System.Web.HttpCompileException: c:\WebRoot\LocalUser\OTest_com\Modules\Orchard.Indexing\Services\IndexService.cs(56): error CS1061: 'Orchard.Indexing.IIndexProvider' does not contain a definition for 'GetLastIndexUtc' and no extension method 'GetLastIndexUtc' accepting a first argument of type 'Orchard.Indexing.IIndexProvider' could be found (are you missing a using directive or an assembly reference?)

 

Stack Trace:

Apr 15, 2011 at 4:27 PM

There are of course pros and cons to this.

I do sometimes find myself part-way through some changes and wanting to quickly run Orchard and check something in Shape Tracing for instance. So I have to get everything to a compilable state first and it would be nice sometimes not to have to do so.

On the other hand; I don't want to end up at some point spending half an hour trying to work out why my feature isn't showing up in the Dashboard, only to discover it was a compilation issue ;)

So if this was possible, there should at least be a very clear notification somewhere obvious that a particular module isn't compiling.

Apr 15, 2011 at 4:44 PM
randompete wrote:

There are of course pros and cons to this.

I do sometimes find myself part-way through some changes and wanting to quickly run Orchard and check something in Shape Tracing for instance. So I have to get everything to a compilable state first and it would be nice sometimes not to have to do so.

On the other hand; I don't want to end up at some point spending half an hour trying to work out why my feature isn't showing up in the Dashboard, only to discover it was a compilation issue ;)

So if this was possible, there should at least be a very clear notification somewhere obvious that a particular module isn't compiling.

I totally agree that one should not simply ignore errors. I think it would be great if the offending module showed up in the dashboard with a big red box around it to indicate that it is the problem module.

The specific case I was addressing however was not the website but rather the command line version of orchard that only outputs to the console. So in this case perhaps a simple Console.Writeline("Module x failed") in the catch block would suffice.