Continued from Part Three - Continued in Part Five

Deployment…

After I finished the initial development of the Weblog project, I decided to first try and deploy the application on my own internet web server machine (at home), which is connected to the internet using a 1024/512 ADSL modem. Since it’s a machine in my own attic (I work from home), I can quickly test and diagnose the ASP.NET application, and adjust whatever is needed when needed. Note that this deployment web server machine is actually the same system that’s running my Skype answering machine (see http://www.drbob42.com/Skype) and garden “motion detection” webcam applications (see http://www.drbob42.com/webcam), so it’s getting a bit crowded. But at least it’s not a development machine, meaning there’s no Delphi 2005 installed, so in that respect it can be thought of as a “clean machine”.

Such a clean machine is needed for a deployment test, since only that will help me to determine which assemblies and related files are needed for a possible deployment on a ISP web server like TDMWeb (see http://www.tdmweb.co.uk). Obviously, on my development machine, all BDP and ECO assemblies will be present, and now it’s the task to determine which of these assemblies are needed to deploy and run the Weblog project elsewhere.

MSDE

Before we can deploy the ASP.NET ECO Weblog application, I should first make sure the database is transferred. In fact, I should first make sure the DBMS itself is installed on the web server. I’m using Windows 2003 Web Edition as operating system on my web server machine, which means I cannot install the full SQL Server 2000, but have to install MSDE (Microsoft SQL Server 2000 Desktop Engine) instead. MSDE is included with Delphi for .NET itself, so you should already have it, but it can also be downloaded from the MSDN website. Of course, I could have used another BDP-compatible DBMS like InterBase or NexusDB, but since I’ve already designed the model and bound it to a SQL Server / MSDE database, I don’t want to migrate at this time (but it might be a nice follow-up story for later).

After MSDE is installed, it’s time to reproduce the database on the web server side. Fortunately, this is an easy task. We first need to create a database with the same name (i.e. weblog) which can be done with the following command-line:

OSQL -i Weblog.sql

with the -E or -U switch to ensure you're using the right SQL Server connection, where the Weblog.sql contains only the following two lines of OSQL commands:

CREATE database Weblog
GO

This creates two database files: Weblog.mdf and Weblog_log.LDF. When you’ve created these two database files on the deployment web server, you can stop SQL Server and then copy the Weblog database files from the development machine to the web server machine. Note that the SQL Server DBMS must not be running (on either machine) while copying the database files (which are Weblog.mdf and Weblog_log.LDF in my case). Otherwise, if SQL Server is still running, you may encounter problems when you try to read (from the development machine) or write (on the web server) the Weblog database files.

No OS Authentication

When using MSDE as database on Windows XP or Windows Server 2003, you will get error messages when deploying (on Internet Information Server) ASP.NET web applications that try to connect to this database. The error is due to the fact that MSDE by default only allows Windows OS Authentication to be used, yet an ASP.NET user runs under the NT AUTHORITY/NETWORK SERVICE account which has no access permission to your databases. The trouble is that by default, MSDE only allows OS Authentication to be used. Unless you installed MSDE with the SECURITYMODE=SQL parameter, which most people don’t know about until after they installed MSDE. With this parameter, MSDE will be installed with mixed mode authentication: both Windows OS Authentication and SQL Server Authentication.

In order to turn Mixed Authentication on after you’ve already installed MSDE, you need to manually modify the registry. Assuming MSDE was installed as default instance, you need the registry value at HKLM\Software\Microsoft\MSSqlserver\MSSqlServer\LoginMode and change it (carefully!) from 1 (Windows Authentication only) to 2 (Mixed Authentication). Note that you need to restart MSDE to allow the new setting to become effective. See also http://support.microsoft.com/default.aspx?scid=kb;en-us;325022

Note that this is only an issue with SQL Server 2000 Desktop Engine (MSDE), and not with the full SQL Server 2000 edition (but according to Microsoft’s rules, we cannot use that version on Windows 2003 Web Edition, so this is like a catch-22).

Weblog ASP.NET Application

Once the database is installed and ready on the web server, we can start to migrate the weblog ASP.NET application itself. First, it’s time to create the virtual directory for the ASP.NET application.

Start Computer Management Console (for example by right-clicking on My Computer) and go to the Internet Information Services node, open the Web Sites node and select the Web Site for which you want to create the virtual directory. Right-click on the web site, and do New | Virtual Directory. This will produce a Virtual Directory Creation Wizard that takes you through the steps to create and configure a virtual directory.

You first have to specify the alias for the virtual directory. Specify Weblog, as shown below:

Figure A. Virtual Directory Alias

The next step is the location for the virtual directory, for which I usually pick a directory like c:\inetpub\wwwroot\Weblog

Figure B. Web Site Content Directory

The last step in the Virtual Directory Creation Wizard dialog involves setting the permissions for the virtual directory. You only need to enable Read and Run scripts (such as ASP) and no Execute, Write or Browse rights.

Figure C. Web Site Content Directory

Once this is done, you can continue and finish the Virtual Directory Creation Wizard. Up until now, there is a good chance you need help from your ISP (for example when creating the SQL server database or the virtual directory).

There is one more step that needs to be performed before we can leave the remaining deployment tasks to Delphi 2005. We somehow need access to the virtual directory, so we can upload our ASP.NET project files. Usually this is done by FTP, and your ISP will have created an FTP account to upload the files to your virtual directory. If you’ve created your own virtual directory, then you need to create an FTP account for the virtual directory (or the entire website).

Delphi 2005 Deployment Manager

Deploying ASP.NET applications before Delphi 2005 was a process of collecting all .aspx files, the .asax, web.config, assembly itself and all related assemblies (most of which will be mentioned in the References list of your project). For each new version of the ASP.NET application, you had to collect everything all over again, or find a way to automate the process.

Delphi 2005 has done just that: it includes a Deployment Manager that can be used on ASP.NET or IntraWeb projects – and is flexible enough to be used in other situations as well (once you find out how, but that’s another story).

Go to the Project Manager, right-click on the Deployment node and select the “New ASP.NET Deployment” option. This will show the ASP.NET Deployment Manager page, listing all the files that are part of your ASP.NET project and need to be deployed. There are a few files that are new compared to last month, since I’ve added a little header.htm with some images in a gif directory, as well as a Stylesheet.css to ensure that the look and feel of the ECO Weblog application is a bit more pleasant.

However, although there may be more files than expected, there are also some files missing. Some readers may notice that the list of files doesn’t appear to include all required assemblies. Specifically, it doesn’t show the BDP or the ECO assemblies in the screenshot below:

Figure D. Delphi 2005 Deployment Manager

A way to justify this is to note that the BDP assemblies (like Borland.Data.Common.dll and Borland.Data.Provider.dll) and ECO assemblies (like Borland.Eco.Handles.dll, Borland.Eco.Interfaces.dll, Borland.Eco.Persistence.dll and Borland.Eco.Web.dll) are signed assemblies. Since ASP.NET doesn’t officially support assemblies signed with a strong name to be deployed in the bin directory or a virtual directory (according to MSDN), these officially need to be deployed in the Global Assembly Cache. You may have to contact your ISP with regards to those deployment needs. However, as we’ll see in this section, it’s not really required….

BDP and ECO Assemblies

The real explanation why the Borland BDP and ECO assemblies don’t show up in the Deployment Manager is because of the way they are referenced in our project. If you open up the References node for the Weblog project, you’ll notice the Borland.Data.Common.dll and Borland.Data.Provider.dll as well as the Borland.Eco.Handles.dll, Borland.Eco.Interfaces.dll, Borland.Eco.Persistence.dll and Borland.Eco.Web.dll. Yet none is mentioned in the Deployment Manager.

In order to add the BDP and ECO assemblies to the deployment manager’s list of files, we need to right click on each of these assemblies and select the “Copy Local” option (or set this option to True in the Object Inspector). Recompiling the Weblog application will now add the two BDP and four ECO assemblies to the list of deployment files.

Figure E. Delphi 2005 Deployment Manager

However, it’s still not enough, since you may remember that we use SQL Server / MSDE. And a BdpConnection component connecting to SQL Server (which is used to store the EcoSpace). And yet the list of files doesn’t show a SQL Server specific BDP driver. The reason for that is the fact that the BDP drivers are loaded dynamically based on their reference in the ConnectionString property of the BdpConnection component. This is the place where the reference is made to the Borland.Data.Mssql.dll assembly. In order to “fix” this, we should also add a reference to the Borland.Data.Mssql to our project. Just right-click on the References node, and select “Add Reference”, which gives the following dialog:

Figure F. Add Reference to Borland.Data.Mssql

After the reference to Borland.Data.Mssql is added, right-click on the new node to ensure the Copy Local option is enabled, and then recompile the project. The Deployment Manager should now have a fairly complete list of files to deploy.

However, we’re not connected to the deployment web server yet, so we must use the Destination drop-down combobox at the top of the dialog to enter either a FTP or File connection to the target machine. When connecting to my internet machine, the list of files to deploy compared to the development machine is as follows:

Figure G. Deployment Manager - connected

Once the deployment locations are defined, all you need to do to deploy is open a specific deployment node and click on the “deploy new and changed files” button. It will then automatically copy or FTP upload all your new and modified files. That’s really a time-saver, especially in those deadline situations where all you want to do is focus on the changes you make to the code, without needing to worry about the actual files to deploy (so you will never accidentally forget to deploy any file that belongs to the project).

First Test

Once all these files are deployed, you can start the application by specifying the address of the Windows 2003 Web server as prefix to the ASP.NET Welcome page URL. That would normally be http://localhost/Weblog/Blogs.aspx, which translates to http://Wanadoo42:4242/Weblog/Blogs.aspx on my local internet machine (where Wanadoo42 is the DNS name of my server, and 4242 is the port number of the test website).

An error message may tell you that not everything works fine. The following screenshot shows the error message as it appeared on my test web server:

Figure H. Server Error

Unfortunately, it’s not clear at all what’s the problem, since we get a so-called “user friendly error message”. These “user friendly” but otherwise useless error messages can be changed into a bit less user friendly, but a bit more useful (for the developer) error messages using the customErrors node in the web.config file:

<!-- CUSTOM ERROR MESSAGES
     Set customErrors mode values to control the display of user-friendly
     error messages to users instead of error details (including a stack
     trace):
     "On" Always display custom (friendly) messages
     "Off" Always display detailed ASP.NET error information.
     "RemoteOnly" Display custom (friendly) messages only to users not
     running on the local Web server. This setting is recommended for
     security purposes, so that you do not display application detail
     information to remote clients.
     -->
     <customErrors
     mode="RemoteOnly"
     />

In order to see the error message, you need to change the value of customErrors from RemoteOnly to Off – just for a short while, don’t forget to set it back to RemoteOnly when the deployment is done!

<customErrors
mode="Off"
/>

This will produce the following more useful error information (which is useful, but could also contain specific information about the application that you don’t want to share with everyone, hence the need to turn customErrors back to “RemoteOnly” as soon as possible):

Figure I. Missing Borland.Eco.Core.dll

As soon can see on this screenshot, it appears that Borland.Eco.Core.dll is missing, so we need to add it to the list of References (with Copy Local set to True), using the dialog from Figure F again. And in case you have multiple versions of assemblies on your development machine: always make sure to add the right one (in this case version 9.0.1882.30496).

The next error message is about assembly Borland.Delphi.dll, which should also be added (with Copy Local set to True). This is the RTL of Delphi, and I should have added it to the list earlier, since it’s always required.

The final error message we then get is about a missing Borland.Eco.Ocl.ParseCore.dll, which we also should add to our reference list, with Copy Local set to True.

Then, it started to work on my machine, and this leads to the current deployed version of the Weblog application on my test web server. It will remain there for a month at least, while I’ll add some enhancements and new features. The first new features are visible already (like the presentation of the blog contents in a plain text field rather than a TextBox which required scrolling), and will be covered and explained in detail next month.

Next Time...

By the time you read this part, the weblog should have been live for some time, and I’m sure I’ve made some modifications to the application and perhaps even to the underlying model. This means that next time, I can cover some of these enhancements, and will include full source code for the project again.

After that (in part 6), it’s time to add an RSS feed, which means writing an ASP.NET Web Service to use the ECO II model and generate some RSS output.

For now, have fun checking out my live weblog at http://www.drbob42.com/blog, feel free to leave me any comment, and I’ll get back to you next month with more blogging!

All this and more next times, so stay tuned...

Copyright © 2005 Bob Swart

September 2005