.NET news » Search results

When a browser displays the HTML sent from a web server it parses the received markup into a Document Object Model, or DOM, which models the markup as a hierarchical structure. Each element in the markup - the <form> element, <div> elements, <p> elements, <input> elements, and so on - are represented as a node in the DOM and can be programmatically accessed from client-side script. What's more, the nodes that make up the DOM have functions that can be called to perform certain behaviors; what functions are available depend on what type of element the node represents.

One function common to most all node types is focus, which gives keyboard focus to the corresponding element. The focus function is commonly used in data entry forms, search pages, and login screens to put the user's keyboard cursor in a particular textbox when the web page loads so that the user can start typing in his search query or username without having to first click the textbox with his mouse. Another useful function is select, which is available for <input> and <textarea> elements and selects the contents of the textbox.

This article shows how to call an HTML element's focus and select functions. We'll look at calling these functions directly from client-side script as well as how to call these functions from server-side code.

Page state, commonly referred to as view state, is persisted in a hidden form field, by default. When a page is being rendered, any programmatic changes to a control's state is saved to the page's overall view state. During the rendering stage, this view state is serialized into a base-64 encoded hidden form field and sent down to the client's browser. On postback, the view state data is sent back to the web server, where it is deserialized and returned to the appropriate Web controls in control hierarchy so that they may re-establish their state as it was prior to the postback.

View state provides a slick way to remember state in a stateless client-server model and it happens underneath the covers without any extra effort from page developers. The downside of view state, however, is that in certain situations the view state can grow to be exceedingly large. A large view state requires a longer page download time since it bloats the total web page size and also affects the postback time, since the entire view state content must be posted back to the web server along with the other form fields.

It is possible, however, to persist view state to an alternate medium. Such customizations were possible in ASP.NET 1.x by overriding a couple of methods in the Page class. ASP.NET 2.0 makes customizing page state persistence easier as this logic is handled through a separate class. In this article we'll explore the built-in page state persistence options in ASP.NET 2.0, which includes the ability to persist page state to session state rather than through a hidden form field.

Membership, in a nutshell, is a framework build into the .NET Framework that supports creating, authenticating, deleting, and modifying user account information. Each user account has a set of core properties: username, password, email, a security question and answer, whether or not the account has been approved, whether or not the user is locked out of the system, and so on. These user-specific properties are certainly helpful, but they're hardly exhaustive - it's not uncommon for an application to need to track additional user-specific properties. For example, an online messageboard site might want to also also associate a signature, homepage URL, and IM address with each user account.

There are two ways to associate additional information with user accounts when using the Membership model. The first - which affords the greatest flexibility, but requires the most upfront effort - is to create a custom data store for this information. If you are using the SqlMembershipProvider, this would mean creating an additional database table that had as a primary key the UserId value from the aspnet_Users table and columns for each of the additional user properties. The second option is to use the Profile system, which allows additional user-specific properties to be defined in a configuration file. (See Part 6 for an in-depth look at the Profile system.)

This article explores how to store additional user information in a separate database table. We'll see how to allow a signed in user to update these additional user-specific properties and how to create a page to display information about a selected user. What's more, we'll look at using ASP.NET Routing to display user information using an SEO-friendly, human-readable URL like www.yoursite.com/Users/username.

The Membership API in the .NET Framework provides the concept of a user account and associates with it core properties: username, passsword, email, security question and answer, whether or not the account has been approved, whether or not the user is locked out of the system, and so on. However, depending on the application's needs, chances are your application needs to store additional, user-specific fields. For example, an online messageboard site might want to also allow users to specify a signature, their homepage URL, and their IM address.

ASP.NET 2.0 Profile system can be used to store user-specific information. The Profile system allows the page developer to define the properties she wants to associate with each user. Once defined, the developer can programmatically read from and assign values to these properties. The Profile system accesses or writes the property values to a backing store as needed. Like Membership and Roles, the Profile system is based on the provider model, and the particular Profile provider is responsible for serializing and deserializing the property values to some data store. The .NET Framework ships with a SqlProfileProvider class by default, which uses a SQL Server database table (aspnet_Profile) as its backing store.

In this article we will examine the Profile system - how to define the user-specific properties and interact with them programmatically from an ASP.NET page - as well as look at using the SqlProfileProvider that ships with .NET 2.0.

When creating ASP.NET 2.0 applications, developers commonly store sensitive configuration information in the Web.config file. The cannonical example is database connection strings, but other sensitive information included in the Web.config file can include SMTP server connection information and user credentials, among others. While ASP.NET is configured, by default, to reject all HTTP requests to resources with the .config extension, the sensitive information in Web.config can be compromised if a hacker obtains access to your web server's file system. For example, perhaps you forgot to disallow anonymous FTP access to your website, thereby allowing a hacker to simply FTP in and download your Web.config file. Eep.

