Microsoft Visual Studio .NET in many ways is a quantum leap forward in software development with the introduction of the .NET Framework. Managed code, assemblies, the Common Language Runtime, Web Forms, and Windows Forms are all improvements in the art of software development. On the other hand, Visual Studio .NET leaves a lot to be desired if you are a web developer. While VS.NET is a great application development environment (even though you lost edit and continue!), the paradigm for the web was the "web application" which treats pages as isolated islands of functionality much like a collection of dialog boxes or application windows. In the real world, web applications live in web sites, whose pages are bound together into a cohesive user experience.

Many web developers are frustrated by the gap between application development tools like VS.NET, and web site development tools like FrontPage. VS.NET is strong in code development, but weak in page layout and site development. FrontPage is strong in page layout and site development, but weak in code development. We set out to bridge this gap when we started designing Parastream PagePorter. We quickly settled on these overall goals:

To be able to easily convert FrontPage pages into ASP.NET pages.
To be able to convert a whole FrontPage web into a VS.NET project.
To be able to use FrontPage and VS.NET together on a project.

In order to be able to convert pages, we needed to create ASP.NET controls that worked like their FrontPage counterparts. Link Bars, for example, needed to be able to understand the navigation structure files maintained by FrontPage, as well as duplicate the design-time and runtime behaviors. Needless to say, it required a lot of characterizing behaviors and file formats. At this point, we had a bunch of ASP.NET controls with names like FpLinkBar and FpSubstitution. A converter architecture was devised which provided a generic way for specific converters to take a FrontPage "webbot" comment tag and convert it to an instantiation of the proper ASP.NET control and parameters. The converter itself was initially a Windows application, but it became clear that there were many advantages for running it inside the VS.NET IDE.

In order to be able to convert a whole FrontPage web into a VS.NET project, the converter was rewritten as a VS.NET add-in. Now that the FrontPage web has become a VS.NET project, VS.NET needed some of the functionality of FrontPage brought in. The Navigation View Window, Site Settings Dialog, and Hyperlink Manager Dialog were born. Now, VS.NET could do real web site development!

Finally, to be able to use FrontPage and VS.NET together on a project, PagePorter needed to work around some peculiarities of the VS.NET Copy Project command used to publish web projects to a web server. For instance, PagePorter can now modify the navigation structure file, but the web server won’t let the Copy Project command copy it directly because the FrontPage Server Extensions has a special API to update the navigation structure. FrontPage can publish it because it implements the FPSE API. We made PagePorter keep up with two copies of the navigation structure file, one for FrontPage and one for PagePorter. On the server end, the controls use whichever one is most recent.

PagePorter has grown into quite a large application – over 40,000 lines of source code and documentation. We are rather proud of what we’ve accomplished with it, but at the same time realize we’ve just scratched the surface. There are more controls to create, support FrontPage Dynamic Web Templates, and making it work with the upcoming Visual Studio 2005 (previously known as "Whidbey") and its Master Pages.

Architecture

The figure below shows the big pieces of PagePorter, and how they relate to and interact with each other.

[ TODO: insert graphic – "click for larger version" ]

TODO: discuss the objects in the diagram.

Visual Studio Enhancements

PagePorter adds several new features to the Visual Studio .NET IDE. All of them are available only to projects created by PagePorter, because they generally require the databases and other infrastructure provided by PagePorter.

Design-time Enhancements

One of the first limitations in VS.NET we ran across developing the original web controls was the fact that you cannot determine the project folder or the page filename in design mode. While this might not be a serious problem for many simple web controls, it was for ours. For example, in order to provide a WYSIWYG display of the Link Bar in design mode, the control needs access to the navigation structure file and possibly the theme files. After much searching, we found a VS.NET add-in by Peter Blum called ADME, which gave you a way to call methods in design mode to determine the project folder and find other project-related files such as web.config. While this was an excellent solution to the problem, it didn’t keep track of the current file within the project. Also, since we were already an add-in, we decided to implement something similar in our add-in.

Themes

Although supporting themes was the last big-ticket item we added, it was nonetheless a very important one. Without themes, there are no graphical buttons in the Link Bar control. Without the ability to choose themes from the existing ones from FrontPage and third parties, you have to go to FrontPage to bring them in. Without a default theme, you need FrontPage again. We gave PagePorter the ability to find all installed themes, show a preview, and apply them to the site or individual pages. Which means we can read .elm files and create the composite theme .css file. The ability to edit themes and write the .elm files is left for a future version of PagePorter.

Shared Borders

Shared border support was one of the more important and technically challenging aspects of PagePorter. Everywhere we looked in the newsgroups, everyone kept asking about how to create page templates for ASP.NET web sites. There were a few decent examples and articles out there, but none of them were quite as simple and clean as we would have liked. We settled on the idea of a new base class for web pages derived from System.Web.UI.Page, and IDE features to automatically re-derive new "web forms" pages from this new base class. The new base class, Parastream.Web.UI.FpPage, hosts up to four specialized web user controls for the top, left, right, and bottom borders. FpPage has properties that let you specify filenames for the borders as well as turning them on and off.

Writing the border controls themselves presented an additional problem. Hyperlinks to objects are relative to the location of the border controls themselves, usually in the _borders folder. For instance, setting the background image for a border might include HTML that looks like background="../images/bkgnd.jpg", which works fine as long as the page hosting the control is at a directory level one below the project directory. But if the hosting page is in the project folder (root), the HTML needs to look like background="images/bkgnd.jpg". Unfortunately, the .NET framework syntax of "~/images/bkgnd.jpg" doesn’t work in ASP.NET. In fact, the parser gets totally confused if you use that syntax in ASP.NET! So, a new comment tag was invented, . If there is a tag attribute that represents a relative URL, use the tag where the "name" value is the name of the name/value pair. Consider this example from the Parastream web site:

    <!--fpoffseturl attr="background" -->
    <table border="1" width="100%" bgcolor="#cfb53b" background="../images/bkgnd_hardware.jpg">

The fpoffseturl comment tag tells the control to adjust the URL in the background name/value pair.

Site Navigation

Hyperlink Management

Site Variables

Web Custom Controls

TODO: This section discusses all of the web custom controls...

###