dmitryr's blog

Last year I've published a simple ASP.NET control, called ‘Dynamic Client Script', that enables IronPython client scripting in ASP.NET pages in Silverlight 1.1 Alpha.  Since then Silverlight evolved quite a bit and Silverlight 2 Beta 1 has been released.  According to the new model, Silverlight applications are published as XAP archives containing the application code, so I've updated the Dynamic Client Script sample to work with the new model.

The user model for Dynamic Client Script stays the same -- all user needs to is to drop the control onto an ASP.NET page:
<asp:DynamicClientScript runat="server" ID="MyScript" Source="myscript.py" />
The control does all the magic, including generation of Silverlight object tag with the link to the Silverlight application (XAP archive) pointing back to the page as a request with a special path-info.  That request gets intercepted by the control, and it creates the XAP archive on the fly, and caches it across requests with the right cache dependencies so it only gets re-created when the page or the script changes.

The XAP creation code comes from Chiron, a development web server that we ship with Dynamic Languages SDK for Silverlight.  Chiron automatically creates XAP archives from any directory, to facilitate development of Silverlight application in dynamic languages.  Dynamic Client Script control does not require Chiron, it works with any ASP.NET web server, including IIS (and Cassini as well).

The updated sample:

• Allows script inline in the ASP.NET page or in a separate file
• Supports IronPython, IronRuby, Managed JScript
• Supports multiple instances of Dynamic Client Script control on the same ASP.NET page
• Includes all DLR assemblies and compliers
• Includes sample pages

The attached package includes all the sources, binaries, and samples.

Thanks to Piyush, the second version of ASP.NET RSS Toolkit is now available on CodePlex.  Please check it out.

Thanks,

Dmitry

Attached is an updated Photo Album sample. The idea is to maximize the simplicity of use - just drop default.aspx page into the [root] directory where the pictures are and it does everything for you -- list view per folder, details view for each picture, thumbnails generation and caching, etc.

It is similar to the one I've published before, but this one is implemented as a page (.aspx, not .ashx) and it handles both page views and image requests.  It is as easily customizable as any ASP.NET page -- it relies on MultiView control to switch between list and detail views.  The package includes sources in C#, IronPython, and Managed JScript -- for the latter two please install ASP.NET Futures package.

Thanks,

Dmitry

Please check out ASP.NET Futures release with Dynamic Langauges support and Dynamic Data Controls.  The former is the updated version of IronPython for ASP.NET, now based on DLR.

Thanks,

Dmitry

Attached to this post is the Dynamic Client Script sample -- an ASP.NET control that simplifies creation of AJAX-like Web pages in managed scripting languages using Microsoft Silverlight cross-browser / cross-platform technologies.

The recent release of Microsoft Silverlight enables a set of scenarios that some people might find interesting. Silverlight 1.1 Alpha release includes features that enable AJAX-like scenarios using managed dynamic languages on the client:

• APIs to access HTML DOM from managed code
• APIs to make HTTP requests to Web services from managed code
• Dynamic Language Runtime (DLR) with the implementation of IronPython and Managed JScript (with more dynamic languages, including IronRuby, coming in the future).  (Please also see Dynamic Silverlight Samples on CodePlex)

As a result, it is possible to author an HTML page with IronPython client script using the following steps:

1. Start with an HTML page
2. Write the IronPython client script file
3. Author a [bootstrapping] XAML file with a reference to the IronPython client script file (and add the XAML file to the project)
4. Add a link in the HTML page to the Silverlight bootstrapping jscript files (and add the files to the project)
5. Add jscript code to the HTML page to instantiate the Silverlight control
   

Dynamic Client Script control dramatically simplifies this:

1. Start with an ASP.NET page
2. Write the IronPython client script file
3. Place Dynamic Client Script control onto the ASP.NET page and set 'Source' property to point to the IronPython file
   

Notes:

