Common Knowledge

Adding the Full Name Property to User Lists

2011-10-04T14:50:00.000-07:00

My earlier post about linking data to the LightSwitch user list has turned out to me my most popular yet. In fact, I've actually used this technique for the 2nd time in project and wound up using my own blog as a reference implementation! In my latest project I added feature that will probably prove useful to anyone using this technique: the addition of the Full Name property. This is a profile property that LightSwitch adds to users in the membership provider that is not part of the standard user properties.

Adding the Full Name property is pretty easy. First, of course, you have to add a FullName property to the Data Transfer Object (DTO):

public class User
    {
        [Key]
        public Guid UserId { get; set; }

        public string UserName { get; set; }

        public string FullName { get; set; }
    }

Next, we have to populate the FullName value from the profile properties. This part involves working with the ASP.Net Profile interface, which is more obscure that the main Membership interface:

var userList = Membership.GetAllUsers();

    foreach (MembershipUser user in userList)
    {
        var returnUser = new User 
        { 
            UserId = (Guid)user.ProviderUserKey, 
            UserName = user.UserName 
        };

        //create a profile object to query
        var profile = ProfileBase.Create(user.UserName);

        //look up the LightSwitch FullName property in the profile
        returnUser.FullName = profile.GetPropertyValue("FullName").ToString();

        returnValue.Add(returnUser);
    }

In order to understand how this code fits in with the overall service, please refer to my earlier post.

Adding the FullName property will allow you to display the full user name that you entered using the LightSwitch user manager, so you won't have to remember user names to identify users of your application.

A Spoonful of Syntactic Sugar

2011-09-09T13:10:00.000-07:00

One of the reasons I love developing with C# is the ease with which you can extend the language using facilities like generics, extension methods, and lambda expressions. As an old C++ coder, I feel very comfortable with a bizarre level of language extensiblity. Here's an example of what I'm talking about:

I was writing a library that scans an XML element tree, and I kept having the need to cast down from an XMLNode to an XMLElement. Naturally, to avoid runtime errors, I had to check the cast for success. The code looked something like this:

    foreach (var node in parentElement.ChildNodes)
    {
        var element = node as XmlElement;

        if (element != null)
        {
            ProcessElement(element);
        }
    }

After a while, this got pretty tiresome. I even started omitting the check for success out of fatigue, which of course led to run-time errors. Something had to be done! Fortunately C# provided a way to address this problem. I created the following extension method:

    public static class ExecByType
    {
        public delegate void DoOp<T>(T t);

        public static void IfType<T>(this T t, DoOp<T> d)
        {
            if(t != null)
            {
                d(t);
            }
        }
    }

This allowed me to change the code to something like this:

foreach (var node in parentElement.ChildNodes)
    {
        (node as XmlElement).IfType(e => ProcessElement(e));
    }

Which not only prevented errors, it also looks kind of exciting, so it's helping keep me awake while I finish my XML processing routines.

Adding Passwords to a WCF Service

2011-08-31T14:38:00.000-07:00

I recently set up a WCF service that required password protection, with user accounts and passwords synchronized with an ASP.NET site using the standard ASP.NET Membership provider. I found several books and a number of blogs that gave helpful examples, but ultimately I felt that I never found the one, single, go-to example that just focused on the topic of adding username and password support in WCF. So this is my humble attempt at a stripped down, laser focused tutorial on the subject.

Prerequisites

Here is a prioritized checklist for your implementation:

