It’s great that some of the innovations from ASP.NET MVC 1.0 were moved into the ASP.NET 4.0 platform. One of those was the RouteTable. I hadn’t written a custom RouteHandler before, so I thought I’d do a simple one as a demo for myself (and any others who are interested).

This is just an example of how to build one – it’s not secure.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Security;
using System.Web.SessionState;
using System.Web.Routing;
using System.IO;

namespace TestWebApplication1
{
    public class Global : System.Web.HttpApplication
    {
        void Application_Start(object sender, EventArgs e)
        {
            RouteTable.Routes.Add(new Route("Assets/{locale}/{assetID}", new CustomRouteHandler()));
        }
    }

    public class CustomRouteHandler : IRouteHandler
    {
        public IHttpHandler GetHttpHandler(RequestContext requestContext)
        {
            return new SimpleFileHttpHandler(requestContext);
        }
    }

    public class SimpleFileHttpHandler : IHttpHandler
    {
        private RequestContext _requestContext;
        private HttpContext _httpContext;

        public RequestContext RequestContext { get; private set; }

        public SimpleFileHttpHandler(RequestContext requestContext)
        {
            _requestContext = requestContext;
        }

        public bool IsReusable
        {
            get { return false; }
        }

        public void ProcessRequest(HttpContext context)
        {
            _httpContext = context;

            string assetID = _requestContext.RouteData.Values["assetID"].ToString();
            string locale = _requestContext.RouteData.Values["locale"].ToString();

            if (string.IsNullOrWhiteSpace(assetID) || string.IsNullOrWhiteSpace(locale)) {
                throw new ArgumentException();
            }
            // this is not adaquate and definitely not secure as it would allow any file to be selected and downloaded
            // needs to prevent any sort of hack attempts using encoded paths, etc. should just be a relative path within the
            // folder that contains the content and no more.
            string path = _httpContext.Request.MapPath("~/Content/" + assetID, "", false);
            if (File.Exists(path))
            {
                // hard coded to the image/jpg type (obviously needs to adjust)
                context.Response.AddHeader("Content-Type", "image/jpg");
                context.Response.AddHeader("Content-Length", new FileInfo(path).Length.ToString());
                context.Response.WriteFile(path);
            }
        }
    }

}

To use it, I created a folder called Content and copied one of the sample photos included with Windows into the folder, and then modified Default.aspx:

<%@ Page Title="Home Page" Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true"
    CodeBehind="Default.aspx.cs" Inherits="TestWebApplication1._Default" %>

<asp:Content ID="HeaderContent" runat="server" ContentPlaceHolderID="HeadContent">
</asp:Content>
<asp:Content ID="BodyContent" runat="server" ContentPlaceHolderID="MainContent">
    <h2>
        Welcome to the Route Table Demonstrator
    </h2>
    <h3>This one should work as it's using the not-so-magical route table and a custom iroutehandler.</h3>
    <p>
        &lt;img src=&quot;/Assets/en-us/Penguins.jpg&quot; width=&quot;320&quot; height=&quot;200&quot; /&gt;
    </p>
    <p>
        <img src="/Assets/en-us/Penguins.jpg" width="320" height="200" />
    </p>
    <h3>THis one shouldn't work due to security in web.config for the folder</h3>
    <p>&lt;img src=&quot;/Content/Penguins.jpg&quot; /&gt;</p>
    <p>
        <img src="/Content/Penguins.jpg" />
    </p>
</asp:Content>

In the Content Folder, I added a web.config file to prevent direct access to the content within the folder:

<?xml version="1.0"?>
<configuration>

  <system.web>
    <authorization>
      <deny users="*"/>
    </authorization>

  </system.web>

  <system.webServer>
     <modules runAllManagedModulesForAllRequests="true"/>
  </system.webServer>
</configuration>

This should work without modification on IIS7+ and Visual Studio 2010.

I was disappointed, but certainly not surprised, to see that Microsoft employees blogging that Visual Studio 2010 performance over remote desktop would almost match, or be slightly slower than Visual Studio 2008 performance.

However, they got some good advice on how to optimize your RDP experience with Visual Studio.

