February 2006 - Posts

The Latest Thing from Microsoft - Video Training
28 February 06 10:24 PM | Scott Mitchell

When I started working with classic ASP back in 1998 the vast majority of the tutorials and training information were to be found on community websites like ActiveServerPages.com, 15Seconds.com, and (dare I say) 4GuysFromRolla.com. (I've reminisced about the community websites back in the day on this blog before...) Anyway, at the time Microsoft seemed to only be the place to go for the technical documentation. There was the scripting center, which had great technical reference for both the VBScript and JScript scripting languages, but there weren't as many tutorials, walk throughs, how tos, blogs, and other training material you find today on msdn.microsoft.com and other Microsoft properties (such as the ASP.NET blogs, the MSDN blogs, the ASP.NET Forums, and www.asp.net).

The latest training vector Microsoft seems to be exploring is video training - both live and on-demand web casts. Scott Guthrie recently blogged about the breadth of ASP.NET 2.0 tutorial videos, and there's also a Video Training section on the ASP.NET Developer Center on MSDN. There's even videos targeted toward JSP/PHP/ColdFusion developers for transitioning to ASP.NET, and if you watch three web casts Microsoft will throw in a free copy of Visual Studio 2005 Standard Edition. (Which really isn't too much more than the free Visual Web Developer version.)

Personally I've not tuned into the video training. I know some people are visual learners and learn best by watching, but I think I learn best by reading and then doing. I think part of it, too, is that I'm a bit impatient. With an article or text-based tutorial I can read at my own speed, stop when I want to try certain things out, skip over sections very easily/quickly. Video training lacks these features. I do, however, enjoy live training in small class room settings with classmates of similar skill level. While it is true that in such settings the presenter dictates the speed of the discussion, the ability to interact with the presentor and other attendees is invaluable. (Of course, the value quickly degrades if there are too many attendees or if the presenter discourages open discourse.)

BUT, if you are someone who does learn best by watching, check out the free ASP.NET video tutorials, they might be right up your alley.

Filed under:
Wizards (Finally) Done Right
22 February 06 09:41 PM | Scott Mitchell

I want to talk about the wizards for the data source controls for ASP.NET 2.0. In Visual Studio 2005, many Web controls, when examined in the Design view, have a smart tag that lists their common tasks as links. The data source controls have a “Configure Data Source” option that, when clicked, fires up a wizard that lets you specify how to access the data. For accessing database data with the AccessDataSource or SqlDataSource controls, you get to pick your database, specify the query to run, add filter parameters, even tell it to generate corresponding INSERT, UPDATE, and DELETE statements... all graphically. Don't know the syntax for a JOIN? Don't sweat it, as the Query Builder allows you to add tables from the database to a design window and automatically wires up the tables for you (assuming you have the foreign key constraints setup correctly). Not only are the data source control wizards a tremendous time saver, but they're also a prime examples of wizards done right.

An ever-increasing problem in computer science is the Law of Leaky Abstractions, a problem discussed by Joel Spolsky. As technologies become more complex, abstractions are piled on top of one another. Developers are presented with tool and language enhancements that make dealing with these abstractions bearable by hiding layers, just like C abstracted out having to memorize (platform-specific) assembly language syntax, just like Java/C# abstracted out having to muck with pointers, or just like classic ASP abstracted out the low-level web server interactions, or how ASP.NET aims to abstract out the logical, physical, and temporal differences between the client and the server.

These abstractions are a Good Thing. Could you imagine trying to build a robust, well-designed web application using assembly code? But abstractions can potentially become problems when they leak, when there's some problem at a lower level that creeps up the abstraction stack and rears its ugly head. For developers well versed in the lower layers, such problems are usually not a big deal, but for the majority of developers, those who cut their teeth on the tool and language enhancements that (supposedly) rendered the lower abstractions moot... well, they just stare dumbfounded at the screen, or blame Microsoft/Sun/hippy open-source developers/1s and 0s.

So abstractions are good and necessary (improved efficiency and productivity), but are also bad and evil (as they can rear into bugs or subtleties indecipherable by those without a background in the lower layers of abstraction). Joel sums up this duality tersely in The Law of Leaky Abstractions:

The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying "learn how to do it manually first, then use the wizzy tool to save time." Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don't save us time learning.

Tools like Visual Studio have oodles of “whizzy” features to aid in saving time, a common meme being some wizard or tool that writes code for you. When you create a new Windows application in Visual Studio, it kindly creates some start files for you with some boilerplate code. In Visual Studio .NET 2002/2003, when you dragged a Web control from the Toolbox onto the page, Visual Studio silently added a protected member variable in your code-behind class with the same name as the control's ID property. While these code generators do obviously save much time, they are ripe for leaky abstractions, as anyone who's renamed an ID property in the markup view of an ASP.NET page without toggling to the Design view can attest to.

Visual Studio 2005 has its fair share of automatic code generation, but in 2005 a lot of the code that is generated is hidden from you. In ASP.NET 2.0, go ahead and drag on a gazillion Web controls, you won't find a single reference in your code-behind class. This has some advantages - a cleaner, more readable code-behind class and a loosely-coupled markup page and code-behind class - but at the same time it buries those abstractions further down. Where did that control reference go? Unless you know about dynamic compilation and partial classes, you might not even realize that there's a correspondence between the Web controls you add on your page and your ASP.NET page class's member variables. And that's good, I guess, unless something goes wrong.

Now back to the data source control wizards. When I first saw these wizards in action, I worried that they were writing oodles of code for you, that they were dumping abstractions on top of abstractions, and that developers new to ASP.NET 2.0 who were using these controls would love them for simple scenarios, but would run into trouble once real-world data models were introduced into the equation. But my initial expectations were misfound because the data source wizards don't write any code for you. They don't do anything other than set properties.

Of course there is a lot of code tucked away (so there are still leaky abstractions here), but it's in the bowels of the SqlDataSource and AccessDataSource classes. And this is the approach all whizzy features should aspire to - make the slick code part of some easily packaged/distributed resource (a custom Web control, part of the framework, whatever) and then have the slick wizard not write one iota of code - have it just use the packaged code, just like one would do without the wizard.

Where Microsoft and the ASP.NET team still need to focus on (IMO) is how to have all this great functionality report meaningful, explanatory error messages. It's typically when something goes wrong that the abstractions start to leak. Green developers who get a page-long stack trace error when something goes awry deep within a data source control are more apt to create a new page and start from scratch than to try to debug the data source control problem, since the problem likely permeates down several layers.

Filed under:
Encrypting Configuration Settings in ASP.NET 2.0
14 February 06 03:55 PM | Scott Mitchell

In ASP.NET 1.x, encrypting database connection strings and other sensitive bits of information was typically done by storing encrypted data in a registry setting, as discussed in How To: Store an Encrypted Connection String in the Registry. This approach, however, required you to write a lot of code. You needed to write code to encrypt the connection string and slap it in the registry, and then, whenever you needed to access the protected setting, you'd need to write more code to pull it out of the registry and decrypt it.

Thankfully with ASP.NET 2.0 protecting configuration settings is much easier. The .NET Framework now ships with configuration-related classes that allow you to encrypt portions of your configuration files in just a few lines of code, as well as a command-line tool (aspnet_regiis.exe) for doing to same but without needing to author any code. And once encrypted, no code is needed to decrypt the values. You can just access them using the exact same code from your ASP.NET pages regardless of whether the underlying data is encrypted or in plain-text. Furthermore, the ASP.NET 2.0 protected settings system uses the provider model, so you can either use the DPAPI or RSA encryption routines that ship with the .NET Framework, or you can create your own provider to take advantage of a different encryption algorithm. (It really is surprisingly easy to go from an unencrypted Web.config file to one that has protected <connectionStrings> and <appSettings> sections...)

My latest 4Guys article, Encrypting Configuration Information in ASP.NET 2.0 Applications, looks at how to encrypt configuration settings as well as the different encryption options.

Filed under:
March's Toolbox Column in MSDN
12 February 06 02:43 PM | Scott Mitchell

My third Toolbox column in the March 2006 issue of MSDN Magazine is now available online. The March issue of Toolbox examines the following two products:

I also review two books: Programming .NET Components 2nd Edition (O'Reilly), and Pro ASP.NET 2.0 in C# 2005 (Apress). For those famliar with (the now defunct) Pro X series by Wrox, you're likely aware that the one thing all of those books had in common was their weight. They were all 1,000+ page titles authored by a committee. Pro ASP.NET 2.0 has the familiar weight and page count (topping out at more than 1,200 pages), but to its credit this book does a good job of focusing on the more important topics and just skimming through the more periphery ones. From the Toolbox column:

To the authors' credit, Pro ASP.NET 2.0 does a good job of balancing the task of covering a wide array of topics and covering them in depth. The central ASP.NET ideas are explored in detail, with sections on the core concepts, data access, and security each examined over roughly 200 pages. The more peripheral subjects—building custom server controls, advanced Web services, dynamic graphics, and client-side callbacks, among others—are covered in just an overview. This approach strikes the perfect balance between the breadth and the depth of the material.

Pro ASP.NET 2.0 focuses on real-world issues and concerns. Rather than just talking about the power of the provider model, the authors provide working examples of plausible custom providers for membership, profiles, and site navigation. Furthermore, the book covers the trade-offs that accompany various design decisions. For example, in the profiles chapter there's a discussion on when to store data using the default profile provider versus using a custom provider, or simply moving the data to a separate, specific table.

You can keep abreast of the latest Toolbox articles through the column's RSS feed or the Toolbox column category here on my blog.

Your Help is Needed!

The most challenging aspect of authoring this monthly column is finding products to review! If you have any ideas or suggestions for products or books to review, please don't hesitate to send them to toolsmm@microsoft.com (which gets auto-forwarded to me).

The only requirements for reviewed products are that:

  • They are useful by developers in their day-to-day operations
  • The use/run on Microsoft technologies
  • They are commercial applications (i.e., not freeware)
  • They are not overly complex/costly.
Filed under:
More Posts


My Books

  • Teach Yourself ASP.NET 4 in 24 Hours
  • Teach Yourself ASP.NET 3.5 in 24 Hours
  • Teach Yourself ASP.NET 2.0 in 24 Hours
  • ASP.NET Data Web Controls Kick Start
  • ASP.NET: Tips, Tutorials, and Code
  • Designing Active Server Pages
  • Teach Yourself Active Server Pages 3.0 in 21 Days

I am a Microsoft MVP for ASP.NET.

I am an ASPInsider.