Getting Started with the ASP.NET 2.0 AJAX Extensions and Control Toolkit

by Thomas | Mar 27, 2007 | Development

I happened to be building an ASP.NET 2.0 website earlier this year when the ASP.NET 2.0 AJAX Extensions RTM’d, so I decided to try it out.  Someone recently asked me my impressions of the Extensions and Control Toolkit and how best to get started, so I thought I’d pass on my comments.

Thinking of existing ASP.NET developers picking up AJAX for the first time with this framework, it is an extremely well designed and natural development model.  It integrates almost seamlessly into the existing development environment and “<asp:xyz>” tag model.

The AJAX Extensions support static page class methods and web services, mainly using JSON serialization, to access and even data bind controls.  Some of the controls use this capability to populate data, such as the CascadingDropDown.  If you want to use that capability outside of the provided controls, you get to start writing some JavaScript against the client-side API (Microsoft created a new object model written in JavaScript, all client-side, namespaces and all).  However, all of the source code to all of the controls, and the entire Toolkit itself, is available for download, so you can dig as deep as you want for usage or implementation examples.

The barrier to entry for JavaScript and all of the cross-brower drama that comes with it can be significantly lowered by learning and programming to the new client-side API, so that is something worth learning.  Developers should make an effort to truly understand what is going on when they use AJAX on a page.  There is a lot of code happening behind the scenes to produce the end user effect of partial updates or fancy animated controls.

There are several good tutorials to get you off the ground.  The AJAX Framework is truly a framework — when you install it you don’t have any fancy AJAX controls to drop on your pages.  Instead, you’ve got the basis for building your own, and for writing cross-browser JavaScript code on top of the client-side API.  That may be a surprise to someone installing it for the first time.  Instead, all the fancy controls are housed in a Microsoft-sponsored open-source project on CodePlex.  Naturally, they are documented about as well as most open-source projects.  However, they do come with a sample website that you can play with.

One thing that should be high on everyone’s to-do list as a web developer is mastering CSS.  If you are not very strong with CSS, it is going to become tougher to use the new tools, including AJAX and WPF/E.  For many of the fancy controls noted above, you need to create a number of CSS styles just to get them to work.  I recommend one site for CSS that may open your eyes to the possibilities.  Check out all the layouts you can do with no nested tables involved, and cross-browser too.

I believe that the AJAX toolkit documentation is lacking, in some areas significantly.  You will probably find yourself with questions that are not answered at all, or poorly.  However, that has not proven to be a major issue.  For the most part things work as expected, but there are certainly subtleties to learn.

I have had some issues with the collapsible controls not sizing correctly in a stacked configuration, but that is in an absolute positioning-based CSS website that may have another CSS issue that I’m missing.  On the same site, we have an issue with the stacking and with calendar controls not appearing in IE6 only, but again, that could be related to the other CSS.

Another downside seems to be page speed during development.  If debugging is enabled you get a non-compressed debug version of the large JavaScript client-side code, and starting a page in the debugger may take an extra five seconds before it is usable vs. no AJAX.  I believe one of the recent Control Toolkit updates is beginning to address this issue.

A not-to-miss blog for a wide range of ASP.NET topics, not just AJAX, is Scott Guthrie’s.  Here are some more ASP.NET AJAX labs.  And training videos.  The good news is that you can start using the Extensions for very small bits of functionality on your site and expand from there.  For instance, I put an existing checkbox that simply turns a flag on and off in a database inside an UpdatePanel to avoid a complete postback.  I’m sure you can think of areas like this on your websites where a simple operation could be easily optimized with AJAX Extensions for a much bigger benefit in user experience.

Reuse the Exception MessageBox from SQL Server 2005 in your Apps

by Thomas | Jan 17, 2007 | Development

I’ve been forgetting to write about this one for the better part of a year…  Many of you have probably seen the exception dialog box in the SQL Server 2005 GUI’s.  It lets you copy the exception text to the clipboard and so on.  It’s pretty nice, certainly an improvement over past dialogs that just printed the error and made you take a screenshot or copy down the error message.

Microsoft quietly released that very exception dialog as a standalone, supported managed assembly that you can use in your own applications.  This is a great thing to take advantage of if you are working on any WinForms 2.0 apps.  (I haven’t checked, but it is probably .NET 2.0 since it is part of SQL 2005.)

From the source:
Microsoft Exception Message Box
“The exception message box is a programmatic interface that you can use in your applications for any tasks for which MessageBox may be used. The exception message box is a supported managed assembly designed to elegantly handle managed code exceptions. It provides significantly more control over the messaging experience and gives your users the options to save error message content for later reference and to get help on messages.”

http://download.microsoft.com/download/f/7/4/f74cbdb1-87e2-4794-9186-e3ad6bd54b41/SQLServer2005_EMB.msi

Optimize Large Data Transfer in Web Services with MTOM

by Thomas | Dec 7, 2006 | Development

I frequently hear comments that Web services are inappropriate for carrying large data messages, say greater than 1 MB.  In the past there was some truth to that, but no longer.  There is really no reason to avoid a Web service simply because you have to send or receive a bunch of data.

