The Dynamic Language Runtime

The Dynamic Language Runtime (DLR) from Microsoft is an ongoing effort to bring a set of services that run on top of the Common Language Runtime (CLR) and provides language services for several different dynamic languages

Silverlight DLR is implemented on top of the CLR to allow both compilation and execution of dynamic code in runtime.
Without DLR, only the already-compiled code can execute. The good thing about DLR is that it can compile and execute code in Dynamic VB.NET, IronPython, IronRuby and Managed JScript—C# is not supported by the DLR yet—at a blazingly fast performance, as the dynamic code is first JIT-compiled before being executed. With DLR, we can now write dynamic code that can fully interact with Silverlight elements at runtime.
Supports the dynamic compilation and execution of scripting languages such as JavaScript and IronPython to program Silverlight-based applications. Includes a pluggable model for adding support for other languages for use with Silverlight.

• The Silverlight Dynamic Languages SDK provides a bridge between Silverlight and the Dynamic Language Runtime (DLR). The SDK allows developers to use dynamic languages, running on the DLR, to build Silverlight applications. With this interoperation, dynamic languages can leverage the feature-rich Silverlight Framework Class Library (FCL), and dynamic languages can call into other dynamic languages, e.g., IronPython calling Managed JScript.
  The SDK also includes services to build new languages on top of the DLR, including a shared, dynamic type system and a language hosting model. It also facilitates hosting dynamic languages inside of different hosts. Silverlight can be viewed as "simply an application host used to host the DLR," using the same services that can be utilized by an application developer.
  To get started writing Silverlight applications in IronRuby, IronPython or Managed JScript, download the Silverlight Dynamic Languages SDK, which includes:
• IronPython, IronRuby, and Managed JScript language libraries
• Chiron, a dynamic language development utility
  source code for IronPython, IronRuby, the Dynamic Language Runtime (DLR), and Chiron sample applications for both Ruby and Python
• batch file used to run sample on Windows
• shell script to run applications on Mac
• Microsoft® Public License (Ms-PL)

WCF