• Dynamic Client Script control automatically renders the links to the bootstrapping jscript and to XAML (the actual links point back to the containing page and the control intercepts these requests and serves the corresponding content)
• No additional files need to be added to the project 
• Several Dynamic Client Script controls can co-exist in the same ASP.NET page 
• Dynamic Client Script control (in addition to 'Source' reference) supports inline script (it uses the same link-back trick to generate the link from XAML to script)

The attached package (DynamicClientScript.zip) contains sources (licensed under Ms-PL) and samples (as a run-able Web app).

Please check this out, if you are interested.

Some time ago I wrote a simple ASP.NET in-process executor for internal testing and I am happy to see it go public on CodePlex (under name "Plasma") including NUnit integration, thanks to Steve Smith from AspAlliance.  Please check it out.

Thanks,

Dmitry

Thanks to Scott Cate the Disk Output Cache project is now on CodePlex.

Please check it out and consider contributing.

Thanks,

Dmitry

Here is a sample code that returns the current trust level, assuming this code (or the calling code up the stack), is not loaded from GAC:

AspNetHostingPermissionLevel GetCurrentTrustLevel() {
    foreach (AspNetHostingPermissionLevel trustLevel in
            new AspNetHostingPermissionLevel [] {
                AspNetHostingPermissionLevel.Unrestricted,
                AspNetHostingPermissionLevel.High,
                AspNetHostingPermissionLevel.Medium,
                AspNetHostingPermissionLevel.Low,
                AspNetHostingPermissionLevel.Minimal 
            } ) {
        try {
            new AspNetHostingPermission(trustLevel).Demand();
        }
        catch (System.Security.SecurityException ) {
            continue;
        }
 
        return trustLevel;
     }

     return AspNetHostingPermissionLevel.None;
}

The result can be cached in a static field for the duration of the app domain lifetime.

When working on Web Services support for Dynamic Languages I needed a simple pluralizer for English nouns, and I did put one together that I would like to share.

The algorithm is very simple:
1) There is a list of special nouns that is looked up first.
2) There is a list of suffix substitutions that is a applied next.
3) Everything else gets 's' appended.

Please download the attached ZIP file, compile the .cs file (it requires .NET Framework v2.0) and run it:

C:\temp>csc Pluralizer.cs
Microsoft (R) Visual C# 2005 Compiler version 8.00.50727.42
for Microsoft (R) Windows (R) 2005 Framework version 2.0.50727
Copyright (C) Microsoft Corporation 2001-2005. All rights reserved.

C:\temp>Pluralizer.exe
> class
classes
> type
types
> werewolf
werewolves
> leaf
leaves
> index
indices
>

Please give it a try and let me know for what words (or classes of words) it fails

My latest work has to do with Dynamic Languages on .NET (please see my updated bio).

We've already posted several projects on the web:

• IronPython, implementation of the Python programming language running on .NET
• Samples for IronPython, including the latest one I put together, Dynamic Web Service Helpers, that shows how easy it is to consume Web Services from Dynamic Languages. Please check it out -- IronPython-1.0.1-Samples-WebServices.zip.
• IronPython for ASP.NET, integration of IronPython with ASP.NET, including the runtime (based on no-compile pages) and the design time support in Visual Studio and Visual Web Developer.

ASP.NET RSS Toolkit now on CodePlex -- please consider contributing...

Thanks to IDisposable for making this happen.

Dmitry

I’d like to setup an open source project on http://www.codeplex.com/ for the ASP.NET RSS Toolkit and I need help coordinating check-ins. I will create the project (with the updated sources that include bug fixes and some new requested features), but I just don’t have cycles to monitor the activity and approve check-ins on a daily basis.

If you are interested becoming the coordinator, please let me know.

Thanks,

Dmitry

I am posting a minor update to the ASP.NET RSS Toolkit (version 1.0.0.1).  It contains changes made in response to the feedback I received -- I'd like to thank everyone for their comments and suggestions!