Understand that you will need SSL. WCF will not allow you to add username/password authentication to a service unless it is encrypted at the transport layer; this means that you must use the HTTPS protocol and you must obtain an SSL certificate. For those of you who are students or cheapskates, it is possible to generate a self signed SSL certificate. If you're a professional developer with control of your own DNS domain, I recommend that you think about just getting a real trusted certificate for your test server. Given the low cost of a certificate from a trusted authority, this can wind up saving time and therefore money in the long run. In any case, don't even think about proceeding until you've taken care of this issue.
Use the basicHttpBinding. The default binding for a WCF service application in Visual Studio is the wsHttpBinding. If you use the ws binding and add passwords, you get a session based protocol in which the client and server first negotiate a shared secret, then use the shared secret to sign all subsequent messages. This is a triumph of technology and generally not a problem if you can be absolutely sure that only .NET programmers will access your service. However, the minute a PHP, Rails, Java, or Phython team tries to work with your service you'll get an earful: it can be very challenging to set up session based WS authentication with these frameworks. On the other hand, if you use the basic binding, you'll get stateless authentication that behaves much closer to expectations and is much easier to implement on other platforms.
Make sure you understand how the ASP.NET membership service is configured. Both the membership and role providers should have configuration elements in your web.config file (don't rely on the default configuration). Take note of the applicationName configuration attribute and its function (short story: it is possible for multiple user name directories to coexist in the same database using different application names). The main point is: if you want your service to synchronize with a website, but the service is not directly a part of that website, you must make sure that both the membership connection string and the application names match.

Now that we've got the preliminaries out of the way, all we need is the configuration file, right? After all, can't all WCF issues be solved in the configuration file? With that in mind, I've prepared a stripped down configuration that contains only what you need to enable the ASP.NET membership passwords for a WCF service:

<?xml version="1.0"?>

<configuration>

  <connectionStrings>

    <add name="YOUR_CONNECTION_STRING"

         connectionString="ToDo: put a valid connection string here" />

  </connectionStrings>

  <system.web>

    <compilation debug="true" targetFramework="4.0" />

    <!-- this is the standard role and membership configuration

        that might already be present in your web.config if

        the local ASP.NET site is using the membership

        framework for page access-->

    <roleManager defaultProvider="AspNetRoleProvider" 

                 enabled="true">

      <providers>

        <clear />

        <add name="AspNetRoleProvider"

             type="System.Web.Security.SqlRoleProvider"

             connectionStringName="YOUR_CONNECTION_STRING"

             applicationName="YOUR_APPLICATION_NAME" />

      </providers>

    </roleManager>

    <membership defaultProvider="AspNetMembershipProvider">

      <providers>

        <clear />

        <add name="AspNetMembershipProvider"

             type="System.Web.Security.SqlMembershipProvider"

             connectionStringName="YOUR_CONNECTION_STRING"

             applicationName="YOUR_APPLICATION_NAME" />

      </providers>

    </membership>

  </system.web>

  <system.serviceModel>

    <behaviors>

      <serviceBehaviors>

        <behavior>

          <!-- no need for http get;

              but https get exposes endpoint over SSL/TLS-->

          <serviceMetadata httpGetEnabled="false" httpsGetEnabled="true"/>

          <!-- the authorization and credentials elements tie

            this behavior (defined as the default behavior) to

            the ASP.NET membership framework-->

          <serviceAuthorization

              principalPermissionMode="UseAspNetRoles"

              roleProviderName="AspNetRoleProvider" />

          <serviceCredentials>

            <userNameAuthentication

                userNamePasswordValidationMode="MembershipProvider"

                membershipProviderName="AspNetMembershipProvider" />

          </serviceCredentials>

        </behavior>

      </serviceBehaviors>

    </behaviors>

    <bindings>

      <!-- this binding configuration stipulates that a

          user name and password are required-->

      <basicHttpBinding>

        <binding>

          <security mode="TransportWithMessageCredential">

            <message clientCredentialType="UserName"/>

          </security>

        </binding>

      </basicHttpBinding>

    </bindings>

    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />

    <services>

      <!-- in this very simple example we're relying on default 

        binding configuration, behavior, and endpoints-->

      <service name="YOUR_NAMESPACE.YOUR_SERVICE">

        <endpoint binding="basicHttpBinding" 

                  contract="YOUR_NAMESPACE.I_YOUR_SERVICE" />

      </service>

    </services>

  </system.serviceModel>

</configuration>

There's lot's more to say about this topic, including how to use role assignments to authorize service access, but hopefully this will be enough to get you started.

Linking LightSwitch Data to Logged in Users

2011-08-03T18:20:00.000-07:00

Note: if you like this post be sure to take a look at my October 4th post that contains an enhancement to this technique.

In my presentation LightSwitch in Context (which I will be presenting on Wednesday, September 28 at the Bay Area Database Developers .NET User Group) I demonstrate how LightSwitch can be used to create an administrative interface for a public facing website. In one part of the demo, I create a RIA service that can be used to query for a list of users from the .NET Membership service. I am starting to realize that this little trick can be quite handy, and I've already used in a paying project for a client. It is also a good demonstration of how easy it is to create a RIA service for a read-only data source that is outside of the normal scope of your application. RIA services can be intimidating, but if you know the right steps to follow they can be blown out in a few minutes using Visual Studio templates.

Here's how to create a RIA service that allows access to the current list of users in your application. Note that this only works if your using Forms authentication, i.e. the ASP.NET Membership provider. If you are using Windows authentication, you can do something similar but you'll have to replace the Membership code with calls to Active Directory. Also, this requires the full (Professional or better) version of Visual Studio; you can't create data extensions like this with the standard edition of LightSwitch.

Step 1: Add a WCF RIA Services Class Library to your project

With your LightSwitch application is open in Visual Studio, right-click the Solution icon and select Add->New Project... from the context menu. This will bring up the New Project dialog. Select template type Silverlight, then WCF RIA Service Class Library:

You can see that I'm calling my project UserDataService. After you add the project, you will see that template adds not one but two projects to your solution. One will be called UserDataService and one will be called UserDataService.Web. Since this blog is not discussing the fine points of RIA Services, the only thing you need to know is that you can ignore the UserDataService project completely, we'll be working only with UserDataService.Web.

Step 2: Add Membership Provider Assemblies

By default a RIA Services library doesn't have references to the library that implement the ASP.NET membership services. So you'll need to add the following references to the UserDataService.Web project:

System.Web
System.Web.ApplicationServices

Step 3: Define Your User Entity

In order to send a user list back to LightSwitch as a table, you'll need to define a Data Transfer Object (DTO) that will hold data about an individual user. The properties of the DTO will depend on what properties of the user you are interested in. In this example, we're sticking just to the login name:

using System.ComponentModel.DataAnnotations;

namespace UserDataService.Web
{
    public class User
    {
        [Key]
        public Guid UserId { get; set; }

        public string UserName { get; set; }
    }
}

Note that we are including the Guid that is used by the Membership framework to uniquely identify users and marking this as the key to the entity. In general, you will always want to define a key for your DTOs.

Step 4: Create The Service

Now it's time to create the service itself. Right-click the UserDataService.Web icon and select Add->New Item.. from the context menu. In the Add New Item dialog, select template type Web, and Domain Service Class template:

In this screenshot, I'm calling my class UserService, however in the example below, I'm using UserData as a class name. Now we get to the fun part, where we actually have to write some code:

using System.Web.Security;

public class UserData : DomainService
{
    [Query(IsDefault = true)]
    public IQueryable<User> GetUsers()
    {
        var returnValue = new List<User>();

#if DEBUG
        returnValue.Add(new User 
        {
            UserId = new Guid("{1F43C32F-D6E3-4CCE-A4A0-7BB9D7572C07}"), 
            UserName = "Tom"
        });

        returnValue.Add(new User 
        {
            UserId = new Guid("{F4D71F57-2CD1-4C60-B9BE-FA2529A9EE2D}"), 
            UserName = "Dick"
        });
        returnValue.Add(new User 
        {
            UserId = new Guid("{8FF1E47C-BA41-4586-8D23-A3079850FDAA}"), 
            UserName = "Harry"
        });
#else
        var userList = Membership.GetAllUsers();

        foreach (MembershipUser user in userList)
        {
            returnValue.Add(new User 
            { 
                UserId = (Guid)user.ProviderUserKey, 
                UserName = user.UserName 
            });
        }
#endif

        return returnValue.AsQueryable();
    }
}

Here are a couple of things to note:

The Query attribute marks this method as an RIA service method that returns a queryable entity container.
The basic structure of the code, in which you return a list of entities that you want to appear as a table, is extremely simple. You can use this same technique for any kind of data that you want to return as a read-only list.
I've put a DEBUG condition in to populate my list with pretend users. This is important because LightSwitch in debug mode, with Forms authentication enabled, will have a valid Membership provider but won't have any actual users.

Step 5: Add the Service to LightSwitch

After you've rebuild your solution to set up the data service (important!), you are ready to add the service as a data source. Right-click on the Data Sources folder in LightSwitch, and select Add Data Source from the context menu. Then, select WCF RIA Service, click Next, then Add Reference, then select the Project tab. You want to add a reference to UserDataService.Web. Then you will be able to select your entity call User. This is a lot of wizard screens, but it goes pretty fast if you've set everthing up according to the instructions above. When you are done, a Users table will appear in LightSwitch, which looks something like this:

Step 6: Link the User Data to LightSwitch tables

Now that the Users table exists in LightSwitch, you can link other tables from your main data source. This is slightly different that creating a relationship within the main data source, because you have to create a foreign key in the linked table yourself. Recall that we're using a Guid as a key, so we'll want the foreign key to also be a Guid. In this example I'm linking to the SalesPersons table, so I want to create a new column call Login in SalesPersons of type Guid. Here's what the relationship dialog looks like when the relationship is set:

Now that you've got the data linked, the RIA service data can be used just like any other LightSwitch data. This screen shot shows the selector that is automatically generated for you when the User link is formatted as an Auto Complete Box:

Hopefully this simple example will get you started with RIA Services extensions. They're not as bad as they look, and when you need 'em, you need 'em.

Transferring a Database to SQL Azure: The Magic Handshake

2011-04-22T16:40:00.000-07:00

Update 8/30/2011: I'm leaving this post as-is for reference; however please be aware that the best way to transfer a database to SQL Azure is to use the SQL Azure Migration Wizard

Transferring an existing SQL Server database to SQL Azure can be very easy if you know the right tools and one essential configuration detail, or what I like to call, "the magic handshake." SQL Azure is still near the bleeding edge, and if you get some bad advice you could spend hours on this. Here's a quick rundown on how to do it the easy way.

The Magic Handshake

There are several ways to get your database up to a SQL Azure instance, but the most painless is the SQL Import and Export Wizard. However, if you don't know the magic handshake, your experience goes something like this:

You start up the Import and Export Wizard, either from the start menu or from SQL Management Studio. You make sure to use the SQL Server 2008 R2 version, because you know that plain old SQL Server 2008 can't talk to Azure.
You set your source data to the database you want to export to Azure.
When setting your destination, for some reason you can't log in to your Azure instance. Undaunted, you do some quick Googling (with Bing, of course) and find out that you have to include the full name to your server in your user name, e.g. Bullwinkle@reallyweirdname.database.windows.net. With that change you actually log in. And you can select the target Azure database! The excitement is building now! With a tremendous sense of anticipation, you click Next.
Boom! you're out of luck:

The wizard says it, "cannot get the supported data types from the database connection," and that, "the stored procedure required to complete this operation could not be found on the server." But what it should have said is, "you didn't give me the magic handshake."

So what is the magic handshake? It happens back at step 2. You have to select .Net Framework Data Provider for SqlServer for your destination. This will give you a distinctly non-wizard like settings screen:

Does this look like a wizard to you?

But it's pretty simple: just fill out the Data Source, Initial Catalog, User ID, and Password the same as you would in a connection string. Also, you can use the simple User ID without the @server suffix. Click Next again and you're off to the races!

Azure Compatibility

If your database is simple enough, you may not need to make any changes to your schema. In fact, I would recommend that unless you know you're schema is too clever, go ahead and grind through the Import and Export Wizard steps I've outlined above. If you have any Azure computability problems, you'll get detailed error messages from the wizard.

If you do get errors, then you won't be able to let the wizard create your tables for you. That means you'll have to script the database schema first and correct the errors that were mentioned in the import error dialog. For example, Azure doesn't like tables that don't have any clustered indexes defined. To fix this, just change the primary key on each table from non-clustered to clustered, run the creation scrip in your Azure DB, then run the Import/Export wizard. It will pick up on the existing tables and use them instead of trying to create new tables for the import.

I decided to write a post on this because there doesn't seem to be a lot of good information available on migrating SQL Server databases to Azure. Now that I've been through the process, it seems very simple. That is, once I learned the magic handshake.

The Incredible Lightness of ELMAH

2011-01-30T22:37:00.000-08:00

I recently gave a lightning talk at the San Francisco Bay.NET User Group meeting on ELMAH (Error Logging Modules and Handlers). This was a great opportunity to learn about this tool, which was originally developed by Scott Mitchell and Atif Aziz as sample code for an MSDN article. Since the initial release in 2004, Atif Aziz has been continuing development and maintenance on ELMAH as a community open source project.

I've been aware of ELMAH for some time, but I hadn't gotten around to really looking at it; I'm very glad that the Mathias Brandewinder, the Bay.NET Chapter Leader for San Francisco, asked me to give the lighting talk. It gave me a chance to roll up my sleeves and get to know this great resource for ASP.NET development.

ELMAH is a good topic for a quick demonstration, because the setup is so easy. All you need to set up an error log is to download ELMAH, put the ELMAH dll in the bin folder of your site, and make a few additions to your web config file. One line must be added to the httpHandlers section:

<httpHandlers>
<add verb="POST,GET,HEAD"
path="elmah.axd"

    type="Elmah.ErrorLogPageFactory, Elmah" />
</httpHandlers>

and one to the httpModules section:

<httpModules>
    <add name="ErrorLog" 
    type="Elmah.ErrorLogModule, Elmah" />
</httpModules>

If you're running IIS 7, you'll have to also make module and handler entries in the system.webServer section:

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

    </modules>
    <handlers>

    </handlers>
</system.webServer>

The amazing thing about ELMAH is that once you make these changes, you'll have a fully functional error log. You get to the error log by entering the path to your handler (I've just left the handler path at the default "elmah.axd" in the examples above). Here's what you see:

