# 12. Web Application Development

Chapter Contents | Prev | Next
Keyword Search:
www.openlinksw.com
docs.openlinksw.com
Book Home
Contents
Preface
Web Application Development
The HTTP Server
Web Services ACL (Access Control List)
Virtuoso Server Pages (VSP)
Virtuoso Server Pages for XML (VSPX)
Writing ASP.Net Web Applications
Programming Concepts ASP.Net Deployment & Configuration The Mono Project Migrating ASP.Net Applications to Virtuoso
ASMX Web Service Hosting
Blogging & Weblogs
Writing PHP Applications
Writing JSP Applications
Perl Hosting
Python Hosting
Ruby Hosting

## 12.5. Writing ASP.Net Web Applications

Virtuoso is a CLR host. It is responsible for initializing the runtime, defining the application domain (its runtime boundaries, security settings, etc), and executing user code within such domains. Windows can be used as the development platform, a very developer friendly environment with a rich set of tools, but you will not be restricted to Windows, .NET and IIS to run the assemblies produced. Where .NET is not readily available or desired Virtuoso contains Mono, an open source re-implementation of Microsoft .NET, a vehicle taking .NET cross-platform.

The CLR run-time is a part of the Virtuoso process. The Mono run time may be run either as in-process or as out-of-process. Hosted applications can make use of the regular Virtuoso .Net data provider to access Virtuoso SQL data and procedures. Microsoft ASPX files can also be run directly from Virtuoso either from the file system or WebDAV. Each of these capabilities releases you from the Microsoft platforms without compromising your development platform.

The Virtuoso CLR hosting is implemented using the VSEI.

Figure: 12.5.1. The HTTP ASP.Net handler

See Also:

CLR Host Environment Setup

VSEI

In-Process Data Access Client

### 12.5.2. Programming Concepts

ASP.Net Web Forms are divided into two sections: the user interface and the application logic. The user interface comprises HTML markup and ASP.Net web controls whereas the application logic contains all the programming code that allows the controls to interact with themselves and the server back-end. This provides the level of abstractions required for dynamic efficient Web application design. The interface can be altered without any backward or forward dependence on the code (logic). The Web Form interface should be created with the .aspx extension. The application logic can be contained in-line within the ASPX application, but developers should strive to keep the code in a separate location known as the "CodeBehind". This is a file that contains the logic (code) for the Web Form which should end in an extension appropriate for the programming language used, such as .vb for Visual Basic or .cs for C#. The CodeBehind can be written in any language for which there is a .Net compiler for. The compiler generates bytecode that can be deployed anywhere the .Net runtime exists.

The ASPX Web Form is compiled into an object that takes its place on a tree of controls and classes. The CodeBehind is compiled into an object on this tree when the page is requested. The Web Form must inherit from a "base-class" defined in the CodeBehind class file.

Figure: 12.5.2.1. ASPX Web Form class hierarchy

Now we will create a new Web Form containing an HTML heading and an ASP.Net DataGrid control that will display results from the local Virtuoso server.

Sample .Net Web Application: VirtTest.aspx

    <%@ Page Language="vb" Inherits="VirtTest" Src="VirtTest.aspx.vb" %>
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
    <html>
    	<head>
    		<title>Virtuoso Provider to DataGrid in VB</title>
    	</head>
    	<body>
    	<h1>Simple VB Virtuoso DataBinding Demo</h1>
    		<form id="Form1" method="post" runat="server">
    			<asp:DataGrid id=DataGrid1 runat="server" DataMember="Customers"
    				BorderColor="silver"
    				BorderWidth="1"
    				CellPadding="2"
    				Font-Name="Tahoma"
    				Font-Size="10pt">
    			  <HeaderStyle BackColor="#2222ff" ForeColor="yellow"/>
    			  <PagerStyle Mode="NextPrev" />
    			</asp:DataGrid>
    		</form>
    	<hr>
    	</body>
    </html>

On the first line of the file we use the @ page directive to inherit the CodeBehind class we will create in the CodeBehind file. The source of which can be optionally declared here with the Src= attribute. Visual Studio makes use of CodeBehind= for tracking associated source code instead. If either of these two attributes are specified then the .Net runtime will attempt to compile the code into an assembly (DLL) upon first execution if it does not already exist or seems out-of-date. The following code fragment is the CodeBehind, VirtTest.aspx.vb.

Now we want some logic behind the Web Form. We have placed a DataGrid control on a web page but we need to supply data to it now:

Sample .Net Web Application CodeBehind: VirtTest.aspx.vb

    imports System
    imports System.Web
    imports System.Web.UI
    imports System.Web.UI.WebControls
    imports System.Web.UI.HtmlControls
    imports System.Data

    imports OpenLink.Data.VirtuosoClient

    Public Class VirtTest
        Inherits Page

        Protected WithEvents myConnection As OpenLink.Data.VirtuosoClient.VirtuosoConnection
        Protected WithEvents myCommand As OpenLink.Data.VirtuosoClient.VirtuosoDataAdapter
        Protected WithEvents DataGrid1 As System.Web.UI.WebControls.DataGrid
        Protected WithEvents ds As System.Data.DataSet

        Private Sub Page_Load(sender As Object, e As EventArgs) Handles MyBase.Load
            Dim myConnection As new VirtuosoConnection("HOST=noodle:1112;UID=dba;PWD=dba;Database=Demo")
            Dim myCommand As new VirtuosoDataAdapter("select * from Demo..Customers", myConnection)

    	    Dim ds As new DataSet()
            myCommand.Fill(ds, "Customers")

            DataGrid1.DataSource=ds.Tables("Customers")
            DataGrid1.DataBind()

        End Sub

    End Class

This file is compiled using the following command (split across lines for readability and would otherwise all be on one line):

    E:\myweb\myapp>
      vbc /target:library
        /r:System.dll
        /r: System.Web.dll
        /r:System.Data.dll
        /r:OpenLink.Data.VirtuosoClient.dll
        /r:System.Xml.dll
        /out:bin\VirtTest.dll
        VirtTest.aspx.vb

Once compiled, the resulting DLL library should be in the bin subdirectory of the application root. When the assembly is available in this way the .aspx file does not need to contain the Src= attribute since there will be no need to compile the CodeBehind. If the Src= attribute is specified in the .aspx file but the CodeBehind file is not located on the server then an error will be signaled indicating that a required resource cannot be found, because the CodeBehind class is compiled on demand.

### 12.5.3. ASP.Net Deployment & Configuration

ASP.Net allows multiple Web applications to run on the same machine independently of each other. Web applications have their own directory for components (the ".\bin" directory) and its own XML-based configuration file (the ".config" file). This allows us to develop robust applications using custom configurations and components (or different versions of components) for each one.

Note:

The ASP.Net machine-wide configuration is held in machine.config found in the (C:\Winnt\Microsoft.NET\)Framework\[version number]\CONFIG directory depending on your installation. Applications hosting or making use of .Net may have an application configuration [App Name].config. Web applications store their individual configurations in Web.config stored in the Web application root directory.

Each ASP.Net application uses a local assembly cache to hold application specific logic (assemblies, contained in compiled DLLs). The \bin directory located in the application root is the local assembly cache for Web applications. This directory is denied access directly from browsers. This prevents users from downloading or executing any DLLs contained within.

When a Web application is started the .Net Framework constructs a new instance of the System.AppDomain class. When the instance is constructed it creates in-memory shadow copies of the DLLs in the \bin directory. The .Net Framework keeps an in-memory cache (shadow) of all assemblies used so that the actual files (.DLLs) are not locked. The .Net Framework will monitor the original DLL for changes. When changes occur the in-memory cache is updated. Applications already loaded and running with calls in-progress to the old library will continue using the old version so there is no interruption. All new calls to library will be effected, and use the new library. This means that you are free to replace the DLL with new versions as required. Previously with ASP you were required to stop IIS, register the DLL with RegServ32.exe and restart the Web server.

When new libraries are added to the .Net Framework for use in any application system wide, such as the Virtuoso Data Provider, these need to be added to the Global Assembly Cache (GAC). This is achieved using the gacutil.exe utility found in the Framework\[version number] directory. The gacutil.exe tool registers the DLL along with its version. One of .Net's strengths is its ability to maintain multiple versions of DLLs for multiple applications. This prevents "DLL-hell"; new DLLs breaking old applications. Applications can also maintain their own local versions of DLLs in their \bin directory.

    gacutil.exe /i <full path and file name>.dll

Registers assemblies with the Global Assembly Cache.

    gacutil.exe /l

Can be used to list registered assemblies.

After registering assemblies using the gacutil.exe tool you must add an <add assembly="..." /> entry into the <configuration><system.web><compilation><assemblies> section of the machine.config.

The application given in the previous section can be deployed to Virtuoso in the WebDAV repository or directly on file system under the VSPRoot directory. You should copy the directory structure as defined, applications in the root of the new directory and DLLs in a bin subdirectory. A virtual directory must be configured with execute permissions enabled. The application can be tested with a Web browser.

### 12.5.4. The Mono Project

The Mono Project is an open source version of the Microsoft.NET development platform. Incorporating key .NET compliant components, including a C# compiler, a Common Language Runtime just-in-time compiler, and a full suite of class libraries, the Mono Project will enable developers to create .NET applications and run them on Windows or any Mono-supported platform. Besides greatly improving the efficiency of development in the open source world, the Mono Project will allow the creation of operating-system-independent programs. Although primarily developed on Linux, Mono is being ported to as many operating systems as possible.

Microsoft.NET development tools, which include the C# compiler and Common Language Infrastructure (CLI), let programs written in C# and other languages run on non-Windows operating systems. The Mono Project development platform provides open source developers with a true "build once, deploy anywhere" tool-set taking advantage of the myriad of services enabled by Microsoft.NET.

The Mono Project will provide three key elements in a development framework designed to allow developers to quickly create, deploy and run .NET compatible applications on non-Windows platform. A C# compiler extending the GNOME development platform will allow Linux developers to create .NET compatible applications. These developers will also be able to build upon a complete implementation of class libraries compatible with the Microsoft CLI, enabling developers to create end-user applications as well as powerful web services using the database functionality available on open source systems. Portation of Mono yields versions of the Microsoft Common Language Run-Time (CLR) just-in-time (JIT) run-time engine will allow non-Windows systems to run .NET applications built on Windows, Linux or UNIX platforms.

The example in the previous section can be run using the CLR hosting ability of Virtuoso, but only with the precompiled assembly which has to be deployed into the Mono/lib directory of the Mono installation.

The Virtuoso installer on non-Windows platforms for which there is a port of Mono available installs the latest Mono CLR. This is required for the Virtuoso server to host .Net applications on non-Windows platforms.

Only a compiler for C#. Inline ASPX code using C# is a safe way to write and experience ASPX hosted from Virtuoso. Although this goes completely against the programming practice guidelines for .Net

The only permissible Application Domain is the Mono application. ASP.Net applications should have their own self containable Application Domain - the ./bin directory. Mono does not support this as of yet. The work around is to place all assemblies into the Mono domain.

### 12.5.5. Migrating ASP.Net Applications to Virtuoso

#### 12.5.5.1. Creating a Simple Data Bound Application

This section will describe how to use the MS Visual Studio to create an application using as much drag and drop as possible. We want to create a table of data in a web page from a database.

1. Launch Microsoft's Visual Studio

   Once Visual Studio has been launch it present you with the start page that lets you create a New Project.

   Figure: 12.5.5.1.1. Databound Examples using MS Visual Studio

2. Create a new Empty Web Project

   From the templates select a new Empty Web Project found in the Visual Basic Projects type. You must also select a location on an IIS web server.

   Figure: 12.5.5.1.1. Databound Examples using MS Visual Studio

3. Wait for IIS application to be set-up

   You will be shown a progress dialogue as Visual Studio contacts your web server creating a new web application there.

   Figure: 12.5.5.1.1. Databound Examples using MS Visual Studio

4. Add New Web Form

   When the application-space has been configued on the web server you will be returned to the main Visual Studio windows. Now we must create our page. Right-click on the project name in the Solution Explorer and select Add New Web Form.

   Figure: 12.5.5.1.1. Databound Examples using MS Visual Studio

5. New Web Form

   The Add New Item option will appear, automatically selecting the "Web Form" item to add. Supply a name for the page and click Open to begin.

   Figure: 12.5.5.1.1. Databound Examples using MS Visual Studio

6. Add a SqlDataAdapter Control

   With the fresh "Web Form" we can start. From the ToolBox double-click on the SqlDataAdapter in the Data panel. This will start the Data Adapter Configuration Wizard. After reading the description on the first panel click on the Next button. You will be asked to choose your connection. Assuming that you have access to a Northwind database hosted in MS SQLServer you can either make use of an existing connection to it or configure a new one using the New Connection button. Pressing the New Connection button will present the normal OLEDB dialogues for creating a new datasource. Once a data connection has been selected press Next to continue.

   Figure: 12.5.5.1.1. Databound Examples using MS Visual Studio

7. Choose a Query Type

   The next panel will ask how the data adapter should access the database. For simplicity we will stick with the default of Use SQL Statements. Press Next.

   Figure: 12.5.5.1.1. Databound Examples using MS Visual Studio

8. Generate SQL Statements

   At this point you can either type a SQL statement if you know exactly what you are looking to get back from the database, or you can use the Query Builder to point-and-click to your data. In our case we will retrieve everything from the Customers table using a simple query:select * from Customers.

   Figure: 12.5.5.1.1. Databound Examples using MS Visual Studio