Here is the list of changes:

• Added MaxItems property to RssDataSource to limit the number of items returned.
• Added automatic generation of <link> tags from RssHyperLink control, to light up the RSS toolbar icon in IE7. For more information please see http://blogs.msdn.com/rssteam/articles/PublishersGuide.aspx
• Added protected Context property (of type HttpContext) to RssHttpHandlerBase class, to allow access to the HTTP request while generating a feed.
• Added generation of LoadChannel(string url) method in RssCodeGenerator so that one strongly typed channel class can be used to consume different channels.
• Fixed problem expanding app relative (~/…) links containing query string when generating RSS feeds.

You can download the toolkit as the attachment to this post.  Of course, all sources are included.

I've posted an update to Cassini v2 sources that fixes a leak of Connection objects pointed out to me by Vlad Hrybok. You can get the update as the attachment to this post.

If you are running stress against Cassini please also be aware that you might run into a problem periodically not being able to connect. The reason for the problem and workarounds are described in this post.

The attached sample illustrates how to execute true server-side child requests that go though the entire HTTP pipeline in ASP.NET v2.0.  The full source code is included.

Out of the box ASP.NET supports two similar features:

• Server.Execute. This method executes (calls ProcessRequest method on) the HTTP handler corresponding to the given path.  None of the pipeline events (for HTTP Modules or GLOBAL.ASAX) are fired and thus, for example, authentication rules are by-passed.
• Response.Redirect. This method does re-enter the pipeline for the 'child request', but at a cost of the roundtrip to the client that issued the original request.

Child Request feature sample allows spawning of server-side requests that go through the entire HTTP pipeline and capturing of the responses.  Several child requests could be used in the context of one parent request. In fact, no parent request is needed at all (which is yet another advantage over Server.Execute and Response.Redirect).

Child Request API

The API is quite simple to use:

1. Create an instance of ChildRequest class
2. Call ChildRequestExecutor.ExecuteChildRequest to execute the child request synchronously (BeginExecuteChildRequest and EndExecuteChildRequest for asynchronous child request execution)
3. Obtain the response from ChildRequest properties (Status, Headers, Content).

In addition, the instance of the ChildRequest being executed can be retrieved from a module or a handler using ChildRequestExecutor.GetChildRequestFromContext. This can be useful in order to retrieve UserData property of ChildRequest set by the caller.

HTTP Pipeline in ASP.NET 2.0

Related to this feature, here is a quick reference for the steps in HTTP pipeline in ASP.NET 2.0.  Some of the steps are internal (cannot be subscribed by HTTP modules or GLOBAL.ASAX):

1. Internal step to validate request.  Protects against malicious attacks exploiting path canonicalization
2. Internal step to perform URL mapping (if the URL mapping feature is enabled)
3. Fire BeginRequest event
4. Fire AuthenticateRequest event
5. Fire DefaultAuthentication internal event
6. Fire PostAuthenticateRequest event
7. Fire AuthorizeRequest event
8. Fire PostAuthorizeRequest event
9. Fire ResolveRequestCache event
10. Fire PostResolveRequestCache event
11. Internal step to determine the IHttpHandler to process the current request (this is when the page compilation takes place)
12. Fire PostMapRequestHandler event
13. Fire AcquireRequestState event
14. Fire PostAcquireRequestState event
15. Fire PreRequestHandlerExecute event
16. Internal step to execute the IHttpHandler (call its ProcessRequest method) for the current request. The handler is determined at step #11
17. Fire PostRequestHandlerExecute event
18. Fire ReleaseRequestState event
19. Fire PostReleaseRequestState event
20. Internal step to perform response filtering (only if HttpResponse.Filter is installed)
21. Fire UpdateRequestCache event
22. Fire PostUpdateRequestCache event
23. Fire EndRequest event.  This is the only event that is guaranteed to be fired for each request