This example contains only a single error, but as you can see the display accommodates multiple errors with paging options. Clicking on the details tab shows a stack trace, error details, and a full dump of the HTTP request attributes.

The only other essential item in setting up a basic ELMAH installation is to set up a data store for errors. The display shown above is using the in-memory log, which means errors will be lost when the server is reset. Adding a data store means that error will persist after a reboot. ELMAH supports multiple database platforms; I set mine up with SQL server, which looks something like this:


<configSections>
    <sectionGroup name="elmah">

    </sectionGroup>
</configSections>

<elmah>
    <errorLog type="Elmah.SqlErrorLog, Elmah"

connectionString="Data Source=YourDatabaseServer;Initial Catalog=YourDatabase;Trusted_Connection=True" />

 </elmah>

There are many more capabilities of ELMAH, including email notification and error filtering. You can learn about them at the official project site. It is a good idea to look at the security setup information on the project site to make sure your error handler is secure.

What I Learned

I have my own philosophy about error handling architectures which I've developed over many projects, but working with ELMAH showed me a new approach. Instead of requiring conformance to a particular error handling and reporting strategy in code, ELMAH treats error handling as a cross-cutting concern and handles errors transparently. This means there is no requirement to build error handling into your code at all, making the code more portable and eliminating any problems with inconsistent implementation. For more on this topic, I encourage you to read the original MSDN article for which ELMAH was created.

