I’ve been working on a series of blog posts the last few months that cover some of the new features coming with .NET 4 and VS 2010.

Earlier today someone pointed me at some nice “quick hit” videos that have been published that also provide quick first looks at some of the new features coming with ASP.NET 4 and VS 2010.  These videos aren’t an exhaustive list of everything new – but do provide a great way to quickly learn about many of the cool new things coming with the release. 

ASP.NET 4 Videos

You can learn more about some of the new ASP.NET 4 features by watching these 22 ASP.NET Quick Hit Videos.

VS 2010 Videos

You can learn more about a few of the new VS 2010 features by watching these 8 VS 2010 Quick Hit Videos.

ASP.NET Team Member Interviews

In addition to the feature demo videos above, you can also watch these ASP.NET team member interviews done by Scott Hanselman.  In them various ASP.NET team members talk about a few of the new features they’ve worked on.

There are a lot more features coming with .NET 4 and VS 2010 not covered by all of these videos.  But hopefully the above clips provide a good way to quickly get a sense of some of the new capabilities.

Hope this helps,

Scott

This is the fourteenth in a series of blog posts I’m doing on the upcoming VS 2010 and .NET 4 release.  Today’s post covers some of the output caching extensibility improvements being made to ASP.NET 4.  These can be used by all ASP.NET 4 applications – including those built using both ASP.NET Web Forms and ASP.NET MVC.

Output Caching Today

ASP.NET 1.0 introduced the concept of output caching, which enables developers to capture and store the generated output of pages, controls, controllers, and HTTP responses in an in-memory cache.  On subsequent web requests, ASP.NET can then serve content faster by retrieving and using the generated output from the cache instead of having to execute the page/controller to regenerate the output from scratch.  This can dramatically improve the performance of your application – especially in cases where your content is based on data within a database (since when the content is output cached you end up not having to hit the database on subsequent requests).

ASP.NET’s output caching system is flexible enough to enable you to cache different versions of content depending on the querystring/form-post parameters to a page/controller (for example: Browse.aspx?category=Beverages versus. Browse.aspx?category=Meat).  It also enables you to cache different versions based on the browser type or user-language preference of the client visiting your application. This allows you to cache a mobile version of a page separate from a version optimized for a desktop browser, as well as to vary the cache entries based on whether the user wants to read a page in English or French.  You can configure ASP.NET to cache a particular output cache entry for a specific period of time (for example: 1 minute – after which the next request will regenerate the content and cache it again).  You can also configure ASP.NET to dynamically invalidate a cache entry based on an external event (for example: if the database upon which the cached content depends changes). 

One limitation of output caching with ASP.NET V1->V3.5, though, is that the cache store itself is not extensible – and the cached content always has to be stored in-memory.

ASP.NET 4 Output Cache Extensibility

ASP.NET 4 adds an extensibility point to output caching that now enables developers to configure one or more custom output-cache providers. Output-cache providers can use any storage mechanism to persist output cached content. This makes it possible to easily create output-cache providers that store the cached content using any persistence mechanism – including local or remote disks, databases, cloud storage, and distributed cache engines (like memcached or velocity).

You can create a custom output-cache provider by creating a class that derives from the new System.Web.Caching.OutputCacheProvider class in ASP.NET 4.  Within your derived class you then override 4 public methods that provide implementations for adding/removing/retrieving/updating cached content (a unique key is passed to identify each separate cached entry).  You can then configure ASP.NET 4 to use your custom outputcache provider by registering it using the new <providers> subsection of the <outputCache> element within an application’s web.config file:

Above I’ve added a new output cache provider (which I’ve named “SampleCache”) that is implemented using the “ScottOutputCache” class within my OutputCacheSample.dll assembly.  I’ve also configured ASP.NET to use my “SampleCache” implementation as the default output cache implementation whenever content is output cached – this is done by setting the “defaultProvider” attribute on the <outputCache> element. 

And now, when I add an OutputCache directive to the top of any of .aspx page the content will be cached and stored using my ScottOutputCache provider:

<%@ OutputCache Duration="60" VaryByParam="None"  %>

Likewise, if I add an [OutputCache] attribute on any action method within an ASP.NET MVC Controller the content will also be cached and stored using my ScottOutputCache provider:

Customizing Which Output Cache Provider is Used

Above I configured ASP.NET to by default always cache content using my “SampleCache” provider whenever output caching is used within the application.

As a slightly more advanced option, developers can also configure ASP.NET to dynamically choose which output cache provider to use on a per-request basis.  This is useful for scenarios where you want to have a slightly richer set of cache semantics. For example, you might want to cache the “Home” page or "Top 10" requested pages of a site using the built-in ASP.NET in-memory provider (which will be super fast because the content will be in-memory), and then cache less frequently requested pages that get lower traffic on disk.

