Windows exposes a great deal of system information through WMI (Windows Management Instrumentation). The 70-536 exam measures your capabilities to query WMI, subscribe to events, etc. Not the names of different WMI types (although I have seen test questions about those, but they could be figured out by pure logic).
To access WMI, you’ll need to set a reference on the System.Management namespace, and include a using directive for it. Then the following steps:
Continue reading “Embed Management Information and Events”
You have to choices to store application data when working with the .NET Framework. The first opportunity is to hard-code it, the second is to use external, XML-based configuration files. The .NET Framework has a whole hierarchy of these files. On the top of it lives the machine.config. This configuration file is machine-wide, all managed applications refer to it.
When you are working with web applications, the hierarchy can have numerous levels. For standard (desktop) applications, there’s only one more level, the application configuration file of the current program. This typically has the name of TheApplicationName.exe.config.
First, let’s set out the rules. If you’d like to read from a configuration file from your code, you’ll require rights for reading all configuration files which plays a role in your application, back to machine.config. To modify configuration files from code, you’ll need the reading rights mentioned before, and writing rights to the application’s configuration file.
Continue reading “Embed Configuration Management Functionality”
The .NET Framework provides functions for the sake of compatibility with unmanaged (COM or C) codes. In this section, I’ll introduce the technique of Platform Invoke (PInvoke).
Platform Invoke is the process of calling unmanaged functions which lives in DLLs from managed code. You need to take four steps:
- Identify functions in DLLs.
- Create a class to hold DLL functions.
- Create prototypes in managed code.
- Call the DLL functions.
To identify functions in DLLs, you should know at least the name of the DLL and of the function. Without it, you are doomed, there won’t be any platform invoke.
I think you can handle the brutal work of creating a class for holding the DLL functions, let’s concentrate on those prototypes. To create those prototypes, you’ll need to define a static extern method, and mark it with the DllImportAttribute. A quick example:
Continue reading “Call Unmanaged DLL Functions”
As its name suggests, XML serialization is the process of serializing an object into XML format. Quite luckily, the format of the XML file can be massively customized, so be prepared for dumb questions, like which XML file well be the output of this code, or the reverse (even better).
The classes of XML serialization lives in the System.Xml.Serialization namespace. No reference needed, because this namespace is part of the System.Xml.dll, which is linked by Visual Studio for every project.
The main class here is XmlSerializer. Now this class has absolutely nothing to do with the previous formatter classes. It has three useful instance methods, namely Serialize, Deserialize and CanSerialize. Yes, CanSerialize needs an XmlReader and returns true if the read XML file can be serialized by the instance. The Deserialize method is essentially the same as it was at the formatter classes, can read any kind of Stream, or Reader classes (XmlReader included!). However, the Serialize method is very different from the others. It takes a type (only include a single type when you are working with an Object-derived type with no is-a, has-a relationships), and an array of types, for the respective is-a, has-a relationships. Yes, you need to include every single type that participates in your object’s life.
Continue reading “XML Serialization”
This objective covers the use of the BinaryFormatter and SoapFormatter classes. I frankly don’t understand why they should be separated from the rest, with a title of custom serialization, but I guess we should just learn it.
These classes lives in the System.Runtime.Serialization.Formatters namespace. Even better, BinaryFormatter lives in the Binary namespace, and SoapFormatter in the Soap namespace. You will need to set a reference on the System.Runtime.Serialization.Formatters.Soap namespace in order to use the SoapFormatter class. BinaryFormatter is included by default.
BinaryFormatter serializes or deserializes yoir objects into a binary object graph. It will need two things to do so: a stream (not necessary a file stream) and an object, marked as Serializable. By default, all public fields and properties are serialized (and private fields with public properties). You can override this setting by mark your fields with the NonSerializable or OptionalField attribute. The latter is useful when dealing with version-compatible serialization.
Continue reading “Custom Serialization Formatting”
Serialization is the process of persisting the current state of an object into a stream in such a way that it contains all information to be deserialized into the same object when needed. You’d do this typically when you’re dealing with remoting services, or when working with web services.
There are two types of serialization in the .NET Framework:
- Serialization by creating object graphs
- XML serialization
Continue reading “Serialization and Deserialization”
In this post, we’ll examine the text handling capabilities of the .NET Framework. We’ll review three major objectives of 70-536:
- StringBuilder class
- Regular Expressions
- Encoding and Decoding text
Strings in the .NET Framework are immutable. Memorize it, immutable. They cannot be altered. Instead, every time you modify a string a new instance of String is created with the new value, and the pointer will be assigned to the memory location of your new string. So when you need to dynamically build strings (for example, adding it line by line), you should use the StringBuilder class.
Continue reading “Enhance Text Handling Capabilities”