Unfortunately Chrome 2.0 rolled out with some significant rendering problems.  Actually it looks to us like it might be just one problem, but with wide-ranging repercussions.  Essentially a lot of pages get rendered with a lot of missing content – blank tables!  For the NetQuarry platform the result was that our Datasheet (a very functional bound data grid) was rendered in Chrome 2.0 as an empty grid.  A few icon buttons rendered, but the text content was gone!  One day we were on Chrome 1.x and everything was fine, and the next day Chrome 2.0 was pushed out to us (like it or not) and voila!

After quickly verifying that it was a Chrome 2.0-specific problem, we did some Googling.  We expected to find lots of people complaining about this and some quick help on a fix or workaround.  Surprisingly there didn’t seem to be a widespread uproar.  We did find that it was a known problem and that lots of main stream sites were essentially unusable with Chrome 2.0 (http://code.google.com/p/chromium/issues/detail?id=9904).  Apparently the list of affected sites includes Facebook, Twitter, WordPress, and even Google Calendar. Unfortunately my search turned up no tips on what to do about it.  It seemed to be some kind of clipping problem that was found before Chrome 2.0 was pushed out to general distribution, but not fixed until after that (or in subsequent releases so far).  Seeing that the problem was so widespread we decided to wait a few days assuming that Google would push out a fix.  A few days later Chrome v2.0.172.31 was pushed out, but lo and behold, the problem persisted.

After a few more days, and customer complaints, we decided that we couldn’t wait.  We did some testing on our datasheet and more Googling and found this Chrome issue (http://code.google.com/p/chromium/issues/detail?id=13333) which matched our problem exactly.  What’s more it gave us a suitable workaround.  Five minutes later we had the fix in test and shortly after that it was checked in and ready for the next build.  Here’s our thanks to terrybarthdesign for providing the workaround.  In short, Chrome 2.0 does not like the overflow:hidden style on a tr tag.  With the overflow hidden the entire table row content is not rendered.  The content is there in the HTML and sometimes flashes briefly when the page is first rendered, but it doesn’t render.

The frustrating thing about this was that it was actually pretty hard to find this.  We tried Googling on things like “empty table Chrome 2.0”, “missing data Chrome”, “blank grid Chrome”, and about every combination of similar keywords that we could think of and it wasn’t until late last night that we stumbled upon the issue report from terrybarthdesign.

There are really two purposes for this post.  The first is to hopefully help someone else stumble onto a way to resolve a very significant problem.  The second, is to point out that the great thing about a platform like NetQuarry is that we, NetQuarry, spent our time figuring this out – once.  Our clients don’t have to worry about it.  Well, they had to worry about it until we fixed it of course, but we investigated and determined it was a Chrome bug, we explained what was going on, we experimented, tested, researched, and provided a fix in our platform – and all our clients benefited.  Today or tomorrow we’ll be releasing a new version of the platform (which was coming regardless) and it will have this fix.  Our clients won’t have to do a thing except install the new platform.  They won’t have to change their code one iota.

The NetQuarry platform supports all recent versions of Chrome, Firefox, Safari, Opera, and IE 6, 7, and 8.  The platform takes care of all the browser differences with no overhead for our clients.  And, when a supported browser releases a new version, NetQuarry makes sure that the platform is completely compatible.  Better yet, the platform is engineered to ensure that such breakage rarely occurs.  The platform is designed not just for compatibility with the latest version of each browser, but for forward compatibility as well.

The movie demonstrates how you can quickly generate a working application that is not only completely functional, but looks great as well.

We recently wanted to install an SSL certificate on our main build server so that multiple sites hosted on that server could (and in some cases must) use SSL. So, I bought a $199 “wildcard” certificate from GoDaddy.com and installed it onto our Windows 2003 / IIS 6.0 build machine. Everything worked until I tried to add the same certificate to multiple sites on the same server. I started searching for an answer – “SSL certificate IIS subdomain multiple” and found that it wasn’t possible. Host headers – the thing you use to allow one IP address to act like different sites – doesn’t work with IIS 6.0.

I eventually bumped into this article: http://www.sslshopper.com/article-how-to-configure-ssl-host-headers-in-iis-6.html that solved the problem. Turns out it’s pretty simple, but you can’t do it using the MMC IIS snap-in.

Here’s the script (run from /inetpub/adminscripts):

cscript.exe adsutil.vbs set /w3svc/<site ID>/SecureBindings ":443:<host header>"

Note that I found that you had to install your wildcard certificate, run the script, and restart IIS before everything worked.

Ryan

Everything started out well enough. I created a master page called minimal.master and added it to my project. The .master file was very simple:

<%@ Master Language=”C#” AutoEventWireup=”true” CodeBehind=”minimal.master.cs” Inherits=”NetQuarry.minimal” %>

<%@ Register TagPrefix=”eap” Namespace=”NetQuarry.WebControls” Assembly=”EAP.WebControls” %>

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.0 Transitional//EN” >

<html xmlns=”http://www.w3.org/1999/xhtml” >
<head runat=”server”>
<title runat=”server” id=”pageTitle”>Untitled Page</title>
<asp:ContentPlaceHolder id=”header” runat=”server”>
</asp:ContentPlaceHolder>
</head>

<body runat=”server” id=”body” class=”background”>
<esp:ContentPlaceHolder id=”content” runat=”server”/>
</body>
</html>

I made a few quick modifications to my templates wrapping my original header and body contents in appropriate asp:Content controls:

<asp:Content ID=”header” ContentPlaceHolderID=”header” runat=”Server”>
</asp:Content>

<asp:Content ID=”content” ContentPlaceHolderID=”content” runat=”Server”>
</asp:Content>

A bit more tweaking, the basics were there, but I still had problems. The big problem was that the NetQuarry platform is used to create web applications, not web sites. Our applications include a fair amount of javascript and AJAX and using master pages had broken lots of script. It didn’t take long for me to figure out that the main problem was that all my client-side elements now had mangled names. For example, instead of a textbox being named something like “first_name”, it was being rendered into the HTML as “ctl00_content_first_name”. This mangling broke our script, and badly.

The cause of the mangling is the .Net NamingContainer idea. NamingContainers allow a page to host multiple instances of an object by automatically generating unique client-side names that represent the control hierarchy on the server. In this case, the MasterPage class itself was a NamingContainer as well as the ContentPlaceHolder control. Since I hadn’t provided an ID for my MasterPage .Net named it ctl00. I had named the ContentPlaceHolder for the main page content “content”. So, since my existing page content was all contained in the “content” ContentPlaceHolder and it was in turn contained in the “ctl00” MasterPage, .Net composed a unique client-side name for the any control in the “content” prefixed with “ctl00_content_” and, voila, broken script.

Now NamingContainers are a great feature of .Net and they allow a lot of things to work seamlessly. However, in this case I didn’t want any stinking NamingContainers. Unfortunately, there’s no way to turn off the NamingContainer feature of any control marked as a NamingContainer (a control is marked as a NamingContainer by deriving from the INamingContainer marker interface). Hint to Microsoft, this would be a good feature.

I actually spent about two days fighting with this and scouring the internet to see if anyone else had come up with a solution. I did find several partial solutions that helped me move in the right direction. First there was a good article about MasterPages in general on www.OdeToCode.com – ASP.Net 2.0 – Master Pages: Tips, Tricks, and Traps. A bit more digging and I found a partial solution on Rick Strahl’s Web Log – Overriding ClientID and UniqueID on ASP.NET controls. I’ve found Rick’s blog to be very helpful in the past. And, that article pointed me to one other helpful blog on glJakal blog – Getting rid of the Naming Container in asp.net 2.0.

Together these articles showed how to defeat the NamingContainer for client-side naming. The full code of the final solution is below, but defeating the NamingContainer for client-side id mangling involved overriding the ClientID, UniqueID, and ID properties on the MasterPage and ContentPlaceHolder classes to return null, and the NamingContainer property on the ContentPlaceHolder class to return null. With that my pages rendered well and my javascript worked!

Alas, what didn’t work was any postbacks. The problem was that the id’s of the client-side controls no longer matched the control hierarchy on the server! It didn’t take me long to figure out that what I needed to do was figure out a way to make the server-side control hierarchy match my client-side naming. Essentially this meant making the server-side hierarchy look like my pre-MasterPage hierarchy, as far as NamingContainers go that is.

After a day of failed attempts, I was able to work out how to accomplish this. The secret was to rearrange the control tree during the page PreInit event. The PreInit event is available only to Page objects and is the only time that you can rearrange controls in the way I needed to. Eventually I figured out that two things needed to be done: 1) move the controls out of the MasterPage and ContentPlaceHolder controls so that .Net can match up the server-side controls with the unmangled client-side id’s, and 2) leave the controls in the MasterPage and ContentPlaceHolder controls for rendering purposes so that the contents are rendered correctly with respect to other elements in the MasterPage.

May 20, 2009 update: Thanks to Ritchie Annand for discovering a problem in the original code when run with .Net tracing enabled (via the <trace> tag) and pointing the way to a fix.  The code now includes a fix to ensure that all hosted controls get an ID which is required when tracing (see the call to AssignIDs() in TemplateMaster::OnPreRender()).  Note that there is still a glitch that affects our platform under certain circumstances when .Net tracing is enabled and pageOutput is turned on.

To use the code below you need to do just a few things:

• Include the code below in your project,
• Derive your master page from TemplateMaster instead of MasterPage,
• Use the <eap:ContentPlaceHolder> tag in place of <asp:ContentPlaceHolder>,
• In your master page .designer file, use the new ContentPlaceHolder instead of the .Net ContentPlaceHolder, and
• In your page’s PreInit event, call the TemplateMaster.Rehost() method, something like this:

protected override void OnPreInit(EventArgs e)
{
    //--- Rehost controls from MasterPage/Content/ContentPlaceHolder hierarchy onto the 
    //--- Page itself.  This has the effect of cancelling the NamingContainer effect of 
    //--- these controls on the server. 

    if (this.Master is TemplateMaster)
    {
        (this.Master as TemplateMaster).Rehost();
    } 

    base.OnPreInit(e);
}

And finally, here’s the code:

//---------------------------------------------------------------------------------------
// Copyright (c) 2005-2009 by NetQuarry, Inc.
// All rights reserved.
//
// Licensed under the Eiffel Forum License, version 2:
//
// 1. Permission is hereby granted to use, copy, modify and/or
// distribute this package, provided that:
// * copyright notices are retained unchanged,
// * any distribution of this package, whether modified or not,
// includes this license text.
// 2. Permission is hereby also granted to distribute binary programs
// which depend on this package. If the binary program depends on a
// modified version of this package, you are encouraged to publicly
// release the modified version of this package.
//
// THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT WARRANTY. ANY EXPRESS OR
// IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
// WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
// DISCLAIMED. IN NO EVENT SHALL THE AUTHORS BE LIABLE TO ANY PARTY FOR ANY
// DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
// DAMAGES ARISING IN ANY WAY OUT OF THE USE OF THIS PACKAGE.
//
// www.netquarry.com
//---------------------------------------------------------------------------------------

using System;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.HtmlControls;
using System.Text;
using System.Collections.Generic;

[assembly: TagPrefix("NetQuarry.WebControls", "eap")]

namespace NetQuarry.WebControls
{
    /// <summary> 
    /// Base class that must be used for any master page hosting platform templates. 
    /// </summary> 
    public abstract class TemplateMaster : System.Web.UI.MasterPage
    {
        private class ContentContainer : Control
        {
            protected override void Render(HtmlTextWriter writer)
            {
                //base.Render(writer);  // Ignore the normal render. 
            }

            public void ExternalRender(HtmlTextWriter writer)
            {
                base.Render(writer);    // Now render! 
            }

            protected override void OnPreRender(EventArgs e)
            {
                base.OnPreRender(e);

                int nIDIndex = 0;

                AssignIDs(this, this.ID, ref nIDIndex);
            }

            /// <summary>
            /// In .Net TRACE enabled every control in the hierarchy MUST have and ID and our juggling rehosting 
            /// controls messes up .Net's id assignment.  Here we recursively search through the specified control
            /// and provide unique ID's to any controls so lacking.
            /// </summary>
            /// <param name="ctrl">The control whose hierarchy should be scanned and assigned.</param>
            /// <param name="baseName">The base name for any subcontrols.</param>
            /// <param name="idIndex">The ID index to use when assigning a unique ID.</param>
            private void AssignIDs(Control ctrl, string baseName, ref int idIndex)
            {
                if (string.IsNullOrEmpty(ctrl.ID))
                {
                    ctrl.ID = baseName + idIndex.ToString().PadLeft(3, '0');
                    idIndex++;
                }

                if (ctrl.Controls != null)
                {
                    foreach (Control child in ctrl.Controls)
                    {
                        AssignIDs(child, baseName, ref idIndex);
                    }
                }
            }
        }

        private class ContentRenderer : Control
        {
            ContentContainer _container = null;

            public ContentRenderer(ContentContainer container)
            {
                _container = container;
            }

            protected override void Render(HtmlTextWriter writer)
            {
                if (_container != null) _container.ExternalRender(writer); // Ask associated container to render. 
            }
        }

        /// <summary> 
        /// Defeat the effect of the .Net MasterPage being a NamingContainer with regard 
        /// to client-side NAME and ID attributes rendering by always returning a null ClientID. 
        /// </summary> 
        public override string ClientID
        {
            get { return null; }
        }

        /// <summary> 
        /// Defeat the effect of the .Net MasterPage being a NamingContainer with regard 
        /// to client-side NAME and ID attributes rendering by always returning a null UniqueID. 
        /// </summary> 
        public override string UniqueID
        {
            get { return null; }
        }

        /// <summary> 
        /// Defeat the effect of the .Net MasterPage being a NamingContainer with regard 
        /// to client-side NAME and ID attributes rendering by always returning a null ID. 
        /// </summary> 
        public override string ID
        {
            get { return null; }
            set { base.ID = value; }
        }

