ASSEMBLIES

• An assembly is the .NET term for a deployment and confi guration unit. Assemblies are
the deployment units of .NET applications, which consist of one or more assemblies..NET
executables, with the usual extension .EXE or .DLL, are known by the term assembly. .NET
assemblies include metadata that describes all the types that are defined in the
assembly, with information about its members — methods, properties, events, and fi elds.
The metadata of .NET assemblies also provides information about the fi les that belong to
the assembly,version information, and the exact information about assemblies that are
used. Assemblies are self-describing installation units, consisting of one or more fi les.
One assembly could be a single DLL or EXE that includes metadata, or it can consist of
different fi les — for example, resource files, modules, and an EXE.
• Assembly Features
• Assemblies are self-describing. Assemblies include metadata that describes the assembly.
The metadata includes the types exported from the assembly and a manifest; the next
section describes the function of a manifest.
• Version dependencies are recorded inside an assembly manifest. Storing the version of
any referenced assemblies in the manifest makes it possible to easily fi nd deployment
faults because of wrong versions available. The version of the referenced assembly that
will be used can be confi gured by the developer and the system administrator.
• Assemblies can be loaded side by side Application isolation is ensured by using
application domains. With application domains, a number of applications can run
independently inside a single process. Faults in one application running in one application
domain cannot directly affect other applications inside the same process running in
another application domain.
• Assembly Structure
ASSEMBLIES
• An assembly consists of assembly metadata describing the complete assembly, type
metadata describing the exported types and methods, MSIL code, and resources. All
these parts can be inside of one fi le or spread across several fi les. In the fi rst
example (see Figure 19-1), the assembly metadata, type metadata, MSIL code, and
resources are all in one fi le — Component.dll. The assembly consists of a single fi le.
The second example shows a single assembly spread across three fi les (see Figure 19-
2). Component.dll has assembly metadata, type metadata, and MSIL code, but no
resources. The assembly uses a picture from picture.jpeg that is not embedded inside
Component.dll but referenced from within the assembly metadata. The assembly
metadata also references a module called util.netmodule, which itself includes only
type metadata and MSIL code for a class. A module has no assembly metadata; thus,
the module itself has no version information, nor can it be installed separately. All three
fi les in this example make up a single assembly; the assembly is the installation unit. It
would also be possible to put the manifest in a different fi le.
• Assembly Manifests
ASSEMBLIES
An important part of an assembly is a manifest, which is part of the metadata. It describes the
assembly with all the information that’s needed to reference it and lists all its dependencies.
The parts of the manifest are as follows:
• ➤ Identity — Name, version, culture, and public key.
• ➤ A list of fi les — Files belonging to this assembly. A single assembly must have at least
one fi le but may
• contain a number of fi les.
• A list of referenced assemblies — All assemblies used from the assembly are
documented inside the
• manifest. This reference information includes the version number and the public key, which
is used to
• uniquely identify assemblies
• A set of permission requests — These are the permissions needed to run this assembly
• Satellite Assemblies
A satellite assembly is an assembly that contains only resources. This is extremely useful for
localization.
Because an assembly has a culture associated with it, the resource manager looks for satellite
assemblies
 assemblies
• The following table describes the assembly attributes defi ned within the
System.Reflection namespace.
• ASSEMBLY ATTRIBUTE DESCRIPTION
• AssemblyCompany Specifi es the company name.
• AssemblyConfiguration Specifies build information such as retail or debugging
information.
• AssemblyCopyright and AssemblyTrademark Holds the copyright and trademark
information.
• AssemblyDefaultAlias Can be used if the assembly name is not easily readable (such as
a GUID when the assembly name is created dynamically). With this attribute an alias
name can be specifi ed.
• AssemblyDescription Describes the assembly or the product. Looking at the properties
of the executable fi le, this value shows up as Comments.
• AssemblyProduct Specifi es the name of the product where the assembly belongs.
• AssemblyTitle Used to give the assembly a friendly name. The friendly name can
include spaces. With the fi le properties you can see this value as Description.
• AssemblyCulture Defi nes the culture of the assembly. This attribute is important for
satellite assemblies
 appdomain