Fortunately ASP.NET 2.0 helps mitigate this problem by allowing selective portions of the Web.config file to be encrypted, such as the section, or some custom config section used by your application. Configuration sections can be easily encrypted using code or aspnet_regiis.exe, a command-line program. Once encrypted, the Web.config settings are safe from prying eyes. Furthermore, when retrieving encrypted congifuration settings programmatically in your ASP.NET pages, ASP.NET will automatically decrypt the encrypted sections its reading. In short, once the configuration information in encrypted, you don't need to write any further code or take any further action to use that encrypted data in your application.

In this article we'll see how to programmatically encrypt and decrypt portions of the configuration settings and look at using the aspnet_regiis.exe command-line program. We'll then evaluate the encryption options ASP.NET 2.0 offers. There's also a short discussion on how to encrypt configuration information in ASP.NET version 1.x.

A ZIP file is a popular, decades-old file format used for file compression and archiving. Commonly, such files have a .zip extension and are used to reduce the size of one or more files and/or to archive multiple files and folders into a single file. Additionally, the contents of a ZIP file can optionally be encrypted and viewable only by those who know the password. Both Microsoft's Windows and Apple's Mac OS provide built-in operating system support for opening, reading, and creating ZIP files.

In a recent project I needed to create ZIP files from an ASP.NET application on the fly. Specifically, there was a web page that listed of series of data files that were created by an external process. Users visiting this page select a file to download, which then displays a dialog box in their browser, allowing them to open the file or save it to their hard drive. This user interface worked for most of our users, as they were only interested in downloading one or two files at most. However, some of our users needed to download upwards of 20 files. For them, clicking a download link, saving it to their hard drive, and repeating, 20 times, was frustrating and time consuming. To improve this user interface we created the notion of "download profiles," which allow users to associate a name - like "Accounting Files" - with a collection of file types that are available for download. After creating a "download profile," a user could then choose to download all available files that belong to that profile. This would create a ZIP file with the appropriate files and display a dialog box in the user's browser, allowing them to open or save the ZIP. With this enhancement, our power users can now download their 20 files with one mouse click.

This article starts with a look at different ways to create ZIP files in an ASP.NET application, but then focuses on using the free and open-source DotNetZip library.

In .NET applications, an illegal operation - an invalid cast, attempting to reference a null value, trying to connect to a database that's been taken offline, and so on - raises an exception. Exceptions can be caught and handled directly in code through the use of Try / Catch blocks. For ASP.NET applications, if the exception is not handled in code, it bubbles up to the ASP.NET runtime, which raises an HttpUnhandledException. By default, unhandled exceptions result in a page that displays the text, "Runtime Error" with instructions for developers on how to display exception details (see the screen shot to the right). This "Runtime Error" error page is what is seen by external visitors; if you visit your site through localhost and an unhandled exception occurs, the default error page includes the type and details of the exception thrown.

End users will no doubt find the "Runtime Error" page to be intimidating and confusing - do you think the average computer user knows what "Runtime" means? All the user knows is that something went horribly wrong. They might fear that their data or progress has been lost and that they are responsible for the error. Ironically, the person who does care that an unhandled exception has occurred - the developer - is left out of the loop unless the end user takes the time to email the developer the details of the error (what page it happened on, the steps the user had performed that caused the error, and so on)..

Screen scraping is the process of programmatically accessing and processing information from an external website. For example, a price comparison website might screen scrape a variety of online retailers to build a database of products and what various retailers are selling them for. Typically, screen scraping is performed by mimicking the behavior of a browser - namely, by making an HTTP request from code and then parsing and analyzing the returned HTML.

The .NET Framework offers a variety of classes for accessing data from a remote website, namely the WebClient class and the HttpWebRequest class. These classes are useful for making an HTTP request to a remote website and pulling down the markup from a particular URL, but they offer no assistance in parsing the returned HTML. Instead, developers commonly rely on string parsing methods like String.IndexOf, String.Substring, and the like, or through the use of regular expressions.

Another option for parsing HTML documents is to use the Html Agility Pack, a free, open-source library designed to simplify reading from and writing to HTML documents. The Html Agility Pack constructs a Document Object Model (DOM) view of the HTML document being parsed. With a few lines of code, developers can walk through the DOM, moving from a node to its children, or vice versa. Also, the Html Agility Pack can return specific nodes in the DOM through the use of XPath expressions. (The Html Agility Pack also includes a class for downloading an HTML document from a remote website; this means you can both download and parse an external web page using the Html Agility Pack.)

This article shows how to get started using the Html Agility Pack and includes a number of real-world examples that illustrate this library's utility. A complete, working demo is available for download at the end of this article.

With the Windows Consumer Preview out the door, I thought it would be interesting to write something about creating great performing Windows applications.  I hope to have a lot more to say about this in the future but I think really the most important things I have to say are more inspirational rather than informational at this point. The key point is that things are quite a bit different than they were, and how you think about creating an application with great performance is perhaps different than it ever has been.

OK that’s a mouthful, what am I talking about?

Well one thing is the operating system itself is a lot more frugal. Improvements in Win7 and continuing improvements in Win8 mean you get more of your system resources available for your applications. Great news!  And what are those applications going to do with those resources?  Why use them of course!  Hopefully wisely, to create great experiences when they are active and economically fade to nothing when they are not.  As we’ll see, resource usage is more temporal in Win8 and so management is essential.