WCF Tutorial
Objectives:
• Review the role of interface-based programming
• Review the role of XML web services
• Define Service-Oriented Architectures (SOAs)
• Review the core distributed APIs of the Microsoft Windows OS
• Understand the motivation behind Windows Communication Foundation (WCF)
• Take a first look at building and testing WCF services
• Learn to create self-hosting WCF services
• Declaratively define hosting logic within *.config files
• Define hosting logic programmatically
• Understand the role of Metadata Exchange (MEX)
• Generate and make use of client proxies
• Learn to host WCF services in a Windows service
• Learn to host WCF services in IIS virtual directories
• Define and invoke ‘one-way’ method operations
• Learn to invoke WCF service methods asynchronously
Overview
Building a distributed system is a very common task for many programmers. However, doing so involves confronting numerous design challenges. In this chapter, you will review two key aspects of many distributed systems (interfaces and XML web services), followed by an overview of Service-Oriented Architectures (SOAs). Also, you will survey several core distributed APIs found within the Windows OS.With this historical background in place, the remainder of this chapter will introduce you to the Windows Communication Foundation (WCF) API. Here you will learn about the problems WCF attempts to solve, study the ABC’s (addresses, bindings, and contracts) of building a WCF application, and explore some common WCF development tools.The information presented here will function as the backbone for the remainder of the class.A Working Definition of Windows Communication Foundation (WCF)
• To begin your examination of WCF, you will start with a review of common distributed programming practices and previously distributed APIs.
• This is important, given that WCF leverages many of the distributed concepts / APIs you may have used in the past.
• WCF is a .NET 3.0 (and higher) API that allows you to build distributed systems.
• WCF is unique in that you can select from many types of bindings. This fact alone makes WCF a very flexible framework.
• A single WCF service could be exposed via an HTTP binding for outwardly facing callers or via a TCP binding for in-house callers.
• The underlying plumbing details can be relegated to *.config files, which make it very simple to change bindings and other details on the fly.
• WCF makes extensive use of interface-based programming techniques.
• When you define a WCF service, you typically begin by defining the interfaces that model the functionality callers can expect to find.
• These .NET interfaces could be used by the runtime to generate WSDL definitions based on your choice of bindings.
• In addition, WCF makes heavy use of .NET attributes to qualify how the runtime should handle client / service interactions.
• Similar to the .NET remoting layer / XML web services, WCF attributes are used to control data formatting, binding operations, and more.
• Recall that attributes are essentially code annotations.
• Attributes are useless unless another piece of software reflects over them. In this case, the ‘other piece of software’ could be the WCF runtime as well as WCF development tools.
• WCF is heavily influenced by XML web services and Service-Oriented Architectures (SOAs) in general.
• Like an XML web service, WCF services make use of contracts and explicit boundaries and support the use of various WS-* specifications.
• However, a WCF service does not have to use web-service-centric bindings.
• If you wish, you can opt for P2P bindings, named pipes, TCP bindings, and so on.
• The underlying binding is decoupled from the service itself.
• Therefore, changing bindings on the fly is very straightforward
.• In a nutshell, as of .NET 3.0 (and higher), WCF is the preferred way to build new distributed systems.
• The original distributed .NET APIs (System.Runtime.Remoting, System.Web.Services, and so forth) are still supported.
• Furthermore, Visual Studio still has templates for ‘traditional’ ASP.NET web service project workspaces.
• It is also possible to migrate existing XML web services / remoting applications into the WCF programming model.
• Doing so, however, may offer little benefit. In fact, it could entail a good amount of work.• This course does not cover migrating existing distributed systems into the WCF programming model.
• The class assumes you intend to build new WCF services, hosts, and clients.
• However, Appendix A illustrates how to interact with legacy COM+ components.
• You can read Appendix A if time / interest permits.
• The .NET Framework SDK documentation provides details of migrating existing systems.• If you are interested in migrating from .NET remoting to WCF, look up the article ‘From .NET Remoting to the Windows Communication Foundation (WCF)’.
• If you are interested in migrating from ASP.NET web services to WCF, look up the article ‘Migrating ASP.NET Web Services to WCF’.
• Finally, be aware that this class will focus on the core aspects of the programming model, which will be commonplace to all of your WCF projects.
• Consult the .NET Framework SDK documentation for WCF topics not addressed in this course.
• The WCF section of the SDK documentation provides a number of excellent code examples, white papers, and tutorials.• Simply look up the Windows Communication Foundation selection of the help system and dive in.

CHIRON

What is Chiron?
The Chiron system provides tools for assisting in the development of graphical user interfaces and provides a run-time system for managing and supporting their dynamic behavior.
The objective of the Chiron system is to reduce long-term costs associated with developing and maintaining graphical user interface (GUI) software. It achieves this objective by providing key interface layers which are resilient to change. In particular, Chiron strongly separates an application from its user interface code, as well as separating the user interface code from the underlying toolkit substrates. Chiron supports the construction of GUIs which provide multiple coordinated views of application objects and allows flexible restructuring of the configuration of those views. Chiron supports a concurrent model of control. While the Chiron architecture supports heterogeneous, multi-lingual systems, the development tools which are part of this release only support clients (applications) written in Ada.
Chiron is a serverized system. The Chiron server and clients run in separate Unix processes. Within a client, artists are active interface agents that are bound to one or more objects. They encapsulate decisions about how objects should be depicted (presentations) as well as how they behave dynamically (dialogs). Multiple artists can be bound to a single object, providing coordinated multiple views of that object. A Chiron client is made up of application code, a set of artists, and client support code. The client support code implements initialization, event detection and routing, and communication with the server. Client support code is automatically generated by client building tools.
Chiron leverages from commercial GUI layout tools. Specifically, Chiron can be used with Sun Microsystem's DevGuide tool to create artists. For those aspects of GUIs which DevGuide is incapable of supporting (e.g. drawing on a canvas), DevGuide and Chiron tools can be used to create an artist template into which the additional graphical aspects can be added programmatically.
The Chiron server manages all aspects of the user interface that are not artist or application specific. It can be thought of as a virtual machine providing a high-level graphical "toolkit" interface to artists by means of an Abstract Depiction Language (ADL). The server receives ADL instructions from the artists and uses them to create and manipulate an internal abstract representation of the graphical interface. The representation is rendered to a concrete depiction (a user viewable image) via calls to the underlying window system. The server also listens for events from the window system (button push, menu selection, etc) and translates them to Chiron events before shipping them back to the appropriate client. The Chiron server provides flexibility in terms of windowing systems and toolkits, application languages, and process inter-connection topology. Although we currently only provide support for Ada clients, it is feasible to provide other language-specific interfaces to the server's ADL.
The Chiron model is highly concurrent. Most components maintain their own, and possibly multiple, threads of control. Thus, unlike most user interface architectures, Chiron avoids imposing sequential control upon tools, allowing the tool, the user interface, and the server, to run in parallel