The Mystery of mscorlib

2010-10-29T13:20:00.000-07:00

I had an interesting problem recently while converting a Visual Studio 2008 project to Visual Studio 2010. This was a solution that included a website project and a number of library projects (side note: I don't recommend website projects, try web application projects instead). The website project and all of the library projects targeted the .NET 3.5 framework. The Reason I was converting this project was just to use the new features of VS 2010; I didn't want to go through a full conversion of the project to .NET 4.0 because that would have meant testing and deployment time I didn't have. So when the framework warning dialog appeared:

I clicked, "No." So far so good.

But now I had a problem. When I rebuilt the project, I saw the following error:


The primary reference  could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "4.0.0.0" than the version "2.0.0.0" in the current target framework.

Huh? I understand that it's not a good idea to mix 2.0 and 4.0 assemblies, but I hadn't asked for any links to the 4.0 runtime. The reference to version 2.0 is confusing, until you reflect on the fact that a project targeting 3.5 is actually using version 2.0 of the core framework. That's why it's so easy to upgrade project from 2.0 to 3.5. But where did the .NET 4.0 reference come from? A little more investigation revealed that reference was embedded in just 1 of the library projects. I was able to build this project successfully, but when I did I got some strange errors, such as:


Warning 5 The predefined type 'System.Action' is defined in multiple assemblies in the global alias; using definition from 'c:\Windows\Microsoft.NET\Framework\v4.0.30319\mscorlib.dll'

So it looked like the 4.0 library was being used, but why, and why wasn't I able to see this anywhere in the project configuration information? The property pages for the project showed that it was targeting framework version 3.5. When I looked at the assembly references for the project, I couldn't see any reference to mscorlib, either 2.0 or 4.0:

This got me thinking: I knew that mscorlib is the assembly that contains the core implementation of the .NET framework, so why don't we see it in the Visual Studio reference list? Apparently the VS team thinks it's none of our business. Fortunately we don't have to be limited by this restriction - I loaded up Redgate Reflector and found the complete list of references for this assembly:

Now we're getting somewhere! We can see both mscorlib references and we can see that one reference is to the 4.0 version of .NET. Comparing this display to the Visual Studio version, we can see that VS represents the mscorlib assembly with logical references that don't exactly match the assembly references. Is this a good thing? I would say no. My view is: when you are looking at the reference list, you really are looking for assemblies, not logical namespaces. Also, obscuring the mscorlib assembly in the reference list is not consistent with the way other assemblies are displayed.

Back to our problem: how do we eliminate this phantom 4.0 reference? For the solution I relied on my old friend Subversion version control. I ran a diff on the projects that converted successfully and compared those to a diff on the project with the .NET 4.0 reference. It turned out that the library with the .NET 4.0 reference had been completely skipped during the upgrade process for some reason. I was able to fix the problem by merging the diffs from the successfully converted files into the problem project by hand. I found that the key problem was at the top of the project file. I replaced this heading:


<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="2.0">

with this heading:


<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="4.0">

And added this section to the PropertyGroup element:


<oldtoolsversion>2.0</oldtoolsversion>
<upgradebackuplocation>
</upgradebackuplocation>

There were also some discrepancies with assembly references, but I found that when I merged the entries shown above the assembly references took care of themselves with a rebuild, and the rogue reference to mscorlib version 4.0 had been purged.

So I learned something about mscorlib, and as is so often the case the learning experience involved some frustration. The account in this blog post omits many of the detours I took while investigating this problem. I hope posting my results here I might save others from spending too much time on this. Remember: ignore mscorlib at your peril!

Is Custom Development OK Again?

2010-04-29T10:13:00.000-07:00

I was very interested to see Mike Jones’s article in Dr. Dobbs about the current state of custom software development. Here are my thoughts on the subject:

During the 1990's there was an irrational commitment to custom development as a strategic asset. Due to the state of development platforms at the time and very high expectations, many projects failed to deliver on the promise of business value and of course most failed to stay on budget (we're talking software, after all).

