ASP.NET MVC Model Generator
In making the switch to ASP.NET MVC, I’ve moved away from using my old Data Access Layer that I’ve used for years and have opted to use Dapper as my ORM of choice in the quest for optimal performance. My DAL was actually pretty optimized for WinForms and WebForms (using straight SQL Queries and SQL parameters) but mapping it to models wasn’t something I had in mind when I created it. I’m finding Dapper takes some getting used too but it is still pretty fast. The downside is that writing the code for Models to wire it up is proving to be a little tedious.
To that effect, I wrote a little application that has helped me generate the models from a database dynamically. It’s in it’s infancy stages and something I cobbled together in less than 8 hours but it works. I’ll add more features too as time goes on if there’s enough interest or to satisfy my own needs. In the meantime, I’m open sourcing the project as it may help others and I’d love to see it become something grander if others are willing to contribute to it. There’s also some useful bits of code that others may find useful to reference like dynamically reading fields from a database, pluralization/singularization of words, amongst others.
You can find the repository on Github: https://github.com/gregvarghese/MVCModelGenerator
Detecting ASP.NET debug mode
The Problem
Recently I ran into a situation where I needed to debug ASP.NET code in a production environment that we had no control over. The server was managed by a third party support team and we deployed to a staging environment through a custom web deployment utility they built.
Of course, the code ran locally and on our internal staging environments with no issues but when deployed to the client’s remote staging servers, the application was encountering odd errors that we couldn’t replicate.
At this point, I wanted to add code to the web application that could be turned on and off without having to recompile deploy new dlls because of code changes in the code behind. With this particular client, code changes would trigger security scans that took over a week to complete and we were short on time.
The Solutions that Should’ve Worked but Didn’t.
Page Tracing wasn’t working. I remembered the #if Debug and HttpContext.Current.IsDebuggingEnabled statements worked rather well in other projects.
So I added:
#if Debug //Debug code here #endif
to the web application. Nothing happened so I tried:
if(!HttpContext.Current.IsDebuggingEnabled)
but it kept returning false even though debug mode was set to true in the web.config file.
The Solution (that worked!)
Finally I got the bright idea to read out the debug setting out of the web.config and execute code if the debug flag was set to true. How to do so wasn’t exactly obvious though.
After some searching, I finally figured it out and here’s the code snippet that will execute only if the debug flag is set to true:
System.Web.Configuration.CompilationSection cfg = (System.Web.Configuration.CompilationSection)ConfigurationManager.GetSection("system.web/compilation");
if (cfg.Debug)
{
Response.Write(ex.ToString());
}
Why Didn’t the Normal Debug Statements Work?
The issue was that the machine was configured as production. The machine.config overrode the web.config since the <deployment retail=”true”/> switch was set in Machine.config.
This setting disables Page.Tracing & #If Debug and always sets the IsDebuggingEnabled to false. This was done by Microsoft as a security precaution for companies so they could ensure no applications were deployed with debugging enabled by mistake.
Bonus! How Do I Loop Through All Session Variables in C#?
I wanted to see what the session variable values were during execution of the page with the caveat that it would only run if the debug flag was set to true.
<%
System.Web.Configuration.CompilationSection cfg = (System.Web.Configuration.CompilationSection)ConfigurationManager.GetSection("system.web/compilation");
if (cfg.Debug)
{
for(int i = 0; i < Session.Contents.Count; i++)
{
Response.Write(Session.Keys[i] + " - " + Session[i] + "<br />");
}
}
%>
I added the code directly to the bottom of the aspx page since I didn’t want to modify the code behind and voila! Once the code was added to the page, we found that the expected session variables weren’t populating correctly on the remote server. Unfortunately it required a code change to resolve the issue but I never would have found the cause without the above snippet of code.