Introduction to Dynamic Languages for ASP.NET
In the ASP.NET Futures release, the ASP.NET Dynamic Language Runtime (DLR) provides a layer for integrating dynamic languages with the common language runtime. This documentation covers:
- ASP.NET features supported by dynamic languages.
- How code is handled in dynamic-language pages.
The addition of support for a wide variety of dynamic languages gives ASP.NET users a new set of tools and new flexibility for building Web applications. The following walkthroughs in this section illustrate some of the functionality of dynamic languages in ASP.NET.
- Walkthrough: Using Dynamic Languages with ASP.NET
- Walkthrough: Using Shared Code with Dynamic Languages for ASP.NET
- Walkthrough: Debugging with Dynamic Languages for ASP.NET
- Walkthrough: Databinding with Dynamic Languages for ASP.NET
- Walkthrough: Creating a User Control with Dynamic Languages for ASP.NET
With Microsoft IronPython for ASP.NET, developers can use popular dynamic languages for the .NET Framework to create compelling Web applications. IronPython for ASP.NET are free extensions to ASP.NET that are targeted at:
- ASP.NET developers who want to enjoy the simplicity and flexibility of a dynamic language.
- Python developers looking to harness the power of ASP.NET and its rapid application development (RAD) environment.
Python’s clean object-oriented design, dynamic nature, richness of expression, ease of use, and concise syntax has won over many users in the last several years. IronPython is an implementation of the Python programming language running on the .NET Framework. It is well integrated with the rest of the .NET Framework and makes all .NET libraries easily available to Python programmers, while maintaining full compatibility with the Python language. To learn more about IronPython and to download the complete source code, please visit www.codeplex.com/ironpython.
Implementations of Ruby and Visual Basic are under development. Future releases will expose hosting interfaces and the API for integrating other languages.
In thisrelease, support for dynamic languages in ASP.NET was expanded from the earlier support for IronPython for ASP.NET. Support for dynamic languages in ASP.NET is built on the Dynamic Language Runtime (DLR), a new platform currently under development at Microsoft. The DLR simplifies hosting dynamic languages on the common language runtime.
In addition, dynamic languages work well with dynamic data controls for ASP.NET, a set of server controls that simplify the creation of data-driven Web applications. For more information, see Introduction to Dynamic Data Controls for ASP.NET and Walkthrough: Using Dynamic Data Controls with ASP.NET.
ASP.NET Features Supported by Dynamic Languages
If you already develop .NET pages, using dynamic language pages will not require a great deal of new learning. Most standard ASP.NET features are supported, including the following:
- Pages (.aspx files), user controls (.ascx files), and master pages (.master files).
- Server controls; that is, elements with the
runat="server"attribute. - Code that is included either inline or in separate code files. There are some differences from the standard ASP.NET compilation model, which are discussed later.
- Code snippets; that is,
<% ... %>,<%= ... %>, and<%# ... %>.
Application File
Dynamic languages for ASP.NET support a file similar to the Global.asax file. The file is named Global.ext, where ext is the language-specific extension. For example, the extension for IronPython files is .py, so the file name is Global.py.
Unlike the Global.asax file, which contains a directive (<%@ %> element) and a script block with a runat="server" attribute, the Global.ext file contains only code. For example, a simple global application file might contain code like the following:
IronPython
def Application_BeginRequest(app):
app.Response.Write('Hello application!') App_Script Directory
A dynamic language application contains an App_Script folder that is similar to the App_Code directory, except that it contains dynamic-language script files instead of static language code files. The purpose is the same, however; files in this directory contain classes that can be used by code anywhere in the application.
Generic HTTP Handlers
A dynamic language application can contain an HTTP handler that is the equivalent of an .ashx file in a standard ASP.NET application, although there are some differences. Dynamic language handlers are implemented as .aspx files. As with the Global.ext file, handlers in dynamic language applications contain only code. For example, a simple dynamic language handler named HelloWorldHandler.aspx might contain the following:
IronPython
<%@ Page Language="IronPython" %>
<Script runat="server">
Response.ContentType = "text/plain"
Response.Write("Hello World")
</Script> Features Not Supported
The dynamic languages for ASP.NET feature do not currently support an equivalent of Web services (.asmx files). The Web service architecture works only with standard .NET Framework types, which can be difficult to create with dynamic languages. In addition, Web service class methods must be decorated with special metadata attributes such as WebMethodAttribute, and many dynamic languages have no syntax for applying attributes.
In this release, there is very limited design time support, no intellisense support, and no support for writing ASP.NET MVC controllers using a dynamic language. These are all limitations we plan to address in future releases.
In the .NET Framework version 2.0, dynamic languages require full trust to emit Microsoft intermediate language (MSIL) for compilation at run time.
How Code Is Handled in Dynamic Language Pages
One difference between managed code and dynamic languages is the compilation model. Dynamic languages do not use CodeDOM, the core of the code-generation model for standard ASP.NET pages. The standard code-handling model requires inheriting from a base class and overriding members with specific type signatures. This can be problematic for dynamic languages.
In contrast to the standard compilation model, in which all user code in a page becomes part of a generated source file, each piece of dynamic language code in a page is treated as an individual entity. The implications of this are best seen by considering the various types of user code.
Code in <script> Elements
In standard ASP.NET pages, all user code in <script> elements that have the runat="server" attribute becomes part of the generated class. In contrast, in dynamic language pages, no new class is generated. Instead, ASP.NET directly instantiates the class specified by the inherits attribute. In this respect, the term "inherits" is inaccurate for dynamic language pages, because no inheritance occurs.
Instead of becoming part of a class, the code in a <script> element becomes a kind of companion code for the ScriptPage class. For example, the Page_Load method shown in the following example is not part of any class.
IronPython
<script runat="server">
def Page_Load(sender, args):
Response.Write("<p>Page_Load!</p>")
</script> Instead, members of the ScriptPage class, such as Response in this example, are injected by ASP.NET so that they are directly available to your code. The effect is that the members appear to be part of the class.
In dynamic language terminology, the code in the script block lives in a module. Usually there is one module associated with each HTTP request.
Code-behind Files
Everything that applies to code in <script> elements applies also to code in separate files. In the standard model, the code file contains a partial class declaration, which the compiler merges with the generated class. With dynamic languages, however, there is no class declaration in the code file. Instead, methods appear directly in the file, outside of any containing construct. Therefore, as with normal ASP.NET pages, the question of where to put your dynamic language code is purely a matter of personal preference
Code Snippets
Snippet expressions and statements (that is, <%= ... %> and <% ... %>) also execute in the context of the module created for the code belonging to the page. As a result, these snippets have access to methods and variables defined inline, in <script> elements, or in separate code files. For example, if you define a Multiply method in a <script> block, you can write <%= Multiply(6,7) %> in your page.
Code snippets also have access to the members of the Page class. For example, you can write <%= Title %> to display the title of the page.
Data-Binding Expressions
Data-binding expressions are a type of code snippet, but they are worth discussing separately because they work more naturally with dynamic languages.
In standard ASP.NET code, you might have a GridView control with a templated column containing the data-binding expression <%# Eval("City") %>. The Eval method is used to get the value the column named City for the current row in the data source.
With dynamic languages, the snippet is simply <%# City %>. City is a code expression in the dynamic language instead of a literal string that must be interpreted by using the Eval method. This means you can write expressions containing arbitrary code. For example, with IronPython you can write <%# City.lower() %> to display the value of the column in lower case.
This straightforward and powerful syntax is possible because dynamic languages support late-bound evaluation. The meaning of City is not known at parse time, but the dynamic language engine is able to bind it to the correct object at run time.
Dynamic Injector Mechanism
The compilation model for dynamic languages enables you to use simple syntax into which additional code is injected at run time. For example, you might have code that reads a value from the query string. The URL for the page might look like this:
http://someserver/somepage.aspx?MyValue=17
In a C# page, you can use the following code to obtain the value:
String myValue = Request.QueryString["MyValue"];
The dynamic injector mechanism allows you to write much simpler code in dynamic languages, as shown in the following examples:
IronPython
myVar = Request.MyValue
The support code for dynamic languages enables the registration of an object referred to as an injector. By registering as an injector, the object agrees to handle code that matches a certain pattern. For example, if the dynamic language engine is unable to resolve the expression SomeObj.SomeName, where SomeObj is an HttpRequest object and SomeName is not a real property of the HttpRequest object, the engine calls the injector that has been registered to handle that pattern. The injector handles the expression by calling SomeObj.QueryString["SomeString"]. The net effect is exactly the same, but the syntax is much cleaner.
The injector mechanism has many potential uses. For example, wherever you would write SomeControl.FindControl("SomeChildControl") in C#, you can write SomeControl.SomeChildControl in a dynamic language application. The mechanism is extensible and can be applied to any collection that is indexed by strings.
Compilation of Dynamic Code
Dynamic language engines parse code at run time, compile it on the fly, and execute the compiled code. They are not interpreters. Compiled code is reused wherever possible, for better performance.
Posted in: .NET Framework| Tags: HTTP Dynamic Language Support Introduction Dynamic Data IronPython Overview Generic HTTP Handler App_Script Dynamic CodeModeling that Works with Code in VSTS 2010
For most businesses only 20% of the code being written today for new applications; the majority of work is being done on existing code bases.
When working on existing code, architects and developers don’t necessarily good enough tools to understand the system, know what needs to be done to make required updates, or be able to anticipate the impact of changes made. Often it isn’t until much later that an unexpected bug is discovered as a result of a change.
Our modeling tools have tight integration into the actual code of the application. This means that a developer or architect can use models to explore existing code assets. The new Architecture Explorer in Visual Studio Team System gives developers and architects the capability of creating a full architectural picture of existing code; understanding how they fit together; understanding how they “work.” This leads to better information about using, re-using, or discarding existing code. The Architecture Explorer provides architects and developers a mechanism for visualizing code assets in a number of ways including graphs, stacked diagrams and dependency matrices.
The introduction of the Architecture Layer Diagram means that a developer or architect can use models to enforce constraints on code as well. The Architecture Layer Diagram can be coupled to code making it an active diagram that can be used for validation. For example, when an architect designs a system where the presentation layer should not talk to the data layer, you want to be able to enforce that model at check-in. Visual Studio Team System 2010 can do that. These capabilities delivered in VSTS 2010 are part of the Microsoft’s overall modeling story.
Product Overview of VSTS 2010
The marketplace has begun to mature and accept Application Lifecycle Management (ALM) as a proven discipline for creating high-quality applications. However, existing solutions in the marketplace have not kept pace with the changing needs of technical users and the expanding inclusion of non-technical users as part of the lifecycle.
Every customer today faces a similar set of business problems:
• How do we build high quality applications that deliver
real business value?
• How do we embrace the Application Lifecycle Management model effectively?
• How can we ensure that all members of the team – both
technical and non-technical – are part of the process?
• How can we get the most value from our existing code assets?
• How do we make powerful modeling tools available to
everyone in the application lifecycle?
The third generation of Visual Studio Team System – Visual Studio Team System 2010 – will be a robust and streamlined solution that addresses these needs and concerns.
We are evolving Application Lifecycle Management by:
Building quality into the lifecycle
• Ensuring architectural consistency through the lifecycle
• Eliminating “No-Repro” bugs
• Ensuring smooth build handoffs and high quality builds
• Incorporating performance in the lifecycle
Driving efficiency into the test effort
• QA Team aligned with Business Analysts,
Architects, and Developers
• Eliminating tedious tasks
• Improving setup and deployment of tests
• Choosing the right tests
Ensuring Complete Testing
• Focused test planning and progress tracking
• Transparently see the quality of requirements and level of testing
• Finding the gaps in testing and fill them
• Ensuring changes are properly tested
Overview of LINQ in .NET 3.0
When developers write enterprise applications using an object-based language (for example C#, Java, or Visual Basic), they typically switch from writing code in that language to writing string-based SQL or XQuery commands to access data. This requires developers to master multiple languages and understand the semantic differences. In this lab you will learn how to use LINQ to SQL to manage (and query) relational data as native language objects.
LINQ to SQL, a component of the LINQ Project, provides a run-time infrastructure for managing relational data as objects. It does this by translating language-integrated queries into SQL for execution by the database and then translating the tabular results back into objects you define. Your application is then free to manipulate the objects while LINQ to SQL stays in the background tracking your changes automatically.
Objectives
In this lab you will learn how to:
- Use LINQ to SQL to implement a resource access layer that interacts with an existing Microsoft SQL Server database
- Use the LINQ to SQL Designer to create LINQ to SQL entity classes and associations (relationships) based on tables in a database
- Manage the DataContext and how to use where clauses, perform joins, order the results, and handle conflict detection