Today I took the test in my local Prometric testing center, and beat it with a score of 768, in roughly an hour. It was a considerably more comforting experience than the 70-562, I knew the correct answer for a lot of questions at first glance.
About the topics: there were a massive amount of serialization and file-system questions, then a lot of security-related ones and a whole lot about globalization. Reflection and COM interop wasn’t covered as much as I expected it, but it wasn’t a bad thing, at least for me.
All in all, I faced with what I expected, it was an easy exam, with some hardcore stuff just to make you sweat while you are waiting for the results.
It’s nice to be an MCTS, but my goal was always an MCPD certification, so I give two weeks (or max a month) to take the 70-564 PRO ASP.NET exam, and earn it.
The meaning of reflection is to provide information on an assembly, type, a method, a constructor or an interface implemented. Every time you run the .NET Reflector, or simply use the dot syntax to explore the members of a class by Intellisense, you use reflection.
Reflection is particularly useful when you have no compile time knowledge of a given type (let’s say for example when you want to create an extendable application). To implement and load a snap-in, you’d create a method which checks for an assembly (the snap-in itself). You’d mark the classes with attributes, or even better, implement a predefined interface (which this time will really act as a contract). What you’d do is the following:
- Create a Class Library (e.g.: Commons.dll), and define your interface there.
- Create your main application, and set a reference on the Commons.dll
- Create a method which checks for the implemented contract interface in a given assembly (or in a group of assemblies, for example in the \\AppPath\SnapIns directory.
- Create some snap-ins, set a reference on the Commons.dll, and create classes which implements it.
- Run your application.
A quick refresher about the security policies of the .NET Framework:
- Security Policy Levels
- A Hierarchy of Code Groups
- Named Permission Sets associated with Code Groups
- Evidences of an assembly
- Application Domain hosts that provide evidences to the CLR
Don’t worry if you can’t recall all of these, check out the MSDN link at the bottom, called Security Policy Management. This post will be about the namespace System.Secuirty.Policy. This namespace contains code groups, membership conditions and evidences. The previous three types are used to create the rules applied by the CLR. Evidence classes are the inputs of security policies, and the membership conditions are switches of it. The policy levels and code groups are the structure of a policy hierarchy. Code groups are the encapsulation of a rule and are members of the policy level.
The .NET Framework introduces a new layer of security, called Code Access Security. This layer lives on top of the OS security, and lets you control what a given assembly can and can’t do, just like the OS lets you define the rights of a user or group.
Before we dive into the details, there’s something (which may seem obvious at first, but is a particularly good thing to remember on the exam): whatever permissions you grant to a code, it will never have more rights than the user who runs it (just recall ASP.NET and IIS).
In the previous post, I wrote about permissions. The first important layer of CAS is the control of them. There are default permission sets, defining what an assembly can do. They are as follows:
|FullTrust||Exempts an assembly from CAS checks.|
|SkipVerification||Enables an assembly to bypass permission checks.|
|Execution||Enables an assembly to solely run.|
|Nothing||No permissions granted. Not even enough to run the given assembly.|
|LocalIntranet||The main restriction is that the assembly is not allowed to tamper with the file system, only through file dialogs.|
|Internet||A restrictive permission set, but safe.|
|Everything||Grants all permissions, but still checks the assembly.|
The classes related to controlling permissions and access for resources are live in the System.Security.Permissions namespace. There are a whole lot of permission classes for imperative security access settings, and each of them has its declarative attribute counterpart. There are three major categories of them:
- Code access permissions
- Identity permissions
- Role-based permissions
Code access permissions represents access to a given resource or the ability to perform a specific operation. For example, FileDialogPermission and RegistryPermission are classes which fall into the category of code access permission.
Now this one is short will be short and will have nothing to do with the title. I’ve found four enumerations in the System.Security.Authentication namespace. The most important of these is the SslProtocols enumeration. It has five possible values. You should know that the Ssl values (Ssl2 and Ssl3) are provided only for backward-compatibility and they are all superseded by the Tsl protocol. The fifth value is None, and it speaks for itself. Here’s a repeat for a better layout of this blog:
- SSlProtocols enumeration:
- Default (Ssl3 or Tsl will be used)
I forgot to mention that this enumeration controls which SSL protocol should be used for a given SslStream. Just in case if someone didn’t figure it out.
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: