in

ASP.NET Weblogs

Phil Scott's WebLog

Quite exciting this computer magic

Deploying the ASP.NET 2.0 Personal Site Starterkit

I've seen quite a few questions regarding how to deploy the Personal Site Starter Kit to a hosting account, so I thought I'd write up some guidelines on how to do this.  These directions have really only been tested with the MaximumASP's free beta account, but they should work with any of the other providers assuming they give you some type of SQL Server as the backend.

The main problem with deploying the Personal Site Starter Kit is that by default it assumes that 1) you have SQL Express running on the webserver and 2) you are using the configuration settings provided in machine.config for the membership / role providers.  Unfortunately, SQL Express is simply not meant to be ran on shared webservers, so obviously we are not going to be able to use this as our backend.  Luckily, Microsoft has recently released some generic scripts for creating the database for the Personal Site Starter Kit, so we can use those to create the tables needed on our SQL 2000 database.

Step one is going to be creating the support tables for the membership / role providers.  The .NET Framework SDK includes a tool called aspnet_regsql that will create the tables / sprocs needed.  On my machine it is located at C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\aspnet_regsql.exe.  Run this program and it pops up a wizard to create the tables.  Choose "Configure SQL Server for Application Services", and click next.  We are now presented with a dialog asking for your login information.  Enter your SQL Server credientials and choose your database.  Note: you may get an error on the drop down.  That's fine, just type the database name in instead.  Finish running the wizard and you should have a bunch of shiny new aspnet_ tables in your database.

Step two is getting the Personal Web Site Starter kit or the Club Site Starter Kit generic sql scripts.  The ASP.NET Starter Kit page has links for both of these files.  Download these files, and extract the .SQL file.  Now it's just a matter of opening up Query Analyzer or SQL Express Manager, connecting into your database and executing the script.

Now that we have the database ready, it's just a matter of updating web.config to point towards the proper database.  There should be two connection strings, Personal and LocalSqlServer.  Update both of these to point towards your database. You can now connect into your site via the ASP.NET Configuration page to create yourself an admin user, or if you just want to see if it worked, fire up the website.  Feel free to delete the MDF files in your app_data folder.  We don't need them anymore.

Now, for a little rant.  Yes, we are now using a connection string called LocalSqlServer to connect into a remote sql server.  And some might wonder why we had to remove a connection string that doesn't look like it had been defined yet.  And who knows how the providers are configured.  Here's the secret:  To make things "easier," Microsoft has created a default Connection String and Providers in machine.config.  I would highly recommend not using these at all costs in your application.  They are there simply for people who want to go "hey, i just created a website in three steps!"  Relying on those default providers will simply make development, maintence and deployment a pain in the butt (who knows if your host will even have those entries in their machine.config, or that they have the same values that you are using on your server).  If left up to me, Microsoft would not include these entries in machine.config and assume people will configure their membership / role providers on an application basis, not on a machine wide basis.  Makes sense to me.

So, my long running, rambling point:  Take some time to look at the documentation for the providers.  Heck, look at your machine.config.  Copy and paste the membership configuration stuff into your web.config.  And never, ever, ever for any reason rely on localSqlServer or the default providers from your machine.config in your applications.  That will only cause you headaches down the road when it comes time to deploy, plus prevent you from learning how these things are configured.

Comments

 

Saeed said:

thx a lot your articl so helpful and professional sir,thc again.

August 21, 2007 10:44 AM
 

David de Backer said:

Thanks for your help! This is really a great article. I've been searching the whole web and finally I found the answer to my questions here! Many thanks.

January 24, 2009 9:06 AM