VBUG Spotlight
LANGUAGES: ALL
ASP.NET VERSIONS:
2.0 (Beta 1, Beta 2)
Early Adoption
Releasing on Betas: Extreme Programming?
By Richard Costall
At the end of last year I was tasked with building our
company s new extranet site. The existing extranet had been developed in
classic ASP and was becoming difficult to maintain. Layout and navigation was
also in need of a spring cleaning.
I had been spending a lot of personal time with ASP.NET
2.0 Beta 1. I was pleasantly surprised with its stability and believed that its
new features would save a substantial amount of development time. The project
was fairly flexible in its launch date, which is one of the biggest
requirements of an Early Adoption project.
Virtual World
The first step was to get Beta 1 installed on my
production machine at work. This is not a particularly good idea, so we opted
to use Virtual PC. Microsoft s Virtual PC software allows you to run a self-contained
operating system within a window of your base operating system. This is a very
impressive piece of software. You can have many Virtual PC images on one box
and switch between them. One well hidden feature is the ability to roll back a
session, which is great for testing installs, running training courses, or
performing demonstrations. A Virtual PC session will support drag and drop
functionality and can be accessed via the network. Using this I was able to
transfer files between myself and a colleague, whilst we were both working
within separate Virtual PC sessions.
Be aware, however, that a Virtual PC session does consume
disk space. Although this is not really an issue in its own right, when
running, the performance is slower because both the operating system and the
Virtual PC session fight over the disk spindle. We purchased an external 160GB
USB 2.0 hard drive and moved the Virtual PC image onto this, giving us a
notable increase in performance.
Provider Model
There were major development savings to be had by using
the new provider model. The ASP.NET team had spent a lot of time analysing the
common tasks a developer must complete in order to build a Web site; for
example, logging into a secure site. This task requires some kind of storage,
code to access it, and a login control to accept the data. The provider model
is a series of classes and controls for data persistence and retrieval covering
the following areas:
- Membership.
For user management and authentication.
- Profiles.
For user-specific data.
- Personalisation.
Web parts configuration storage.
- Roles.
Maintaining the roles for a user.
- Site
Management. Interacting with navigation controls.
Quite often features are all or nothing. There is
generally no half-way; if you need a slightly different behaviour, you must roll
your own. The provider model overcomes this by being totally extensible and
enabling the developer to supply it with the code to run in each instance.
Let s take a look at the default membership provider. It
will create your users table behind the scenes in a SQL or Access database. But
our extranet already had a database. Did that mean I couldn t use the
membership provider? Absolutely not; I was able to write our own provider in a
couple of hours. By changing a web.config setting I was able to tell the
ASP.NET framework to use my code and not that which is supplied. However, I
could still utilise the new login, forgotten password, and change password
control.
All the login controls came with selectable default themes
and a host of properties to change its appearance without descending into CSS.
We wanted to change not only the look and feel, but also the layout of our
extranet; this is supported by the login controls. By right clicking on the
control s smart tag and selecting convert to template, we had total control
over the layout, yet were still able to use the functionality of the provider
model.
Documentation for Beta 1 is sparse, and whilst the
interfaces seemed quite obvious, I was sometimes left unsure as to what was
required in the method call. I addressed this by using an excellent tool,
Reflector, written by Lutz Roeder. Reflector allows the user to locate an
assembly and its types and reverse engineer its methods to VB.NET or C# source
code. I did this on the SQLMembershipProvider, ensuring my code implementation
matched that of Microsoft s standard type. Building your own provider becomes
easier following Microsoft s recently announced Provider Toolkit. This is a
great addition and will make it all much simpler.
Another headline feature I utilised was Master Pages. This
feature allows you to define the overall page layout in a master Web page and
then build pages that inherit their layout from a master page. The Web page can
only place content in regions, or content placeholders, specified by the
master. At the first project review a management decision was made to change
template structure which took only minutes to change in the master page
rather than hours to visit each page individually. Master pages can also be
changed programmatically at run time, and you can even nest them with other
master pages. The caveat to this is the designer does not currently support it,
so tread carefully.
I also implemented Web parts, giving the user the ability
to personalise the layout on the front page. This feature consists of around six
lines of code. This is a feature set we could not have contemplated in anything
other than ASP.NET 2.0.
At design time any user control or custom control can be
dropped into a Web part zone and it immediately becomes a Web part. The
developer does not have to write any additional code. Included in the 60-plus
new user controls are some to manage Web parts. The sheer amount of
functionality you get code-free is amazing; there s no worrying about browser
types or debugging JavaScript.
Avoiding the Drop
CTP (Community Technical Preview) drops are interim builds
released between the betas and, as a result, do not go through the same
rigorous testing procedures. We elected to avoid these as our goal was building
and delivering an application. Some features in CTP builds changed regularly
and the fact they were appearing almost monthly would have had an impact on the
project.
Beta 1 was incredibly stable. It had its quirks, but we
could live with these. It was all part of the fun of developing in beta! Most
of the issues were within the development environment, not in the .NET Framework
or in the ASP.NET runtime. We could have gone live with this but lacked the
go-live licence, available with Beta 2. The go-live licence gives you
permission from Microsoft to legally deploy your application on a live
production machine.
I kept up to date with MSDN and blog articles about the
changes between Beta 1 and Beta 2, which made the conversion process fairly
smooth (it only took about a day). The only real issue we found in the
conversion was that in Beta 2 the provider name type definition in web.config
became case sensitive, a change which will be reverted for RTM in November. Other
changes we had to make were special subdirectories where they were created
within the Web project; for example, Themes
became app_themes .
We had to visit each page, user control, and master page
in source view and the code-behind and change the following:
<%@ page compilewith="Front.aspx.vb"
classname="Front"
%> - under Beta1
<%@ page CodeFile="Front.aspx.vb"
Inherits="Front"
%> - under Beta 2
Partial class front - Under Beta 1
Partial class front - Under Beta 2
Inherits
System.Web.UI.Page
We had used the new ConnectionString section of web.config
to hold all our connection strings and during the move to Beta 2 we had to
change the access code as follows:
System.configuration.configurationsettings.
connectionstrings.item("ConnStr")
- under Beta 1
System.Web.Configuration.WebConfigurationManager.
ConnectionStrings.Item
("ConnStr") - under Beta 2
Prior to installing the site on the live machine we
pre-compiled it using the pre-compilation command line tool aspnet_compiler.
Pre-compilation increases performance and provides added security. The site is
pre-built, including all the aspx pages. In fact, only a placeholder for a page
exists in the directory with a single line of plain text. A new file,
PrecompiledApp.txt, is created, which is used by ASP.NET to determine whether
the site is pre-compiled. If you add a new .aspx page to the pre-compiled site,
it will not be served, but instead will generate an exception, making the site
more resilient to the addition of rogue pages.
If you decide not to pre-compile your 2.0 site, make sure
you don t let anyone save a file called PrecompiledApp.txt on the root level of
your site, as it will break your site.
Our extranet went live under Beta 2 with a go-live licence
on 15 May 2005, and has been a great success; feedback from our 4,000 users has
been very positive, particularly regarding performance.
Conclusion
Throughout the development process I provided feedback to
the product team through the Microsoft product feedback centre; this is really
what beta releases are all about. In each instance, Microsoft responded quickly
and thoroughly. I have learnt a lot over the last six months and recommend
anyone about to embark on a Web project investigate the functionality of
ASP.NET 2.0 it just might save you a huge chunk of development time.
Richard Costall
(MCSD.NET) has more than 17 years development experience and works for 1st
Software, a Microsoft Gold Partner and the UK s leading software solution for
Financial Adviser and Intermediaries, designing and implementing IFA
applications in the financial services sector. Previously specialising in VB,
XML/XSLT, COM, ASP, and MSMQ, Richard now lives and breathes the world of .NET,
and in particular ASP.NET (including 2.0). Richard is also the Midlands
regional coordinator for VBUG (Visual Basic
User Group) and spends a fair amount of time organising and presenting at
meetings. When not in .NET land, Richard enjoys relaxing at home with his wife
and two sons or ultimately jetting off to Walt Disney World in Florida for a
trip or two on the Tower of Terror. Richard can be reached at http://www.costall.net.