Back when I worked on the Whidbey CLR we thought a modest forms-based application ought to be able to start up in something like 50ms and use something roughly like 5MB of working set.

In many ways we considered the working set number to be too big. We addressed that at least in part by making as much of that memory shared as possible – good for amortizing the cost over many processes.  Big fractions of the private memory came from things like the GC heap’s initial allocation, and pre-committed stack pages plus other fixed costs but much of it had to do the raw cost of getting a CLR application going.  Still that’s where we were:  50ms and maybe 5MB, fighting to go down from there.

Fast forward to 2012 and things look a lot different.  A metro style application might spend say 9 frames @60 Hz fading in a splash screen (call it 150ms) and then another 9 fading it out.  And then maybe as many doing some cool slide-in type effect as the title comes in from one side and the data from the other.  These kinds of effects are part of the Metro look and feel.  Now at that point we haven’t actually done anything per se and we’ve spent maybe 450ms just on animations.

Memory wise, to do those transitions we probably have spent private memory to the tune of 3 full screen surfaces.  Easily 4MB each (at 1366x768) with probably 2 live at any given moment and that’s just the memory for the video.  Clearly the world is a different place.  And already the temporal nature of resource usage is showing clearly, those costs are short term.

So what does it mean?

This metro style application experience, despite the fact that it takes longer to start up, is actually much more pleasing to use.  It responded instantly to our command and fit nicely into the expected design.  I think that’s the most important observation: in a metro style application we do get some more latitude to use video memory especially for effects but the price we pay is that we have even less latitude for stalls.  People expect a smooth responsive system at all stages.  No video glitches, no jerkiness, no synchronous pauses to get resources, no long wait-cursors.  The expectation has been set from the first frame that your experience will be a lovely one and applications that don’t deliver will look like old klunkers.

Let’s also consider where this extra memory came from: video memory is in many ways the cheapest in terms of time-to-get-ready.  In previous frameworks we were dealing with mostly code that had to be brought in and working set was a good proxy to startup time because working set tends to translate directly to disk IO.  Clean video surfaces don’t have to be paged in so that (nearly) 1:1 relationship between working set and startup time is ancient history.  Which isn’t to say you can now load all the code you like: you can’t, especially not all at once because page faults turn into glitches.  Like all your other resources you’ll want to get them loaded asynchronously and have a good UI experience while they are coming in.  That means don’t load your whole program at startup, don’t initialize everything you might ever need, and create suitable transitions and incremental experiences for data and program parts arriving.  In a great application all of that is part of the overall experience.

This is why I think it’s even harder on the programmer to get all these things right and why it’s even more important than ever for the frameworks to give you a Pit of Success experience when you use the normal templates and the normal services to get your job done.   If you aren’t careful then you’ll destroy the intended experience and even “a little bit broken” will look terrible in contrast to the expectation set by the design.

Compounding all of this is our desire to run metro style applications on lower end hardware.  Some of these systems are equipped with decent GPUs (though not the greatest)  but their CPUs offer a raw compute speed that might be say 1/6th (on a per core basis) of a high end desktop.  If you want your application to run well in that environment you’ll need to think carefully about how much work you do in one transition and how you use asynchronous patterns to keep you application feeling crisp even with CPU resources that are less abundant.   Careful testing and measuring on these lower end systems will be essential because your normal development machine could delude you with speed you don’t have.

And as if that’s not enough, almost universally power consumption is a huge concern.  In unplugged scenarios, whether it’s laptop or tablet every joule consumed matters.  In some cases a core feature of the tablet is the excellent battery life and hence the lower power CPU and so forth.  As an application or framework author you must consider these things very carefully.  The system will want to suspend your application when it isn’t running – how will this affect the way you store your state?  You will want to have lovely animations while your application is active because that’s what a great application does but you’ll want to be able to turn those off when you aren’t visible.  Background activity generally should be looked at with great suspicion because it will drain power.  What background work must happen?  What could be reduced or suspended entirely?    Great choices will mean superior battery life which could be a huge aspect of your success.

Despite these challenges I’m optimistic.  I think the Metro design is a great one because has a lovely look while at the same time it is not so terribly hard to create that you must spend all resources to make it.  The Metro look and feel is largely composed of things that GPUs do comparatively well.  That’s good news for everyone and it’s a good basis to create your applications.  Asynchronous design patterns are possible in all the languages WinRT supports and especially in Javascript, which is likely to be the most popular choice by volume. Asynchronous patterns are already normal for most javascript libraries.

Bottom line: what constitutes a great performing windows application has changed in the metro world,  but great performance is still important, perhaps more important than ever.

As I said above, I hope to write more about these concerns in the coming weeks but for now I'd like to refer you to some articles that have already been written on MSDN.  It's not everything by a longshot but its something.  While this particular work discusses the problems in the context of javascript, most of the advice is actually broadly applicable no matter what framework you use.   Check it out the guidance here.