Download at http://www.betaplace.com/ (Guest ID: mshPDC)
- Nikhil's demo slides and code are available at http://www.asp.net/whidbey/ as well as on his blog at http://www.nikhilk.net/, where he will post samples of his demo controls that will work with the PDC build of Whidbey as well as with the forthcoming beta release.
- Nikhil started with a demo of the finished control that he's using to demonstrate his points, an HTML Editor control.
- A new base class has been added to the framework called CompositeControl, which encapsulates much of the work for composite controls. This class implements INamingContainer, so you don't have to do that manually anymore. Controls are still added by overriding CreateChildControls.
- New notion is that you override the Render method in composite controls to render layout for your controls.
- Cleaner APIs have been added for sending client-side script to the browser, including referencing a .js file, as well as for common tasks like setting focus on the client side.
- Web resources are a new feature that allow you to package scripts, images, style sheets, and more as assembly resources. Using the Page.GetWebResourceUrl method, you can access these resources programmatically (uses an HttpHandler under the covers). This means that control developers no longer need to ship images, etc. and figure out how to get them installed on the control user's machine. Much less brittle model. Also automatically works at design-time, so images, etc. show up on the design surface in addition to working at runtime.
- Another new feature is script callbacks. Script callbacks allow you to make requests back to the server to retrieve information from the page, without navigating away from the existing page. So you can now update a page seamlessly without postbacks. Script callbacks cause the target page to be instantiated, but it does not go through the entire page lifecycle, only the amount necessary to create and rehydrate its controls, and fire the scriptcallback event. It also solves two problems of postbacks: losing scroll position, and the back button. Because the browser never navigates away from the current page, the user can't use the back button to re-play the interaction.
- Improvements in State Management - Addressing the limitations/issues with ViewState. New feature is Control State...used to store essential information about that control. Control State is separate from ViewState, allowing ViewState to be disabled without breaking controls. Control State is opt-in, so controls must register their interest in maintaining Control State with the page (call Page.RegisterRequiresControlState). Important to keep the information stored as small as possible. The idea is to avoid having Control State become as bloated as ViewState sometimes becomes (such as when using a DataGrid with many rows and columns).
- Adaptive Rendering - Whidbey will provide support for helping control developers to target their controls to multiple browsers and/or devices, using different HtmlTextWriter types and/or Adapters. Nikhil hinted that one possible use of this feature would be to generate XAML from ASP.NET (see, I told you XAML was ASP.NET for Windows guys!). You can write your own custom adapters for devices/browsers you wish to target, if existing adapters don't meet your needs.
- Cross-page posting - In Whidbey, you will be able to post Web Forms to pages other than the page on which the input is entered. Postback target is chosen based on the PostTargetUrl (interim name) attribute of a control that causes a postback. On the target page, you will be able to access all of the controls, viewstate, etc. of the page that caused the web form post. Whidbey hangs a PreviousPage object off the current page to provide access to the controls, etc. of the posting page. Because it's based on postback controls, you can have a page that both posts back to itself, and also posts to another page, depending on which control is clicked.
- Validation Groups - The new feature validation groups allows you to logically group a set of validation controls, and only validate the fields that are in the group to which belongs the postback control that the user clicks. Uses the ValidationGroup attribute to implement in declarative tags. The key here is that you can have two sets of form fields that aren't typically used together, and implement validation on both sets of fields, without the non-used fields causing the page to fail validation.
- Wizard UI - New <asp:wizard> control that enables step-by-step wizard UI, for example for gathering multiple pages of input for a single purpose before saving or processing the input. The Wizard control defaults to a Next/Previous UI, but is also templated, so you can customize the UI to your needs. In combination with the Personalization and Membership providers, you can use the Wizard control to very easily create a UI for registering new users for a web site, etc.
- Image Generation - New feature for generating images in Whidbey. Includes an HttpHandler (.asix) providing a custom handler and base class for image generation, including support for downlevel rendering. Also includes a new DynamicImage control that uses callbacks with the image generation handler to pull down dynamically generated files.
- .asix files use the @ Image directive and inherit from System.Web.UI.Image.ImageGenerator. Does not require registering your own custom HttpHandler for image generation. Just write the code.
- The <asp:dynamicimage> control supports databinding. You can bind its imagebytes property to a data column that contains binary image data.
- URL Rewriting/Mapping - new built-in module for rewriting paths. Allows the use of "vanity" urls, instead of ugly querystrings, and also makes it easy to move content without breaking existing links. Perf tip: - This feature makes it possible to use kernel-level caching in IIS 6 for pages that would otherwise need querystring or form fields to perform the mapping.
- Site Counters - Provides a service and API for efficient logging and tracking of site visitors. Can also be accessed through attributes (CountClicks, CounterGroup, etc.) on declarative tags, as well as through web.config.
- Client Script Goodies - Server buttons now have an OnClientClick attribute for client-side handling. Focus mechanisms are now built into the page and controls. A page can also have a default button and a default focused control. All these features emit the appropriate client-side script. There will also be automatic scroll position maintenance in the beta release of Whidbey (not in the PDC bits).
- Whidbey adds support for custom build providers. ASP.NET allows you to register to receive notification of files needing dynamic compilation. Whidbey uses this feature to support dynamic compilation of .wsdl, .xsd, and .resx files in the /code directory of an ASP.NET application.
- No-compile Pages - You can configure at the page and folder level whether pages can be compiled after they've been deployed. If compilation is disabled, any change to the page after the page or directory has been locked down will throw an exception.
- File System Provider - allows Web content (both compiled and non-compiled) to be stored in non-filesystem locations such as databases or CMS, and even use Sql Cache invalidation to output cache stored content, while always getting the updated content if it changes. Pretends to be the filesystem and provides an interface into whatever storage location the content is actually stored in. Cannot store assemblies, but can store just about any other content.
- Securing non-ASP.NET Content - Requires IIS 6.0, using its ExecuteUrl feature. This allows forms authentication to work with static files like .jpg, .gif, etc.
- RSS Reader - Combine an XmlDataSource control and a DataList control to read and render any RSS feed.
Improved Data Source caching:
- Exposed via properties on datasource controls (EnableCaching="True", CacheDuration="5", etc.). Greatly simplifies the use of caching with data, as simple or simpler than output caching.
- Added SQL Cache Invalidation - automatically purges cached output or data when the underlying data is changed. Again, this is exposed via properties on the datasource controls (can be configured in the @ Page directive of ASP.NET pages as well).
- Caching also allows you to pull more data, and use the filtering functionality of the datasource controls to view subsets of data, without incurring the expense of pulling the data from the database on each request.
- New configuration section in web.config for Connection Strings. MMC Snap-in for configuring ASP.NET allows GUI access to this config section, and you can also access them via the configuration API. In declarative code, it uses a
<%$ connectionname:tablename %>
syntax for accessing a given connection.
- New DetailsView control, provides a more intuitive way of providing the details portion of a master-detail relationship, with the GridView control handling the master portion of the relationship. DetailsView provides an easy UI for inserting/updating data.
- Added new syntax for databinding in templates:
<%# Eval("field") %> 'for one-way binding
<%# Bind("field") %> 'for two-way binding
- Both GridView and DetailsView support two-way databinding (this feature is not in the PDC build of Whidbey).
- Templated databinding supports drag and drop of controls to be databound within, for example, a DetailsView control that is in template editing mode.
- New hierarchical DataSource controls - provide access to XML files and ASP.NET site maps, for example, and integrate with new controls designed to render hierarchical data, such as the TreeView control.
- All templated controls now also support databinding to XML, using XPath databinding expressions.
Finally got a chance to meet Kent Sharkey, who's responsible for the MSDN ASP.NET Developer Center. Kent works very, very hard to make sure that MSDN supplies the best and freshest content for ASP.NET developers, so if you see him, say “thanks”...he definitely deserves it. Kent got a whole raft of Whidbey-related ASP.NET articles launched on MSDN even in the midst of the travel nightmare that getting from Seattle to LAX became this week thanks to the wildfires here.
Clearly, the coffee vendors haven't gotten the .NET message yet, so this intrepid soul took matters into his own hands:
If you're interested in hearing the PDC perspective from noted industry figures like Brent Rector, Jeff Prosise, Dan Appleman, and Mike Amundsen, you can check out the interviews being done by Sys-Con Radio from the show floor. You can also find my interview here.
Improved Project System
- No need for FrontPage
- Supports file system webs, allowing ASP.NET development even when IIS is not installed locally (Whidbey ships with its own lightweight Web server)
- Build and debug without being an Admin
- Directory-based project system (reduces contention for project files)
- Makes it easy to do single-file editing, with complete IntelliSense support.
- When you create a project, very few files or folders are created automatically. When the IDE needs to add something (such as a web.config to enable debugging), the user is provided with a notification before the file is added.
- Debugger visualizers allow you to hover over an object at debug time and get an expanded view of the state of that object.
Remote Site Publishing
- Support for UNC, FTP, SharePoint, IIS (IntelliSense works for all of these scenarios)
- Publish all files or individual files, and keep local and remote sites in sync easily
- Logging is built into the Remote Publishing Wizard
Source Editor Improvements
- Intellisense Everywhere - in inline code and codebehind, in script blocks, in CSS styles, in web.config (yay!), and in XML files.
- Added tools to navigate your code - view at a glance the hierarchy of tag relationships.
- Outlining is available to allow you to expand or collapse on a tag-by-tag basis
- Code formatting (which can be turned off completely...really completely) can be customized based on tag categories (server vs. client) and even on a per-tag basis, allowing you to format upper/lower case, self-closing or paired tags, line breaks, etc. Formatting options for the client also determine what the server controls render to the client, making it very easy to write XHTML-compliant code.
- Cleaner code-behind. Based on partial classes, removes the requirement for separate control declarations in code-behind, and other "generated goop".
- If you select text in Source view, then switch to Design view (or vice versa) your selection is preserved, so selecting an element in Design view makes it easy to locate the tags for that control.
- Drag and drop is supported in Source view.
- Formatting us supported at the page level, as well as at the selection level, and does not automatically introduce whitespace when formatting.
- The formatter also supports automatic word-wrapping of tags.
- Tag formatting can be customized based on whether the tag contains content or is a self-contained tag, in addition to the parameters discussed above.
- The IDE supports exporting and importing of your desired formatting settings, so it's easy to share formatting across a development team to enforce a standardized format.
- Everything built in the design surface is validated to XHTML 1.1, and can optionally be validated against various browsers, and even accessibility standards.
- IntelliSense is now even supported in the @ Page directive, as well as in all inline code, including in <% %>blocks.
Whidbey Design Surface
- Never, ever, EVER, modify your code (without your asking)
- 100% XHTML 1.1 compliant and uses styles for formatting.
- Master pages provide shared layout, and provides visual representation of both the master page, and the customized content
- User Controls are rendered on the design surface
- Added smart tags to expose common control tasks (databinding, autoformatting, etc.)
- Improved table editor, with both pre-existing table templates, and/or editable table attributes.
- Added visual feedback for resizing templates, including display of the changes in pixel measurements (or percent, depending on how you defined the table) as you resize.
Faster Web Development
- No builds, save and refresh and see your changes.
- Faster project open time.
- Build Page feature - Allows you to locate compilation errors and validation problems on a page-by-page basis.
- New Code directory that provides dynamic compilation and linking for class files, including Intellisense support.
- Easier for teams to develop together since a compiler error on a single page doesn't prevent others from working on different pages.
- Pre-compiler allows you to compile your entire application (including HTML and other tags) into a single assembly, which runs just like an app deployed with source code.
- Allows you to upgrade a v1.1 application to Whidbey seamlessly.
- You can choose in-place upgrade, or make a copy to modify to the new version.
IMPORTANT! Not all of these features are in the PDC bits...about 2/3rds are there, and the rest will be in the beta coming in the spring.
Eric Rudder's keynote is focused on coding for current technology and Whidbey. "What we hear from you" was an early theme:
- I need more code samples (in my language)
- How do I support different languages?
In all the excitement yesterday, I forgot to mention that I've got two new articles up on the MSDN ASP.NET Developer Center. The first is on the new compilation features in ASP.NET Whidbey, and the second, originally written for aspnetPRO magazine, discusses the new personalization and membership features in ASP.NET Whidbey.
...a bit. Probably just as well, since I was despairing of keeping up with the variety of RSS feeds I have set up in SharpReader.
Too much to blog about, so I'm going to let some pictures talk this time:
BillG's talking about how Moore's law, and the rapid increase in availability of computing power has helped with the advances in OS (GUI, thanks to x86 processing, etc), and how increases in hardware performance enable more features in the OS.
More security tips from the Web Perspective Pre-con:
Been hearing a lot this morning about the fact that LAX was closed, due to the wildfires that are going madly here in the L.A. area.
From his ASP.NET Security Pre-Conference talk: Knowing the default accounts under which the ASP.NET worker process is run (ASPNET on IIS 5.0, Network Service on IIS 6.0) allows you to set ACLs on resources that your application may need, so as to allow ASP.NET to read, write, or take other actions on these resources. You can also use the
element in machine.config to change the account under which the ASP.NET worker process is run. Note that you should always encrypt any passwords stored in machine.config (you can use aspnet_setreg.exe utility to store credentials in the registry and then refer to them from machine.config...see KB article #329290 for more details)
Finished our pre-lunch ASP.NET overview talk. Jeff Prosise followed my overview with a good drill-down on data-bound controls.
Slides...check. Demo code...check. Looks like I'm just about ready. It's pretty clear that some people forgot to set their clocks back last night, as we've had several people come in before 9am (I start at 10) thinking that they were running late. Of course, if I hadn't had reminders from the hotel, the conference manager, and several other bloggers, I probably would've forgotten myself. :-)
My first blog entry from smoggy (and smoky) L.A.:
Thought that would get your attention. :-)
Scott's presentations are always fun, but the ASP.NET Whidbey session he describes in his blog looks to be more content than a human mind can safely absorb without cranial damage. :-)
...running Windows Mobile 2002 (thanks to Scoble for the link to Amazon's page for the phone, complete with a $150 rebate). It was time for a new phone for my wife, and since I can also use the phone to test out SmartPhone development, this one made a lot of sense. And given the rebate, the price was right. Unfortunately, Windows Mobile 2002 does not appear to support .NET, but hopefully Motorola will eventually support an upgrade to WM 2003, which does. If not, well, I've used the eMbedded tools before...
The only bummer is that it won't arrive in time for me to take it with me to PDC. What fun is it getting a new toy (ahem...a new phone for your wife) if you can't show it off? :-)
Anybody else have a SmartPhone in their future? Let me know via the comments...
[Listening to: Dam Would Break - Toad the Wet Sprocket - Coil (04:05)]
Working with the samples for my upcoming pre-conference talk on ASP.NET for the PDC, I got to wondering whether there's a dominant preference among conference attendees regarding how presenters work with code. Do you prefer to have a presenter write the code live, or do you prefer to have the presenter show a pre-written example, and explain how the important parts work?
For example, live demos take a lot more work to get right, but I can see some advantage to walking attendees through a process, rather than reviewing code with them. On the other hand, using pre-written demos generally allows for more demos within a given presentation, since inevitably some of the code that would need to be written for a live demo is really not relevant to the concepts being explained.
I'd like to hear what you think. Let me know in the comments, or via the contact link, as I'm eager to base my demo style on what real attendees want, rather than what I assume they want or what works best for me as a presenter. The reality is that I'm likely to end up with somewhat of a hybrid style, but to the extent that I can accommodate attendee's desires, I want to do that.
[Listening to: Dangerous [Hazchemix] [Hazchemix] - Depeche Mode - Personal Jesus [#3] (05:37)]
For those of you who've never heard of them, there's a couple of guys by the name of Mark Russinovich and Bryce Cogswell who run a site called Sysinternals. Sysinternals provides some of the most useful utilities available for Windows (NT, 2000, XP, etc. - don't tell anyone, but they've also got some for Linux, too). Developers and admins alike should definitely keep this site in their favorites list.
In the process of preparing for my PDC pre-conference session with Jeff Prosise (we're doing sort of a tag-team approach throughout the day), I've been keeping a list of presentation tips from some of the folks who I know to be the best speakers in the business (either from personal experience or based on their reputation). Here's a list of links to stuff that I've found. I hope that I'm able to live up to the confidence that Microsoft has shown in having me present, and I'm sure that these tips will help.
From recent experience...
I'm in the process of digitizing a whole mess of Christmas albums that my wife had growing up. This involves hooking up a turntable to my laptop (I'm using a new Audio-Technica AT-PL50 that I picked up for just $99, which includes a built-in preamp so you don't need a receiver or mixer to record from it), and using the Analog Recorder tool from Plus! Digital Media Edition to record the audio, split it into tracks, name the album/tracks, and filter out pops and hissing. The Analog Recorder creates WMA files at whatever bitrate you choose.
Thanks to Kent Sharkey, who runs the MSDN ASP.NET Developer Center, my article on design-time support for ASP.NET server controls is now up on the MSDN site. Any questions, comments, or suggestions for future articles are welcome in the comments section below, or via the contact link to the left.
Graham Harwood writes about geek plates, and the difficulty of getting the one you want in the U.K.:
Duncan MacKenzie writes about a reader's comment that URLScan causes 404 errors when attempting to browse the .aspx pages installed by the VB.NET Resource Kit, because by default URLScan does not allow paths that contain dots (the resource kit has such a path). To solve this problem, follow these steps:
I'm trying to decide whether there's a case to be made for the utility of the Smart Displays being marketed by ViewSonic and Philips, among others. Smart Displays are essentially an LCD monitor that runs a customized OS that allows you to connect wirelessly to a Windows XP-based desktop (or laptop, one assumes) PC.