You can dynamically indicate which output cache provider to use on a per-request basis by overriding the GetOutputCacheProviderName() method within the Global.asax file of an application.  Below I’m indicating that for the “Home.aspx” page within my application I want to use the built-in in-memory ASP.NET output cache provider – and that I then want to use whatever is registered within the web.config file for every other request:

This ability to easily switch between providers depending on scenarios ends up enabling a bunch of really powerful scenarios.

Common Output Cache Providers

We’ll be shipping samples that demonstrate how to implement a disk-based output cache provider that stores cached content on the file-system.  We’ll also be shipping samples that demonstrate how to integrate output caching with the new Windows Server AppFabric Caching Service (formerly known as “Velocity”).  AppFabric’s caching service will be a free, fully supported, Microsoft distributed cache system.  It will also be easy to use the new ASP.NET 4 output caching extensibility with memcached – a popular open source distributed caching system.

You can learn more about how to create providers by watching Stefan Schackow’s ASP.NET 4 Core Runtime talk at PDC 2009.  You can also learn more about AppFabric’s Caching service from this PDC 2009 talk.

Summary

The addition of output-cache provider extensibility to ASP.NET 4 enables developers to easily pursue more aggressive and more intelligent output-caching strategies for web sites and applications.  These can significantly improve the performance and responsiveness of applications, and improve both end-user experiences as well as reduce the amount of server resources required. 

Hope this helps,

Scott

Technical debates are discussed endlessly within the blog-o-sphere/twitter-verse, and they range across every developer community. Each language, framework, tool, and platform inevitably has at least a few going on at any particular point in time.

Below are a few observations I’ve made over the years about technical debates in general, as well as some comments about some of the recent discussions I’ve seen recently about the topic of ASP.NET Web Forms and ASP.NET MVC in particular.

General Observations About Technical Debates

Below are a few general observations independent of any specific technical debate:

a) Developers love to passionately debate and compare languages, frameworks, APIs, and tools.  This is true in every programming community (.NET, Java, PHP, C++, Ruby, Python, etc).  I think you can view these types of religious technical debates in two ways:

1. They are sometimes annoying and often a waste of time.
2. They are often a sign of a healthy and active community (since passion means people care deeply on both sides of a debate, and is far better than apathy).

Personally I think both points are true.

b) There is never only “one right way” to develop something. As an opening interview question I sometimes ask people to sort an array of numbers in the most efficient way they can.  Most people don’t do well with it.  This is usually not because they don’t know sort algorithms, but rather because they never think to ask the scenarios and requirements behind it – which is critical to understanding the most efficient way to do it.  How big is the sequence of numbers? How random is the typical number sequence (is it sometimes already mostly sorted, how big is the spread of numbers, are the numbers all unique, do duplicates cluster together)? How parallel is the computer architecture?  Can you allocate memory as part of the sort or must it be constant?  Etc. These are important questions to ask because the most efficient and optimal way to sort an array of numbers depends on understanding the answers. 

Whenever people assert that there is only “one right way” to a programming problem they are almost always assuming a fixed set of requirements/scenarios/inputs – which is rarely optimal for every scenario or every developer.  And to state the obvious - most problems in programming are far more complex than sorting an array of numbers.

c) Great developers using bad tools/frameworks can make great apps. Bad developers using great tools/frameworks can make bad apps. Be very careful about making broad assumptions (good or bad) about the quality of the app you are building based on the tools/frameworks used.

d) Developers (good and bad) can grow stronger by stretching themselves and learning new ideas and approaches.  Even if they ultimately don’t use something new directly, the act of learning it can sharpen them in positive ways.

e) Change is constant in the technology industry.  Change can be scary.  Whether you get overwhelmed by change, though, ultimately comes down to whether you let yourself be overwhelmed.  Don’t stress about having to stop and suddenly learn a bunch of new things - rarely do you have to. The best approach to avoid being overwhelmed is to be pragmatic, stay reasonably informed about a broad set of things at a high-level (not just technologies and tools but also methodologies), and have the confidence to know that if it is important to learn a new technology, then your existing development skills will mostly transition and help.  Syntax and APIs are rarely the most important thing anyway when it comes to development – problem solving, customer empathy/engagement, and the ability to stay focused and disciplined on a project are much more valuable.

f) Some guidance I occasionally give people on my team when working and communicating with others:

1. You will rarely win a debate with someone by telling them that they are stupid - no matter how well intentioned or eloquent your explanation of their IQ problems might be.
2. There will always be someone somewhere in the world who is smarter than you - don’t always assume that they aren’t in the room with you.
3. People you interact with too often forget the praise you give them, and too often remember a past insult -  so be judicious in handing them out as they come back to haunt you later. 
4. People can and do change their minds - be open to being persuaded in a debate, and neither gloat nor hold it against someone else if they also change their minds.