• Before .NET, processes were used as isolation boundaries, with each process having its
private virtual memory, an application running in one process could not write to the
memory of another application and thereby crash the other application. The process
was used as an isolation and security boundary between applications. With the .NET
architecture, you have a new boundary for applications: application domains. With
managed IL code, the runtime can ensure that access to the memory of another
application inside a single process can’t happen. Multiple applications can run in a
single process within multiple application domains (see Figure 19-9). An assembly is
loaded into an application domain. In Figure 19-9, you can see process 4711 with two
application domains. In application domain A, objects one and two are instantiated,
object one in assembly one, and object two in assembly two. The second application
domain in process 4711 has an instance of object one. To minimize memory
consumption, the code of assemblies is loaded only once into an application domain.
Instance and static members are not shared among application domains. It’s not
possible to directly access objects within another application domain; a proxy is needed
instead.
 appdomain
• The AppDomain class is used to create and terminate application domains, load and unload assemblies and types, and
enumerate assemblies and threads in a domain. In this section, you program a small example to see application
domains in action. First, create a C# console application called AssemblyA. In the Main() method, add a Console.
WriteLine() so that you can see when this method is called. In addition, add the class Demo with a constructor with
two int values as arguments, which will be used to create instances with the AppDomain.
• using System;
• public class Demo
• {
• public Demo(int val1, int val2)
• {
• Console.WriteLine("Constructor with the values {0}, {1} in domain " +
• "{2} called", val1, val2, AppDomain.CurrentDomain.FriendlyName);
• }
• }
• class Program
• {
• static void Main()
• {
• Console.WriteLine("Main in domain {0} called",
• AppDomain.CurrentDomain.FriendlyName);
• }
• }
• Running the application produces this output:
 CUSTOM HOSTING WITH
Using WCF Data Services, you can use the CLR OBJECTS
Entity Framework (or a simple CLR object
model) on the server side and send HTTP queries from the client to the service to retrieve
and update data. Figure 44-1 shows a typical scenario with a Windows client or a Web
page using HTML and JavaScript to send an HTTP request to the server. The returned
information can be in AtomPub or JSON format. AtomPub is the Atom Publisher format
based on XML. JSON (JavaScript Object Notation) is best accessed from JavaScript clients.
WCF Data Services makes use of WCF (Windows Communication Foundation) for the
communication part and uses the WebHttpBinding. With WCF Data Services you not only
get features on the server and the capability to use HTTP Web requests with AtomPub or
JSON, there is also a client-side part of WCF Data Services. For the client, there’s a data
service context and the possibility to create queries that are transformed in the AtomPub
or JSON format. Whereas the HTTP protocol is stateless, the data service context for the
client is stateful. With this context, the client can keep track of what entities are changed,
added, or removed, and send a request with all the change information to the service
 CUSTOM HOSTING WITH
CLR OBJECTS
The heart of WCF Data Services is the DataService<T> class, which enables implementation
of a WCF service. DataService<T> implements the interface IRequestHandler, which is defi
ned as follows. The attribute WebInvoke is specifi ed to accept any URI parameters and any
HTTP methods. With the parameter and return type, the method ProcessRequestForMessage
is very fl exible. It accepts any stream and returns a message. This is a requirement for the
flexibility of data supported.
• [ServiceContract]
• public interface IRequestHandler
• {
• [OperationContract]
• [WebInvoke(UriTemplate="*", Method="*")]
• Message ProcessRequestForMessage(Stream messageBody);
• }
• CLR Objects
The sample defi nes two entity classes: Category and Menu. These classes are simple data
holders. The Menu class contains Name, Price, and a reference to the Category class. To make
the different instances uniquely identifi able by Data Services, the attribute DataServiceKey
must be added to reference the unique identifi er. This attribute is defi ned in the namespace
System.Data.Services.Common. Instead of defi ning a single property as the identity, it is also
possible to assign a list of properties for unique identifi cation. The Category class is defi ned
in the code fi le DataServicesSamples/DataServicesHost/Category.cs:
 CUSTOM HOSTING WITH
