Additional commentary from Damon Armstrong, Telligent consultant and author of Pro ASP.NET 2.0 Website Programming.
ASP.NET 2.0 and Visual Studio 2005 have been out for several months now, and many preople have had a chance to use the product in a day-to-day environment. Rick Strahl takes stock of the major changes and provides a personal perspective on some of the highs and lows.
Ed: This article originally appeared on Rick's weblog (and in Code Magazine) where it provoked much debate. With Rick’s permisison, I edited the piece, summarized some of the major discussion points and invited contribution from Damon. Enjoy.
I have a bit of a love/hate relationship with ASP.NET 2.0 and Visual Studio 2005 but, nevertheless, I've decided to move up most of my internal applications to 2.0 and not look back. Basically, there are just too many new features in ASP.NET 2.0 that make my life easier, and make it hard go back to 1.1 for coding.
So far it has worked out great. I've found many improvements that have reduced code complexity and volume, improved performance by 10-20%, and reduced memory footprint (very important to larger applications), with almost no effort at all on my part.
Incorporating 2.0 features in existing applications is not something that will happen overnight – the biggest time sink is removing 'legacy functionality': things that the .NET framework deems outdated and wants you to replace with other things. However, I find that I am nevertheless rapidly adopting many 2.0 features into my new applications. In the end, going back to ASP.NET 1.1 and VS 2003 would seem like a huge step backwards.
So, let's take a tour through some of the major changes, starting with the good and then on to the "not-so-good".
File based projects in Visual Studio 2005 for development
In Visual Studio 2005 you can now open a directory as a web project, which is very nice. On my development machine, I probably have 50 different web projects hanging around and, using VS2003, it is a real pain to configure and maintain all of these as virtual directories in IIS, and to keep the project references right. You don't think so? Have you ever tried to move projects to a new machine? In VS 2005 you simply point at a directory and the project opens. You can use the built in local Web Server to run the application, which eliminates the need to configure a Web Server in any way.
This feature is also great for developers who share examples – anybody who wants to check out a sample web application doesn't have to go through the pain of configuring virtuals on IIS. With file-based projects you now have – at least in development scenarios – the true promise of xCopy projects. This is a great feature, but not one that comes without pain (more on this later).
DJA:Everyone I talk to loves the Cassini web server built into Visual Studio, and I'm a big fan too because it simplifies a lot of things. However, there are a few pitfalls to its use. Primarily, you have to watch out for minor variances between Cassini and IIS. For example, Cassini passes all requests, regardless of extension, to ASP.NET. If you have custom handlers that process specific file types (e.g. dynamically built Excel reports, etc) then you have to remember to set up custom mappings in IIS for the extension when you deploy your application. Otherwise, IIS will not pass the request to ASP.NET. I've seen people lose a lot of time trying to troubleshoot their application at deployment because they did not have to worry about configuration settings in Cassini during development.
You can now define a Master Page template that can be reused throughout your application. This is a huge timesaver. There were ASP.NET 1.x based implementations of this concept floating around before 2.0 shipped, but to me the key feature that makes this viable is the visual support for it in Visual Studio. This enables you to see the master layout, along with the ContentPlaceholders used in each page to provide the page level content.
In addition to the important visual aspect of the designer, Master Page templates also provide a great means of hooking together related and reusable code. Because Master Pages tend to wrap a fair amount of functionality that previously required several user controls (for example, Header, Footer, Sidebar), they can isolate logic more efficiently than was previously possible.
DJA:Also noteworthy is the fact that you can dynamically change the Master Page at runtime, giving you an even greater level of visual flexibility. This support is great for allowing users to change the look and feel of an application in ways that cannot be achieved by merely switching style sheets.
Visual representation of user controls
Call me vain, but I really prefer to see what the whole page looks like while I'm designing it. As with Master Pages, Visual Studio 2005 can now display a rendered User Control, in place, in the Web Form Editor. Instead of the old, non-descript grey box with a control name, you now get a fully rendered layout right there in the designer. Double-click on it and VS takes you to the User Control Designer. I don't use a lot of user controls, and foresee many of my existing ones being replaced with Master Pages, but nevertheless I find that this visual representation of the user control makes design mode a lot more useful. This is especially true for my existing 1.1 applications, which generally still use these controls for headers, sidebars and footers.
DJA: I wouldn't call you vain. Full-rendering of User Controls is a huge time saver. I've wasted a lot of time flipping back and forth from the IDE to a browser trying to see how User Controls appear fully rendered. No more.
Ok, this isn't an ASP.NET specific feature, but the introduction of Generics in .NET 2.0 has had a profound effect on the way I write code. In the past, I've been very wary of creating custom collections because, frankly, it was a pain in the butt to subclass from CollectionBase and then re-implement the same code over and over again. For custom control development, in ASP.NET especially, I find that Generic collections work really well when you need collection properties.
You simply use List, or one of the specialized Generic collections, as a property of the control and you're done. Visual Studio sees the collection and, in most cases, provides the collection editor for you. Use of Generic Lists also makes it easy to replace many ArrayList based lists with strongly typed lists, which will often make code cleaner.
Finally, use of dynamic type replacement in business objects removes the need for the funky initialization code that had to be specified in each business object to specify which entity type is related to it. Prior to Generics a small stub of code was needed to tie business object and entity together, now with generics that code is gone in favor of a single generic type parameter. Once done, all class-level code can use that generic class description to automatically generate the correct types at runtime. This has removed a large chunk of cut-and-paste code from all of my business objects in favor of one type parameter and a couple of parent class level methods. There are many more places where Generics have had a similar effect on my code and I find it very hard to revert to not using Generic types and, especially, collections.
DJA:Generics is going to be most prevalent with collections and business objects, but you can even get some benefits using it in base classes for Pages and User Controls. I recently saw Kyle Beyer, one of the prodigies at Telligent, build a generic base page to automatically load business object data and setup our Ajax callback mechanisms for updating those objects. What would have been a headache on each new page suddenly became extremely simple.
Support for embedded resources
I tend to build a lot of custom controls for my applications and occasionally for tools and demos that I put out. Often, these controls require dependent resources, such as images, CSS files, XML Resources and so on. In such cases, any consumers of the control had to remember to distribute the appropriate files with their applications. No longer. Using Web Resources in ASP.NET you can easily embed these resources in a project, and then access them via a dynamic URL that ASP.NET generates. You simply add the [WebResource] attribute to your control's AssemblyInfo file and then use Page.ClientScript.GetWebResourceUrl to retrieve the URL that contains the resource content.
The Visual Studio ASP.NET code editor
The code editor in Visual Studio represents a huge step up from the 2003 version. The most important new "feature" from my perspective is the fact that the new editor doesn't automatically "wreck" my code formatting unless I reformat the document. I try to keep my content organized the way I like it, and it was a huge issue for me when VS 2003 would gleefully reformat the HTML whenever new controls were added to the page. In VS 2005, the editor preserves your code formatting in most cases and also does a much better job handling the insertion of control markup into the code.
A really big productivity-enhancer is the incorporation of Intellisense in the HTML editor – it's everywhere! I frequently embed <%= %> expressions into a page and Intellisense means that I avoid typos. ASP.NET 2.0 also compiles the page and checks the embedded script code generated, so that errors in the HTML markup can be caught at design time rather than runtime.
Intellisense works for all controls, including your own, so no longer do you have to provide an undocumented schema file. Visual Studio will simply find your control and internally manage the Intellisense. The Intellisense support is so good that it almost makes sense to skip the visual designer altogether and work in code. You'll see why this is actually more important then you might think in a minute.
DJA:As a recent convert from Visual Basic to C#, I am extremely pleased with Visual Studio 2005's C# IntelliSense support. Previous version of Visual Studio seemed to have a fairly sizable gap in IntelliSense support between VB and C#, and I constantly found myself wanting the VB-like IntelliSense help when I ventured into C# code. Now that gap has been closed, making the language switch even easier.
The truth is that I could go on and on about features in ASP.NET 2.0 and VS2005 that I now use frequently. Suffice it to say there are many useful and productivity enhancing features in VS2005 that make it a very hard call to have to go back to ASP.NET 1.1 and VS2003.
Nevertheless, there are also a number of issues with ASP.NET 2.0 and more specifically Visual Studio 2005 that don't sit well with me. It seems that while the ASP.NET 2.0 engine is very stable, tuned and performing well, Visual Studio doesn't fare nearly as well.
I'll note upfront that some of the "lows" that I cover here – namely deficiencies surrounding page compilation, web projects and deployment – are partially or even fully corrected by a new VS 2005 Web Application Project option that is being developed by Scott Guthrie and his team. The RC1 was released on 5th April and it's definitely worth checking out.
Visual Studio 2005 is slow, slow, slow – especially for ASP.NET applications
I used to think that Visual Studio 2003 wasn't exactly a speed demon when it came to bringing up projects and switching views between documents, and especially when switching between code, HTML and Design views in Web Forms. Unfortunately, the performance of the editing environment in VS 2005, especially for context switches between code and the designer, is even worse. It must be pretty bad because now when I go back to VS2003 I'm amazed at just how fast it is!
The main issue seems to be the Web Form editor which is dreadfully slow in rendering controls onto the form. I have several large forms with about 50-70 controls on each, and these forms take upwards of 15 seconds to load – for every context switch. I recently bought a new dual core laptop and everything on my machine now runs "blazing fast", except Visual Studio 2005, which is the one application that is still not even close to being as responsive as I would like. If you are upgrading, make sure you have a fast machine and LOTS of memory. Running Visual Studio commonly results in nearly 500 MB of memory usage on my machine for Devenv.exe alone. Add to that either IIS's worker process or the VS Web Server, plus browsers, and you can easily chew through 2 GB of memory.
DJA:Performance is definitely an issue with Visual Studio 2005, but performance is the price you pay for all of the new features. It takes time to load up and render out that user control instead of showing a little gray box, and to display a Master Page with editable content regions inside the IDE. One way I've found to reduce the pain is to configure the IDE to open web forms in HTML mode instead of in the designer. IntelliSense support even in HTML mode is awesome, and I find it preferable to use HTML mode if I'm only making one or two minor changes. If you need to do some heavier work, then you can always switch into design mode manually.
Overall, I have not found the performance to be much of a deterrent. On the bright side, it gives you a great reason to tell your boss that you really do need that 64-bit dual core system with 8 gigs of ram that you've been coveting. The 24 inch LCD may be a harder sell.
Visual Studio 2005 Web Designer bugs
The biggest time sink in VS2005 has been in dealing with a variety of editor bugs that I and many others have hit. Most of these are non-critical but they are highly annoying and waste lots of time.
My list of small but time sapping little bugs in VS2005 Web Designer is quite long; the following section just highlights a few of the more annoying examples.
Visual Designer refuses to switch focus
The most frequent bug I run into is where the visual designer refuses to switch focus to another control. You click on a new control, but the property sheet stays locked on the first control. You have switch into HTML view, then back to get it to work. Alternatively, you can right click on the new control and select properties, the focus is then changes and you can edit the correct control properties.
In some instances, VS won't let you rename a control, saying that there are already references in the mark up asking if you want to continue. Whether you click continue or not, the rename doesn't take and you have to switch to HTML view to change the name. Even when renames from the Web designer do work, they are very, very slow as VS does a full refactoring on the new name. In a large project, it can take 10-20 seconds plus a dialog click for the rename to complete. Now bear in mind that we're changing the name of a PROTECTED control attached to a Web Page here. Why is VS searching through whole project/solution?? I think it's safe to assume that a name change to a designer Page control isn't going to have much effect outside of the current page scope. Talk about the 99% scenario getting the shaft so that the 1% scenario (subclassed page used elsewhere) can work reliably. Besides, if you change the control name in the HTML view there are no checks at all – I would expect the Web designer to behave the same.
Another annoying one occurs when using stock collections and the default Collection Editor. If you try to enter a custom name in pace of the default item name, VS2005 simply doesn't save the changes. In fact, it simply blows away the properties and items you've entered. You have to use the default name or change the name in HTML view, then you can edit the item with a new name with the Collection Editor.
In any event, the end result is that I spend a lot more time in HTML view than I should. Luckily HTML view is a lot more useful in VS 2005, with intellisense making it much easier to enter property settings in code. I tend to use the designer to drop my controls onto the form and move them into place, then use HTML view for most of my property assignments – at this point it's simply more efficient to work this way. But it shouldn't have to be this way.
Doubling up of style sheet references
If you have style sheet references in the page, VS2005 doubles up the style references randomly. I recently opened a page that had 10 of the same CSS references in the file, only one of which I had added.
HTML validation "Errors"
Another issue that's not a bug but an odd implementation of a feature: VS 2005 flags a HTML validation error as an Error. A validation error is grouped in the same error list as a break-the-build error. Not only is the HTML validation overly anal with what it flags (example: it doesn't understand named colors), but it actually obscures 'real' application errors. It's not uncommon for me to have 20-30 HTML 'errors' and 1 code error. The code error will be at the bottom where it's the least useful and there's no visual separation. Validation is useful, but it needs to be separated and easily toggled on and off, ideally with a separate error tab. You can turn off HTML validation altogether, but the option is buried in the slow Tools | Options dialog in the Html Editing section.
DJA:As a side note, HTML validation errors only display when the page on which the error occurs is open in the IDE. If you find yourself wading through a swath of HTML errors, you can close down your open windows to weed them out. Annoying? Yes. But it gives you an alternative if you don't want to turn off validation errors altogether.
ASP.NET page compilation
I mentioned earlier that the new file-based Web Project model is nice for development. In order for that model to work, ASP.NET has introduced some fairly radical changes to how web applications are compiled and deployed. Specifically, by default, each ASP.NET page in a project compiles into a single assembly. On the plus side, this makes it possible to unload each page individually so you can re-run it after making a change. On the down side, it means that each of these assemblies is dynamically generated and cannot be easily referenced from within your applications. In other words, it's very difficult to get a strongly typed reference to another Page or UserControl in your application, because there's no known class name to which you can cast.
This proves to be problematic if you have subclassed Page classes whereby one Page inherits from the stock behavior of another, based on an ASPX file. In ASP.NET 1.x, you simply referenced the first class with its namespace and classname. In 2.0 there's no namespace, since the name of the class is dynamically generated and doesn't exist in the same assembly.
The biggest problem with this behavior is manifested in applications that rely on dynamically loaded user controls. It's nearly impossible to get a reference to a user control that is not explicitly referenced using the <%@ Register %> directive. In most scenarios using the <%@ Register %> directive does the trick, as long as you know exactly where you're loading the control from – you have to specify the path of the user control in the @Register command. The Register tag then forces the Page assembly to reference the related assembly for the control.
However, if you're dynamically loading a user control at runtime it may be that no Register directive is in place. So while you can load the control with Control. LoadControl() there's no way to cast it to the control type. A highly visible example of this is DotNetNuke which heavily relies on user controls as well as .Text (which I use for my WebLog) both of which don't run in ASP.NET 2.0 out of the box.
You might expect that if you write some code like that it should both compile and run as expected:
MyUserControl_ascx x = (MyUserControl_ascx)LoadControl("~/UserControls/MyUserControl.ascx");
x.MyProperty = "hello, world";
However, it depends on how the app is compiled. If you compile per directory and the control is in the same directory then this works, but if you compile a single page then it won't work. I think this is what VS 2005 does during development because it works with the control in the same directory. Move it into a different directory and it no longer works. You'll get an invalid cast on the control.
DJA:We have experienced a number of issues pre-compiling applications that reference user controls by class. Our workaround was to implement interfaces for the controls instead of using the User Control classes directly. Another caveat to pre-compilation is that when you call LoadControl("~/UserControls/ControlName.ascx") the .ascx file you reference may only be a marker file. A marker file contains the text "This is a marker file generated by the pre-compilation tool, and should not be deleted!" Naturally, the LoadControl method can't do much with that, so it fails if you try to load that user control. You have to specify tell the pre-compiler (aspnet_compiler.exe) to make the application updateable (via the –u command-line parameter). This tells the aspnet_compiler to actually write out your entire .ascx file, and not just the marker file it normally creates.
This is not a very common scenario, but there are a number of highly visible products that use dynamically loaded user controls in 1.1 to handle theming of applications. In those scenarios controls are loaded out of potentially unknown directories and there's no way to get any sort of @Register or @Reference directive into the page to get a reference to the control. This particular scenario is more of a problem for migrations from 1.1 as many of these scenarios can be addressed with ASP.NET 2.0 Themes and Master Pages (for example: http://west-wind.com/weblog/posts/4899.aspx), but if you have to port a project that uses these techniques there are no easy workarounds.
There are a few workarounds, from creating base classes and interfaces that provide the published interface, but none of them do much good for existing applications. Fortunately, the Web Application Project option mentioned above addresses this concern. With that option everything is compiled into a single assembly – so direct references across pages/user-controls are allowed.
ASP.NET Web Projects aren't real projects
ASP.NET projects aren't real VS2005 projects – they're a custom project type that by default are based on the directory structure in operating system file system. If you open an ASP.NET Web Project it pulls in any and all files below that project folder. This means you really have no control over what gets pulled into your 'project'.
As a particularly disastrous example of the problem with this, it took about 20 minutes to open the root for my own web site in VS. It sits on top of a large number of virtuals; there are probably 50,000 files below the Web root. When I opened the root it pulled in everything – images, XML files, doc files, utilities, the lot…
File projects have no way of excluding anything. Any file in the tree becomes part of your project, be it an image, support file, configuration utility, or documentation file, and regardless of whether it really has much to do with your project. The reason for this is that there really is no project. A few things like the path mapping etc are stored with the solution, but overall there's none of the typical project configuration that you see in class projects.
ASP.NET 2.0 compiles projects using a new ASPNET_COMPILER utility which copies everything to a 'deployment' directory. So not only is your project huge, but compiling it copies the entire project including images and support files to a new location. As you can imagine, this process is very slow. Compiling a medium sized Web of about 50 ASPX pages takes a good 30-40 seconds on my dual core machine. Compare with a couple of seconds for the same project under VS2003. Granted the compilation is more complete and results in a deployment directory, but during development 30-40 seconds is just too long. The problem is so bad that I rarely compile my web project. Most of the time I work on a page, test run it and move on, but rarely do I do a full compile. The compile cycle is too slow.
Any code that is outside of CodeBehind pages and is stored in the same path as the ASPX files need to reside in the APP_CODE folder. Everything in APP_CODE is compiled and can contain plain classes and controls. Be careful if you create backup files – for example, I often do things like copying Control1.cs to Controlbak.cs. Because both controls now exist in the same project with the same code and this causes a compilation error as you end up with duplicate classes.
All the project dialogs look different than the 'stock' projects in VS 2005. There's no stock AssemblyInfo file, no support for Xml Comments or direct MSBUILD support for a Web project. All the information about the application is stored based on the filesystem layout and a few Solution file settings.
One workaround for the massive file importing of file projects is to use IIS Web projects instead which requires explicitly adding files. This is a little closer to the old model and at least respects virtual directory boundaries, but other than the the file limiting aspect the project is still not a real project.
To Microsoft's credit, the Web Application Projects add-in also addresses most of the concerns I've raised here. It provides VS 2003 style Web projects (with some enhancements for the 2.0 functionality including file based project access).
Deployment of ASP.NET applications
Deploying ASP.NET applications got a whole lot more complicated with ASP.NET 2.0. In ASP.NET 1.x deploying applications was pretty simple: you compiled your project and you ended up with ASPX pages and a single assembly of the compiled CodeBehind files that you had to deploy to the Web Server.
In ASP.NET 2.0, you now have many, many options for deploying your applications, many of which overlap, none of which are simple, and none of which produce a repeatable install, except the uncompiled option which copies all files – source and all to and compiles everything on the fly.
The uncompiled compile is the simplest as it is an in-place mechanism that allows you to copy exactly what you have on your local machine to the server. But this install mechanism requires source code to be installed on the server, which is not the best of ideas for security and code protection.
All other mechanisms use the new ASPNET_COMPILER utility is used to compile projects into a deployment folder. Options exist to compile every page in a separate assembly, group all pages into a single assembly per directory, but none of the options produce a single assembly to deploy. In fact, there are lots of files to deploy including stub files and assemblies for APP_CODE and Master Pages.
Microsoft apparently intended people to completely redeploy applications every time an update was made. The compilation creates a deployment folder with a copy of the Web site. VS 2005 includes tools that let you upload the deployment folder to your Web site. But that's pretty unrealistic. Typically you need to adjust web.config and possible other configuration files and you certainly wouldn't want to redeploy all of the incidental files like images for every update.
The bottom line is that, with this new mode, you can't update a site by simply copying one file. You can deploy compiled assemblies for each page, which creates one assembly per page which are stored in the BIN directory. That would be OK, except that every time you run ASPNET_COMPILER, the timestamp and file name changes, so the next time you upload you have to clean up the old compiled files. Options allow you to compile both ASPX and CS files or leave the ASPX file intact and let ASP.NET compile the ASPX page content at runtime.
You can also group directories together into a single assembly of all ASPX files in that directory. This produces fewer assemblies, but unfortunately there are marker files for every page and – you guessed it – these change name on every compile. So the number of files is no less with this installation. In both cases additional assemblies are created for the APP_CODE directory, Master Pages and a few other separated files – all of which are dynamically named. The filenames generated for all of these installs change so the builds are not repeatable.
The worst thing about this deployment is that there's no quick and dirty way to deploy with the stock options – you pretty much have to copy all the files in the BIN directory to server every time and you have to remove existing files on the server before you copy them back up. And while you're copying files to the server your application is in a very unstable state as there are many files which can become out of sync while uploading. In short, live updates are not really possible on a busy site.
Again, Microsoft has heard the message from developers, although a little late. The Web Deployment Projects tool builds on top of the ASPNET_COMPILER functionality and not only can it combine all the generated assemblies into a single assembly, but it can also create stub files that have consistent names, so you can create a repeatable deployment image. If you use this tool to build it is possible to update your application on the server by simply overwriting the one or assemblies it generates on the server.
The tool also allows custom build actions to modify Web.Config files easily for deployment on the fly. This add-in provides a new VS project type and you can use MSBUILD to customize the process. I've been using the command line version of the tool for my deployment needs and it works much better than the stock behaviors. It makes the process much more manageable.
With all these confusing choices available, I created a GUI front end to ASPNET_COMPILER and the Web Deployment Projects with a ASP.NET 2.0 Compiler Utility. The tool lets you experiment with the various different compilation modes, save the configuration, create batch files and it includes support for the Web Deployment Projects tool.
Will Microsoft do the right thing?
As you can tell, there are a number of things that bug me about ASP.NET 2.0 and Visual Studio 2005. In my estimation, the productivity and feature gains are offset by and the slowness and bugs in terms of net productivity. But with a little effort on Microsoft's part it could be so much better.
However, it's not there yet. One look at the faces of developers I stand in front at presentations when I describe some of these issues says it all – "this stuff looks like Beta software". It happens all the time. Consider some of these specific comments:
"I hate to bite the hand that feeds, but I have to say that unless we can put the R back in RAD, the future of ASP.NET looks bleak. I have found ASP.NET in its VS 2003 incarnation to be cumbersome enough, but VS 2005 is an even tougher sell if I have to factor in a slower IDE and additional deployment complexity into my time estimates"
"The new 'nightmare' deployment, in addition to the sluggish interface of the IDE, inability to exclude files/directories, among other things has been a deal breaker at my company. We just decided to roll back to VS2003."
I can't tell you how many people have asked me whether they should upgrade to VS2005 and whether it's 'good enough'. I'd say yes it is, but don't expect a bug free environment in Visual Studio. And it will be a real pity if it fails to fulfill its full potential because of these problems because, overall, there are many, many things that make life a lot easier for developers.
On the whole the process of migration has gone well and I'm reasonably happy with working with VS2005 and ASP.NET 2.0. I'd be really hard pressed to want to go back to 1.x. There are problems but most of them are annoying more than anything, rather than deal breakers. And the most significant ones – the project management and deployment – are being addressed by the forthcoming Web Deployment Projects and Web Application Projects tools that Microsoft has already out in late Beta now. I'm using both and they are stable enough now to use for production work. And both will be rolled into the next service release of Visual Studio, so there's nothing non-standard about using them. The key is to make sure that developers are aware of them.
In addition, Microsoft is aware of the issues I've highlighted in this article and I've seen many Microsoft developers get involved in Blogs and message boards to address them. So if and when a Service Release for VS 2005 becomes available most of these issues should be resolved. I sincerely hope that Microsoft is making a strong commitment to fixing these and other issues and fixing them sooner rather than later. Microsoft has a tendency to move on to the next big thing and already we're hearing talk about the next version of Visual Studio.NET (Orcas). Let's hope that this release can still be made all that it was promised it would be for so many years.
DJA: I definitely agree that things could be better, but what application couldn't be improved? Minesweeper is close, but I've still got a couple of things I'd like to see changed in that too. So I doubt the future of ASP.NET looks bleak. Deployment needs some major work, but throw in better project file support, fine-tune the re-factoring, get rid of some of the buggy Visual Designer functionality, and it's going to be even more solid for development.
I'm running a 3.2 GHz single-core processor with 2 gigs of RAM, and I'm not seeing a significant enough decrease in performance to offset the gains in productivity.