Creating MMC Snap-Ins
This column appeared in the June 2000 edition of EXE.
It discusses the MMC snap-in designer, a tool that not many people know about
One of the criticisms that I seem to recall Microsoft
promising to address around the time of the Visual Basic 6 launch was that
there would be a central Visual Studio site that would be a one–stop
location for developers. No more would it be necessary to trawl through the
Microsoft web site to track down items that you’ve heard about but
can’t find, and the world would therefore be a happier place, etc. I just
mention this because I think Microsoft need to be reminded that they said this.
Possibly a better kept secret than which of the characters from The Simpsons
was going to be killed off is the existence of the MMC snap–in designer VB
project template. Well, I’m pleased to report that I’ve tracked it
down, have spent some time getting to know it, and am reporting on it in this
month’s column.
Before I start, a quick recap is in order. MMC, or the
Microsoft Management Console to give it its full name, is a standard
environment through which different components within Windows can be
configured. Its primary benefit is that it provides a consistent interface for
support and administration staff. MMC itself has been around since SQL Server
7.0 and the earlier versions of Microsoft Transaction Server, but nowadays it
actually comes as an integral component within Windows 2000.
MMC is a host application that contains snap–ins;
separate code components which can be loaded to provide management
functionality for a Windows application or service. If you’ve got access
to Windows 2000 then track down the Computer Management application for an
example of its usage. If you’ve got an NT 4 server that has had the NT 4
Option Pack or SQL Server 7 installed then you are probably running MMC version
1.1; if you’re running Windows 2000 then you’ll have version 1.2. If
you find that you’ve only got version 1.0 then you’ll need to upgrade
because version 1.1 is the minimal requirement for the MMC snap–in
designer. Likewise, the snap–in designer will not run with any other
release of Visual Basic than version 6.
Providing your administrative programs via MMC is actually a
Windows 2000 logo requirement, but even if you’re not yet developing for
this platform (or aren’t interested in forking out for the logo) you might
still want to go down this route in order to take advantage of the benefits
that MMC offers. It’s likely that you will find some version of MMC
already installed on most servers as I’ve described above, otherwise you
can bundle in the MMC setup program on the back of your own installation
routine by obtaining the necessary components from
http://www.microsoft.com/management/mmc/download.htm.
Finding and installing it
The MMC Snap–In Designer for Visual Basic 6 can be found
either on the Microsoft web site or on the Platform SDK that ships with MSDN.
At the time of writing (April) the version on the web –
http://www.microsoft.com/management/mmc/vb6designer.htm – is still
an old beta release, despite my having pointed this out to them a couple of
months ago. For those of you who have access to the Platform SDK (disk 3 of the
MSDN Development Platform set) the release version is available, but to install
it you need to check the following sequence from the Platform SDK setup
program: Sample Code, Management Samples, Microsoft Management Console Samples.
Once this installation has completed you can load up Visual Basic 6 in which
you should be able to see that a new project type called SnapIn is now
available. Go ahead and create this new project and you will find that the
Project Explorer consists of a User Controls folder containing an item called
SnapInControl, and a Designers folder containing SnapIn1. The SnapInControl
item isn’t always likely to be of much use but it’s important that
you don’t delete it from the project. Most of the development that you
need to do will be from the context of the designer item, in this case SnapIn1.
The Designer window
Double–clicking SnapIn1 will open a TreeView
configuration construct as shown in figure 1.
Figure 1: The MMC snap-in designer in design mode
Note that this isn’t something that will be visible at run–time; its
purpose is to let you customise the default implementation that the designer
provides. The root node name, initially set to SnapIn1, should be altered (if
you’re going to) as soon as possible to something more relevant. The
Properties window also displays some of the other values that you will probably
want to set or alter, such as the display name, help file, and description
text.
The designer tree view consists of four main folders, each of
which can contain further sub–folders. These main folders are:
-
Nodes: MMC is organised very much like
Windows Explorer, in that the left hand pane – the scope pane – is a
TreeView control and the right hand pane – the results pane – can
contain any one of four different types of view. In the left hand pane each
folder is referred to as a node. A snap–in always has a static node which
is shown as the Console Root folder in the MMC environment. Nodes can be
defined at design–time, or they can be created dynamically at
run–time.
-
Extensions: Add–on components to other
snap–ins. This is the MMC equivalent of common code in that an extension
might well be used by more than one snap–in. Extensions typically add
property pages, toolbar buttons, and they can also add additional nodes to the
main snap–in tree view hierarchy.
-
Tools: Consist of image lists, menus, and
toolbars. These standard windows resources are applied to the child window
owned by the current snap–in and will typically have standard Visual Basic
code accompanying them. One notable difference with this particular method of
design is that menus are defined by right–clicking the Menus folder and
choosing Add Menu, rather than the traditional method employed by the Visual
Basic Menu Editor.
-
Result Views: There can be four kinds of
result views: List views, OCX views, URL views, and TaskPads.
-
A List view, as the name implies, uses a ListView control to display item data
such as a list of files.
-
The OCX view is determined by the characteristics of the OCX control being
utilised. This will typically be a custom ActiveX control.
-
A URL view is a browser interface.
-
The TaskPad is a means of displaying shortcuts to actions in a very simple
fashion. They typically consist of hotlinks or icons from which dialogs may be
raised, wizards started, or property pages displayed. An example of a TaskPad
can be found in the SQL Server 7 Enterprise Manager snap–in by clicking on
the databases node in the scope pane.
Compiling and deploying a snap–in
By default a snap–in project will suggest a compiled
target filename with an .ocx extension, which is due to the fact that the
snap–in project template is actually based upon the template for an
ActiveX control. Snap–ins are normally given a .dll extension so Microsoft
recommend as good practice that you rename the offering from .ocx to .dll (if
you edit the underlying template then you can alter this behaviour). Having
created an initial version of a snap–in you can then open the Components
tab of the Project, Properties dialog and click the binary compatibility option
in order to retain the same interface id values.
I’ve commented before on how Microsoft are now generally
being much tidier when it comes to standard locations for files, and this is no
exception. The snap–in designer has a required runtime file called
mssnapr.dll which Microsoft would like to see placed at \Program Files\Common
Files\ Microsoft Shared\SnapInDesigner. The snap–in DLL should be
installed to whichever target application folder you see fit, and the only
other required file is the Visual Basic runtime file msvbvm60.dll which belongs
in Windows’ System32 folder. Once these files are in place you will need
to register them with RegSvr32.exe. Be sure to register mssnapr.dll and
msvbvm60.dll before you attempt to register the snap–in DLL because these
runtime files are dependencies for the snap–in; if they are not registered
then the snap–in registration will fail.
Raising a configuration wizard
It is common for a snap–in to raise a configuration
wizard when it is formally added into MMC in order to gain some parameter data.
As part of the process of adding a snap–in to the MMC console a
QueryConfigurationWizard event is fired by MMC, and is received by the
corresponding SnapIn_QueryConfigurationWizard template in the code behind the
SnapIn1 designer. If you wish to go ahead and raise a configuration wizard then
you should set the supplied HaveWizard parameter to True. Once this value has
been received by MMC then a subsequent event called CreateConfigurationWizard
is raised.
A configuration wizard consists of one or more property pages
that can be created by selecting Add Property Page from the Project menu. Each
property page should include an implementation of an interface called
IWizardPage; this is achieved by adding the line
Implements IWizardPage
to the module–level declaration area. This interface
exposes four methods called Activate, Back, Finish, and Next which give you the
opportunity to save the data so far, or otherwise take some form of control
over the contents of the other property pages.
In the SnapIn_CreateConfigurationWizard code it is necessary
to add whatever predefined property pages are relevant, which is achieved as
shown in Listing 1.
Private Sub SnapIn_CreateConfigurationWizard(ByVal
PropertySheet As SnapInLib.MMCPropertySheet)
PropertySheet.AddWizardPage "ppgIntro", moConfigData
PropertySheet.AddWizardPage "ppgParms", moConfigData
End Sub
Listing 1: Adding property pages to a configuration
wizard
The pages must be added in the order in which they will be
presented. Note the second parameter, which I have shown as a mythical data
item called moConfigData. This parameter is defined as an Object data type
which is used purely for passing an instance of a user–defined class for
the purposes of data cargo. In this case I would have written a class called
CConfigData which exposes properties for all the data items that I want to
store. The mechanics of how the data is actually stored is up to you, although
it is customary to write them to a PropertyBag object which is supplied to both
the ReadProperties and WriteProperties routines within the SnapIn object.
Sample code
For this particular article I have opted
not to produce a sample set of code for download. The Platform
SDK documentation has a section entitled Common Development Tasks
that walks you through the fundamentals of creating snap–ins
with various different kinds of result panes, and I would point
you in this direction. My aim this month has been to raise awareness
of the tool and to outline the fundamental concepts that go along
with it; to go into it in any depth would require more sample
code than I could fit in to two pages. However, the MSDN–based
install will copy several well–written Visual Basic sample
projects to your hard disk and these really are worth some study
(particularly FileExplorer.vbp) before you embark on a project
of any size.