Around the turn of the century, there was a sea change and since then we've been living with the backlash against past excess: over the last decade there has been an irrational aversion to custom development at all levels. Ironically, advances in methodology (primarily Agile) and also the maturity of development platforms and technology stacks has led to a dramatic increases in the productivity and effectiveness of custom development teams. The $1 million custom project of 1998 now cost $30K, and, unlike 1998, it actually works!

What I would like to see is a balance assessment of custom development’s potential. If we can achieve this, I think we'll see an important role for custom work going forward.

Secure automatic updates

2010-02-25T09:45:00.000-08:00

Over the last month or so, I've update the Flash player on several of my workstations several times. Each time I do this, there's one little detail that gets my goat: the executable file that actually does the updating isn't digitally signed. Here's how the Flash updates sequence plays out:

The Flash update warning appears automatically when I log in. I try to distrust everything that happens; how do I know this is really a Flash update? But I figure, let's see where this goes.
I get a UAC flash. I know that some people don't like UAC, but I love it. I want to know when an application starts messing with my system settings.
The UAC warning is telling me that there's an app call "flashupdate2.exe" that's trying to change my system settings.
Here's the problem: flashupdate2.exe isn't digitally signed. That means there's no way to verify what it really is and where it came from.

At this point I have a choice: either don't update my Flash player, leaving me vulnerable to known attacks, or bet that the application that says it's a Flash updater really is a Flash updater and not a malware trojan.