[DataServiceKey(“Id”)] CLR OBJECTS
public class Category
{
public int Id { get; set; }
public string Name { get; set; }
public Category() { }
public Category(int id, string name)
{
this.Id = id;
this.Name = name;
}
}
 BUBBLING AND
TUNNELING EVENTS
Elements can be contained in other elements. With XAML and WPF, you can defi ne that a
Button contains a ListBox; and the ListBox can contain items that are Button controls.
When you click on an inner Button control, the Click event should go all the way up to the
controls that contain the inner control. The Click event is a bubbling event. The
PreviewMouseMove event is a tunneling event that tunnels from the outside to the inside.
First the outer controls receive the event followed by the inner controls. The MouseMove
event follows the PreviewMouseMove event and is a bubbling event that bubbles from
the inside to the outside. WPF supports these bubbling and tunneling events, which are
often used in pairs.
A routed event is a type of event that can invoke handlers on multiple listeners in an
element tree rather than just the object that raised the event. It is basically a CLR event
that is supported by an instance of the Routed Event class. It is registered with the WPF
event system. RoutedEvents have three main routing strategies which are as follows −
Direct Event
Bubbling Event
Tunnel Event
Direct Event
A direct event is similar to events in Windows forms which are raised by the element in
which the event is originated.Unlike a standard CLR event, direct routed events support
class handling and they can be used in Event Setters and Event Triggers within your style
of your Custom Control.A good example of a direct event would be the MouseEnter
 BUBBLING AND
Bubbling Event
TUNNELING EVENTS
A bubbling event begins with the element where the event is originated. Then it travels up the visual tree to the topmost
element in the visual tree. So, in WPF, the topmost element is most likely a window.
Tunnel Event
Event handlers on the element tree root are invoked and then the event travels down the visual tree to all the children
nodes until it reaches the element in which the event originated.
The difference between a bubbling and a tunneling event is that a tunneling event will always start with a preview.
<Window x:Class = "WPFRoutedEvents.MainWindow"
xmlns = "http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x = "http://schemas.microsoft.com/winfx/2006/xaml"
Title = "MainWindow" Height = "450" Width = "604" ButtonBase.Click = "Window_Click" >
<Grid> <StackPanel Margin = "20" ButtonBase.Click = "StackPanel_Click">
<StackPanel Margin = "10">
<TextBlock Name = "txt1" FontSize = "18" Margin = "5" Text = "This is a TextBlock 1" />
<TextBlock Name = "txt2" FontSize = "18" Margin = "5" Text = "This is a TextBlock 2" />
<TextBlock Name = "txt3" FontSize = "18" Margin = "5" Text = "This is a TextBlock 3" />
</StackPanel> <Button Margin = "10" Content = "Click me" Click = "Button_Click" Width =
"80"/>
</StackPanel> </Grid>
</Window>
using System.Windows; BUBBLING AND
TUNNELING EVENTS
/// <summary> /// Interaction logic for MainWindow.xaml //
</summary>
public partial class MainWindow : Window
{ public MainWindow()
{ InitializeComponent();
}
private void Button_Click(object sender, RoutedEventArgs e)
{ txt1.Text = "Button is Clicked";
}
private void StackPanel_Click(object sender, RoutedEventArgs e)
{
txt2.Text = "Click event is bubbled to Stack Panel";
}
private void Window_Click(object sender, RoutedEventArgs e)
{
txt3.Text = "Click event is bubbled to Window";
}
}
 BUBBLING AND
TUNNELING EVENTS