Developing with CSKDotNet
|
|
Developing with CSKDotNet |
This document contains an overview of the issues faced by developers extending and modifying the CSKDotNet version of the CSK 1.1.
VS.NET 2003 & .NET Framework 1.1:
There CSKDotNet project is an evolution of the CSK 1.0 CSVS version. It contains a ready-to-use Visual Studio.NET 2003 project file.
If you are using Visual Studio.NET 2003 and the .NET framework 1.1 all you need to do before you open the project is edit the CSKDotNet.csproj.webinfo file and change the URLPath attribute of the <web> node to point to the correct URL for your web server. By default, the CSKDotNet project expects to be installed at: http://localhost/CommunityStarterKit/ You may need to adjust this value if your CSK installation is not in the default location.
Then you can open the project by simply double clicking the csproj file in explorer. A solution will automatically be created when you open the project.
Using the .NET Framework 1.0:
No matter what development tool you are using, you should be able to compile the CSKDotNet project for the .NET Framework 1.0. However, you should remember to edit the web.config file in the application root. under the the <system.web> node, Remove the line:
<pages validateRequest="false" />The .NET framework 1.0 does not support the validateRequest attribute, and if you fail to remove it an error will be thrown when you attempt to view the site in a browser.
Using Visual Studio.NET 2002:
The CSKDotNet project can be used with Visual Studio.NET 2002; however, the supplied project file was created with VS.NET 2003 and will not work with older versions of VS.NET. To use VS.NET 2002 with the CSKDotNet project:
Database Projects:
The /SQL folder in the CSKDotNet project's root contains all of the scripts used to create and upgrade CSK databases. It also contains the command file (CSKDB.CMD) that executes these scripts. Though VS.NET can be used to edit these files as part of the CSKDotNet project, you may prefer to create a DataBase project in VS.NET instead. Using a database project will give you more functionality for developing, testing, and executing the scripts. Just create a new database project file (recommend you save the project outside of the CSK's folder structure) then copy the files form the /SQL folder into your database project.
Using other development tools:
No direct support is provided for using non-VS.NET based tools or command line compilers. You should be able to use the command line compilers though. Please note that you will need to create a resource file from /Engine/Framework/ContentPages/Controls/HtmlTextBox.resx using Resgen.exe. Without this resource, the Integrated FreeTextBox component will throw an dexception. The other resx files in the project are VS.NET generated, and shouldn't be required for the CSK's runtime operations. You can ignore them.
This is a revised version of an article posted by Stephen M. Redd at http://www.reddnet.net that provides advice and insight into general development and deployment practices. It is aimed at people deploying from local development CSK installations to production servers at a web hosting provider, but will also be useful for all CSK developers. The article is reproduced here with permission of the origonal author. It has been updated for use with the CSKDotNet project.
Introduction:
This guide explains how to move a local (development) installation of the CSK to a production web and database server. This guide is designed for people that need to deploy the CSK to a web hosting provider, or where running the installer isn't an option.
Before we begin:
This guide assumes you have a local installation of the CSK and a database configured. It assumes you have FTP or Front Page Extensions to the production web server. And, it assumes you have SQL Enterprise Manager and can connect to both the development and production database servers (options for transferring without Enterprise manager are mentioned, but I don't go into detail).
Setting up the destination web site:
If you haven't already done so, you need to make sure the server has the correct application mappings in IIS on your web site. If you are using a web hosting provider, chances are you'll need to contact them and have them make the changes for you. Your provider probably already knows how to do this. Just tell them this:
"I need new application mappings in my web site. Please map the *.gif, *.jpg, and *.jpeg extensions to the aspnet_isapi.dll (same mapping that *.aspx uses)".
That is the exact statement I've used with 3 different providers, and they all understood what I needed done immediately. If your provider doesn't understand then you may want to consider changing providers... but you can also send them the ISPOverview.htm file from your CSK's \documentation folder. This file contains info on how the mappings should be setup.
Getting the CSK web site ready for deployment:
If you've made any changes to *.cs files on your development system you may need to recompile your CSK application. How you do this depends on what development tools you are using. The important thing to remember is that you should compile without using debug flags (in VS.NET build in "release" mode) unless you plan to do development or debugging on the production server. You will also want to make sure that, in web.config, you change the <compilation> node's debug attribute to "false". You will also want to change the <customErrors> node's mode attribute to "RemoteOnly" (so visitors won't see stack traces and informative errors that could give hackers an edge, and also for better performance).
You will need to modify the database connection string in the web.config so that the CSK points to your production database server and uses the production server's user login and password.
Deploying the web site:
Now your CSK should be ready to deploy. You have several options for transferring the web site files. Most people will use FTP, however you can also use WebDAV via Front Page Extensions from VS.NET or other tools capable of using FP extensions.
One thing to know is that you do NOT have to copy the *.vb or *.cs files to the production server. These files are only used to compile the DLL file (in the /bin folder). They aren't needed to run the web site. If you do copy these to the production server, they won't hurt anything. I copy all the files up as a sort of off-site backup, but for security and efficiency reasons many people prefer not to copy them. If you are using VS.NET's copy project feature to publish over FrontPage Extensions, you can select the "copy only files needed to run this application" from the copy project options (this automatically omits the project and source code files).
For FTP operations, I highly recommend a product called FTP Voyager from RhinoSoft. This tool has the option to filter which files it transfers (you can exclude the *.cs files with this filter easily). It also has a synchronize feature that can be used to only push new and changed files, making updates as simple as clicking a button. It does require a small amount of configuration that is beyond the scope of this document, but once configured this is an amazing deployment tool.
Deploying the Database:
This is the hard part. Getting that database up to the production server.
The most common need is to transfer the existing SQL objects and data from your local database to the production database server. The easiest way to do this is to use the DTS functionality in SQL Enterprise Manager. This tool allows you to copy objects from one database to another with a friendly GUI interface. It can transfer data between SQL servers or MSDE databases without you even knowing which is which.
To use DTS, open Enterprise Manager and make sure you have a SQL Server registration for both your production and development databases. You will have to already have the destination database created and a SQL login with db_owner permissions. Assuming the destination database exists, open up your local server, and find your development CSK database. Highlight the CSK development database then right click and choose All Tasks, then choose Export Data. This will invoke the DTS wizard. In the wizard follow these steps:
- Click next on the DTS Import/Export screen to bring up the "Choose a Data Source" screen.
- Enter in the login information for your local database, and choose the CSK database from the drop down list if it isn't already selected for you. Click next to proceed to the "Choose a Destination" screen.
- In the "Choose a Destination" screen, enter the name of your production database, enter the login and password, and choose the destination database from the drop down list.
- Click next to move to the "specify table copy or query" screen. Choose the last option for "copy objects and data between SQL Server Databases".
- Click next to move to the Select objects to copy dialog. Uncheck the "Use Default Options" checkbox.
- Click the "options" button to invoke the "Advanced copy options" dialog.
- Make sure all 3 options in the "Security Options" area are unchecked. You will not be copying the users and roles, permissions, or logins. The other options should be fine as they are. Click OK to return to the "select objects to copy" screen.
- Click next to go to the "save, schedule, and replicate" screen. Leave "Run Immediately" checked here. You may want to save the DTS package for later execution. I recommend saving to SQL Server so you can run the DTS copy again later without having to go through the wizard again.
- When you are done, click next to go to the summary screen, then next again to run the package.
That's it. Your database should copy over without error. If there is an error double click the errors in the error dialog that will appear to see the exact problem.
Other ways to transfer data:
If you don't have Enterprise manager your options are a lot harder. There are a number of 3rd party tools that can do DTS type copies, but most of these tools aren't free. If you can't afford to buy one of these tools, perhaps you can download a trial version long enough to get your initial deployment done. You can use BCP (Bulk Copy Program). This is a command line data and object transfer tool (DTS in Enterprise manager is just a GUI front-end for BCP). BCP comes with SQL server and MSDE both if I'm not mistaken. Using BCP is painful and complex so if you resort to this tool you'll want to make sure you read the documentation and test thoroughly.
I've also heard that some people have transferred CSK data by running the create scripts manually against the production database, then using Microsoft Access to copy the data to the production server. This requires some skill and a copy of MS Access. I've no first-hand experience with this technique, and no idea if this really works or not.
Post transfer:
If you only had one community in your CSK site, you may not have to do anything else after you copy the database and web site files. You can fire up a browser and test that your transferred CSK site works. However, if you do have more than one community, you may need to invoke the ISPAdmin tool on your production server and change your domain and sub-domain settings for each community.
Ongoing Development:
If you intend to continue doing development on your local system, don't forget to change your web.config back to allow debugging and point at the local SQL server, and you may want to recompile again with debug flags (or change VS.NET to "debug" mode.
After initial deployment, you may make changes to your development version of the site. I do recommend that you continue to work from the local SQL server rather than the production one, but I don't recommend you ever use DTS to transfer local changes to production again. If you need to make changes to the production database run scripts for each change against the production database separately.
You can follow the reverse process to make a DTS copy of the production database and transfer it to your development system (to keep your local copy "fresh"). If you make a reverse DTS like this, I recommend you delete all rows from the Community_Notifications table on your local database after the transfer. That way, your dev site will not email notifications to your site's real users.
As for the web site. Changes to *.cs files only require you to compile (remember to compile without debug flags) and copy the DLL from the /bin/ folder. Other files, including *.ascx files and images will need to be copied up to the production server if you change or add any. Unless you make changes in web.config that need to go to the production server, I recommend that you don't copy web.config up again (it is very easy to forget to change the database connection and debug settings in web.config).