Now I’m a bit stuck in my .NET studies (I’m slowly getting unmotivated because the 70-536 exam seems to focus on method overloads and constructors), so I decided to play around with iPhone development and Objective-C a little. I’ll recently publish my first app, it’ll be a quiz application, just to get the flavor of it.
The goal is to publish some really eye-catching apps, but first I’ll need to train myself into the Cocoa Framework, and then find (or train) a graphic expert for my company.
The point is, for a little time, .NET notes will be suspended. I think I’ll post some iPhone-related articles during this period, but I’ve just started studying the language, so I’m not very confident in it, and don’t want to mislead anybody with my possible errors.
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:
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.
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:
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.
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.
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