        /// <summary> 
        /// Rehost controls from MasterPage/Content/ContentPlaceHolder hierarchy onto the 
        /// Page itself.  This has the effect of cancelling the NamingContainer effect of 
        /// these controls on the server.  
        /// </summary> 
        /// <param name="parent">The parent control whose children should be rehosted.</param>
        /// <param name="idIndex">The ID index to use when providing ID's to controls so lacking.</param>
        private void MoveControlsToPage(Control parent, ref int idIndex)
        {
            if (base.Page != null && this.Controls.Count > 0)
            {
                List<Control> lst = new List<Control>(this.Controls.Count);
                ContentContainer container = new ContentContainer();                // Container will host the controls w/out a NamingContainer. 
                ContentRenderer renderer = new ContentRenderer(container);        // Renderer will render contents of container. 

                //--- In .Net TRACE enabled every control in the hierarchy MUST have
                //--- and ID and our juggling rehosting controls messes up .Net's id assignment.

                container.ID = "ctlcont" + idIndex.ToString().PadLeft(3, '0');
                renderer.ID = "ctlrend" + idIndex.ToString().PadLeft(3, '0');
                idIndex++;

                //--— Create collection of all controls to move.

                for (int ii = 0; ii < parent.Controls.Count; ii++)
                {
                    lst.Add(parent.Controls[ii]);
                }

                //--— Determine index of this container. 

                Control root = parent;

                while (root != null && root.Parent != null && !(root.Parent is Page))
                {
                    root = root.Parent;
                }

                int nIndex = (root == null) ? -1 : root.Parent.Controls.IndexOf(root);

                //--— Remove controls from original parent and add them to new container. 

                for (int ii = 0; ii < lst.Count; ii++)
                {
                    Control ctrl = lst[ii];

                    parent.Controls.Remove(ctrl);
                    container.Controls.AddAt(ii, ctrl);
                }

                //--— Add new renderer to replace original controls and new container to the page itself. 
                //—-- The container is used to extablish the control hierarchy and in this way collapsing  
                //—-- the MasterPage so that it doesn’t act as a NamingContainer for the purposes of the 
                //—-- control hierarchy.  The container will ignore the control’s normal Render() method. 
                //--— The renderer has no controls, just a reference to the container.  When the renderer’s 
                //--— Render() method is called it will have the container render in its place.

                parent.Controls.Add(renderer);                    // Render controls as if contained in master. 
                Page.Controls.AddAt(nIndex + 1, container);        // But host them flat on the page instead of nested in NamingContainers. 
            }
        }

        /// <summary> 
        /// Rehost controls from MasterPage/Content/ContentPlaceHolder hierarchy onto the 
        /// Page itself.  This has the effect of cancelling the NamingContainer effect of 
        /// these controls on the server.  
        /// </summary> 
        /// <param name="parent">The tree of controls from which to rehost.</param>
        /// <param name="idIndex">The ID index to use when providing ID's to controls so lacking.</param>
        private void RehostMasterControls(Control parent, ref int idIndex)
        {
            //--— Find all ContentPlaceHolder controls and rehost the children to the page itself. 

            foreach (Control ctrl in parent.Controls)
            {
                if (ctrl is NetQuarry.WebControls.ContentPlaceHolder)
                {
                    MoveControlsToPage(ctrl, ref idIndex);        // Rehost children to page. 
                }
                else
                {
                    RehostMasterControls(ctrl, ref idIndex);    // Recurse. 
                }
            }
        }

        /// <summary>
        /// Rehost controls from MasterPage/Content/ContentPlaceHolder hierarchy onto the
        /// Page itself.  This has the effect of cancelling the NamingContainer effect of
        /// these controls on the server. 
        /// </summary>
        public void Rehost()
        {
            int nIDIndex = 0;        // Need to provide unique ID's for controls so lacking.

            RehostMasterControls(this.Page.Master, ref nIDIndex);
        }
    }

    /// <summary> 
    /// Replacement control for System.Web.UI.WebControls.ContentPlaceHolder for use when it is desired 
    /// to NOT have the MasterPage, Content, and ContentPlaceHolder controls behave as naming 
    /// containers.  There are two aspects to this: 1) the effect a NamingContainer has on the  
    /// client-side control NAME and ID mangling, and 2) the control hierarchy on the server. 
    /// </summary> 
    public class ContentPlaceHolder : System.Web.UI.WebControls.ContentPlaceHolder
    {
        /// <summary> 
        /// Defeat the effect of the .Net ContentPlaceHolder being a NamingContainer with regard 
        /// to client-side NAME and ID attributes rendering by always returning a null NamingContainer. 
        /// </summary> 
        public override Control NamingContainer
        {
            get { return null; }
        }

        /// <summary> 
        /// Defeat the effect of the .Net ContentPlaceHolder being a NamingContainer with regard 
        /// to client-side NAME and ID attributes rendering by always returning a null ClientID. 
        /// </summary> 
        public override string ClientID
        {
            get { return null; }
        }

