Why don't you create WCF service for administration on server and deploy client that connects with it to development team?
--------------
http://www.lotushints.com

Funny, I have a different outlook. I prefer to build all my services as libraries. I frequently have small console app's to test these, but I can also have test suites, server processes and GUI app's all utilise the same library.

I believe most software should be constructed this way. That way if you want to support a new UI/service model, the core component should be available for reuse.

So instead of using an existing tool (like SSH) for piping commands one way and their results back the way, you've written a web page to do it?

A better alternative might be to provide a page with some sort of bootstrapper link which fires up a pre-authenticated SSH session. I bet such a tool already exists.

I would agree with RobG. Make your service as a library. Then wrap that in a command line client to test or make a functional command line interface. Then you can wrap it in a UI or web based frontend, knowing that the core functionality will work and is reusable.

I have been working on a similar approach. I did write my own command line parser/dispatcher server side. I was also able to use the same sub system client side to provide various useful services. Here are a few notes/thoughts:

- I am using webapi/MVC. This allows my Javascript calls to map to the same code that my CLI is using.
- There is an open source web based CLI on GitHub. Needs work but was a great starting point. I was actually able to port my C# dispatching arch to the web and run a CLI from a web page. This CLI can not only send commands back to the server, but can also be used to interact with the local client (local storage, etc.).
- The command line vector is just a Controller so I was easily able to use the same authorization scheme.
- My command 'controllers' and command vector methods are decorated with attributes. This allows a startup scanner to identify and register the functionality with the dispatcher.
- Because of WebApi's self hosting capability, I was able to use the same architecture in my service as well (authentication was a little tricky, IIRC). So I can use the same client to connect to my web server or my windows service. Both servers are using a common user store.

All in all, I am a big believer in having a CLI. Once you have it in place, you will continually find use cases for it. Whether it be utility apps, testing, config...

I find myself agreeing with RobG's approach of building libraries: it seems to me that writing stuff which runs at the command line and then patching it together is a method of deliberately keeping one's coding style in some way tied to obsolete platforms. I have no doubt that it works... and one hopes that the coffee machine works too, because I can envision needing to go and make coffee while waiting for the resultant programs to run... OK, OK - I'm being facetious... but in reality, what happens if you write command-line oriented stuff is that ultimately, you end up forgetting what any of the commands actually do, and if you write enough of this stuff, it becomes unmaintainable at a certain size.

Great idea, this has worked for me. We just did a CRUD app using C# LINQ with initial prototyping in web pages, then as the database grew in complexity we moved the same code around into utility libraries and a console app evolved. One other benefit of this approach: We always use the utility app to do the bulk changes into the db, and can see the log file (who did what when). Every time we needed to do an operation, we quickly added a new command-line switch to handle it. The code was then readily available if we ever needed to do that again. Sure, lots of switches, but if we forget what "-updatesystemstats:true" means, we still know how to read the code and figure it out.

If you haven't already thought of it, you might want to include a way to upload a sequence of commands from a file. The risk is that as soon as you have that, you may find you also want conditional execution and all the other features of a full scripting language. Implementing those features can become an entire project in and of itself.

Another alternative that I like to do similar is to write small powershell cmdlets.
You get options / flags / command line handling / doco almost for free (once you learn the PS way).
Then from a PowerShell command prompt, the user types Import-Module yourCmdLet.dll and then:
Update-Customer -customerId 123 -firstname Jesse -lastname Taber

[CmdLet(VerbsData.Update, "Customer"]
public class UpdateCustomerCmd : PsCmdlet
{
[Parameter]
public string CustomerId { get; set; }
[Parameter]
public string FirstName { get; set; }
...

protected override void ProcessRecord()
{
...
}
}