AspNet2Holes

When introduced with trumpets and fanfares, Microsoft's C# language provided little beyond the C++ language, for which Microsoft already offered a widely used tool set, that was not also provided by the Java language. Unlike the extensive, collaborative and sometimes public efforts in which Bjarne Stroustrup designed C++ and James Gosling designed Java, the design of C# was a mostly private process. Initially rather constricted and viewed by some as a crippled C++, the C# language was revised in a fall, 2005, release that improved its capabilities.

While C++ and Java were each major innovations, C# has an industrial tone. It is mostly a language for applications rather than systems. It disfavors pointers, which can crash applications but are often necessary for systems. As did Java, it revives from classic application languages like PL/I constructs such as built-in strings, arrays and streams that may be misfits or excess baggage in systems. Thread management is provided by built-in constructs similar to Java, while the ability to pass function arguments by reference rejects Java's limitations. The native class library was strengthened in the second edition with type-safe "generic" classes, but collections classes remain scattershot as compared with the C++ template library.

C# is performance-oriented. Although it allows copy-constructors, it rejects the C++ convention of using them for collection objects, gaining run-time performance at a potential cost in robustness. Passing function arguments by reference likewise trades performance against robustness, protected to some extent by requiring matching "ref" or "out" attributes in function declarations and references. Unlike Java, C# retains the "enum" and the "struct" from C++, originally taken from C in round-about inheritance from Pascal, PL/I and COBOL. In C#, however, the "struct" is distinct from the class, more efficiently allocated and accessed and providing no inheritance. Once again the main benefit is performance.

A key differentiator for C#, not apparent from syntax, is strong typing when implementing its type-safe classes, improving performance as compared to Java and preventing run-time errors as compared to C++. Distinctive features of C# syntax are built-in constructs for events and delegates, main ingredients of ASP.NET applications, and for class properties. In a similar spirit of automation its development environment automatically prepares declarations for and extracts them from compiled assemblies, eliminating "header" files of declarations.

Perhaps as a marketing ploy, Microsoft has played up what it calls "innovations" in C#, but nearly all are new words or new implementations for well-established concepts. The "managed code" concept is a good (and key) example; its roots are in the automatic bounds checking of PL/I and other classic procedural languages. The Ada language remains a reference standard for managed environments, with rigorous component definition, type safety, bounds checking, automatic garbage collection and exception handling. C# joins these concepts with a concise syntax and an orientation to high-performance, event-driven applications.

The future development of C# is reported to be integration with database access, currently supported by class libraries. That would be a risk-laden approach for Microsoft, likely to be seen as a venture to build out a monopoly for its SQL Server database products. Signals as to Microsoft's intents, if such a road is taken, will be whether or not unique features or syntax of SQL Server become imbedded in C# language constructs.

Microsoft Internet Information Services (IIS) version 6.0 introduced essential capabilities for managing Web page services to the Windows environment, including process pools, caching and server farms. Along with that came several more security features, including detailed control of the privileges under which Web page services execute on a server.

IIS 6.0 includes several protentially conflicting ways to specify privileges, yet Microsoft provides very little information about how they interact. The most obvious of these potential conflicts is specifying a user account for a Web site and also specifying a user account for the process pool in which the site's services execute. When they are not the same, who's on first? What happens?

The Web site's user account is specified in the IIS Manager tool under the properties "Directory Security," "Authentication and access control (Edit)," "Enable anonymous access." The process pool's user account is specified in IIS Manager under the properties "Identity," "Configurable." Both affect documented fields in the XML metabase of IIS, but undocumented is what will happen when the specified user accounts are not the same. Other, largely undocumented complications are "special privileges" and the default user accounts similarly specified for all Web sites and all process pools.

At present most of this remains a mystery to be disentangled mainly through experimental programming. The few Internet forums and Web logs that touch on these topics reveal a general lack of knowledge. The only significant book on IIS 6.0, by Mitch Tulloch (Osborne, 2003), provides no more help than one can get on-line from Microsoft. At the "deliberate speed" with which Microsoft provides documentation, the next version of IIS is likely to be available before the current one has been explained.

Validity checking of postbacks in ASP.NET 2.0 is a useful feature, but it can fail, generating mysterious messages that may begin, "Exception reported in __Page view...Invalid postback or callback argument...." One may also see, "Invalid postback or callback argument...Description: An unhandled exception occurred...." The messages go on with paragraphs that are likely to confuse a software developer, let alone a hapless user.

Many problems result from Internet Explorer or other browsers responding to user actions before a page has been completely constructed. An early postback may lack necessary information from controls that have not yet been fully processed by a browser. That is likely to happen when a page contains a grid or other bulky data or when it uses third-party controls that construct themselves on a client through JavaScript. In its designs for ASP.NET 2.0 and Internet Explorer, Microsoft evidently failed to anticipate such synchronization errors, and its marketing and support cheerleaders do not candidly acknowledge them either.

Validity checking can be disabled for all pages in web.config:

    <~system.web~>
        <~pages buffer="true" validateRequest="true"
          enableEventValidation="false" /~>
    <~/system.web~>

Validity checking can be disabled for individual pages by adding markup attributes ValidateRequest="false" and EnableEventValidation="false" to Page directives. Although sometimes recommended by novices, these are usually poor approaches, since they will open major security holes in applications. Yet how else to prevent users from tripping across ugly error boxes? Microsoft does not advise, and neither do makers of third-party controls such as Telerik.

Many such problems can be solved by strategic testing and design. Pages that contain bulky data or self-constructing controls must be tested aggressively to see whether early user action can cause errors. If such errors can occur, then controls that would provoke them need to be kept hidden until a page's controls have all been processed by a browser. The trouble-provoking controls are often buttons, but any control that is configured to generate a postback or an AJAX callback may be the source of a problem.

To hide a control, in markup add the option "visibility: hidden" to its Style attribute. At the end of the markup for a page, add a JavaScript block such as:

    <~script type="text/javascript"~>
        var oControl = document.getElementById
         ('<~% = ofControl.ClientID %~>');
        if (oControl != null)
        {
            oControl.style.visibility = 'visible';
        }
    <~/script~>

In the example, ofControl matches the ID attribute of a control that can trigger a postback and is initially hidden. The JavaScript block makes these controls visible. By the time it does so a browser will have processed a page's controls, and they should be prepared to participate correctly in a postback.

[Note: because of display limitations, characters "< " and " >" here are shown with a tilde ~ after or before them.]