70-515. TS: Web Applications Development with Microsoft .NET Framework 4

With the announcement of the .NET 4.0 exams, it seems a bit like a wrong career move not to aim for taking the web application development certificate for 4.0 instead of 3.5, since I have already been working with VS2010 for some time now.

Looking at the Skills Being Measured List it seems like a good idea to continue studying the MCTS Self-Paced Training Kit (Exam 70-562) with a sharp eye to the list of topics.

Hopefully I will be invited to take a beta exam when they come out in April.

I guess a good place to start looking into the ASP.NET 4.0 would be here

Here are some of my comments to the elements of What's new:

• Prealoading Web Applications

Reflecting on a Reflection description

I was quite surprised when I arrived at the Reflection chapter in my self training book, because on the first page I found the following:

Reflection is useful anytime you need to examine or run code that isn't available at runtime.

MTS Self-Paced Training Kit (Exam70-536): Microsoft .NET Framework - Application Development Foundation, SECOND EDITION

After I read this, I fear I really need to study Reflection, because the reflection I studied at the university, was exactly the opposite. But I guess just because reflection means something in the Java world doesn't mean that its the same on .NET.

Code Access Security (CAS)

In the .NET framework all assemblies (which run managed code) is running in their own security scope. Which doesn't just depend on the user running the assembly(in respect to the Role-Based security (RBS)) but also on the Code Access Security (CAS).

The CAS system gathers evidence to identify assemblies to determine which code group the assembly belongs.

Evidence

Evidence is data which the CAS collects at runtime to determined the assembly's security level, like a user is identified by username and password.

Examples of Evidence is:

1. Applications directory


2. Hash


3. Publisher


4. Site


5. Strong Name


6. URL


7. Zone: The zone in which the assembly is running(Internet Zone, Intranet Zone, or Trusted Zone)

permissions

There is a long list of things an assembly needs to have permission to do, like sending web requests, read or write files ect. for a complete list look here: (System.Security.Permissions Namespace)

A specific example could be the File dialog permission(link), which specifies whether an assembly may present one to the user. Another permission can be File IO which restricts access to files and folders(link)

Permission set

So, this seems pretty straight forward, a permission set is a set of permissions right, it is a so called ACL (Accesss Control List), which means it is a list of permissions, used by the CAS to verify whether it should give permission/access to an assembly.

A well known permission set is the Internet default permission set, which contains the following permissions:

1. File Dialog


2. Isolated Storage File


3. Security


4. User Interface


5. Printing

Most are self describing, even if it is worth noting that the Security permission gives the permission to execute, but as with all permissions there are many levels of a permission, look further here SecurityPermissionFlag

.Net framework contains seven default permission sets.

Code group

Based on the evidence, an Assembly is places in a specific code group. A code group is a user groups provided to RBS, its connects the assemblies with permission sets. A group membership condition is determined by one piece evidence which the assembly should have.

An assembly can be member of several groups, if so the assembly will receive the union of the permissions in the permission sets.

Code groups can also be nested inside each other, which allows the manager to make arbitrary complex structures. An example of such a hierarchy is: assemblies with Microsoft strong names is placed in a group called Microsoft_Strong_Name code group, which is contained in My_Computer_Zone code group which again is contained inside All_Code. (in short All_Code->My_Computer_Zone->Microsoft_Strong_Name)


--

Security Policy

Okay so all these things together, should also have a term, so we can make different sets of all these things, and these sets is called a security policy.

A security policy is a logical grouping of code groups and permission sets. The security policy is used to group the security into levels. There are four default security policy levels; Enterprise, machine, User and Application Domain.

Since these overlap an assembly's permission set is the intersection of the policies.

By default, the Enterprise and User security policies grant all code full trust.

Put It All Together

The system administrator can make security policies for the hole network (enterprise security policy), for each computer, for each user, and application domain.

Inside each policy he might look at the different code groups (fx. My_Computer_Zone, LocalIntranet_Zone, Internet_Zone) and check permission set of the groups.

When an assembly is loaded, the system will look at the evidence, and figure out which groups the assembly is in. then all the permissions of these groups are joined, but then you have to take the intersection of the policies, meaning that the policy which is most restrictive sets the permissions. when all this is finished the CAS will compare notes with the RBS of the operation system, and again choose the most restrictive set of permissions. This is also called Security stack walk