Oh, that's right. There is a 3rd alternative: uninstall Flash until Adobe decides to exercise some common sense and sign their application updates for the benefit of everyone's security.

Mea Culpa

2009-11-29T11:12:00.000-08:00

I've spend the last year completing a major update of the Cook! SF web site. In the process I've had to come to grips with my fear of Javascript and I've become much more aware of the amazing things that are being done using web standards based presentation. So perhaps I've greatly exaggerated the death of HTML.

The lesson I'm taking from this is not just that HTML is not in any way doomed, but more importantly that the Internet never has been, and never will be, just one thing. So Flash will continue to be increase in popularity, Silverlight adoption will proceed apace, and so will mobile platforms and everything else, including plain old HTML and Javascript.

Please disregard that last post.

AJAX and the Pony Express

2009-01-11T21:46:00.001-08:00

I sometimes teach classes at AcademyX, and by luck the San Francisco campus of AcademyX is located within walking distance of my office on Market St. On my way to class, I often pass a collection of commemorative placards that mark the site of the old western terminus of the Pony Express on Clay St. between Kearny and Montgomery. Many people have heard of the Pony Express: a heroic enterprise in which mail pouches where carried over the Rocky Mountain West in a tightly scripted relay of horses and riders. Deliveries could make it from Missouri to California in just 10 days, which a very good time for horse and rider.

One surprising fact about the Pony Express is that it lasted less than a year as a going concern. But Pony Express couriers are still galloping through the American imagination; even today the Pony Express emblem is used by the U.S. Post office.

