Deploying a webpart which depends on a database store

Question

Whats the best way to deploy a webpart in WSS3 or MOSS2007 which has a database dependency? Should the .wsp include code to create the database, should I encapsulate the .wsp in another installer which handles the database creation, or should I supply two different packages to allow the admin to handle the backend creation?

Answer 1

What sort of client is your webpart aimed at?

I imagine it might be worth being slightly flexible in your approach and considering multiple methods of installing your webpart.

So for someone without a dedicated DBA it might be best to have one .wsp. (Although this should be robust enough to handle superuser's installing it.)

Alternatively go for a .wsp and a msi (or even scripts), which will give the installer more control over exactly how it is installed. (I'd prefer this approach, over the .wsp only approach.)

Answer 2

Well, I prefer the SharePoint way where you create the databases from a SharePoint admin page in Central Administration. Just take a look at how SharePoint handles the creation of new Web Applications where you are asked to name the database server and the name for the SharePoint content database.

In other words, I would opt for a WSP only deployment. The WSP should include a database configuration page (an ASPX page) plus a farm level feature for installing a custom action link to the page inside Central Administration. The beauty of doing it from Central Admin is that it runs in a context with privileges to create new databases on the SQL server. Hence, you do not need to ask the user for login and password to the database server. The configuration page should upon successful creation of the database persist the connection info in the SharePoint configuration page, using a custom derivative of the SPPersistedObject class. Web Parts can in turn read these settings to connect to the database.

MSI installers should in my opinion be avoided when designing SharePoint apps.