USER CONTROL VS CUSTOM CONTROL

1) Custom controls are written in separate program files that are compiled explicitly and are persisted as an assembly (.dll).User controls are authored using the ASP.NET page syntax, either in the script block or in CodeBehind pages and are implicitly just-in-time compiled by the ASP.NET runtime system.
2) Custom Controls are nicely suited for general re-use as they are easy to package and redistribute as third-party controls. User Controls are best suited for reuse within a web application. Because they are persisted as source files, less chances exist that third parties would like to distribute them.
3) Once created, a custom control can be added to the toolbox of a visual designer, such as Visual Studio .NET, and dragged and dropped onto a page— just like any built-in server control. The visual designer can also support visual manipulation of custom control’s various properties.User controls provide minimal support for use with a visual designer toolbox.
4) A custom control provides minimal support for design-time authoring in a visual designer.A user control provides design-time support for authoring in a visual designer—just like an ASP.NET page.
5) A custom controls inherits System.Web.UI.Control or System.Web.UI.WebControls.WebControl class with class hierarchy (bottom up) either MyCustomControl.Control.Object OR MyCustomControl. WebControl.Control. Object.A user control inherits System.Web.UI.UserControl class with class hierarchy (bottom up) MyUserControl. UserControl. TemplateControl. Control. Object.
6) A custom control is in the form of dynamic linked library (.dll), thus pre-compiled.A user control has extension .ascx and is JIT compiled
7) A custom control does not have any design editor. It may or may not inherit functionality of other standard control(s). It can be an entirely new one.A user control must encapsulate functionality of other web server control(s) through dragging and dropping in design mode.
8 ) A custom control does not have design editor so is harder to create.A user control is easy to create because it can be designed like a page is designed i.e. they have design editor and code behind simultaneously
9) A custom control (newly created or extended) is a separate and pre-compiled component.A user control requires registration and instantiation per page and resides on a page as an object and is compiled along with the page. It is not in pre-compiled form
10) A custom control is more reusable because you do not need a separate copy of it for each application; it can automatically be loaded be from the GAC. Thus giving an advantage of being a framework wide component.A user control cannot be registered with Global Assembly Cache (GAC) .
11) A custom control’s class is not bound with any design. Here you can take the leverage of the flexibility and richness of .NET programming model; you can expose properties, override functions of the base class and also register complex client side logic in the class. A user control cannot provide the level of richness that a custom control can provide.
12) A custom control is the best choice especially when you want to make your controls redistributable, more reusable and make it a Visual Studio IDE aware component.A user control may fulfill your need if you are working on a single web application
13) A custom control cannot use the user control. A user control can use a custom control.
14) The custom control model is designed for authoring redistributable components in the form of an assembly (compiled class library) that can be used by a number of applications. The assembly containing the controls can be used by a single application at a time when placed in the application’s private bin directory, or it can be shared across multiple applications when placed into the global assembly cache, commonly referred to as the GAC. The assembly can be deployed and used in its compiled binary form without the associated source code.The user control model is designed for single-application scenarios. A user control is dynamically compiled at run time when a page that uses it is first requested. As a result, a user control must be deployed in source form, and the .ascx file (and its associated code-behind, if any exists) must be copied into every application that requires the user control.
15) Custom controls are authored by writing a managed class that derives directly or indirectly from System.Web.UI.Control in a .NET programming language.User controls are authored declaratively in the form of .ascx files, which is very similar to the way ASP.NET pages are designed and developed.

