Mimic Unknown Connection String in .NET Assembly

Recently a web hosting company contacted me for a small job to help them deploy an ASP.NET 1.1 web application for them, for one of their new customers. The host primarily uses Linux boxens, but had recently acquired a number of MS Windows machines and so of course were a little new to .NET.

Although the customer (a non-profit community organization in the US) thought they had all the "source-code" for their specialized web application, a quick review of the files showed just the compiled assemblies and content files (*.aspx, *.htm, etc...), and of course the SQL Server *.mdf and *.ldf files. The code-behind files were missing, and apparently no other copy for the original files are available (let alone any documentation).

It was unfortunate the source was not available, but at least the immediate need of deployment shouldn't be a problem - except, an editable database connection string wasn't to be found in the standard place (namely the Web.config file). For some unknown reason, the original developer choose to hard-code the database connection string - now safely hiding in one or more places in the compiled assembly in the /bin folder.

Okay, so how do you deploy an ASP.NET web app with a hard-coded connection string? When you have no idea what that string may contain!

Enter Lutz Roeder's Reflector for .NET. After a quick download and a simple loading of the compiled *.dll file, I was able to navigate the Class hierarchy of the application. Luckily, the original developer had at least build the app with a common data object which provided a single location for the connection string (removed from screen-shot).

Once I knew the connection string of the application and the database, it was quite simple to mimic the expected properties of the connection.

• The web application needed to point to a specific server URL address for the database, which of course didn't exist on the hosting company's network. But a simple text edit of the local HOSTS file of the webserver fixed that (look in the %windir%\system32\drivers\etc folder). The HOSTS files basically gives you simple DNS alias control for the local machine.
• Then, the database side was simple, by ensuring the SQL Server database name matched what was in the connection string, and the expected SQL Login account was created with the given password.

All-in-all it was a satisfying little job (a few hours), because I find trouble-shooting quite rewarding, and I've never had to go to quite this level of sleuthing before for an ASP.NET app.

Thank you Lutz!