http://blogs.msdn.com/jgoldb/archive/2010/02/27/optimizing-visual-studio-2010-and-wpf-applications-for-remote-desktop.aspx

Slow connections:

1. On slow connections, change remote desktop connection settings to use 16-bit color.
2. If running on high latency connections, select a “high latency” connection speed in RDC options:
   
3. On XP/Vista, grab the new remote desktop client, version 7.0.
4. Disable all check boxes except Persistent bitmap caching.
5. Also recommended is using a smaller window size (but that may be the most difficult to do).

WPF Application Optimization for Remote Desktop

In addition to the performance tips for Visual Studio, there’s a very nice set of best practices to follow for how to optimize any WPF application for use over remote desktop. Until the long-ago Longhorn promise of truly remoted-WPF applications support is added to the platform, we’ll need to optimize your WPF applications if they may be used over remote desktop.

The worst offender that I’ve encountered in the past is that animations, even hidden behind an opaque element, still cause that area of your application to be sent for each frame of the animation! (You might need to think about how silly that seems).

John Nack makes an extremely rational and systematic analysis of how many voices on the Internet consider Adobe to be the Devil. Is Adobe and in turn Flash Player the antagonist of all that is good about the web? Are they set to destroy the evil proposed Html 5 standards because they might compete with Flash Player?

Read and ponder.

Sympathy for the Devil

I’m using a progress bar in a small WPF application I’m working on and noticed that the Private Working Set for my application seemed higher than I expected.

My application, once simplified down to it’s most basic element, consisted of:

Window, Grid, ProgressBar

On my Windows 7 x64 machine, running the application uses around 29MB (private working set).

Removing the animation only from the visual template drops the private working set to 19MB.

So, it appears that the animation alone causes an extra 10MB of private working set to be needed. Sorry, but that’s crazy (especially for my application)!

If anyone has any specific theories – speak up! Here’s the basic starting Window I created:

<Window
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:Microsoft_Windows_Themes="clr-namespace:Microsoft.Windows.Themes;assembly=PresentationFramework.Aero" x:Class="PerfProgressBar.Window1"
    Title="Window1" Height="300" Width="300">
    <Grid>
        <ProgressBar x:Name="progressBar1" Value="100" />
    </Grid>
</Window>

