It's a simple concept - the more you know about Whidbey, the more you know how WSS v3
operates.
Working on the product itself...
Want to work on my team (developer platform - rendering, WebParts, SafeControls,
compiled pages, etc)? The last person hired on my team
was simply given an Asp.net 2.0 book and told that assignment #1 was "go
learn Whidbey".
WebParts
In the past, WebParts were distinctly a SharePoint-only entity.
With Asp.net 2.0, that is no longer true. The Asp.net team adopted the
concept of WebParts and reworked the framework to provide a system that can
be used in all Asp.net sites. If you want to learn about WebParts, all
you have to do nowadays is open up any Asp.net 2.0 development book.
Does v3 utilize Asp.net WebParts? Yes. The entire v2 framework was
completely rewired to rely on Asp.net's WebPart framework. This
gargantuan effort took well over 10 months. The net result is that all
the goodness of Asp.net's framework is natively available in WSS.
WebPart Connections
I want to call out this feature of WebParts out because it's
truly one of features that changed from top to bottom between "then" and
"now". The v2 implementation of connections was a very complicated,
fault intolerant, delegate based system. I was honestly never a fan of
the operational model that we chose way back in 2001. The number of
hoops required by a developer to get a WebPart connected was simply
ridiculous.
When the Whidbey team began formulating the new WebPart framework, they
looked at the v2 connections model and laughed. Rightfully so.
Interestingly enough, they liked our "page dictator" model that we scrapped
due to complexity and time requirements. The second, less ambitious model is what was shipped with v2.
In effect, the "page dictator" became the
WebPartManager... and
the connections framework was switched over to a reference based system.
If you were leery of WebPart connections in v2, I don't blame you but
you should really check out the new model that is offered by Asp.net 2.0.
It's not only easier, it's also much more robust.
The big "takeaway" when using Asp.net connections instead of
WSS connections is the lack of
client-side connections and cross-page connections. I don't believe
this is a big deal for most developers. For client-side connectivity,
you can can craft custom javascript or even utilize Ajax (as you would for
any generic Asp.net site). For cross-page connections, there are
number of generic solutions out there which allow you to pass data from page
to page. If custom solutions don't work, you can always fallback and
use WSS WebParts.
No more ISAPI filter!!
One of the first things that you will notice when you install WSS
v3 is the departure of the ISAPI filter. This one change is massively
huge, both to you as an admin and you as a developer.
As everyone knows, the isapi filter was used to determine whether or not
a given request's content existed on file system. This junction point
was where the entire "is it ghosted or not ghosted" conversation began.
For v2 reference, check out the post
Ghosted and unghosted pages.
The "missing" isapi filter is perhaps the biggest clue as to the power of
Asp.net 2.0 and how WSS is built on top of a truly robust system.
To be clear, the functionality of the filter still exists but the filter
itself was replaced by two key mechanisms...
-
VirtualPathProvider - this Asp.net 2.0 class allows WSS to determine
where to retrieve content from (e.g. database or the filesystem).
-
CompilationMode - the Page class now contains a new property that
describes whether or a page can contain inline code. The net
effect is that the Page class can operate with the same intent as v2's
SafeMode parser, which provided WSS the capability on disallowing code
on unghosted pages. This new feature of the Asp.net parser is
huge! WSS no longer needs to build and maintain its SafeMode
parser - instead we squarely rely on Asp.net to handle parsing and page
characteristics when compilation modes are changed.
What are the other benefits of removing the isapi filter?
- For developers, the ability to more natively interact with
HttpModule
and
HttpApplication classes without having to worry about the filter
preempting everything is super nice.
- For administrators, the number #1 nice thing is that all requests will
be recorded properly in the IIS log files. This is a huge win for
metrics.
Gone are the days of usage reports that look like...
#reqs
%bytes
last time
file
Instead, your IIS log-based reports will start looking
like...
#reqs
%bytes
last time
file
Better resolution... long gone are the days of vague owssvr.dll entries!
Granted you will continue to have some owssvr.dll entries, but those
will be limited to actions that actually call into the dll.
SafeControls
Everyone loves SafeControls, right? Well, did you know that
Asp.net 2.0 can control whether or not a type is instantiated? That's
right... check out the
PageParserFilter class. WSS maintains the list of "safe" controls
(both compiled and user controls); Asp.net 2.0 provides the mechanism which
allows enforcement to occur.
Unghosted pages that actually compile?
In v2, once a page was unghosted it was forced through the SafeMode
parser. This inevitably meant the page was not allowed to contain inline
code. In v3, the "no code on page" behavior is still the default behavior.
However, thanks in large part to Asp.net's framework, it is possible to render
an unghosted page that contains inline code.
Is this a highly privileged action? Yes - only server admins can allow
this type of behavior.
Does it seem scary from a security standpoint?
Absolutely - this is without one of the
scariest operation that can be enabled by a server administrator.
Because of the nature of this feature, there is only way to activate this
feature... the server administrator must manually turn on the functionality
(i.e. there's no object model or browser interface). The plus side to
this functionality is that server owners will be able to push their
unghosted customizations in directions never before attainable.
Master Pages
Themes and site presentation/layout was always one of the biggest
headaches in v2. If you want to see how to quickly update the look of
any Asp.net 2.0 site, look into
Master Pages. It will undoubtedly the way you design a site... and
help you understand how to v3 sites rely on Master Pages.
User Controls
Another artifact of relying of completely relying on Asp.net 2.0
to handle rendering is the ability to easily use *.ascx user controls.
This is a huge win for both the product itself as well as developers
building custom solutions on top of WSS. Every control that is utilized by WSS is available to all
page authors. All controls are subject to the SafeControls processing
and validation.
The only feature that WSS does not support is the ability to drop any
user control into a WebPartZone. On a standard Asp.net site, any
control can become a WebPart when it is dropped into a WebPartZone - under
the hood, Asp.net wraps the control in a
GenericWebPart. I honestly feel this is a small difference in
behavior between a pure Asp.net site and WSS site that will not be
encountered by many folks.
Authentication providers
Need an alternate means of authenticating your users?
Want to implement Forms authentication or perhaps tie into a custom
solution? Leverage Asp.net's
Membership and Roles features.
There you have it... a quick overview of how WSS v3 is
built on top ASP.NET 2.0.