g) I always find it somewhat ironic when I hear people complain about programming abstractions not being good.  Especially when these complaints are published via blogs – whose content is displayed using HTML, is styled with CSS, made interactive with JavaScript, transported over the wire using HTTP, and implemented on the server with apps written in higher-level languages, using object oriented garbage collected frameworks, running on top of either interpreted or JIT-compiled byte code runtimes, and which ultimately store the blog content and comments in relational databases ultimately accessed via SQL query strings.  All of this running within a VM on a hosted server – with the OS within the VM partitioning memory across kernel and user mode process boundaries, scheduling work using threads, raising device events using signals, and using an abstract storage API fo disk persistence.  It is worth keeping all of that in mind the next time you are reading a “ORM vs Stored Procedures” or “server controls – good/bad?” post.  The more interesting debates are about what the best abstractions are for a particular problem.

h) The history of programming debates is one long infinite loop – with most programming ideas having been solved multiple times before.  And for what it’s worth – many of the problems we debate today were long ago solved with LISP and Smalltalk.  Ironically, despite pioneering a number of things quite elegantly, these two languages tend not be used much anymore. Go figure.

Some Comments Specific to ASP.NET Web Forms / ASP.NET MVC debates:

Below are a few comments specific to some of the recent debates that I’ve seen going around within the community as to whether a ASP.NET Web Forms or ASP.NET MVC based approach is best:

a) Web Forms and MVC are two approaches for building ASP.NET apps. They are both good choices. Each can be the “best choice” for a particular solution depending on the requirements of the application and the background of the team members involved. You can build great apps with either.  You can build bad apps with either. You are not a good or bad developer depending on what you choose. You can be absolutely great or worthless using both.

b) The ASP.NET and Visual Studio teams are investing heavily in both Web Forms and MVC.  Neither is going away.  Both have major releases coming in the months ahead.  ASP.NET 4 includes major updates to Web Forms (clean ClientIDs and CSS based markup output, smaller ViewState, URL Routing, new data and charting controls, new dynamic data features, new SEO APIs, new VS designer and project improvements, etc, etc).  ASP.NET 4 will also ship with ASP.NET MVC 2 which also includes major updates (strongly typed helpers, model validation, areas, better scaffolding, Async support, more helper APIs, etc, etc).  Don’t angst about either being a dead-end or something you have to change to.  I suspect that long after we are all dead and gone there will be servers somewhere on the Internet still running both ASP.NET Web Forms and ASP.NET MVC based apps.

c) Web Forms and MVC share far more code/infrastructure/APIs than anyone on either side of any debate about them ever mentions - Authentication, Authorization, Membership, Roles, URL Routing, Caching, Session State, Profiles, Configuration, Compilation, .aspx pages, .master files, .ascx files, Global.asax, Request/Response/Cookie APIs, Health Monitoring, Process Model, Tracing, Deployment, AJAX, etc, etc, etc.  All of that common stuff you learn is equally valid regardless of how you construct your UI.  Going forward we’ll continue to invest heavily in building core ASP.NET features that work for both Web Forms and MVC (like the URL Routing, Deployment, Output Caching, and DataAnnotations for Validation features we are adding with ASP.NET 4). 

d) I often find debates around programming model appropriateness and abstractions a little silly. Both Web Forms and MVC are programming web framework abstractions, built on top of a broader framework abstraction, programmed with higher level programming languages, running on top of a execution engine abstraction that itself is running on top of a giant abstraction called an OS.  What you are creating with each is HTML/CSS/JavaScript (all abstractions persisted as text, transmitted over HTTP – another higher level protocol abstraction). 

The interesting question to debate is not whether abstractions are good or not – but rather which abstractions feels most natural to you, and which map best to the requirements/scenarios/developers of your project.

e) We are about to do a pretty major update to the www.asp.net site.  As part of that we will be posting more end to end tutorials/content (for both Web Forms and MVC).  We will also be providing tutorials and guidance that will help developers quickly evaluate both the Web Forms and MVC approach, easily learn the basics about how both work, and quickly determine which one feels best for them to use. This will make it easy for developers new to ASP.NET, as well as developers who already know either Web Forms or MVC, to understand and evaluate the two approaches and decide which they want to use.

f) Decide on a project about whether you want to use Web Forms or MVC and feel good about it.  Both can be good choices.  Respect the choices other people make – the choice they have made is also hopefully a good one that works well for them.  Keep in mind that in all likelihood they know a lot more about their own business/skills than you do.  Likewise you hopefully know a lot more about your own business/skills than they do.

g) Share ideas and best practices with others.  That is a big part of what blogs, forums, listservs and community is all about.  What makes them work great is when people know that their ideas aren’t going to be ripped to shreds, and that they will be treated with respect.  Be constructive, not snarky. Teach, don’t lecture. Remember there is always someone else out there who you can also learn from.

Hope this helps,

Scott