I’m not going to post the entire ProgressBar template, but if you want to reproduce the problem (and see how the animation impacts the memory requirements, just comment out the “Animation” rectangle in the control template (and in the trigger as well):

<Rectangle x:Name="Animation" Fill="{TemplateBinding Foreground}" Grid.ColumnSpan="3" Grid.RowSpan="2">
    <Rectangle.OpacityMask>
        <MultiBinding>
            <MultiBinding.Converter>
                <Microsoft_Windows_Themes:ProgressBarHighlightConverter/>
            </MultiBinding.Converter>
            <Binding Source="{StaticResource ProgressBarIndicatorAnimatedFill}"/>
            <Binding Path="ActualWidth" ElementName="Background"/>
            <Binding Path="ActualHeight" ElementName="Background"/>
        </MultiBinding>
    </Rectangle.OpacityMask>
</Rectangle>

<Trigger Property="IsIndeterminate" Value="false">
    <Setter Property="Fill" TargetName="Animation" Value="#80B5FFA9"/>
</Trigger>

Apparently, the ProgressBarHighlightConverter is intense (a little double checking in Reflector confirms!).

(All animations have some price of course – as an experiment I rotated the progressbar in a storyboard and that used about 7MB).

The moral of the story here really is to make sure you do some sanity checks against your [fill-in-the-blank] technology so that you understand how it uses system resources such as memory, CPU, etc, as it may have an impact on the success or failure of your application. I’ll leave out the gratuitous animations in my application so it doesn’t use memory unnecessarily.

If you’re using the Microsoft Ajax Library (learn), you may not always want to start the automatic “attach” process that takes place when the page loads. It’s easy to disable, but not yet documented any place I could find easily.

<script src="Scripts/MicrosoftAjax/Start.debug.js" type="text/javascript"></script>
<script type="text/javascript">

    var ajaxPath = "";

    Sys.activateDom = false;

All you must do is set Sys.activateDom to false as shown above (make sure this is set after the new Start.js JavaScript file loads, otherwise your code will crash when you try to set the Sys object before it has been properly constructed).

Then, to begin the attach process, just call Sys.activateElements:

Sys.activateElements(document.documentElement);

In the code line above, though I’ve specified that I want the entire HTML document activated, you could provide any element you want as a starting point (for example to optimize the use of the library and prevent unnecessary DOM searching for example).

I’m adding the delay in some JavaScript code because I wanted to set up a few variables in advance of the attach occurring. I tend to write my JavaScript code in an object oriented fashion these days (using the prototype pattern), including code that is interacting with the DOM. In this case, I’ll create a class that represents the logic of the page rather than following the typical purely functional model that is done on many JavaScript pages. But, when using the “eval” syntax of the Microsoft Ajax library “{{ code }}”, occasionally, I’ll need to delay the eval or the page will crash.

From my recent post on making a simple command extension to the Microsoft Ajax library, I wanted to make that more object oriented by referring to an instance of my class, rather than pointing directly to a function:

<body sys:attach="wpc"
    wpc:onbubbleevent="{{$view.onCommand}}"
    xmlns:sys="javascript:Sys" xmlns:wpc="javascript:WiredPrairie.Commanding">

$view represents the instance of my page’s behavior. However, if the attach were to occur too early, this variable is not yet set. I’m using the slick script loading functionality of the ajax library, specifying the various JavaScript libraries and their dependencies, including my page’s behavior. It’s not until that JavaScript code is loaded that the code can create an instance – and that could be AFTER the page has already done the attach logic. The attach happens before Sys.onReady for example. (Sys.onDomReady happens before onReady, but not all JavaScript files may have been downloaded).

Sys.onReady(function() {
    $view = new WiredPrairie.MainView();

    Sys.activateElements(document.documentElement);

When using the sys:attach attribute, note that the attach and instantiation process happens before any code you’ve specified in onReady is executed (Microsoft currently uses the same method for determining when everything is ready by adding a function call to onReady – but their call is first in the queue).

If this isn’t a head-slapping coding-moment I don’t know what is…

Encryption busted on NIST – certified Kingston, SanDisk and Verbatim USB flash drives

The crack relies on a weakness so astoundingly bone-headed that it’s almost hard to believe. While the data on the drive is indeed encrypted using 256-bit crypto, there’s a huge failure in the authentication program. When the correct password is supplied by the user, the authentication program always send the same character string to the drive to decrypt the data no matter what the password used. What’s also staggering is that this character string is the same for Kingston, SanDisk and Verbatim USB flash drives.

I can’t imagine the security firm SySS’s reaction when they found this:

Analyst 1: “Ah Houston, we have a problem here. Dudes, this thing isn’t secure at all. It doesn’t even use my password for the encryption!”

Analyst 2: “Get the #$@!# out!! I’ve got 4 weeks scheduled to look at this thing. It’s day 2. No @$%!@# way.”

Analyst 1: “Seriously. It data is always encrypted with the same string.”

Analyst 2: “Cool, I get the next 4 weeks off.”

There may be another way to accomplish this, but I wanted to have a simple commanding system in the Microsoft Ajax Library which worked outside of the templates.

After a number of false starts and frustration brought about by very limited documentation, I discovered a reasonable implementation.

I created a script file, “Commanding.js” (in a Scripts folder):

/// <reference name="MicrosoftAjax.js"/>

Type.registerNamespace("WiredPrairie");

WiredPrairie.Commanding = function(element) {
    WiredPrairie.Commanding.initializeBase(this, [element]);
}

WiredPrairie.Commanding.prototype = {
    initialize: function() {
        WiredPrairie.Commanding.callBaseMethod(this, 'initialize');

        // Add custom initialization here
    },
    dispose: function() {
        //Add custom dispose actions here
        WiredPrairie.Commanding.callBaseMethod(this, 'dispose');
    }
}

WiredPrairie.Commanding.registerClass('WiredPrairie.Commanding', Sys.UI.Control);

if (typeof (Sys) !== 'undefined') Sys.Application.notifyScriptLoaded();

This is just a basic JavaScript class, with the default implementation provided by the Ajax Client Control template in Visual Studio 2008. The reason this is needed is that Controls all support a special event onBubbleEvent that is needed by commands when they’re raised.

In the body of the HTML, I attached an instance of the “WiredPrairie.Commanding” class to the body. Next, I attached a JavaScript function to the onbubbleevent (wpc:onbubbleevent, remember that all attributes need to be all lowercase). Here, I’ve used the special {{ }} syntax to indicate I want JavaScript code to execute when the event is raised.

<body xmlns:sys="javascript:Sys"
    xmlns:wpc="javascript:WiredPrairie.Commanding"
    sys:attach="wpc"
    wpc:onbubbleevent="{{onCommand}}" >
    <div >
        <button sys:command="startRunningCommand" sys:commandargument="iargueaboutit">Run</button>
    </div>
</body>

I needed my JavaScript WiredPrairie.Commanding class to load and run at the right time on the page, so I’ve used the new loader classes in the Ajax library.

Sys.loader.defineScripts(null, [
{
    name: "Commanding"
    ,releaseUrl: "Scripts/Commanding.js"
    ,debugUrl: "Scripts/Commanding.js"
    ,dependencies: ["ComponentModel"]
 }
 ]);

First, I needed to declare this new script file and any dependencies. Since I don’t yet have a minified version, I’ve just specified the same file for the releaseUrl and the debugUrl. For the dependencies property, I looked through a few source files to discover that the “ComponentModel” key included Sys.UI.Control, which my class depends on to be created, so I added that here (hopefully this will be documented at some point).

Next, I added code to indicate to the loader which scripts were necessary and let it determine the best way to load them:

Sys.require([Sys.components.dataView, Sys.scripts.jQuery, Sys.scripts.Commanding]);

Here, you see the “Commanding” key is added to a special namespace, “Sys.scripts.”

In the new onReady event which is raised when the DOM and scripts have been loaded, I’ve added code to activate the control class I wrote:

Sys.onReady(function() {
    Sys.activateElements(document.documentElement);
});

Finally, I wired up that event declared above in the onbubbleevent attribute on the body element.

function onCommand(sender, args) {
    if (typeof (args) !== "undefined") {
        var commandName = args.get_commandName();
        var commandArgument = args.get_commandArgument();
        alert(commandName + " " + commandArgument);
    }
}

OK, that’s cool, but you might want to raise a command without it being triggered by a control event (such as a click). So, I added a simple function to my Commanding class:

WiredPrairie.Commanding.raiseCommand = function(sender, commandName, commandArgument, commandSource) {
    var source = sender || document.body;
    Sys.UI.DomElement.raiseBubbleEvent(source, new Sys.CommandEventArgs(commandName, commandArgument, commandSource));
}

var $sendCommand = WiredPrairie.Commanding.raiseCommand;

Because of the way the raiseBubbleEvent works, it does depend on the source being set to a valid control/element (as raiseBubbleEvent walks through the parent chain until there aren’t any more parents) – in this case, I’ve defaulted to the body element.

Finally, an enhancement to the test case above to demonstrate both receiving and sending a command:

function onCommand(sender, args) {
    if (typeof (args) !== "undefined") {
        var commandName = args.get_commandName();
        var commandArgument = args.get_commandArgument();
        switch (commandName) {
            case "startRunningCommand":
                $sendCommand(null, "alertCommand", new Date().toLocaleTimeString(), null);
                break;
            case "alertCommand":
                alert(commandArgument);
                break;
            default:
                break;
        }
    }
}

One command just sends another command which displays an alert. It’s simple, but functional.

Enjoy.

Here’s an e-mail I received this morning, a legitimate e-mail:

“Travel Planner Email”, from “Airlines”

????

Huh?

We’re planning a brief vacation that requires a bit of air travel, so before I hit delete, I paused to see what the spam e-mail said – and then realized it was not spam at all.

Note to programmers: ….

Aw heck.

Just stop doing stupid anti-human stuff.

OK, I’ll admit that HTML 5, when it becomes a true standard and the common browsers implement it and all of CSS 3 that we won’t need as many browser plug-ins for doing rich interactive applications anymore. We could ditch Microsoft’s Silverlight and Adobe’s Flash and not look back.

But, to do that, we need to move the web to a better programming language!

Reading this rant from MG Siegler on Tech Crunch made me want to come clean about my true feelings.

As Google Backs Away From A Plug-in, Microsoft Rushes Towards One

I don’t want to need Flash or Silverlight.

But, I’ll take either of them over programming a large scale web application using JavaScript – since both of them have a modern programming language (ActionScript 3 and C#). Seriously. JavaScript, born in 1995. It’s 14 freaking years old as of this December (as it was first released in December 1995). We’ve got budding programmers who were born AFTER it was created. JavaScript, unlike many of it’s commonly used, similarly aged counterparts, has not had any significant upgrades or improvements to reflect new market needs. Java and C++ both have (Java got generics for example), and C# was born in the last decade. I like Silverlight more than Flash only because of the programming language (and IDE) attached with its development.

Here’s my short list of complaints about JavaScript:

• Dynamic typing – great, I can’t know until runtime what a type should be, and even then it could change. Makes for a great time.
• Prototype – oh don’t get me started on the patterns that are necessary to create a robust object oriented framework in JavaScript – and “this”, and “oops, you’re missing a comma, good luck finding that!”
• Closures – the source of too many memory leaks and confusion over the years, especially given the subtly of its behavior in JavaScript
• No official “imports” or “usings” to make doing code-completion practical, and one JavaScript file can’t declare another JavaScript file as a dependency and have it automatically be loaded (just once of course), without creating a new framework.
• Run-time code discovery – it’s great to be able to load things dynamically, but it’s completely a mess at design time trying to sort everything out and make sense of a large application.
• Debugging – terrible IDE and debugging support across the browsers. Too many “alert” style debugging workflows in this day and age.
• Interpreted – still making the browser do extra work and a bonus feature: you don’t know about coding errors until you try to execute the code!
• Poor internationalization support – to do it right, you need to build functions or get a library to parse and format properly

(Don’t get me started about the inconsistency of DOM access from JavaScript across browsers – which I realize isn’t JavaScript – it’s a browser thing – but they’re intertwined from all practical purposes).

(And, I’m not complaining about a web application that consists of 2 JavaScript files, where one of them is JQuery. Think big. Applications. Complex workflows. Frameworks. Etc. It’s tough stuff. It’s doable, but unnecessarily difficult).

Major Web applications would have taken off long ago if the entire development experience/environment would have modeled after something like Visual Basic 3, 4, 5,  or 6. Web applications are still held back by an awful development experience.

Do you love JavaScript? Does it need to be upgraded to this century?

Updated to reflect a bit of ranting inconsistency.

However, will Silverlight and WPF merge?

From Pete Brown:

The Future of Client App Dev : WPF and Silverlight Convergence

As a Microsoft employee (Developer Community Program Manager for Windows Client), he said:

What the Future Holds – Convergence of WPF and Silverlight

 

I recently spoke with Ian Ellison-Taylor at Microsoft. Ian is a General Manager at Microsoft, reporting directly to Scott Guthrie. Among other things, his group handles both Silverlight and WPF (and RIA services and a lot of other stuff). I figured if I wanted the skinny on the future, he’d be the guy to talk to. So, he and I talked about the convergence of Silverlight and WPF, and later exchanged some email on the topic.

 

In the future, it is very likely that both Silverlight and WPF will be a single technology with a single codebase. After all, Silverlight was originally known as WPF/E (E as in Everywhere), and in an amazing 180 degree reversal of our usual approach, we took an ugly codename and created a great product name (Silverlight) from it.

D’uh. Like it wasn’t obvious, especially with the explosive growth and capabilities of Silverlight, why wouldn’t this be on the road map?

Of course, there’s no time frame mentioned, so don’t plan on your Silverlight application being able to use real 3D and actual DataTriggers any time soon.