System.Drawing for backend programmers... hmm

On my quest to become certified microsoft programmer I have arrived at chapter 6 in my self paced training kit for exam 70-536. Which is about drawing graphics. So far I have seen the logic in the topics that every Microsoft certified something should know - reading from files, using different encodings, but drawing graphices, is a bit of a strange topic to put in the basic certificate. Especially when you take it to be allowed to take 70-503 exam which will enable you to call yourself Microsoft Certified Technology Specialist (MCTS) in .NET Framework 3.5, Windows Communication Foundation, which is about communication in distributed systems.

Anyway, now I have just learned to make a jpg file with the following picture:



Which I am sure will come in handy next time I develop a WCF web service, or create a distributed application.

Did it with the following code: (more or less taken from the book)

Bitmap bm = new Bitmap(600, 600);
Graphics g = Graphics.FromImage(bm);

Brush brush = new LinearGradientBrush(new Point(1, 1),
new Point(600, 600),
Color.White, Color.Red);
Point[] points = {
new Point(77,500)
, new Point(590, 100)
, new Point(250, 590)
, new Point(300, 410)
};
g.FillPolygon(brush, points);
bm.Save("bm.jpg", ImageFormat.Jpeg);

WCF service behavior

Unlike the contracts and the addresses a behavior does not always affect both client and server. A behavior can be local and affect only the server sides way of processes the messages.

A behavior is not exposed as part of metadata.

A behavior can either be a service behavior or an endpoint behavior:

Service Behaviors (behaviors which implement IServiceBehavior

A typical service behavior is the debug logging behavior, which is enabled by adding a serviceBehavior in the config file.

Like this:
<behaviors>
<serviceBehaviors>
<behavior name="serviceBehavior">
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
</behaviors>

One thing that is important to remember is to associate the service with this behavoir. like this:

<services>
<service behaviorConfiguration="ServiceBehavior" name="host.HelloIndigoService">
[...]
</service>

Behaviors can of cause also be added programmatically.

Endpoint Behaviors(behaviors which implement IEndpointBehavior

A endpoint behavior is defined in the same way, but here its not associate with a service but with the actual endpoint.

WCF Metadata Exchange (mex)

To my understanding, metadata exchange (in WCF) means whether the service will offer a WSDL or other types of metadata to a client to enable them to autogenerate a proxy for the web services.

By default it is not enabled to exchange metadata, so its something that has to be added as an extra endpoint.

The endpoint works as any other endpoint (see link), where the contract type IMetadataExchange is mandatory. This contract type is a predefined service contract which is found in System.ServiceModel.Description namespace.

The endpoint can have different kinds of bindings like MexHttpBinding (meaning HTTP), MexHttpsBinding (HTTPS)

From a web service perspective it seems a bit strange that you would have to specifically add an endpoint to allow metadata transfer. But since WCF is a general communication framework I'm sure there is lots of places where its better not to have a service sending out metadata.

WCF service endpoint

An endpoint is defined by an address, contract and binding.

A address can be defined in the following ways (in the config file) either as implicit using the base address (which is required to be defined):

<endpoint binding="basicHttpBinding" name="basicHttp" contract="Host.ItecneckService" />

Which would make the service address: "http://localhost:8000/tecneck/"
or as a relative url:

<endpoint address="TecneckService" binding="basicHttpBinding" name="basicHttp" contract="Host.ItecneckService" />

making the url: "http://localhost:8000/tecneck/TecneckService"

or full url:

<endpoint address="http://localhost:8000/tecneck/TecneckService" binding="basicHttpBinding" name="basicHttp" contract="Host.ItecneckService" />

The base address is added like this (under the <service> tag):
<host>
<baseAddresses>
<add baseAddress="http://localhost:8000/tecneck"/>
</baseAddresses>
</host>

A Service can have several endpoints but they have to be unique, and differ in either address, contract or transport protocol. There can be several reasons why a service would have multiple endpoints for example:

• The service implements several contracts, which could each need their own endpoint


• More the one protocol should be supported


• same service must be accessible by clients with different binding requirements, possibly related to security, reliable messaging, or transactions.