        /// <summary> 
        /// Defeat the effect of the .Net ContentPlaceHolder being a NamingContainer with regard 
        /// to client-side NAME and ID attributes rendering by always returning a null UniqueID. 
        /// </summary> 
        public override string UniqueID
        {
            get { return null; }
        }

        /// <summary> 
        /// Defeat the effect of the .Net ContentPlaceHolder being a NamingContainer with regard 
        /// to client-side NAME and ID attributes rendering by always returning a null ID. 
        /// </summary> 
        public override string ID
        {
            get { return null; }
            set { base.ID = value; }
        }
    }
}

For me, the reason I feel this way is because there are always parts of an application that aren’t quite right. I’d like a chance to make it better.

Since this isn’t always possible we’ve made a huge effort to allow for a way to add and remove parts of your application in a simple, safe, and discoverable way. In fact, this idea of “feature versions” is a first class concept in the Platform.

A feature version allows you to add metadata and code and tag it with a name that won’t be available in your live application unless you enable the version. This works for all important metadata objects – pages, mappers, fields, and extensions. Because it works with extensions you can actually write code, add it to the build, installer, and publish it to your live site without any risk of the code kicking in before the feature is absolutely ready.

Feature versions allow you to make your Great New Feature – the one you got to “start over” on – show up at several levels. The simplest way is by setting the version on an extension – for example, say you’ve built Version 1.0 of a task queue feature and you’ve written an extension for Version 2.0 that does much, much more. In this scenario, you would set the MinVersion value on the ‘task’ version to 1 and the MaxVersion to 1. Then you set the MinVersion for the next extension to 2.

When you set the value of the version to 2 your new extensions automatically kicks in. Simple, safe. You’ve just started over.

If you are lucky enough to be starting a new project then you really, really should take a good look at the NetQuarry Platform today. Contrary to the popular thinking of project managers and software architects, custom applications do NOT require custom infrastructure. Really. Spend a few minutes with us – talk to one of our customers. It’ll be short. We promise.

NetQuarry – Start Right.

I’ve been personally involved in an enterprise architecture project for a well funded valley company (it was J2EE, to be fair) that had 100 people (including QA, Docs, and a bunch of managers) working for 2 years to implement an enterprise application architecture. We spent nearly 40 million dollars (seriously) on development. I’ve spoken to CTOs at software companies (ISVs) who are solving this and have arrived at the conclusion that nobody knows exactly where to start.

Most people in my position would roughly agree with me, at least in principle, but most would have a hard time citing real examples of why this is so hard. So, here are some examples:

Simple example first – permissions.

When you build an application of any reasonable complexity, you will have to architect and implement a way to authenticate users, retrieve a set of profiles (groups), and restrict access to parts of an application based on who the user is and which profiles have been assigned to them. How could you accomplish this? There are a ton of ideas out there. There is an idea of a database directory that .NET will build for you in SQL Server. There is a decent way to hook in Microsoft Passport authentication. There is a user/password/reset password control. There is the “forms based authentication” that takes a real time investment to understand and once you do you wish you hadn’t. What doesn’t exist anywhere is a reasonable way to consume the information you get from your authenticated users.

What also doesn’t exist (and this is the important bit) is a way for you to declaratively hide a column in a grid based on which user just logged in. Hold on, I’m going to explain.

Say I have a column in my DataView grid (say a salary column) that I only want users with the Administration Profile to see. Further, I want to define this by checking a little box somewhere that says “Hide from general users, please.” Then, I want that information stored in some persistent format that allows me to check it into source control. Asking too much? You might say this is easy. All you have to do is… build a file that holds the data, or put the data in a database (this sort of discussion ends relationships), write a little tool that edits the file or just screw with it yourself, store this file in source code, add it to your installation script, build a tool to change it inside your application (which you need to secure as well), copy it to the server before you go live, … Crazy.

Another example  - filtering

The .NET Framework and Visual Studio, along with the competition (J2EE, and the slew of tools available here) has a way to take data out of a database and present it in a grid. Generally there is a way to handle sorting, paging, hiding columns, and, of course, applying some sort of theme. However, what if you want to filter the list in some way? Simple, right? All you do is build another set of controls on the form for each column that you want to use in your filter. Some of the columns are foreign keys to other tables, so you’ll want to build some sort of interface to deal with these. Many of your foreign keys are really just lookup values, so you’ll want a way to build a DropDownList control with these values in it. Next, you’ll have to take the result of a postback on this form, determine if it has to do with your filter controls, and construct some sort of SQL filter for your database and re-display your list. If your users want to be able to filter on multiple values, well, then, its a bit harder. You’ll need either a new interface, or you’ll have to handle filters like: “BETWEEN x AND y” or “This Month” or “>Today” or “=FRED” or “Starts With Fred” and likely a bunch of others.