By default, transferring non-ASCII data over a SOAP call means using Base64 encoding.  You have to go back to the early days of the Internet to find the Base64 definition in IETF RFC 1521, which was adapted from an even earlier RFC.  Base64 typically increases the size of the encoded data by 33%, not to mention the CPU and memory required to encode and decode.  Imagine sending a 3 MB PDF over a SOAP call with Base64 encoding.  That PDF gets translated into a 4 MB ASCII string, transmitted to the other endpoint, and then converted back to the original 3 MB PDF.  Clearly this is not an efficient scheme.

Years ago, Microsoft first addressed this issue in the Web Services Enhancements (WSE) add-on to .NET with their proprietary DIME extension to SOAP.  Like MIME, DIME is designed to define message attachments of varying data types, but in this case to a SOAP message.  According to Microsoft, DIME was a more efficient format than MIME for message parsers.  It was not widely adopted.

Why attachments?  Just like sending an email, you might want to send a SOAP message that carries alongside it one or more other chunks of data, whether that’s a ZIP file, another XML file, a PDF, etc.  An attachment scheme like MIME defines in the message header the list of attachments, and for each attachment an encoding method.  We would prefer to use a binary encoding method that does not increase the size of our data.

The W3C standards organization got involved with the advent of the Message Transmission Optimization Mechanism (MTOM), which today is a W3C Recommendation.  MTOM uses concepts from MIME/Multipart to add attachments to a SOAP message, and it can optimize elements of type base64Binary.  If you put data into a base64Binary element with MTOM disabled, you will literally see a Base64-encoded version of your data (and much bigger than the original).  If you look at the same element with MTOM enabled, you will find a pointer to a MIME part that contains your actual data in binary format.

MTOM is available today for .NET 2.0 Web services in Web Services Enhancements (WSE) 3.0 and Windows Communication Foundation.  Both of these are freely available and fairly easy to use.  WSE 3.0 is perfect for your existing ASMX Web services because there is usually no code to change to take advantage of MTOM.  Keep in mind that clients of an MTOM Web service also need to be MTOM-aware.  The only requirement is that the data element you wish to optimize is of type base64Binary in the XML, and a byte array in your .NET code.  Once you enable WSE3 on your Web service project, you can simply enable MTOM in the WSE configuration.  Remember to enable it on the client side too.

Attached to this post you will find a sample .NET 2.0 solution that demonstrates a single Web service implemented in plain ASMX, ASMX with WSE3 and WCF.  You’ll notice that there is no special code at all for MTOM, just configuration.  If you use an HTTP monitor like Fiddler to examine the SOAP messages, you will see the differences with and without MTOM.

It is worth pointing out that BizTalk 2006 Web services CAN take advantage of MTOM!  When you publish a schema or orchestration as a Web service, what comes out is a regular old .NET 2.0 ASMX Web service.  Again, as long as the large data elements are defined as type base64Binary and as a byte array in code, MTOM can be enabled with no code changes.  Just update the BizTalk Web service project to enable WSE3 and MTOM.

Please contact me if you have questions, and please take advantage of these free and easy tools to make your Web services faster.

webservicesmtomdemo.zip

Code Conversion Tools – VB6 to VB.NET, Java to C# and more

by Thomas | Aug 22, 2006 | Development

You might have used the VB6 to VB.NET Upgrade Wizard in Visual Studio, or maybe the Java Language Conversion Assistant (JLCA) to convert Java code to C#.  These tools have something in common – the technology comes not from Microsoft, but from a company called ArtinSoft.

This is a company with some very intriguing products based on artificial intelligence engines.  Their business is all about source code and platform conversion – VB6 to VB.NET, Java to C#, PL/SQL to T/SQL, Linc to J2EE – you name it, they can probably do it.  They have two AI-based engines, and the one called Freedom is behind JLCA and the VB.NET Upgrade Wizard.  Through a complex process, this engine creates a langage-agnostic intermediate representation of the original source code, which can then be written out in a completely different language.

Now, people tend to complain a lot about the VB.NET Upgrade Wizard, but if you stop and think about what the tool has to do, it works incredibly well.  The quality of the original source is obviously going to be a major factor.  If the VB6 source has Option Explicit off and looks, well, like most VB6 code does, it’s amazing that the wizard can make any sense of it.

One important thing to know is that ArtinSoft sells their own versions of both of these tools: the Visual Basic Upgrade Companion and the JLCA Companion.  These products are much more advanced versions of the free tools.  The VB Upgrade Companion can even convert your VB6 code to C#.  Yes, VB6 directly to C#!  How cool is that?  ArtinSoft also offers consulting services to help with your migration projects.

Sometimes the right answer is to redesign and rewrite your code.  Other (most?) times, that is very hard to justify to your CIO, and that’s when your company might want to consider ArtinSoft’s paid applications and services.  Cost may still be an issue, since I hear that these tools are licensed by number of lines of source code, but that’s something to evaluate while you look at all of the pros and cons and make a final rewrite/upgrade decision.