It was technology that killed the Pony Express: the service was discontinued shortly after completion of the transcontinental telegraph. This is a familiar story to those of us who've been following digital technology for very long. Ingenuity, planning, and perspiration won't make the grade if you're competing against a superior platform. With just a flick of the wrist, a telegraph operator could beat a team of Pony Express riders and their carefully build infrastructure of relay stations. This got me thinking: could it be that Asynchronous JavaScript And XML (a.k.a. AJAX) will face the same fate as the Pony Express?

The role of the transcontinental telegraph in this story will be played by Rich Internet Applications (RIAs). RIAs have actually been around since before AJAX, but they have been slow to catch on compared to the wildfire acceptance of AJAX among web developers. But there can be no doubt that RIAs are catching on. Flex has clearly had blockbuster success recently, and both Silverlight and JavaFX are waiting in the wings.

Now that AJAX interfaces are common on the web, the limitations of this architecture are becoming clear. It's common for AJAX pages to become unresponsive when something goes wrong with a script based postback. Error handling is a problem; most browsers have JavaScript error reporting turned off by default because errors are so frequent. Last year I was blown away and frankly shocked by Alan Holub's presentation about the security problems associated with AJAX. Most importantly, from a developer's perspective, AJAX can be a lot of work. Of course there are frameworks that make simple and common effects easy to achieve. But frameworks require debugging and customization: ultimately there's no escape from the complexity of the architecture.

Ultimately the advantage of an RIA platform is simplicity. An RIA application is what it is: a stateful, sandboxed, and media rich application that can be scripted to respond to user interaction. In fact, we can drop the "scripting", RIAs run compiled code, just like a decent programming environment. An AJAX web application only appears to be these things. There is no simplicity, even in the simplest AJAX enabled page.

As a programmer, what would you rather do: spend a few hours in a single development environment putting together an application with data binding, full user interaction, and some neat animations, or spend several days making an AJAX-enabled web page behave as if it were an RIA? If you chose the AJAX path, you might just be as heroic as the Pony Express rider of old, doing the impossible with stout ponies, wits, and willpower. No doubt you'll have some adventures along the way. When you get to town, you'll find me a the telegraph office.

Adaptive Connection Strings for Windows Forms Applications

2008-11-10T23:17:00.001-08:00

As a developer working with small businesses, I do a lot of Windows Forms based development. One of the great things about this platform is the ease of deployment. A traditional installation program can be created in a matter of minutes. Better yet, with one-click deployment it's easy to update a client's machine at a remote location with the touch of a button.

In a small-scale custom development context, it's very common that simple updates are urgently needed. This could be because of an undiscovered bug, but more commonly it is the result of an unknown or poorly understood business rule that emerges at the worst possible moment. For example, during invoicing it is discovered that no one told the developer about new discount rules. In this scenario a simple fix at the code level is usually possible, and extensive acceptance testing is counterproductive. This is where quick and easy deployment makes everyone's life easier.

But there is one fly in the deployment ointment: the database connection string for the production environment is always different than the development environment. That means that the last step in any deployment is resetting the database connection string. There are several problems with this, including:

If you forget to change the connection or make a mistake in resetting the string, your already cranky client gets an immediate connection error after the deployment.
There's no obvious automatic way to make sure you don't make a mistake when you reset the string.
There's no way to test within the development environment to make sure you've got the production connection right. If you develop this way, every build you deploy is in fact an untested build, because it can't run successfully in the development testing environment.

What we really need is an application feature that will manage the connection string for us, that will make sure the correct connection string is always used. It must be possible to set up the connection configuration once, test it in all environments, and then leave it alone. This would allow us to deploy our changes without any changes to the connection string. The feature should be valid for both application assemblies and DLLs that are deployed as components. I call this feature, "Adaptive Connection Strings" and the rest of this post describes how to make it happen.

Getting Control of the Connection String

Almost all useful business applications have at least one database connection. Whether you're using hand-coded ADO.NET Connection objects, table adapters, LINQ to SQL, or the ADO.NET Entity Framework to connect to your database, the most convenient and flexible option for managing database connection strings is to create connection string setting in the application settings class. Visual Studio designers do this for you when you choose the save this connection option. But application settings of type connection string are always application level read-only properties, so it is not possible to build run-time logic to modify them.