The kicker – you have to do this with every grid. You’ll probably get clever and build a base class that reads information from the DataSource and builds some filtering capabilities. Once you’ve done this, you’ll think its pretty easy. Honestly, though, a full featured grid view with good filtering (forget about column wise permissions) is a bunch of work. Even if you are pretty good at this you’ll still have the problem of managing the thousands of foreign key lists. (Much more on this idea here.) And, each one is just a little different. So, you probably end up with a bunch of pages all with slightly different code in them to change the properties of the particular page you are working with. At least you can check these into source control.

Meaning?

Enterprise application development is hard, really hard. Any way you look at it, you absolutely must solve most of these problems, even if you solve them poorly. Generally this is done by giving your Highly Paid talent the title of Architect and asking them to guide you through this process. If you are smart you’ll get two of these smart folks, because one smart guy alone will always come up with dumb ideas. If he is working by himself then you’ll usually end up implementing some of these ideas. Loosely quoting Brian DePalma – “Every time you think up a perfect architecture there are 50 ways to screw it up. If you think of 25 of them, you’re a genius.”

The solution always looks about like this:

1. Hire 1 or 2 expensive people and let them think for 3-6 months.
2. Add a productive resource and start writing a low-level database access class library that wraps ADO.NET. or JDBC. This puts you 6-9 months into the project.
3. Add another productive resource and build a reasonable grid, detail view, and a simple navigation metaphor. You are at least 9 months into the task now.
4. Frantically add a bunch of not so productive (read, cheap) resources and tell them you are behind. Sometimes you send your application to India, China, or Iowa at this point.
5. Scramble for another 6 months or so until you begin slashing features as fast as you can.
6. Release your first version 18 months from the start of your project to resounding cries of disappointment and astonishment from your user base.

This isn’t just me talking. There are well known research reports from respected analysts that assure us that more enterprise projects fail than don’t. Below, from Software Magazine, a blurb on the Standish CHAOS report:

“The 10th edition of the annual CHAOS report from The Standish Group, which researches the reasons for IT project failure in the United States, indicates that project success rates have increased to 34 percent of all projects. That’s more than a 100-percent improvement from the success rate found in the first study in 1994.”

So, we’re getting better. Only 66% fail. I’m not suggesting that poor architecture implementation is the only reason projects fail. I’m betting that it isn’t even the leading direct cause. But I do know who gets blamed when the project doesn’t go correctly – the Highly Paid developers. And, I believe it isn’t necessary.

Why hasn’t this been solved?

I believe that eventually Microsoft will introduce enterprise infrastructure to the .NET Framework that solves a good chunk of this problem. What they have done so far is give us the Enterprise Library, which solves some real problems, but is still, as its name suggests, a library. You’ll still need an implementation of an architecture using this library before you can start your application. Why the Enterprise Library isn’t directly part of .NET is another question. I love this quote:

“Enterprise Library is a guidance offering, designed to be reused, customized, and extended. It is not a Microsoft product.”

So, why hasn’t Microsoft solved this yet? I think they don’t want to offend anyone. When one implements an architecture you have to make choices that will cause concern and questions from almost any of the consumers. Where is the application metadata stored – relational database or the file system? Is the object mapping strictly typed or not? What is the external access strategy – Web Services? What about authentication? Permissions? Data Permissions? Deployment? Testing? Localization? Internationalization?

The other reason there isn’t any cohesive strategy around an implementation of an enterprise architecture is because there are a lot of people that get paid a lot of money who are pretty interested in continuing to get paid to design and implement terrible applications. If I had a choice between a year getting paid $200 (or more) an hour or simply using an available solution, it would be a simple choice.

The other problem is that depending on the group of people you are talking to, many are convinced that this problem can be solved by using the right tools or selecting the correct grid control. Really. I’ve spoken to presumably smart people who have told me that the problem with enterprise development is simply management process. This is generally followed by a conversation with someone who knows that if you would simply get the requirements right nothing would go wrong. Next, I’ll speak to an Architect who has landed on a architecture that is, in its entirety, .NET. And, of course, you can throw a rock and hit someone who believes that the answer is UML. The worst, of course, is this: “we’re using SOA.”

I-got-a-good-idea

NetQuarry is an enterprise application platform (for Microsoft .NET). What this means is that we have a layer of runtime code that reads a definition of your application at runtime and produces an ISV quality web-based application. The definition includes references to code that you write (extensions), profiles you declare, schema that you design, and presentation that you build. Much of the definition is built using our tooling (NetQuarry Studio). When you write your code you use Visual Studio, we’re not in the IDE business. Read more here.

The important point to understand about NetQuarry is that it is both an architecture and an implementation of an architecture. It is also important to understand what it is not. It is not a code generator and it is most decidedly not a framework.

