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
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]
Licensed to [email protected]
Index
A
SqlDataSource object code, 494
ABS function,
329
access modifiers,
81
updating an employee's address and
city
, 486
accessing directories and directory inviewing employee details,
469
with SqlDataSource control, 491
ActiveViewIndex property
, 131
,
132
AddressViewGridView,
646
ActiveX Data Objects .NET (
see
admin newsletter
, 159
ADO.NET)
Admin T
ools link, 588
Admin T
ools page, 396–397
Add Employee LinkButton,
647
in Design View
, 398
Add Extender…
, 649
Administer Website link,
588
Administration Tool (
see
ASP.NET Web
Site Administration Tool)
Administrators role