JetBrains dotPeek

The JetBrains company, which makes ReSharper, also makes a free tool called dotPeek which will allow one to see what is inside of a .dll that was once a C# project. "What is the application?" you ask. Glad you asked. Where I work (HDRI), I have been asked to retire two servers running MSSQL2000 databases. Every database on the server must die or get migrated to MSSQL2008. In the MSSQL2008 environment DBEncrypt for encryption will NOT be used as it is for MSSQL2000 databases. I have pulled the source code for an old app using one of the MSSQL2000 databases and have tried to get it working with a MSSQL2008 copy of the applicable database. No dice. When I attempt to log in the compiler makes its way from the UI project of the app into a referenced compiled library (for which source code was not checked in) and then causes a red and yellow screen of death informing me of an error vaguely to do with DBEncrypt:

The compiled .dll, like the app, is something made by the company I work for, and like the app running on MSSQL2000, it is old, old, old. The .dll was intended, I surmise, in its day to facilitate some common concerns for numerous applications and hence it is not merely a project within the existing application. I tried to find the source code for this other thing but had some trouble. This makes the error opaque. The red and yellow screen of death offered more of a stack history than the Call Stack window in Visual Studio.

The problem has to lie at the database, correct? Somewhere something that looks like this:

SELECT cast(master.[dbo].dbefn_session_decrypt_varchar([Foo], '238', 'AES', 'CBC', NULL) as varchar(20)) as 'Foo' FROM [dbo].[Bar]

 
 

...needs to be redacted to merely:

SELECT [Foo] FROM [dbo].[Bar]

 
 

...but where? The database is deep with numerous views and stored procedures. Should I just dig into them all? No, Will Hendrix recommend that I use dotPeek. We installed it and he drug the .dll into the Assembly Explorer Window. We could then see the code inside the .dll. It turns out that the method called in the .dll turned around and reached back into the data layer of the existing application!

We found an NHibernate .hbm.xml mapping file that corresponded to a view at the database. The view had to be "cleaned up." I did not expect this! I was betting that the .dll was reaching into a stored procedure on its own accord. Not so.