We also think that the real promise of NetQuarry isn’t simply an architecture with implementation, but rather what you might do with this implementation once it becomes generally available. The largest idea is the concept of application content. What I mean by this is the availability of functional application parts that can be deployed into a platform (like NetQuarry). Real application assembly. Salesforce.com has done something like this with AppExchange. I like AppExchange but of course I can’t see how I’d use this to create OptionEase, DiForza, or iLUXCARS. For these sorts of applications I have to build it myself. So, the content parts should be a bit less coupled with the application, which is hard, but possible, again, once we have a real implementation of a platform.

If you are interested in the NetQuarry platform or what you might be able to do with it please feel free to contact us: info@netquarry.com.

Ryan

The actual support of Visual Basic and Visual Studio 6.0 (in which VB 6.0 shipped) is over now. This sort of surprised me. I assumed that Microsoft would continue to support VB more or less forever, silly as that may sound. The actual dates for “support” are here: Visual Basic Product Lifecycle, and this says that real support ended 3/31/2005, and extended support will last until 4/8/2008.

I was a long time Visual Basic user — our last product used it as the extension language — and if I had a large VB 6.0 application, I would probably worry. I’m pretty sure that many VB 6.0 applications will continue to run. I’m also pretty sure that if they didn’t, and if they were mission critical, most enterprises would be able to find someone to tweak their application so that it would continue correctly.

What would worry me is less concrete. If you manage or develop an important product for a large enterprise and the language that the application was written in was out of official support, I’d start thinking that maybe it was time to think about a port. Why? If nothing else because anything large enough to worry about is likely to take until April of 2008 to get ported.

All of this is a somewhat shameless pitch for NetQuarry, of course. Actually, I don’t see how one would begin a reasonable port of a large Visual Basic application without at least the start of the infrastructure that we provide. Many of these applications are huge — e.g. 1000s of pages, tables, and complex rules. Most of the folks who built and probably deeply understand the application are off on other projects (presumably in a more modern language).

Works like this:

1. NetQuarry is installed. The core assemblies are in the <webroot>/bin folder.
2. The application needs some custom controls (mostly for wizard pages).
3. The application wants to reference another custom assembly. To do this, we copy the assembly to the /bin folder of the new project. We include the reference and we can use the code in the debugger.
4. The application’s new web project is installed and developed in a sub-folder of NetQuarry. (<webroot>/Apps/<myapp>).
5. The code compiles, but you can’t load any of the custom controls because it can’t resolve the type.
6. On most machines (I can’t tell you why this isn’t all machines) all you have to do is add a reference in the .ASCX page like this:
   <%@ Register TagPrefix=”myappref” Namespace=”MyApp.Common” Assembly=”MyApp.Common” %>
7. On other machines, you have to copy the referenced assembly to the root /bin folder.

Incidentally, I’ve tried the new Web Application Project model to solve this and failed as well. Scott Guthrie has a good post about it: Web Application Projects that you should read. The (really) good news about this new project model is that it compiles significantly faster. The bad news is that I have a similar reference problem when I try to create a web user control dynamically unless the assembly is copied to the <webroot>/bin folder.

So, why not just copy the sub-project .DLLs to the main /bin folder? Because I really don’t like it. In NetQuarry, sub-projects are loaded dynamically (a somewhat foreign concept to everything ASP, I know) and they don’t have a dependency on the main NetQuarry Web assembly. The idea is that one installs the core NetQuarry web, then builds their own web components (web user controls), references them as components using the NetQuarry Studio and uses them as PageElements to build wizards.

NetQuarry also loads extensions dynamically, which is exactly what we want to do with these web projects. So, I tried converting to the new Web Application Project model for sub-projects and loading the assemblies dynamically. Still didn’t work. Since these are web projects, you would think that the way to do this is in two steps: first, load the assembly, and second, load the user control via its virtual path. Once the assembly is loaded .NET should understand the types in the control but for some reason it doesn’t.

The idea behind NetQuarry is that you don’t have to know any of this stuff, but just so you know, the idea (that doesn’t work) is like this:

private IWizPage LoadWizardPage(NetQuarry.ComponentInfo ci)
{
    System.Reflection.Assembly asm = ci.LoadAssembly();
    return LoadControl(ci.Component) as IWizPage;
}

Where the ComponentInfo.LoadAssembly method is a little complex (and ommitted here for brevity). Basically, we try and find it in the list of loaded assemblies first, then in the specified path, then in <webroot>/bin, and finally in Apps/<appid>/bin.

Turns out that after you load the assembly, the component still doesn’t load. So we’re still discussing this. Perhaps I’ll break down and have custom projects deployed to the <approot>/bin folder, but I sort of doubt it. As ususal, it feels as if we’re the only ones solving this problem, but I did find this post from over a year ago (Dynamic LoadControl of ascx with dll not in bin path) and there is a response there (from a DevelopMentor staffer) that says: “ASP.NET mandates implicit loading of assemblies from ~/bin or the GAC. You can always call Assembly.LoadFrom, but I’m not sure if the LoadControl will work with that. It’s worth a try.”

