shell.me - your universal shell framework

We often find us wrapping code in a minimalistic console app just to run it with the OS task scheduler at a specific interval. That's a dump, repetitive and tiresome task to do. It's getting even worse once you start to parse parameters again and again.

shell.me is our attempt to fix that.

• it provides a simple way to run any custom implemented command

• just create a dll project and implement a very simple interface

• drop your dll and all it's dependencies into a \plugins\myCoolCommand\ directory

• once you restart the shell.me console it will be automagically know about it!

• we sandbox all commands. Consider you have two plugins: /plugins/foo/foo.dll /plugins/foo/dependency.dll /plugins/bar/bar.dll /plugins/bar/dependency.dll Both plugins use dependency.dll in different versions. Normally this would cause problems since the CLR can not load the same dll in different versions. However, since we sandbox each plugin with it's own ApplicationDomain it's perfectly valid to do so.

• it does all the heavy lifting for you. No need to parse parameters yourself. Let's say your command foo needs an int argument (e.g. BatchSize). All you've got to do is to add an int property BatchSize to your command. Now you can use it like this: foo --batchsize=100. And say you also want a boolean property Force. Easy!

  You can either say:

  foo --batchsize=100 --force //means force == true
  foo --force=true //means force == true
  foo --force=false // means force == false

• it is trivially extensible. For example: We parse a lot of common types for you. But if for instance, you want to use the Point type as a command argument, you need to give shell.me a hint. Just add a custom TypeProvider and add it to the collection of built in TypeProviders. That's the way to teach shell.me new tricks! After that you could use it like that for example: foo --Point={ X: 4, Y: 3}

• it's layered into small chunks to provide rich flexibility

  ShellMe.CommandLine hosts the core functionality of shell.me That's a simple dll (not a console app!) that you actually can use to build a shell on top of it. For instance, you could build a html shell, a wpf shell - it's really up to you!

  ShellMe.Console a console app that uses ShellMe.CommandLine to provide a basic shell

  ShellMe.Testing provides useful helpers for testing. We care a lot about testing. That's why we also provide you with rich testing helpers. For instance, we have a TestConsole that you can use to write unit tests against custom commands.

• it provides a way to run commands in a non interactive way. Remember when we talked about using shell.me to run repetitive tasks with the OS task scheduler? You really don't wan't the shell.me process to stay open when using shell.me in such a scenario. Just add --non-interactive as an argument to the command and shell.me will immediately shut down after the command has finished.

• it provides a rock solid way to prevent commands from running in parallel if you don't want that to happen! Let's say you schedule a command to run every 10 seconds. However, the time consumption of the command itself might be hard to predict and you don't want commands to overlap themselves. The OS task scheduler (at least on Windows) provides a way to avoid overlapping of tasks but it really only looks up for the process name not to clash. However, if you are using shell.me to schedule a bunch of commands, you don't want to use that option because you do want multiple instances of shell.me to overlap! You just don't want that to happen for specific commands! If you don't want that to happen just add --allow-parallel=false as an argument to the command. Shell.me automatically creates lock files in the shell.me directory that will prevent multiple instance of this command to run in parallel.

• It provides rich tracing features! We made things really easy for you. If you derive from BaseCommand you get all the rich tracing features from System.Diagnostic for free! In addition, you don't have to gamble with an app.config.xml file. If you like to log to the file system use --writeFile=foo.log and if you like to write to the system event log use --writeEventLog. You can either leave the LogLevel untouched or set it globally (read: for File and EventLog) with e.g. --LogLevel=[Information, ActivityTracing] or use --FileLogLevel=[Error] and --EventLogLevel=[Information] seperatly. Make sure you read up about all the different Levels: http://msdn.microsoft.com/de-de/library/system.diagnostics.sourcelevels.aspx

• it's MIT licensed https://github.com/dff-solutions/shell.me/blob/master/LICENSE.md