views:

1106

answers:

6

What are the benefits of developing MMC snap-ins instead of traditional GUI apps? AFAIK the MMC snap-ins can be loaded remotely to control some server applications but I have never dived deep in this approach. What are the pros and cons of MMC snap-in approach over traditional Win Forms (or WPF) GUI applications?

And btw lately PowerShell is getting a lot of attention and again AFAIK there are some relation between MMC snap-ins and PowerShell script but I don't know any further. Any ideas?

+4  A: 

Pros: Having a standardized UI is definitely a benefit, and since MMC is a pre-built UI, you also don't have to build that part, but simply add the logic to it.

I've never thought about the MMC's remotability, and how this might play into things. The older remoting model was via DCOM (AFAIK), but newer versions appear to use WSMAN/HTTPS for their remoting (such as IIS7's admin UI).

So, the admin layer may do remoting, versus having the cmdlets being able to do remoting.

Cons: Nothing obvious to me.

With either MMC or WinForms/WPF, you are still using C# (or VB.NET) to access the PowerShell engine to either use the PowerShell API to its full extent or using the API to call already built PowerShell scripts.

There is a MMC-look-alike that integrates well with PowerShell scripting: http://www.powergui.org.

Marco Shaw
There are a few cons: Having to stash objects in nodes to be pulled out later making it difficult to parameterize from above. MMC itself creates your views so that can cause difficulty in the design. MMC caches your views which means that you have to devise ways of refreshing the data.
Ed Sykes
However, if you're devloping an enterprise console the admin's you're targeting will expect your console to be an MMC snap-in. Using anything else will just create a barrier to selling your product.
Ed Sykes
+5  A: 

If your app is targeted to Sysadmins, offering a MMC snap-in is a good idea. Assume all windows services would have an own GUI, that would definitely suck for the admins. Using MMC they can collect all the snap-ins they need for their work in a single place and work more efficiently. Having the possibility to connect it to remote machines is another Plus.

driAn
+2  A: 

Ideally, it shouldn't be all that cost-prohibitive to entertain both ideas. Encapsulate your logic in a DLL, and have bother MMC, PowerShell, whatever use those public routines. I always appreciate having the choice - particularly when it is something repetitive, which MMC does not lend itself to very well.

Goyuix
actually - one theory is to implement all the logic in Powershell cmdlets, and then build the GUI (MMC) on top of *that*. This is a great way to keep yoruself honest. What it means is that there is NOTHING you can do in the GUI, that is not also possible in the scripting (powershell) interface.
Cheeso
I like Cheeso's idea. As an admin, I can always find circumstances where the command line is the only option. And PoSh is the new command line for admins who just want to get things done.
serialhobbyist
+2  A: 

Pros: as mentioned before - a familiar UI for admins. Using MMC snap-ins, an admin can stitch together custom admin "shells" with just the snap-ins (s)he needs. That's a BIG plus for an admin!

Cons: less flexibility in terms of the UI, and a more "complicated" (e.g. pre-defined) way of building your app.

If you're really serious about targeting admins in a big way --> definitely go MMC (or possibly offer an MMC and a custom version - that way your users can pick the one they prefer).

Marc

marc_s
+3  A: 

PROS:

  1. standard UI sysadmins are familiar with.
  2. Framemwork that implements the treeview + listview model, including classes for element properties, selection, context menus, column selection, sorting etc.

CONS:

  1. not flexible. want to set a background color for a listItem row? forget it.
  2. restrictive framework, no source code. I ran into threading and UI access issues and spent many hours trying to figure a way around it.
  3. poor documentation. don't bother googling for most problems
  4. deployment - really, it's much simpler to supply a web based administration UI imho. be sure not to find out that's what your clients really need and want AFTER you spent money on building a "rich" MMC client.

last - you never mentioned what you need the MMC Snap in for. the more complex your requirements are, the better you stay away from MMC. but if you want to build a quick small configuration interface, you could save time by downloading the code samples and have a prototype running in no time.

Yonatan Karni
+2  A: 

Another disadvantage of using MMC snap-ins is that they don't support .NET 4.0. I encourage you to read the following: http://connect.microsoft.com/VisualStudio/feedback/details/474039/can-not-use-net-4-0-to-create-mmc-snapin.

Note that there is a workaround mentioned there.

Piotr Nedzynski