Should I hardcode the path for the database while deploying?

Question

I created a software using Visual Basic 2010 and SSMS 2012 and I wish to deploy it. The question here is how should I go about doing it? I know I can create an executable file .exe which is already a good thing about VS2010 and I also think that installing SSMS-2012 as well before installing the main setup. Also, the script of the database would be generated and then run on the client's computer which enables the database to be attached. However, the question here is that should I hard-code the directory of the database files (.mdf) in Visual Basic Currently, my connection string is such:

Server=myServerAddress;Database=myDataBase;Trusted_Connection=True;

When SSMS 2012 gets installed on any computer, the server (which is based on the computer's name) which could differ in all computers. So will this work? Or are there any other options

P.S i'm a beginner, so please go easy on me :)

Answer 1

if your problem only lies on the computer's name on a different pc, then try to concatenate this on your myServerAddress variable. Use

My.Computer.Name 

to get the target computer's name.

This is also a good link I guess, it is an Access database though but the same concept is used (the use of DataDirectory).

Answer 2

I'd not suggest to hardcode the connection string as this ties your application to a very specific deployment scenario. What if a customer wants to use his or her existing SQL Server instance? What if the customer creates a named instance for the SQL Server Express installation (e.g. SERVERNAME\SQLEXPRESS). Sooner or later you'd have to change your code to reflect the different situations and you'd do the same thing that you can do already now.

In .NET, you can store a connection string in an application configuration file. It is named as the Exe file but has a .config extension (e.g. MyExeName.exe.config). In Visual Studio, all you need to do is to add a file to your project ("Application Configuration File", app.config) if it doesn't exist yet. Upon build, it will be renamed to the Exe-name plus .config. See this link for detailed information.

For your scenario, you'd have a configuration file like this. It references the local computer by using "." as the server name. So you don't have to change it after deployment if this is your default scenario:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <connectionStrings>
    <add name="MyConnection" 
         connectionString="Data Source=.;Initial Catalog=myDatabase;Integrated Security=SSPI"/>
  </connectionStrings>
</configuration>

In your code, you can access the connection string using the ConfigurationManager class (you might need to add a reference to the System.Configuration assembly). You can use the acquired connection string when you create the connection:

Dim connStr = ConfigurationManager.ConnectionStrings("MyConnection").ConnectionString
Using conn = new SqlConnection(connStr)
    conn.Open()
    ' Use the connection
End Using

To summarize: you'd add a default configuration file with a connection string that works for any server name to your deployment. If the customer wants to have the database on a different instance or another server, you simply change the connection string - but you don't have to if the customer is fine with the default configuration. As you see, it is not much more effort than to hard code it, but it will make your deployments more flexible.

Answer 3

I work for a large company delivering enterprise solutions and the way we handle this is very easy. All you need is a small configuration utility (could even be your installer wizard) where you request a user credentials (which presumably have enough access right to the SQL Server to create/alter databases and objects), and for the server name.

All you need to do after that is to establish a connection to the server, create the database and run the table and/or views creation scripts.

I see you mentioned attaching an MDF file but I cannot see a reason why you would like to do that. If you have system data you still can insert it using the same script or an additional one.