But are connection string properties really read only? Let's take a quick look at a connection string property definition in the Settings.Designer.cs class:

        public string MyAppConnectionString {        
    get {         
        return ((string)(this["MyAppConnectionString"]));         
    }         
}

You can see that the property is clearly defined as read only. But you can also see that the connection string property is really just an alias for a call to a indexer defined by the settings class. The indexer used here is defined in System.Configuration.ApplicationSettingsBase to provide a reference to the Properties member collection. It turns out that all application settings are accessible in read/write mode by using this indexer directly. The following code demonstrates how to modify the connection string using this approach:

//change the application connection string Properties.Settings.Default["MyAppConnectionString"] = strCnString; //debug:verify that this really did work Console.WriteLine(Properties.Settings.Default.MyAppConnectionString);

So we can set up the connection string at run time, as long as we have an effective place to put this code. For example, we could put this in the constructor of the main form of an application. But how do we determine which connection string to use?

Finding the Right Connection

The whole point of this technique is to make the connection adaptive; we want the application database connection to automatically adapt based on the context in which it is running. This can be done in a number of different ways, but in most cases you will find the Environment class very helpful. The static instance of this class can be used to collect information about the host of the current process. I usually use the MachineName property to identify development workstations. The code looks something like this:

string ServerName; string DatabaseName; switch (System.Environment.MachineName) { case "DEV1": case "DEV2": ServerName = @"DEV\SQL2008"; DatabaseName = "Test"; break; default: ServerName = @"CONTOSO\BIGBOY"; DatabaseName = "Production"; break; } System.Data.SqlClient.SqlConnectionStringBuilder bld = new System.Data.SqlClient.SqlConnectionStringBuilder(); bld.DataSource = ServerName; bld.InitialCatalog = DatabaseName; bld.IntegratedSecurity = true; Properties.Settings.Default["MyAppConnectionString"] = bld.ConnectionString;

This approach works well in small scale settings when you can be sure that there won't be duplicate machine names in different domains. For a more scalable approach, you can also parse the domain name from the UserDomainName property of the static Environment instance.

At this point we're in pretty good shape. We have a way to control the connection string at runtime, and we have a programmatic method to determine which connection string to use. But that still leaves one important issue: we don't have a standard way to include this code in our projects that will guarantee the connection will be initialized before any data components are constructed. For example, if we are building a DLL that exposes multiple public methods, there is no single entry point at which we can perform the initialization. Wouldn't it be nice if we could simply handle a "load" event for the assembly settings? It turns out that we can do that, and use the same technique whether we are building a stand-alone application or component.

Hooking Settings Initialization

In order to hook the load event for your assembly settings, you must first create a code behind file for the settings class. To do this, select <app name> properties from the Project menu in Visual Studio, then click the settings tab. This is the same screen that is used to modify connection string properties:

Note the View Code button, which is highlighted by the red circle. When this button is clicked, Visual Studio creates a Settings.cs file in the main directory of your application (you would expect this file to appear in the Properties directory, but it goes into the main directory instead).

When this file is created, it contains two pre-wired events: SettingChanging and SettingsSaving. These events are of no use for our purposes. In order to hook the SettingsLoaded event, you must manually add an event handler, as shown below:

public Settings() { // // To add event handlers for saving and changing settings, // uncomment the lines below: // // this.SettingChanging += this.SettingChangingEventHandler; // // this.SettingsSaving += this.SettingsSavingEventHandler; // this.SettingsLoaded += new System.Configuration.SettingsLoadedEventHandler(Settings_SettingsLoaded); } void Settings_SettingsLoaded(object sender, System.Configuration.SettingsLoadedEventArgs e) { // Connection string initialization goes here // ... }

You can now move the connection string setting code into the SettingsLoaded event. Since you are in the code behind file for the settings class, you can replace references to Properties.Settings.Default with the this keyword:

this["MyAppConnectionString"] = bld.ConnectionString;

The connection string initialization is a good candidate for a code snippet. In most cases the only difference in this code from project to project will be the server and database settings.

It should be noted that if you're using SQL Server Authentication or another connection type that requires a user name and password, you won't want to hook the SettingsLoaded event. In this case, you'll have to display a login dialog to retrieve the authentication information. But you'll still be able to use the technique described above to control the connection string properties of your application.

Conclusion

This post demonstrates a technique for adaptive connections strings that can be used for all Windows Forms application and component projects. I've used this technique at my company, PJPM, to deploy patches and updates to clients very quickly and easily. It definitely takes an important pain point out of the deployment process.