Build Your Own ASP.NET 3.5 Website Using C# & VB (117 page)

Read Build Your Own ASP.NET 3.5 Website Using C# & VB Online

Authors: Cristian Darie,Zak Ruvalcaba,Wyatt Barnett

Tags: #C♯ (Computer program language), #Active server pages, #Programming Languages, #C#, #Web Page Design, #Computers, #Web site development, #internet programming, #General, #C? (Computer program language), #Internet, #Visual BASIC, #Microsoft Visual BASIC, #Application Development, #Microsoft .NET Framework

BOOK: Build Your Own ASP.NET 3.5 Website Using C# & VB

5.91Mb size Format: txt, pdf, ePub

Read Book Download Book

see this in action. Open
Default.aspx
and add a line of text like the one shown in

bold here:

Company News

We'll add some news later.

We added some news.

Company Events

We'll add company events later.

Save the file and open the
Copy Website
tool again. Note that there is now a blue

arrow next to the
Default.aspx
file icon and the status is now listed as
Changed
. Select everything, as we did above, and click the double-arrow button again. Since we’re

working locally, the action will be a little too quick for us to catch, but if we click

the
View Log…
button, we should see that, even though we had all the files selected,

only the
Default.aspx
has been updated:

Synchronize between 'C:\Dorknozzle\VB' and 'C:\DorknozzleTemp'

started at
date and time
.

Copy file Default.aspx from source to remote Web site.

Synchronize between 'C:\Dorknozzle\VB' and 'C:\DorknozzleTemp'

is finished. Completed at
date and time
.

Don’t forget that synchronization is a two-way street. A changed file on the remote

site will be copied to the local site. The
Copy Website
tool will indicate when files

on the remote site have been updated in the same way that it indicates local updates.

Now that we’re done, feel free to delete the
C:\DorknozzleTemp
folder at your leisure. Licensed to [email protected]

Appendix B: Deploying ASP.NET Web Sites

701

Do take care when using this tool—it can easily lead to accidental file overwrites

if you’re not careful. For example, your
Web.config
file is likely to be different in

production than it is in your development setting and you don’t want one overwriting

the other. There isn’t an
Undo
button, so be certain before you synchronize.

ASP.NET Deployment “Gotchas”

Deploying ASP.NET sites can get frustrating at times. Here are a few gotchas that

I’ve run into which could save you some time, some hair, your liver, or all three:

1. If you have disabled custom errors, getting the dreaded error “An application

error occurred on the server. The current custom error settings for

this application prevent the details of the application error from

being viewed remotely (for security reasons). It could, however, be

viewed by browsers running on the local server machine.” can be painful!

It usually indicates that the web site you’re using is configured to use a version

of ASP.NET that’s different than the one your
Web.config
file wants. Be sure to

double-check that with your host.

2. Most shared hosts run at a security level of Medium trust. You’ll probably figure

this out when you try to either access a file outside of the web root or access a

remote URL and get the dreaded System.Security.SecurityException. The

best solution is to run your application locally at the same security level, so you

can discover any issues ahead of time. To do so, add the following line to the

system.web section of your
Web.config
:

3. This issue isn’t especially ASP.NET-specific, but it’s worth remembering that

you should never do anything in production without having a backup of the

previous state of the web site. If something goes wrong when you push it to production, at least you can get back to
status quo
. The previous working state of the web site is often better than a non-functional web site.

4. Hard-coded file paths will come back to bite you. Remember to resolve all paths

using Server.MapPath
(we used this method in the section called “Writing

Content to a Text File” in Chapter 14
), or to handle the issue with configuration Licensed to [email protected]

702

Build Your Own ASP.NET 3.5 Web Site Using C# & VB

values. To assume that your site will always run in
C:\MyApplication
is not a wise

approach.

5. I mentioned this above, but be certain that your host supports the features you

wish to use. A good example of this would be ASP.NET AJAX support on

ASP.NET 2.0, which some hosts have not yet installed, even though it’s been a

production release for some time.

This is not a complete list of everything that can go wrong. But remember: if you

run into an insurmountable issue, contact your host or the server administrators.

They’re there to help you—in theory, at least!

Using the SQL Server Hosting Toolkit

As we saw above, deploying the web site is fun and easy—it simply involves

copying some files. By contrast, getting your database going can be very difficult if

you’re not careful. In this book, we’ve been using SQL Server Express, which includes one very easy deployment option—user database instances in which the database file itself is included and deployed with the project. Unfortunately, many

hosts don’t support this feature, preferring to push users to a dedicated SQL Server

instance, which renders this easy deployment and management option useless.

That said, SQL Server databases are notoriously hard to transfer if you don’t have

direct access to the server, which is even harder to obtain! Rather, you need a tool

that can generate an SQL script that can be executed either from SQL Management

Studio or via an ASP.NET web page if you can’t access even the database server

directly. Your first approach might be to use the Generate Scripts functionality in

