What do you need to configure your machine to use the Ektron Framework?
How do you install the Ektron Framework?
What else do you need to know when you install?
In order to follow along with this book's development samples, you'll need a few programs installed on your computer. This chapter covers the basic software requirements to develop for the Ektron Framework, followed by instructions on setting up the OnTrek starter site on your development machine, followed by a discussion about approaches for team development.
Once your system is configured with the required software, you can install the Ektron Framework. The list of required software to run Ektron locally as a developer is not too long. You must have a copy of the following:
Windows with IIS 6.0 or greater and .NET Framework 3.5 or greater, along with a SQL Server 2005 or later instance available.
Visual Studio 2005 or later. Any text editor will work for developing .NET code, but Visual Studio provides IntelliSense and other features that are invaluable when working with code you are not familiar with.
Beyond that, you'll simply need a recent browser — Internet Explorer 7 or greater, or Firefox 2 or greater — and any Webkit browser such as Apple Safari or Google Chrome, supported by the Ektron Framework.
Visual Studio 2005 or later. Any text editor will work for developing .NET code, but Visual Studio provides IntelliSense and other features that are invaluable when working with code you are not familiar with. Visual Web Developer is also an option that will work for most developers, but keep in mind that it is limited in its debugging capabilities. For example, Visual Web Developer cannot attach to a process, which is the recommended method of debugging a site. Also, Visual Web Developer cannot be used to build Ektron Extensions.
The installer for the Ektron Framework can be found at http://www.ektron.com/download_center/. The installer will set up the support files and Windows Service. It presents you with the option of installing one of the included starter sites, which can be used either as examples or as the basis of your final site, to the local machine. Finally, it offers to install the SDK. This allows for building Ektron Extensions. These expose system events like AddUser and OnPublish to the developer.
The installer asks you at one point for a license key. For a local installation, it is easiest to just leave the box blank — this sets the framework to work only when accessed through localhost. In a distributed development environment with a central server, or when you are ready to move to a staging or production server accessed through another URL, you need a license key for the URL. Trial license keys can be requested through http://www.ektron.com/download_center/. To get a non-time-limited license, speak to your account manager or sales engineer at Ektron.
You can install by doing the following:
Start your installation by running CMS400Basev80.exe. This installer guides you through installing the core files and the Ektron Windows Service. Once completed, it asks you if you would like to install a site. Select No, since you want to install a starter site.
Go to
http://www.ektron.com/cms400-starter-sites.aspxand download the OnTrek Starter Site. Running the installer adds the information needed to create an instance of the site to your Program Files directory.Once complete, go to Start
You are asked what site and host you want to install to — leave these as the defaults.
You need to specify where the site files will reside; the default here is fine, unless you need to install somewhere else, for instance if you have multiple site roots defined in IIS. The Wizard will now install the site files.
Once the installation completes, you will have a live site, but the site won't do anything since you haven't set up the database yet. That database setup is the next thing the Wizard will ask for. Specify the connection parameters to your SQL instance, and it will configure the site to connect to the instance and create the database for the site.
When this Wizard completes, you can go to http://localhost/OnTrek/, and the example site for this book will be there.
When acting as a single developer, the requirement to manage the source and assets is easily fulfilled. In this scenario, all development is done locally. When the developers are ready to push the site live, they can copy all the files to the production home and perform a backup of the database followed by a restore at the destination. However, when working with a team of developers, a number of additional requirements may present themselves.
The first item typically required when multiple developers need to collaborate is a source control system. Almost any versioning system works — Subversion, Git, Perforce, and Visual SourceSafe are all fine. Only the folders under development should be maintained in the repository. This means it is typically safe to leave the Workarea unmanaged. It is also usually best to leave the .config files in the root of the site unmanaged, as the configuration from one machine to another is likely to change.
A typical setup for managing source is to use Subversion to manage the source code. A single server is set up to view the current head revision of the source, and the database is set up on that server. The process to set up this portion is as follows:
Install either a min site or a starter site to that machine, and then perform an
svn importon the directory. Make sure to exclude all .config files, as well as the Workarea, bin, uploadedfiles, and uploadedimages directories.Once the import is complete, use
svn checkoutto turn the site directory into a working copy.From here on, you can just run
svn updateto bring the machine to the head revision. Depending on your source control platform choice, this can usually be automated. For instance, Subversion has a folder that contains executable scripts, so it is straightforward to attach to the post-commit event hook, and force a refresh of the server at that time. Likewise, when using the Perforce daemon, it is possible to configure the daemon so that the working directory is updated at a regular interval.Every developer should then have their own copy of the site installed locally on their machine, where changes are made through the development cycle. To initially set this up, install a min site to each machine, and then perform an
svn checkoutto bring the site up to the same file base as the other machines.
At this point the typical setup has each developer machine connect to the master database on the review server, by modifying the web.config. Through the use of load balancing, the associated assets are kept up-to-date across the machines.
There are two main options for managing content across a team of developers. The two options rely on different configurations of client server architectures. The one you choose for your project will depend on your license, your team size, and your requirements. The main difference between the two choices is whether you utilize a single shared database for all developers, or whether each developer has a local database, where each database is synchronized to each other.
In both situations, it is advised that each developer have his/her own ASP.NET instance. This allows for developers to feel free to use breakpoints, and debug output without interrupting the other developers on the project. Whether you share the database or use separate instances is determined by personal preference.
The two options are:
To use separate databases, one per development instance: If you want to use this method, you should make sure you have eSync configured. eSync manages updating the database on both sides through the use of the Microsoft Sync Framework. It can also optionally update the templates and other files on the file system, but it is usually more straightforward to use your source control software. eSync is included with an Enterprise license, and is available as an addon with a Professional license.
To have one shared database that's used with many development servers: The benefit with this configuration is there is no wait time for the database to be synchronized between the servers. The only caveat is that you should use load balancing to make sure that assets are updated on each of the development servers. Load balancing is a feature of the Ektron Framework which allows multiple servers to keep assets including library items and search summaries synchronized. If load balancing is not set up, any assets uploaded are not copied to the other sites. This prevents features such as Search from functioning properly, and may cause content to appear incorrectly. Figure 4-1 depicts the differences between the two options:
More information on each of these methods can be found in the CMS400.NET Manual, installed with the Ektron Framework. Chapter 18 in the manual covers eSync in depth, while Chapter 22 in the manual has a section dedicated to load balancing.
There are a few tips to help you streamline your development process. Some of the items in this section are performance tips that can help your team develop faster, and some are quirks to keep in mind that make working with the Ektron Framework slightly different from working with other ASP.NET sites.
Speed: One of the issues developers run into is not a problem, but rather a question of speed. The typical development server is configured to build on demand by having all the source in the website directory. When the ASP.NET worker process receives a request for a given page, it ensures the files have not been modified since the last time the site was compiled. If they made changes, however, the ASP.NET worker process compiles the relevant files at that time. This makes development straightforward, because there is no build process that must happen after each edit, making it easier to modify code and test the modifications.
Time: Many development teams are accustomed to building the site from Visual Studio in order to debug the code they are writing. A frequent complaint is the amount of time required to build the Workarea folder in the site folder. In a normal project, you can simply right-click a particular folder and select Exclude from Project. However, in an Ektron project, since there is mixed language, there can be no .csproj or .vbproj configuration file, so there is no way to mark a folder as excluded. The workaround for the inability to exclude files is to simply mark the Workarea folder as hidden in Windows Explorer. This typically reduces the build process by several minutes. This is necessary only in a project that is built from Visual Studio — a compiled on-demand site will only compile the required files, which rarely includes much of the Workarea.
Debugging: Part of the reason teams sometimes decide to compile their project from Visual Studio is a lack of clarity on how to enter into debug mode without pressing F5, which initiates a build. However, debugging without precompiling is actually pretty straightforward, and is, within Ektron, the preferred method of day-to-day development. To debug your site in Visual Studio without compiling, first make sure your web.config is set to debug mode. This setting is stored as an attribute (
'debug="true"') in the Compilation tag in the System .Web section. Now, in Visual Studio, select Debug
Setting up an Ektron development instance is fairly straightforward, but here are some take away points:
All the elements of the Ektron Framework are bundled into an intuitive installer, which takes most of the headache out of the operation.
There are also several open source starter sites provided by Ektron that can be great jumping off points for your own development efforts.
Beyond single-server development, there are also several options that allow for rich collaboration between developers, shortening the lifecycle of synchronization so that less time is spent keeping everyone up-to-date, and more time is spent developing new features.
By choosing an appropriate development practice early on, you can help ensure the success of your project by keeping everything moving smoothly as you move towards completion of your project.