Conference Management Toolkit_wolverine access

ManagementObject mo = new ManagementObject( @//BCK_OFFICE/root/CIMV2:Win32_ComputerSystem.Name='BCK_OFFICE');

Often when you are developing a managed application you will want to work with WMI objects on your

local machine. But because hardcoding the server name into a program is not a very flexible solution, 

you can substitute "." (which stands for the name of the local machine) for the server name. In fact, 

you don't need to include the name of the hosting server or "." in the object path at all; if you omit it, 

the local computer system will be the default server.

通常，你在开发管理程序时是希望使用本地的WMI对象。你可以通过硬性编码的方式指定服务器的名称来使用本地的WMI对象，但是这不是

一个好的解决方案.你可以使用"."来代替。"."是标准的本地机器的替代名称。事实上，你并不需要在路径中使用主机名称或"."。如果你

忽略了他们，本地机器就会是默认的服务器。

The namespace portion of the path is also optional and, if you omit it, root/CIMV2 will be the default.

In our discussion of WMI settings in Chapter 1, you learned that the default value for the namespace is

specified by the HKLM/SOFTWARE/MICROSOFT/WBEM/Scripting/Default Namespace registry setting. You may also

recall that changing the registry value does not affect the namespace to which ManagementObject gets bound. 

This is because the default path is hardcoded in the ManagementPath type's static type constructor so that

every time this type is loaded, its static property, DefaultPath, is set to //./root/CIMV2. During its 

initialization sequence, the ManagementObject type examines the supplied object path and, if necessary, it 

reads the default value from the ManagementPath's DefaultPath property. Hopefully, in future FCL releases, 

Microsoft will address this issue and make sure that the default namespace for ManagementObject is 

configurable rather than hardcoded.

路径中的命名空间部分也是可选的，如果忽略它，root/CIMV2就是默认的命名空间。在第一章中，你知道了默认的命名空间是通过注册表中

的HKLM/SOFTWARE/MICROSOFT/WBEM/Scripting/Default Namespace指定的。你可能还记得通过改变注册表中的键值无法影响

ManagementObject绑定的默认空间，这是因为默认的空间已经硬编码到ManagementPath的DefaultPath属性里。

Although you must encode a unique object identity into the object path, including the name of the property

that functions as an object's key is optional. In other words, you can place an equal sign and the value of 

the key directly after the name of the class—WMI is smart enough to apply the value to a correct property 

based on the class definition. Therefore, to create an instance of the ManagementObject type that is bound 

to the WMI class's Win32_ComputerSystem instance (which resides on the local machine), you would use the 

following code:

虽然你必须在对象路径中指定一个唯一的对象标识符，但是属性名称是可选的。换句话说，你能直接在WMI类的后面跟上等号和属性的值，WMI类

能自动的把值赋给正确的属性。因此，产生一个绑定到本地机器的ManagementObject的实例可以这样写（省略了Name熟悉）：

ManagementObject mo = new ManagementObject(@"Win32_ComputerSystem='BCK_OFFICE'");

Accessing Singletons

Anyone who spends some time playing with WMI will eventually notice that there are some classes that don't 

seem to have any key properties. For example, the Win32_WMISetting class, discussed in Chapter 1, does not 

designate any of its properties as a key that uniquely identifies a given instance. The reason behind this 

is simple—these classes, known in object-oriented parlance as singletons, are restricted to having only 

one instance at a time.

凡是花费一定的时间使用WMI的人都会注意到，有些类没有任何关键属性。例如我们第一章提到的Win32_WMISetting类，没有任何一个属性

作为关键属性来唯一的标识一个实例。这里的原因很简单，因为这个类是单一的，一次只能有一个实例。（个人感觉有些问题）

To bind a ManagementObject to an instance of a singleton class such as Win32_WMISetting, you may assume 

that you can just use the class name as a path and let WMI figure out the rest. However, this approach does 

not quite work; as a result, the following code throws an ArgumentOutOfRangeException:

将一个ManagementObject对象绑定到一个单一的实例如Win32_WMISetting,你可能觉得可以只使用类名作为路径其他的事情WMI会自动的

完成。不过，这个方法不可行。下面的代码就是这样做的，执行的结果将会抛出一个ArgumentOutOfRangeException的异常。

ManagementObject mo = new ManagementObject("Win32_WMISetting");

Appending the equal sign right after the name of the class will not work either; doing so will just cause 

WMI to throw a ManagementException. It turns out that WMI has a special syntax to access singletons. 

As demonstrated by the following example, you have to use the @ placeholder as a property value:

在WMI类名的后面跟上等号"="也同样运行不起来，这样会抛出一个ManagementException异常。其实WMI对于访问单一的实例有专门的语法。

下面的例子说明了这一点，你需要使用@占位符来作为一个属性值。

ManagementObject mo = new ManagementObject("Win32_WMISetting=@");

During its initialization sequence, ManagementObject validates the object path that is passed as 

a parameter to its constructor. To aid the validation, it uses another type, called ManagementPath, 

which is responsible for parsing the path string and breaking it up into the server, the namespace 

path, and object path components.The ManagementPath is a public type, and as such, you can create it 

manually and then feed it into an overloaded version of the ManagementObject constructor. In fact, 

this type offers a slew of useful properties and methods and, on occasion, using it may ease the 

process of binding the ManagementObject to a WMI class instance. The following code, for instance, 

does the same thing as the previous example:

在初始化ManagementObject的过程中，将确认ManagementObject构造函数中参数的合法性。为了帮助验证，这里还使用了另外一个类型为

ManagementPath的参数。这个类型负责分析路径字符串，将其分解为服务器、命名空间、和对象路径。它是ManagementObject构造函数的

另外一种参数类型。事实上，ManagementPath提供了一系列有用的方法和属性。有时使用它可以很容易的将ManagementObject绑定到一个

WMI实例。下面的代码和先前的代码功能相同：

ManagementPath mp = new ManagementPath();
mp.Server = "BCK_OFFICE";
mp.NamespacePath = @"/root/CIMV2";
mp.ClassName = "Win32_WMISetting";
mp.SetAsSingleton();
ManagementObject mo = new ManagementObject(mp);

Here the properties of the ManagementPath instance are explicitly assigned and then the path is marked as a 

singleton path using the SetAsSingleton method. This approach is cleaner and more readable because the 

ManagementPath object takes care of assembling a valid WMI object path and relieves the user of remembering 

the syntax details, such as separators and placeholder values.

这里明确的设置了ManagementPath的各项属性，然后通过SetAsSingleton方法将其指定为单一对象的路径。这种实现方式非常的清晰

而且更加具有可读性。因为ManagementPath对象管理WMI对象路径，减轻了用户记忆语法细节的负担，例如分隔符和占位符。

Using the ManagementPath Type

I already mentioned that the ManagementObject type constructor creates an instance of ManagementPath 

internally, unless, of course, you pass it as a parameter. In either case, you can access the 

ManagementPath object, which is associated with a given instance of a ManagementObject, through the 

Path property of the ManagementObject type. Therefore, the code above could be rewritten as follows:

我已说过ManagementObject的构造函数将在内部产生一个ManagementPath实例，除非你使用以ManagementPath为参数的构造函数.

这两种情况下，你都可以通过ManagementObject的Path属性来访问和当前的ManagementObject实例相关联的ManagementPath对象。

因此上面的代码可以改写成这样：

ManagementObject mo = new ManagementObject();
mo.Path.Server = 'BCK_OFFICE';
mo.Path.NamespacePath = @"/root/CIMV2";
mo.Path.ClassName = "Win32_WMISetting";
mo.Path.SetAsSingleton();

This approach is, perhaps, a little more concise, but otherwise it is no different 

from the previous one.
这种方式可能稍微简洁一点，除此之外它和前面的代码没有任何不同。

One other property of the ManagementPath type, which I already mentioned, is DefaultPath; 

this property contains the default server and namespace portions of the object path. 

As you may remember, the initial value of this property is automatically set to a hardcoded 

string, "//./root/CIMV2", when the type is first loaded. Because the DefaultPath is a static 

property that can be written into, if you set it manually before using the ManagementPath type, 

you will affect the default namespace settings for all the subsequently created management 

objects. Thus, to make the default namespace setting configurable via the system registry, you 

can use code similar to the following:

我曾提到过ManagementPath的DefaultPath属性。这个属性包含了默认的服务器名和命名空间。你可能还记得，在这个对

象首次加载时，该属性的初始值是通过硬编码的方式设置为"//./root/CIMV2"。由于该属性是个静态属性而且能够被改写，

因此你可以在使用ManagementPath前，手动的设置DefaultPath属性的值来影响后面所有创建ManagementObject时的命

名空间。你可以用类似于下面的方法实现系统注册表初始化ManagementObject的默认命名空间。

RegistryKey rk = Registry.LocalMachine.OpenSubKey(@"SOFTWARE/Microsoft/WBEM/Scripting");
ManagementPath.DefaultPath = new ManagementPath(rk.GetValue("Default Namespace").ToString());

This code first reads the static LocalMachine property of the Microsoft.Win32.Registry type to get

a reference to an instance of Microsoft.Win32.RegistryKey type that is bound to the HKEY_LOCAL_MACHINE 

registry key. It then retrieves the reference to the SOFTWARE/Microsoft/WBEM/Scripting subkey using 

the OpenSubKey method of the RegistryKey. Finally, it assigns the value of the Default Namespace 

registry entry (obtained with the GetValue method of the RegistryKey type) to the ManagementPath type's 

static DefaultPath property.

这段代码首先获得了Microsoft.Win32.Registry的静态属性LocalMachine的引用。该属性和HKEY_LOCAL_MACHINE注册表键相关联。

然后通过RegistryKey的OpenSubKey方法来检索SOFTWARE/Microsoft/WBEM/Scripting子键。最终用Default Namespace键的值

设定了ManagementPath的DefaultPath静态属性。

The ManagementPath type has a few other properties that may come in handy when you are analyzing an 

arbitrary WMI object path. Using these properties, you can determine whether an object path refers to 

a class or an instance of a class and whether the object at which it points is a singleton. For instance, 

this snippet of code

ManagementPath还有一些其他的属性在分析WMI对象路径时非常的方便。使用这些属性，你能知道一个路径指向的是一个类还是一个实例。

如果指向一个类，你可以知道这个类是不是单一的类。例如下面这段代码：

ManagementPath mp = new ManagementPath("Win32_WMISetting=@");
Console.WriteLine("Class: {0}", mp.IsClass);
Console.WriteLine("Instance: {0}", mp.IsInstance);
Console.WriteLine("Singleton: {0}", mp.IsSingleton);

produces the following output on a console:

Class: False
Instance: True
Singleton: True

Implicit vs. Explicit Binding

Although the ManagementPath constructor and property set routines validate the object path, the scope of 

this validation only ensures that the path is compliant with the WMI object path syntax constraints. So, 

if a path contains the name of a nonexistent class, the ManagementPath type will not throw any exceptions. 

For instance, if the name of the class in the previous example is mistakenly entered as Win64_WMISetting 

rather than Win32_WMISetting, the code will still work perfectly and produce the same results. Moreover, 

if you try to create an instance of ManagementObject type based on an object path that references a 

nonexistent WMI class, you will succeed. However, the instance you get will be largely unusable and if 

you invoke its methods, a ManagementException will be thrown.

虽然ManagementPath构造函数和属性会检查对象的路径，但是范围也只限于路径要符合WMI对象路径的语法规则。因此，如果路径中包含

一个不存在的类，ManagementPath不会抛出任何异常。例如，如果把前面例子中的WMI32_WIMSetting误写成WMI64_WMISetting，代码

仍将正常的运行并得到同样的结果。此外，如果你用这个不存在的类产生实例也可以成功。但是，这个实例大多数是无法使用的，如果你调用

它的方法将会抛出一个ManagementException异常。