InfoPathology - Part 2 - The Code-Behind Conundrum

One of my favorite aspects of writing Windows applications is the sheer bliss of security ignorance. Now, of course, we have to prepare for situations when users do not have certain rights on their workstations, but for the most part, we are free to code without fear of permission denials, code access security errors, and login screens popping up with every button click. However, unlike ASP.NET, users have to do a little bit more than simply browse to a URL and scribble in their password to get to the application.

So in terms of security, InfoPath is like a child born of parents from two very different backgrounds, and its genetics are inherited from both. From its Win Forms parent, it inherited the fact that managed code is running on the client’s machine, not the server. From its ASP parent, it inherited the permission restrictions that allow it to be easily (and safely) distributed across the network or Internet. So when you put the two together, you have managed, client-side code running behind an application downloaded from the web by clicking one little link. With that, eyebrows should be raising and neck hairs should be standing on end.

As a developer, you can create your InfoPath forms (with Office 2003 Service Pack 1) in essentially two different ways: write code with the mouse, or write code with the keyboard. “Writing code with the mouse” is how I describe InfoPath forms created straight from InfoPath with no managed code. These forms are basically free from the strife of trust levels, certificates, and other forms of security headaches. You can create a very rich experience for the user, and nonchalantly toss the application on the Internet without a care in the world. This is optimal for cranking out small (but not necessary not complex) forms that need to reach a lot of users quickly.

The only drawback (and it’s not really a drawback; it’s just not a “drawforward”) is that your toolbox only contains three items: InfoPath rules, web services, and (gasp) JavaScript or VBScript code. InfoPath rules are the reason I use the term “writing code with the mouse.” You will find yourself clicking, clicking, clicking, scrolling, scrolling, scrolling, and then having to take a break to stretch. InfoPath licenses should come with free carpal tunnel exams.

Say what you will about having to write excess amounts of plumbing code; I could probably write a standard SharePoint web service in the same amount of time it takes to click my way through the InfoPath web service data connection wizard, create my rules for setting and retrieving method parameters, and setting the conditions to fill controls with data. You never even touch the keyboard! Creating forms this way just doesn’t make me feel like a programmer.

“Writing code with the keyboard” on the other hand, entails firing up Visual Studio .NET 2003, installing the InfoPath project template, and diving in. Having a blank class in .NET on one screen and blank InfoPath form on the other makes me feel like a racecar driver poised on the starting line, revving my engine, ready to fly. Unfortunately, if you are not equipped to handle the security ramifications, your race car will be the one featured on the highlight reels tumbling end-over-end down the track and exploding.

InfoPath forms with code-behind require the security level in the form to be set to Full Trust. This ask-no-questions-take-no-prisoners setting requires one of two things: that the form be installed, or signed with a certificate form a trusted root authority. Certificates are the preferred method, since the client is accepting the certificate itself, not explicitly the content it is signing. Therefore, you can sign multiple versions of the form, or even multiple forms with the same certificate. This makes updates deployment as easy as simply republishing the form.

Since we’re all either not on a Windows 2003 Server domain or not ready to cough up the dough for something like Verisign, form installation is the way to go. This entails creating an MSI for your form via some command line statements, and uploading the MSI to your shared location. The users then run this installer, and the form is Fully Trusted. Updates require the MSI to be recompiled, and the form to be reinstalled. I will go into more detail about form deployment in a future blog entry.

So how do we go about deciding which way to begin? I make the following considerations:

• Security: Do I need code behind?  Although I consider myself a “plumber’s” developer and I love physically writing code, I’d much prefer to forego this if it means forgetting about having to answer any security questions if possible.  If I can’t get my hands on a certificate and my environment precludes easily distributing an MSI, I’ll grit my teeth and close Visual Studio.  
• Functionality: Again: Do I need code behind?  Beyond making certain asks easier, managed code also makes certain tasks possible.  Our clients are far more concerted with delivering requirements than obsequiously dimming them down to fit the security model.  Code-behind really unleashes the power of InfoPath – if that power is needed, and there’s no way around it, the security issues instantly seem less important.
• Time: Finally: Do I really need code behind?  Code behind could be faster, but then again it is truly only more efficient in certain situations.  If you need to crank out several cookie-cutter applications in a short period of time, it would be faster to create one, save it as a template, and simply augment it for the others.  

Having to refactor, redubug, and retest the code every time can slow you down. I’ve played with the idea of a base form that all my forms inherit from, but down the road I found myself “cheating” the idea of inheritance by tweaking the base form to work; life wasn’t any easier.

At the same time, if you have to create an enterprise level application with variable workflows, multiple views, interactions with several different external data sources, and other complexities, managed code is certainly the way to go. It is just faster (and much easier to manage, which also saves time) to create one form validation function then to have to set conditional rules and validators for each control. It is faster to write a custom web method to query a SharePoint list than to connect directly to it via an InfoPath wizard and use the clunky, cryptic built-in functions to get the data to look and act exactly the way you want it to.