Editor's//Comment
Interview With Scott Guthrie
By Elden Nelson
If there's a "father" of ASP.NET, Scott Guthrie may well be it. Guthrie co-founded the ASP.NET team six years ago. Back in version 1, he was the key architect, driving the design of the feature set. Today, as Product Unit Manager over the ASP.NET and Visual Studio Web Tool Teams at Microsoft, he oversees the development, testing, and design of ASP.NET. Steve Smith - feature contributor and Technical Director for this special ASP.NET 2.0 issue - and I chatted recently with Scott to learn a little more about what we can expect in the next version of ASP.NET.
Tell us a little about the ASP.NET team at Microsoft and how they work to create ASP.NET.
Basically, the team's broken down into three different types of disciplines. First, there's program management, which is responsible for figuring out the feature set of the product: What are the features we need to build and how should they work? They work very closely with customers to identify the common things people do over and over again, and figure out features that address those issues.
Next, there's the development discipline on my team. Developers are responsible for actually implementing the features and designing the core architecture of the product.
The third discipline on my team is testing. They're responsible for testing the product, figuring out the bugs and holes in our story and making sure they get addressed.
All in all, it takes us about 14 hours to build the product end-to-end on a clean machine. If you count everything that comes from our team, there's close to 20 million lines of code. It's a fairly big product - lots of moving gears. We do a build basically every single day of the year. We kick off the builds usually in the late evening and have the build out in the morning. From there, the testing team picks it up, start verifying it, get bugs checked in, and then gets the next build ready for the next night.
This process goes on for a year or two between releases. It's a like a steady, marching machine, where we figure out how to make the best product possible, build it, test it, and then get it out to our customers.
As we've been deciding what to include in this special issue of asp.netPRO, we've had to pick and choose from a pretty large feature set.
Yes, it's a pretty massive release in terms of feature set. I'd say it's as major a release as our version 1 release was. Hopefully, it will take what is state-of-the-art of Web development today and bring it forward. It makes administration and deployment a lot easier. Performance-wise, it's going to scale tremendously. In fact, those are the three core themes we focused on for ASP.NET 2.0: First and foremost, developer productivity; second, administration and management; and third, speed and performance. If you look at our feature set, you'll find you can put most of the new features into one of those three buckets.
What new features do you see as key to supporting those three themes?
Well, for developer productivity, we talked to a lot of customers and asked ourselves, "What are the kinds of things people need to do over and over again within their code? Is it data access? Role-based security? What are the patterns of things people are having to roll their own solutions for time and time again?" In ASP.NET 2.0, you'll see we've component-ized these kinds of features and built them into the product. For example, we now support a built-in membership and role management system, so we can store usernames and passwords for you in a safe, secure location, as well as map incoming users into roles you define - without you having to write any code (for more on this topic, see Get Personal by G. Andrew Duthie. - Ed.).
We've also got Master Pages, which allow you to do UI page inheritance across a single site, so you can define a single-page template that determines the overall site structure; every page on your site then effectively inherits the layout of that template (for more on this topic, see Standardize Your Site Fast With Master Pages by Paul Wilson. - Ed.).
We have things like a navigation system, which helps you keep track of links throughout your site. Rather than hardcode links on any individual page, you can now define in an XML file or database for the link structure of your site. Then, from code, you can quickly figure out what page you're on, and what links to other pages you should show.
We have Themes, which allow you to "skin" the UI of your site. All these features work well together, so you could, for example, use the personalization system to store UI preferences for individual users - whether they like the metallic green theme or the wacky blue theme. I can use a theme to dynamically apply a skin to the site, so when that user comes to the site, the appearance is personalized for that person's preferences.
We have Web Parts, which let you do rich portal-style customization of the UI, so that end-users can drag-and-drop bits of the page within the client browser, re-ordering what the page looks like (for more on this topic, see Meet the Web Part Framework by Stephen Walther. - Ed.).
We augment all these infrastructure features with more than 40 new server controls out of the box. These enable declarative support for data access, security, wizard navigation, cross-page posting, tree views, menus, portals, and more. What would take 100 lines of code today with a DataGrid - paging, sorting, editing, filtering - you can do completely declaratively with two lines of code (for more on this topic, see Bind Your Data in ASP.NET 2.0 by Steve Smith. - Ed.).
For administration and management, we're trying to ensure that administrators love ASP.NET as much as developers do today. We're focusing on features that enable deployment, management, and the operation of ASP.NET servers. For example, in ASP.NET 2.0, we now have a built-in config management API, so you can programmatically modify web.config and machine.config files. This works both locally and remotely.
We also have an NMC admin tool that snaps into the IIS admin tool. Rather than having to write code or work with the XML directly, administrators can directly graphically adjust settings for their Web apps.
We have secure encryption of connection strings inside web.config files, so it's easier to deploy secrets on your server. We have a precompilation utility so you can take an app - which is dynamically compiled - and effectively run this utility to generate a pre-compiled version of your site, which you then deploy on your server. This lets you find all the errors up front, and you've got a nicely-packaged unit you can hand off to customers or administrators.
We have new help-monitoring support, so administrators can be automatically notified when an application on a server has an error. So if, for example, an unhandled exception occurs, we can send the stack trace to the administrator, as well as a description of all the current server variables and incoming client data for the request that caused the error, so you can identify what the problem was.
Lastly, in terms of speed and performance, our benchmarks are getting better. ASP.NET 2.0 will also be fully 64-bit enabled for Intel and AMD processors. Basically, this means you'll be able to copy over an existing 32-bit ASP.NET application to a 64-bit server running Windows and that app will automatically run inside a 64-bit address space - you can take advantage of much more memory, without having to write any more code.
We also now include automatic database server cache invalidation. This means you can effectively output cache any page UI or cache any data in the middle tier, then have it automatically be invalidated when the data changes in the database. You'll hit the database far less often than before - performance will dramatically improve.
What databases does this work with?
Out of the box, it works with SQL 7, SQL 2000, and Yukon. It's pluggable, so you could also make it work with any database if you wanted to.
What about IDE changes?
We have a much richer Web development story in Visual Studio: We no longer require project files; you can now just point at a file system directory and we can edit any file within it. We support both inline code and code behind, with full IntelliSense and debugging. We have a WYSIWYG page designer, so that when you're using Master Pages, you can see at design time what the unified page will look like, with the parts of the Master Page you can't edit grayed-out. We now generate XHTML-compliant markup, we now have a validation engine so you can validate your HTML against any option you want. We now have HTML source preservation.
What improvements have been made to ASP.NET's built-in tracing?
We've unified the tracing models in the .NET Framework so there's now a single tracing model. When you turn tracing on at the top of the page, we have a built-in listener inside ASP.NET that will capture all the trace messages from anything using SystemDiagnostics.Tracing, then output it at the bottom of the page. You'll also be able to capture trace statements inside your debugger. So if you're debugging an app and have an output window, your trace statements should appear there.
One of the major sources of pain in ASP.NET 1.x is team development. How is that being addressed in version 2?
First, the source control system is being dramatically beefed up. We're making a lot of improvements to SourceSafe in general. Also, by going to a "projectless project" system, we do away with the need to have a project file that every file in the project has to be listed within. This eliminates that single point of contention in a shared development scenario that can be kind of ugly, frankly, and makes team development that much harder. By doing away with the notion of a project file, that becomes a lot easier. You can have a team of developers working on a site, and they can each operate on the files specific to them, without having them all trying to simultaneously update the same project file.
You're also no longer building everything as a single DLL for the Web, right?
Correct. By default, we'll have a dynamic compilation level for VS. NET. So - and this isn't true for the Alpha, but will be true for the Beta - when you press F5, we'll still do a client-side compile check within your project, showing you all the errors that will show up. The difference is, rather than persist as a DLL, we also dynamically compile on the server, and then run it using that approach. So if you just update one file, then press Refresh on the browser, it will immediately take effect. It will be a lot easier to build and deploy an app - you won't have to constantly be building DLLs and worry about getting clobbered by Source Control and so forth.
Once you build your app and are ready to deploy it, you can also, from within the IDE, use MakeWeb to precompile the app, strip out the source code, and then deploy a binary into the production directory.
What kind of porting issues should developers expect as they move from ASP.NET 1.x to 2.0?
Our goal is to be 100% backward-compatible. You should be able to take an existing app, copy it onto version 2.0, and have it work. That said, we expect that during the Alpha and Beta there will be incompatibility issues that we haven't discovered to that point. But our goal is to have all of those fixed by the time we finally ship. Upgrading should be as seamless as installing on the box, going into the admin tool, and saying, "Yep, run this app using version 2."
I should also mention that we will continue to be fully side-by-side compatible with 1.x versions. You can install version 2 on top of a Win2K server, a Windows XP server, or a Windows Server 2003 box. It runs on the same version of IIS and on the same operating systems that today's ASP.NET runs on. You can have both installed at the same time and choose which to use on an application-by-application basis. We'll have admin support to enable that.
What's the timeline for releasing ASP.NET 2.0?
We're going to release the early tech preview - in other words, Alpha - at the October PDC to conference attendees. I should point out, though, that there will be many features that won't be appearing in the Alpha/PDC version that will appear in the final product.
And how about those who aren't attending the PDC? When can they look forward to working with ASP.NET 2.0 bits?
The first big beta will come out in the first quarter of 2004 - probably in the March/April timeframe.
Any advice for asp.netPRO readers as they continue developing with 1.x versions for the next several months?
There are an awful lot of features in ASP.NET 2.0, but there aren't any significant model changes. The development you're doing right now isn't being obviated, but will in many cases be simplified. The same skills and approaches you've been using today are still valid - there aren't any features where I'd say, "Oh, don't use that, because it's going away." ASP.NET 2.0 is complementary to the development you're doing today.
Elden Nelson is editor-in-chief of asp.netPRO and its companion e-newsletter, asp.netNOW.
Learn more about ASP.NET 2.0 Online
For more info and code on ASP.NET 2.0, visit http://www.asp.net/whidbey.
