This topic outlines what the prebuild application does.
This topic contains the following sections.
What does the prebuild application do?
The prebuild application is a console application that is launched by Visual Studio before the NodeConfigTool project is built. It's job is to verify and prepare the Phoenix web application and database scripts, so that they can be stored as Resources within the final binary of the NodeConfigTool application.
 Note: |
|---|
| prebuild is implemented as a Pre-Build event on the NodeConfigTool project and is launched when that project is being built. For more information, see Build the NodeConfigTool tool. |
The following is a list of everything prebuild does.
1. Delete Unecessary Files
Verify the bin/ folder exists.
The following files and folders are deleted:
- Delete the flashsource/ folder.
- Delete bin/*.xml. These are Xml comment files and should not be deployed.
- Delete bin/*.pdb. These files contains run-time symbol/debug information and should not be deployed.
- Delete bin/Phoenix.Resources.resources.dll
- Delete *.default from the root
- Delete web.config.default.2.0 from the root
- Delete web.config.default.3.5 from the root
2. Sanitize the appSettings.config file
appSettings.config is reset to factory settings by setting the values of the following attributes (blank values indicate an empty string). The goal here is to remove any settings that are needed for development. Recall that it is the NodeConfigTool that will take this clean appSettings.config and populate it with values that the user has entered into the various forms.
| Name of Attribute | New Value |
|---|---|
| ApplicationTitle | |
| ApplicationURL | |
| ConfigFolder | |
| LogFile | |
| OutgoingFolder | |
| SmtpServer | |
| SmtpServerPort | |
| SmtpUsername | |
| SmtpPassword | |
| SmtpFrom | |
| SysAdminName | |
| SysAdminEmail | |
| DefaultCulture | |
| DefaultStyle | |
| SearchFolder | |
| FTPEnabled | False |
| FTPUsername | |
| FTPPassword | |
| FTPUrl | |
| FTPDirectory | |
| FTPDirectoryPath |
3. Sanitize the web.config file
web.config is reset to factory settings by setting the values of the following attributes (blank values indicate an empty string). The goal here is to remove any settings that are needed for development. Recall that it is the NodeConfigTool that will take this clean web.config and populate it with values that the user has entered into the various forms.
| XPath to the attribute to set | New Value |
|---|---|
| /configuration/system.web/profile/properties/add[@name='Style']/@defaultValue | |
| /configuration/system.web/globalization/@culture | |
| /configuration/system.web/globalization/@uiCulture | |
| /configuration/system.web/compilation/@debug | False |
| /configuration/system.web/trace/@enabled | False |
| /configuration/system.web/customErrors/@mode | RemoteOnly |
| /configuration/system.web/httpRuntime/@maxRequestLength | 2000000 |
| /configuration/system.web/httpRuntime/@executionTimeout | 600 |
| /configuration/system.web/httpRuntime/@shutdownTimeout | 600 |
In addition, any existing connection strings in the /configuration/connectionStrings element are cleaned up. If any begin with PhoenixDB, its value is set to an empty string. All others are displayed in the Console window as warnings.
4. Archive the files of the web application
Zipping the Phoenix web-application takes a fair amount of time. There are approximately 3000 files and the resulting zip file is roughly 36 MegaBytes. To save some time, prebuild only performs a full zip operation if the existing PhoenixWeb.zip file is out of date. It does this by comparing the time stamp of PhoenixWeb.zip with the value of the LastWriteTime on the \trunk\Installer\WebDeployment\Release directory.
The final archive is copied to the \trunk\Installer\NodeConfigTool\data directory, where it can be embedded as a local resource when the NodeConfigTool project is built.
5. Prepare the SQL scripts for storage
This step has two main purposes:
-
Ensure that the concatenated SQL files are up to date based on the time-stamps of each script in it's source folder.
The table below shows the source folder that was used to create each concatenated SQL script. For example, the timestamp of 2functions.sql is compared with every *.sql file in \Phoenix.Database\_Functions. If any source files are more recent than the concatenated script file, a warning is displayed in the console.
Caution:If the concatenated scripts are out-of-date, you will have to execute the joinscripts.bat file manually. Refer to the section on how to Concatenate the Database scripts. SQL Script file Source Folder 2functions.sql \Phoenix.Database\_Functions 3views.sql \Phoenix.Database\_Tables and Views 4sprocs.sql \Phoenix.Database\Admin,
\Phoenix.Database\Library,
\Phoenix.Database\MapEngine,
\Phoenix.Database\Metadata,
\Phoenix.Database\Providers,
\Phoenix.Database\Registry,
\Phoenix.Database\Reporting,
\Phoenix.Database\SAGA -
Compress and encrypt the concatenated SQL files into a binary resource.
Compression of the script files is handled by the ICSharpZip library which shrinks the content of each text file, resulting in a binary file. As added security, and to thwart possible attempts to reverse engineer the database scripts, each binary is then encrypted using the DES standard. See Zip..::.CompressToFile for more information on this.
The illustration below shows what tools are involved to ensure that the SQL scripts are accurately packaged into the final executable.
