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.
