Question

I am modifying some old code someone wrote and they had placed a connection string in the web.config and due to business rules, I am having to remove it. I have made a singleton class that generates the connection string and want to set it in the asp.net markup in a similar fashion like this:

<asp:SqlDataSource ID="DataSource" runat="server" 
    ConnectionString='<% MyNameSpace.Credentials.Instance.DatabaseConnectionString %>'
    ProviderName="Oracle.DataAccess.Client" 
    SelectCommand="SELECT * from aTable">
</asp:SqlDataSource>

Unfortunately, that doesn’t work and is taking that line and using it as the literal connection string. Anyone know how to access a property of a class inline like this?

Answer 1

Consider the following (not unrealistic) scenario. It is a normal weekday morning when your exception monitoring suddenly starts sending large number of SQL logon errors. After a few panicked phone calls to your infrastructure team it becomes apparent that the RAID controller on the database server has failed. The nearest replacement is in another country and will take at least 48 hours to arrive.

Fortunately your DBAs are on the ball and have started a restore onto another server which will be available in less than an hour, one of them is due to phone you with the connection details shortly.

At this point, if your application stores database connection details in a single central location, you should be able to bring the application back online almost as soon as the backup database is restored – after quick testing to ensure no data corruption has occurred and normal functionality is available.

If you have to search through each and every page and class in the project then it could take hours to update all the different connection strings, and you can’t be sure you haven’t missed one.

Instead of having the application restored before lunch, you’re working well into the night with users angry at you for a lost day.

Admittedly Find/Replace tools will make it easier to track down references to the server/database name without having to manually hunt through every line of code, but you are still making life a lot harder than it needs to be.

Microsoft created the connection strings element in the web.config file for good reason, cater for many high security environments, and even provide encryption for the strings to keep them safe. In contract, even compiled code can almost instantly be made human readable using a solution like ReSharper, dotPeek or JustDecompile. If your managers believe keeping connection strings in compiled code is safer then they are wrong.

If you must store the connection strings outside of the web.config, then I would suggest you create a utility class for the purpose-

using System;

namespace YourApplicationNameSpace
{
    public static class Common
    {
        public static string DatabaseConnectionString
        {
            get { return "server=myserver;database=Products;uid=salesUser;pwd=sellMoreProducts"; }
        }
    }
}

The string can then be added to the declarative data source of your page like so-

<asp:SqlDataSource ID="DataSource" runat="server" ProviderName="Oracle.DataAccess.Client" 
SelectCommand="SELECT * from aTable"></asp:SqlDataSource>

In the code behind-

protected void Page_Load(object sender, EventArgs e)
{
    DataSource.ConnectionString = YourApplicationNameSpace.Common.DatabaseConnectionString;
}

This looks like the pattern your company uses.

I believe this would also work (note the addition of the equals sign)-

<asp:SqlDataSource ID="DataSource" runat="server" 
ConnectionString='<%= MyNameSpace.Credentials.Instance.DatabaseConnectionString %>'
ProviderName="Oracle.DataAccess.Client" 
SelectCommand="SELECT * from aTable">
</asp:SqlDataSource>

If you have to keep connection strings confined to individual pages then do-

protected void Page_Load(object sender, EventArgs e)
{
    DataSource.ConnectionString = "server=myserver;database=Products;uid=salesUser;pwd=sellMoreProducts";
}

Then start looking for a new job as the code will be a nightmare to maintain.

Side note that you should make sure you are using parameterized commands for your SQL, especially when updating or deleting data in order to avoid SQL injection – or even better Stored Procedures (also with properly constructed parameters).