9. Advanced Options

   Click on the Advanced Options button. Unselect the top checkbox. This will also unselect the other two automatically. We will not be performing any updates in this example. OK the advanced options, upon return to the main dialogue press the Next button to continue onwards.

   Figure: 12.5.5.1.1. Databound Examples using MS Visual Studio

10. View Wizard Results

    The next panel confirms all the options selected leaving us to simply complete the wizard.

    Figure: 12.5.5.1.1. Databound Examples using MS Visual Studio

11. Back to the main window...

    When the wizard finishes and returns you to the main Visual Studio window you will see that two controls have been added to the Web Form. The connection control has been automatically generated to support the Data Adapter.

    Figure: 12.5.5.1.1. Databound Examples using MS Visual Studio

12. Generate Dataset

    Before we can display anything on the page we need to form a Dataset. Right-click on the SQLDataAdapter1 control you previously added and select Generate Dataset. Defaults on the displayed dialog are all sufficient. After verifying them click the OK button to generate the dataset.

    Figure: 12.5.5.1.1. Databound Examples using MS Visual Studio

13. Add a DataGrid Control

    Now we need to show the dataset that we are fetching from the database. We will use a simple DataGrid for this. Open the toolbox in the Web Forms panel and double-click on the DataGrid control. This add the control to the page and will display a table on the web page view.

    Figure: 12.5.5.1.1. Databound Examples using MS Visual Studio

14. Table Properties

    Configure the DataGrid control by right-clicking on the table and selecting Property Builder.

    Figure: 12.5.5.1.1. Databound Examples using MS Visual Studio

15. DataGrid Properties

    You can adjust most properties of the table such as colours, fonts, borders, etc. You can control paging aspects that will be taken care of automatically by the control, you only need specify the number of results per page. For now we only want to adjust the most important aspects of the table, where the data comes from.

    Figure: 12.5.5.1.1. Databound Examples using MS Visual Studio

16. DataGrid Bindings

    From the first General properties panel you must select the DataSource, DataMember, and select the Data key field (especially important for updatable tables). These properties may be selected via the drop-downs on the panel, allowing you to select the now-familiar controls configured earlier. Once configured, press the OK button to save the changes.

    Figure: 12.5.5.1.1. Databound Examples using MS Visual Studio

17. Preview

    Once the details have been saved the view of the table in the page will be updated to reflect the dataset details.

    Figure: 12.5.5.1.1. Databound Examples using MS Visual Studio

18. Page Initialization

    We are very nearly finished. The controls are all ready to be used, however, the final touch is to edit our Page_Load function. Double-click on the empty part of the web page view in Visual Studio and the associated .vb file will be opened. This is the file containing the actual code. You will be automatically placed at the Page_Load function. This is the page initialization section where will need to instruct the DataAdapter to fill with data, and then instruct the DataGrid to bind to that data.

    These lines of code need to be added by hand:

        SqlDataAdapter1.Fill(DataSet11)
        DataGrid1.DataBind()

    You will find that Visual Studio will offer some assistance in the form of intellisence command-completion while you are typing.

    Figure: 12.5.5.1.1. Databound Examples using MS Visual Studio

19. The End Result

    Next we will set the project's initial start-page by right-clicking on the form name in solution explorer and selecting Set as Start Page option. Finally we can run the project using the start button at the top. The project will automatically be built and a browser window launched automatically. Admire your results. When finished, on closing the browser windows you will automatically return to Visual Studio.

    Figure: 12.5.5.1.1. Databound Examples using MS Visual Studio

#### 12.5.5.2. Migrating ASP.Net Applications to Virtuoso

The previous section showed us how to build a very basic web application using an ASPX data-bound control. Now we will host this same application in Virtuoso demonstrating that IIS is no longer required for ASPX application deployment.

1. Locating your ASPX application

   Use explorer to locate the ASPX application you want to move away from IIS and re-deploy under Virtuoso. The previous section created the application in the IIS virtual directory represented by http://ash:8888/aspxdemo1/ which was physically located in c:\inetpub\wwwroot\aspxdemo1\. We can simply copy this directory and place it somewhere under either the VSP root directory or WebDAV. We will copy the application to a location in WebDAV for a local Virtuoso server.

   Figure: 12.5.5.2.1. Migrating ASP.Net Applications to Virtuoso