CUSTOM CONTROL

· Exist in precompiled assemblies.
· Code entirely contained in .cs (or .vb)
· No visual designer. Any HTML code needs to be declared programmatically.
· Can be used in .aspx pages, user controls or other custom server controls.
· Can be added to the ToolBox (drag and drop)
· Can be shared between web applications.

• Reusability of control (or extend functionalities of existing control)
• We can add toolbox
• Just drag and drop from toolbox
• U can register user control to. Aspx page by Register tag
• A single copy of the control is required in each application
• Good for dynamics layout
• Hard to create
• Compiled in to dll
• You can create a Custom control when it is going to be used across different applications.
• Custom controls don't a visual interface.
• Custom controls however can be added to your tool box and used in different applications without re-compiling.
• It's a .dll

USER CONTROL

· Have an ascx extension.
· Are compiled at runtime when the page is loaded.
· Visual design is possible, just like an aspx page and uses the ASP.Net page model with code behind file.
· Can only be used on a host aspx page or another user control.
· Cannot be added to the ToolBox.
· Can only be used in the current web application (source must be copied to another application to use).

• We can’t add to toolbox
• Just drag and drop from solution explorer to page (aspx)
• U can register user control to. Aspx page by Register tag
• A separate copy of the control is required in each application
• Good for static
• Easier to create8)
• Not complied into DLL
• Here page (user page) can be converted as control then We can use as control in aspx
• Reusability web page

Animation in silverlight

