One of the things we did with ASP.NET 2.0 was to work very closely with the SharePoint and CMS teams within Microsoft to enable much richer architectural and developer integration than we had with previous releases.
Specifically, we tried to drive many of the core architectural requirements and scenarios they and other portal/CMS vendors had into the ASP.NET 2.0 runtime (for example: web parts, virtual path providers and compilation, site navigation, membership and role management, personalization, etc). The SharePoint/WSS/CMS Teams are then building their new releases on top of these ASP.NET 2.0 APIs -- and will have the Beta2 versions of these apps out shortly. This will enable .NET developers to learn and master a single core set of APIs and then easily re-use this across any type of web application they are building – whether it is a SharePoint Portal, a CMS application, or a totally custom ASP.NET web application.
A few of the many cool extensibility scenarios this enables:
1) You can now build a web-part control that supports drag/drop user-personalization and customization and use it within any vanilla ASP.NET 2.0 application, or host it within a SharePoint 2007 or Windows SharePoint Services (WSS) site.
2) You can build a class library, control, or page that uses the Membership, Roles, Profile, or Site Navigation APIs and re-use it across both a custom ASP.NET application and a SharePoint/CMS site. SharePoint will ship with a bunch of SharePoint providers that plug-in using the standard ASP.NET 2.0 Provider API (for example: they ship a SharePoint provider that integrates the SharePoint Page and List models under the ASP.NET 2.0 Site Navigation API). This means you get *a lot* more mileage with your code, and can re-use your API knowledge for a lot more projects.
3) You can plug-in your own custom providers to extend SharePoint and WSS solutions just like you would vanilla ASP.NET 2.0 sites. Because SharePoint uses the standard ASP.NET 2.0 APIs for things like Membership, this means you can now easily change the authentication mode and membership storage for SharePoint solutions (previous versions required Windows Credentials). Sahil Malik posted last week here about how to-do this. In Sahil’s post he was using the default ASP.NET Membership Provider to enable Forms Authentication for a SharePoint site. What is cool is that you could actually plug-in *any* ASP.NET membership provider and have this scenario work. You can also now download the source-code to the built-in ASP.NET providers, customize them or write your own, and then add them to a SharePoint or WSS solution.
We think all of this unification is going to enable a bunch of really cool scenarios for .NET developers going forward. It also helps validate and drive requirements down to the APIs we ship in ASP.NET and the .NET Framework, and ensures that they provide all the hooks needed to build big feature-rich applications on top of them (having the Office Division starting to build on top of the new ASP.NET 2.0 APIs two years ago really drove a bunch of great enhancements and improvements to their extensibility and capabilities).
Best of all, it means you can also start more projects using SharePoint or WSS (note: Windows SharePoint Services is a free download and can be deployed totally free on Windows Server), and quickly create a solution with rich document management and collaboration support already built-in (including client Office tool support) – and then be able to customize and enhance it further using the ASP.NET 2.0 and VS 2005 skills you already know.
This should enable you to build and deploy really great solutions even faster, and make your customers (whether internal or external) even happier.
Hope this helps,