SQL Server Management Studio Express—which does work to some extent. It does

a fine job of generating the scripts you’ll use to create your database objects—the

tables and stored procedures we made in this book. But it doesn’t know what to do

with your data, which is often a key feature in a database-driven web application!

Conveniently, Microsoft has created a very handy tool that’s designed to help nondatabase administrators deploy SQL Server Databases: the SQL Server Hosting Toolkit. The software can be found on the Microsoft CodePlex web site at

http://www.codeplex.com/sqlhost/. Click on the
Database Publishing Wizard
link to

grab the current release, which is version 1.1 at the time of writing. Once you’ve

Licensed to [email protected]

Appendix B: Deploying ASP.NET Web Sites

703

downloaded the file, close all running Visual Web Developer Express instances and

install the product with the default options.

Running the wizard is easy. Find
Microsoft SQL Server Database Publishing Wizard
in

your
Start
menu, then run the
Database Publishing Wizard
:

1. Click
Next
to get past the introductory page.

2. Specify
localhost\SqlExpress
in the
Server
field and leave
Use Windows Authen-
tication
selected.

3. Select the Dorknozzle database, leave the
Script all objects in the selected database

box checked, and click
Next
.

4. Choose the
Script to file
option and select a handy location for the generated SQL

file. Click
Next
to continue.

5. The
Select Publishing Options
page is a bit more interesting than the last few. Examine the options, but make sure you leave them set to the defaults before you click
Next
. Be especially careful about the first option. If you’re making an update

to your database, you probably don’t want to generate DROP statements, unless

you actually want to delete your data.

6. Click
Finish
and let the tool create your SQL script.

Now browse to the location you chose in step 4 and open the script file with SQL

Server Management Studio Express. You’ll notice this is a rather obtuse mess of

SQL code, but you should see a number of INSERT statements among the other SQL

statements. In any case, given proper credentials, you’ll be able to connect to your

host’s SQL server and execute this file to deploy your database.

There’s one big potential land mine here: the script we created could include DROP

statements. So, if we were pushing this into an existing database, we could very

easily destroy all the existing data. And if there’s one thing that will cost you dearly

in the software development field, it’s losing people’s data. My rule of thumb is

that before touching the production data, make absolutely certain you have a good

backup of the database. Your host or your database administrator should be able to

help you with this problem. I’ll also add that, in its current version, this tool is

better suited to initial deployments than it is to updating your application. Your

own, hand-crafted SQL ALTER scripts still rule the day on that front.

Licensed to [email protected]

704

Build Your Own ASP.NET 3.5 Web Site Using C# & VB

For further reading about the Hosting T
oolkit, head over to the CodePlex site.2
There, you’ll find a
discussion forum
3 as well as several good tutorials and demonstrations that show how to make the best use of this tool to deploy your application in various

scenarios.

Dealing with SQL Security

Another issue that drives many novice developers crazy is dealing with SQL Server

security. We have not really had to touch on the subject in this book, as we’ve been

relying on a default feature of SQL Server security whereby local administrators are

automatically granted full access to all databases and database objects. And, since

we were using Visual Web Developer’s built-in web server and Integrated Security

features, our application was accessing the database in our context with full privileges. Running your application in the cold, hard world of the Internet will make things a bit more complex.

Your first resource should be your host or database administrator. They hold the

keys to the bank—specifically, they can tell you which account you should be using

to access your database. W
e explored the use of SQL Server authentication in the

section called “Setting Up Database Authentication” in Chapter 9. In many cases,

with most web hosts, you’ll have a single SQL user account to access the database,

and that account will have “database owner” privileges to your database. However,

depending on the host, your database account might be a bit more restricted.

To work around this issue, first ensure that the account in question has been created

on the SQL Server and granted a login to your database. From there, one could take

the easy way out by simply adding this account to the
db_owners
role. But beware—in

this context, users can do just about anything they want to your database should

they find a way to execute arbitrary commands. A better method is to assign only

the required permissions. In most cases, you can achieve this goal by using a statement such as the one below to grant the account privileges on the DBO schema:4

2 http://www.codeplex.com/

3 http://www.codeplex.com/sqlhost/Thread/List.aspx

4 Note that in many shared hosting environments, your database might not be using the default DBO

schema. If you examine the table names in SQL Server Management Studio Express, the name of the schema should be visible—your employee table will be called
xxx
.Employees rather than dbo.Employees.

Licensed to [email protected]

Appendix B: Deploying ASP.NET Web Sites

705

GRANT SELECT, INSERT, UPDATE, DELETE on SCHEMA :: DBO to
account

That will allow the SQL user account to run SELECT, INSERT, UPDATE, and DELETE

statements while also granting the account the powers necessary to execute stored

procedures. However, it will not allow users to complete nefarious actions such as

dropping or creating database objects.

Licensed to [email protected]

Index

paging, 498

SqlDataSource object code, 494