I nearly refused to believe it, but after about 2 bad days on this, I’m convinced. Love to know why, Microsoft, anyone?

For now, we are leaving it alone and leaving the hacky @Register business in place.

We did, however, convert our main project (EAP.WebHost) into the new model and boy oh boy is it better.

Normally, you solve the problem by creating a 2 column table with a key and some descriptive text. For example, say you wanted to have a status table:

Table: status

You might get a stab of reusability and conclude that a good idea is to store these sorts of things in a table that has a type and therefore keep yourself from having to create 300 of these tables in your database. So, the table might look like this:

Reusable design: picklist

Now, all you have to do is change the SELECT statement and you can have one table to handle most everything. Next, you bump into a requirement where you have to store something besides and integer as the key (say, its data that you didn’t own and the key is some cryptic string). No problem, you just add another column to this list with an alternate ID (or another table, I suppose) and indicate that somehow.

2^nd try: picklist

Next, you decide that some of the items in this list are required to be shown, but you don’t want the user to select them. So you add another column to the table and indicate which items are disabled.

3^rd try: picklist

At this point you’ve thought of several more interesting requirements so your table design ends up with several more columns to support these:

• Localization. If you plan to support a multi-lingual application you are very likely to need to have your vocabulary displayed in the user’s culture.
• Readable string as a way to lookup an ID. The common case for this is when you want either to set a default value in a field but do not want to hard code some opaque primary key values in your code or you want to take some action based on the value that a user chooses and you don’t want to hardcode the primary key value.
• Caching (or not) the items in the list. If you are going to model this, you’ve likely decided that you need to metadata tables – Picklist (for the name of the list and some attributes like “cache”), and PicklistItems (for the actual items).
• Discrimination. Often you’ll have a requirement where the value in one column filters (or discriminates) the potential values in another. For example, you may have a list of vehicle make types in one list and based on the selection, you need to show the available models in another. The typical way to solve this is to take the value from the first control, post the results to the server, dynamically determine the new SELECT statement, and return the page with the second control filtered.
• Two-way lookup. Often you have the value of the item’s key only and you need to find the text, but we have found that you just a frequently need to do the reverse (e.g. you have the text and you want the key). We use the reverse lookup, for example, when searching or filtering in a list – the user enters “Open” and we search for “1.”

The next issue you solve is how to fill the controls with the contents of these lists. The most straightforward method is to write code to open a DataReader with a statement like (SELECT id, description FROM picklist WHERE list_type = ‘status’) and add these items to a DropDownList control like this:

while (dr.Read())
{
    listControl.Items.Add(new ListItem (dr.GetString(0), dr.GetInt32(1)));
}

Or, a better way is to bind using the DataBinding features of the DropDownList– something along these lines:

DataTable dt = CreateTableFromPickListSQL();
dropList.DataSource = dt;
dropList.DataTextField = “id”;
dropList.DataValueField = “description”;
dropList.DataBind();

In both cases, you are responsible for creating either the DataReader or DataTable and properly disposing of it. Most folks know how to do this, or at least they know how to cut and paste some code somewhere that does it reasonably well. It’s still a pain and generally isn’t written in such a way to promote even moderate reusability.

Another consideration is that you may need to use one of these lists for something other than as a DataSource for a DropDownList control. For example, if you are displaying a table of data that has several columns which are foreign keys to your picklist table you either must create some sort of view to resolve these or do a lookup as you fill the list (this is almost never an option for performance reasons). The trouble with the view is that unless you strictly enforce the integrity of your data you are likely to lose some rows because the values in your main table have foreign key values that are invalid.

There are a bunch of other factors, of course, which is why there is a dedicated object to solve this problem. Again, a Picklist represents a domain specific list of values that can be used to translate the key of an item (typically a foreign key in a database table) to a description.

In the NetQuarry Platform, Picklists are of one of three distinct types:

• A “standard” Picklist. This type of list is loaded from the metadata and supports the descriptive text in the current user’s culture (language). We use a pattern similar to the one just described to model this. (Picklist, PicklistItems (with a foreign key to a “Text” table to support localization))
• A “SQL” Picklist. This type of list is loaded from one of the databases (can be the “main” operational database or the repository) and can contain 1 to 3 columns of data.
• An “Enumeration” Picklist. This list is a 2 column Picklist loaded from a string type name that represents an Enumeration as its source. (The NetQuarry Studio makes good use of this.)
• For the most part, Picklists tend to have the LimitToList attribute set. This attribute says that the item selected by the user MUST be one of the items in this list. There are several other attributes of interest as well, listed here and briefly explained:

Read the full White Paper.