Animation in silverlight
The Importance of an Impressive User Interface
Microsoft and other companies have invested millions of dollars in software research and development. The primary factors that affect and influence end users are performance and the user interface. The compilation of factors that influence the end user are referred to as the "user experience" (UX). Software developers are on a continual quest to improve application performance, however new rules and guidelines have recently been introduced that define higher standards for the creation of user interfaces. The new guidelines were primarily released by Microsoft and coincide with the release of Windows Vista, WPF, and, in turn, Silverlight.
Basically, the more impressed a user is with the overall user experience that an application provides, the more impressed they will be with the application and the more likely they will be to refer the application to others. This module, obviously, focuses on how to create user interfaces by using Silverlight.
Drawing Graphics
Silverlight is a subset of WPF as applied by using principles of an extended ASP.NET AJAX. As such, Silverlight implements many of the features included in WPF. For instance, Silverlight provides the ability to draw two-dimensional (2D) graphics in applications. Graphics of this caliber are more than adequate for most user interfaces and applications, particularly business applications. However, there are applications which require more elaborate graphic capabilities, three-dimensional graphics (3D). For example, an engineering application may benefit tremendously from 3D graphics in the user interface. Whilst WPF provides 3D graphics, Silverlight, currently, does not.
In order to provide 3D graphics, an application must utilize the hardware of the local workstation and the facilities of the local operating system. Silverlight is designed to be cross-platform and cross-browser compliant. With that in mind, it cannot be tied to any particular hardware configuration, operating system, or browser. This design coincides very well with the design goals of Silverlight but does not lend itself to rendering 3D graphics.
Silverlight, currently, does not support 3D graphics but may do so in a future version.
Graphic Elements
Drawing in Silverlight is accomplished through the use of graphic elements such as an ellipse or a rectangle. All graphic elements in Silverlight extend the Shape type. As a result, all Shape type objects in Silverlight include some common functionality as listed below:
Stroke: the stroke defines the outline of the shape
StrokeThickness: the stroke thickness defines the thickness of the outline of the shape
Fill: the fill defines how the interior of the shape is filled or painted
Lines
To draw lines in Silverlight, use the Line object. A line can easily be drawn on a canvas by using Blend and can be created directly in XAML by using Visual Studio 2008. A line is defined through the definition of two points. Each point is comprised of a combination of an X coordinate and a Y coordinate.
The markup snippet shown below is used to render a red, diagonal line from 10, 10 to 100, 100.
The canvas that results from the markup snippet above is shown in the following figure.
Ellipses
An Ellipse object is used to draw round objects in Silverlight. The circular characteristics of an ellipse are defined by specifying the height and width of the ellipse. The markup snippet shown below renders an oval ellipse with a blue gradient fill and a stroke of 3.
Sometimes, when using a graphical design tool, such as Blend, it may be tough to create an exact circle. To create a circle with a Silverlight ellipse, ensure that the height and width values are the same. To create a circle in Blend, when sizing the ellipse, hold down the Shift key. The markup snippet below renders a circle with a diameter of 100px, a stroke of 3, a green fill, and a yellow stroke.
The result of the two ellipse definitions above is shown in the figure below.
Rectangles
The Rectangle class is used to draw rectangles in Silverlight. The markup snippet below illustrates drawing two rectangles, a larger, blue rectangle in the background and a smaller, orange rectangle on top.
Just as with an ellipse, when sizing a rectangle by using Blend, if you want to draw a square or maintain the current aspect ratio of the rectangle, hold down the shift key. The result of the markup above is shown in the figure below.
Paths and Geometries
The Path object also derives from the Shape object, however, the Path object has no defined shape. Instead, a Path accepts an indirect or abstract definition of a shape to define how the Path is rendered. The Geometry class is used to define how a Shape is rendered. There is only one Path class but many types of Geometry classes. The Geometry class itself is an abstract class that cannot be directly instantiated but one of its child classes must be instantiated.
The Path class can be used to define simple shapes such as lines, ellipses, and rectangles in the same manner as the Line, Ellipse, and Rectangle classes, however the PathGeometry class is used to create more complex shapes. Creating paths can be rather tricky by hand coding the path coordinates directly in XAML. When using a design tool, such as Blend, paths are created as a combination of simpler elements or freehand by using a pen / pencil tool. The markup snippet below shows several path elements that were rendered in Blend when a sketchy little stick man was quickly drawn with the pencil tool.
The result of the markup shown above is shown in the following figure.
There are several types of geometries that can be utilized with a path including a LineGeometry, a RectangleGeometry, an EllipseGeometry, and a PathGeometry. The PathGeometry can compile complex shapes from multiple path segments. Path segments include arcs, béziers, lines, and variations of each.
The PathGeometry is used above in shorthand form. The Path object includes a Data attribute that accepts multiple coordinates to define points along the path. Upon closer look, you will notice that the Data attribute value also contains characters such as "M" or "C". The Data attribute value is actually a mini markup language and the characters are very meaningful as well as case-sensitive. For instance, an uppercase "M" signifies a move command and the coordinates that follow indicate the movement of the path.
Brushes
Brushes are used to paint spaces contained by a stroke, or border or the stroke itself. For instance, a brush can be used to paint the interior space of a rectangle. In fact, in the rectangles example above, a gradient brush is used to paint the interior of the rectangle as shown in the markup snippet below.
Brushes can be used to paint solid colors, gradients, images, and even video. The ability to paint with images is fairly common among graphic design tools, however the ability to paint with video is only available in a very few elite graphic tools. Expression Blend currently supports image and video brushes but only for WPF and not for Silverlight applications.
However, it's fairly easy to create an image brush fill as shown in the markup snippet below.
The result of the markup snippet above is shown in the following figure.
To paint by using video, a little more work is required. First, a VideoBrush does not directly play video but utilizes video from another source such as a MediaElement object. The MediaElement object is discussed again in the section below. In the example below, video is being played as the fore ground of text. The TextBlock.ForeGround utilizes a VideoBrush that, in turn, utilizes video from a MediaElement object.
The result of the markup above is shown in the figure below with video playing as text.
Transformations
Transformation objects are used to transform other Shape objects. There are various types of transformations including rotations, scales, skews, and translations. A scale is a resize. A skew transformation skews the shape of the Shape. A translate moves a shape.
The markup snippet below illustrates applying a 45 degree rotation to a TextBlock.