2. Add a Network Place to DAV

   From My Network Places in explorer or Network Neighborhood double-click on the Add Network Place shortcut to start the wizard.

   Figure: 12.5.5.2.1. Migrating ASP.Net Applications to Virtuoso

3. Network service provider

   Select the default option. Click next to continue.

   Figure: 12.5.5.2.1. Migrating ASP.Net Applications to Virtuoso

4. Internet or Network Address

   Here you specify the URL of DAV on the Virtuoso server. We are using Virtuoso on the local machine but this could be anywhere on the Internet. Click next to continue.

   Figure: 12.5.5.2.1. Migrating ASP.Net Applications to Virtuoso

5. Name the Network Place

   Provide the network place with a meaningful name so we can easily find this location in the future. Click on next to continue.

   Figure: 12.5.5.2.1. Migrating ASP.Net Applications to Virtuoso

6. Open the Network Place

   On the final panel of the wizard there is a checkbox to "Open this network place when I click Finish" that we will leave checked. Click Finish to continue and open the DAV directory.

   Figure: 12.5.5.2.1. Migrating ASP.Net Applications to Virtuoso

7. Connect to DAV

   When you attempt to connect to DAV you will be prompted for a User name and Password. These will be whatever you entered during the installation, possibly both dav, in which case type dav in both fields and press the OK button to continue.

   Figure: 12.5.5.2.1. Migrating ASP.Net Applications to Virtuoso

8. Copy the ASPX application to DAV

   Once the explorer opens up on the DAV network place we can copy the aspxdemo1 application directory to it.

   Figure: 12.5.5.2.1. Migrating ASP.Net Applications to Virtuoso

9. Configure Virtual Directory

   Now we have to configure a Virtuoso virtual directory. Launch a web browser and go to the Virtuoso server, which would be http://localhost/ for this example, and select Administration. You will be prompted for the DBA user name and password to administer Virtuoso. These will be whatever you entered during the installation, possibly both dba. When the menu appears select Web Services followed by HTTP Virtual Directories. You will see the default site listed, we will want to Edit URL mappings for this site. Click on the action link to continue.

   Figure: 12.5.5.2.1. Migrating ASP.Net Applications to Virtuoso

10. Add Virtual Directory

    The next page will list all mappings currently present for the Virtuoso server. Scroll down the page to the Add Virtual Directory button and click it.

    Figure: 12.5.5.2.1. Migrating ASP.Net Applications to Virtuoso

11. Select DAV Domain template

    On the next page select the DAV Domain template.

    Figure: 12.5.5.2.1. Migrating ASP.Net Applications to Virtuoso

12. Configure the Virtual Directory parameters

    We must supply a logical path, /aspxdemo1, in this case. We must also supply the physical path that this represents, we can either type in the DAV location or use the Browse button to the find the directory under DAV. The WebDAV checkbox will correctly already be checked. For now we will also set to Allow Directory Browsing, and Override execution permissions in WebDAV. Finally we must set the VSP Execution user to dba using the drop down. To save the changes click on the Add button at the bottom of the page.

    Figure: 12.5.5.2.1. Migrating ASP.Net Applications to Virtuoso

13. View the ASPX page hosted in Virtuoso DAV

    With the virtual directory configured we have only to test that it works as expected. On opening a browser at: http://localhost/aspxdemo1/WebForm1.aspx, we will see the same output as before.

    Figure: 12.5.5.2.1. Migrating ASP.Net Applications to Virtuoso

Note:

If ASPX hosting is attempted on a machine that never had IIS installed it is possible that ASP.NET is not configured, although required. The Virtuoso installer will take care of this for you in most cases but if you run into problems you may want to confirm that ASP.NET is configured correctly. You will have to use the regedit utility to edit the registry, changing a search-path so System.Web.dll can find aspnet_asapi.dll. Always exercise caution whenever editing the registry as invalid data can prevent your machine from operating properly.

You will first need to find out what version of the aspnet_isapi.dll library you have. The simplest way to determine this is by locating the file and right-clicking properties on it from explorer.

Assuming the version is 1.0.3705.288, we should enter the following details into the registry if the HKLM\Microsoft\ASP.NET key is missing (if your version differs change it accordingly):

    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET]
         "RootVer"="1.0.3705.288"
    [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\1.0.3705.288]
         "Path"="C:\WINDOWS\Microsoft.NET\Framework\v1.0.3705"
         "DllFullPath"="C:\WINDOWS\Microsoft.NET\Framework\v1.0.3705\aspnet_isapi.dll"

Previous Virtuoso Server Pages for XML (VSPX) | Chapter Contents | Next ASMX Web Service Hosting