Posted on

.NET – Determine Whether an Assembly was compiled in Debug Mode

Finding out whether an assembly was compiled in Debug or Release mode is a task we must do from time to time.

I know two ways of accomplish this:

Either attributes are applied to Assemblies and can be found in the Assembly Manifest but there are a major difference between them:

  • AssemblyConfigurationAttribute must be added by the programmer but is human readable.
  • DebuggableAttribute is added automatically and is always present but is not human readable

You can easily get the Assembly Manifest by using the amazing ILDASM from your Visual Studio Studio Command Prompt:

ildasm_1

ildasm_2

And if you double click the MANIFEST item you will get all manifest data.

Looking carefully you will find the DebuggableAttribute:

ildasm_3

And perhaps the AssemblyConfigurationAttribute:

ildasm_4 

AssemblyConfigurationAttribute

Locate the AssemblyConfigurationAttribute – this attribute can be easily interpreted: its value can either be Debug or Release

ildasm_5

DebuggableAttribute

If AssemblyConfigurationAttribute is not present then we must use the DebuggableAttribute to get our goal.

Since we cannot understood the DebuggableAttribute value we have to open the assembly from another tool and read this attribute content. There’s no such tool available out-of-the-box but we can easily create a Command Line tool and use a method similar to: 

private bool IsAssemblyDebugBuild(string filepath)
{
    return IsAssemblyDebugBuild(Assembly.LoadFile(Path.GetFullPath(filepath)));
}
private bool IsAssemblyDebugBuild(Assembly assembly)
{
    foreach (var attribute in assembly.GetCustomAttributes(false))
    {
        var debuggableAttribute = attribute as DebuggableAttribute;
        if (debuggableAttribute != null)
        {
            return debuggableAttribute.IsJITTrackingEnabled;
        }
    }
    return false;
}

or (if you prefer LINQ) 

private bool IsAssemblyDebugBuild(Assembly assembly)
{
    return assembly.GetCustomAttributes(false).Any(
        x => (x as DebuggableAttribute) != null 
            ? (x as DebuggableAttribute).IsJITTrackingEnabled 
            : false);
}

As you can see … it’s pretty simple.

Note:

Tipically I add a pre-build task to my build server so that the AssemblyConfigurationAttribute is added to the CommonAssemblyInfo file with the appropriated value: either “Debug” or “Release”. This way anyone can easily see, using only the ILDASM, which king of compilation was used to generate my assemblies.

Posted on

ASP.NET Controls – Validators problem (NetFx 1.1 versus NetFx 2.0 or higher)

It is not a secret that I have a passion related to ASP.NET Controls ID and all related subjects.

This time I’ll write about a problem I found while migrating a NetFx 1.1 application to a new server.

The problem is about Validators and how they render the data needed to validate Client-Side.

Scenario NetFX 1.1.4

All data is rendered thru attributes and this way they must only follow the attributes naming conventions.

Scenario NetFX 2.0 or higher

Most required data is rendered thru Expando attributes. This means that an javascript object is created to host the required data.

At first look this seems quite the same, only with a different storage  approach, but it hides one tricky issue related to naming convention differences between Html attributes and Javascript variables.

The tricky issue

I believe that most of us tries to follow the best patterns and naming conventions and if we all did this on old applications this wouldn’t be a problem.

While migrating an old .Text v0.91 application to a new server, without NetFX 1.1 installed, I found that all pages with Validators raise a javascript error.

Digging into it I found the error in this line: 


var ctl00_pageBody-2_RequiredFieldValidator1 = document.all ? document.all["ctl00_pageBody-2_RequiredFieldValidator1"] : document.getElementById("ctl00_pageBody-2_RequiredFieldValidator1");

The problem is obvious, the character ‘-‘ is a javascript operator and cannot be used in a variable name . The javascript parser after finding the ‘-‘ say that an ‘;’ is expected after ‘ctl00_pageBody’.

So … Why this didn’t occurred in the old server? What lead us to this point?

As I noticed before, in NetFX 1.1 this object didn’t exist, all data were simple rendered as attributes.

I didn’t find any good reason for naming a control like this but in fact this is a absolutely valid control ID.

Solutions

There are two approaches, we can either force the validator to render attributes or change the ID value to remove unwanted characters.

The first is obviously the better one but as you will see is a global application change.

Instruct the validator to render attributes

The validator controls are ready to work in a legacy mode, but to enable that mode we need to change the all behavior of our application. We can do that adding the following web.config data: 

<system.web>    <xhtmlConformance mode="Legacy"/>

While this solution is the one I like the most I choose to use the other simply because I don’t know exactly the potential side-effects, and I need to made a chirurgical change minimizing impacts.

Change the controls ID

This approach requires you to change all controls ID in the validators hierarchy to prevent javascript naming problems. It could take some time but, usually, it should present no problems.

That is not my case. It took me some time to find where the pageBody-2 control.

I ended up finding that it was an UserControl, loaded dynamically and its ID was also composed dynamically. Unfortunately, this was all done in a private method belonging to an internal base class and the only practical solution was to override the Page Render method and replace the pattern ‘_pageBody-‘ with ‘_pageBody_’.

I know it is a dirty solution … I don’t like it … but this is a short term solution before migrating the application to CommunityServer.

Mental note

Never use the ‘-‘ to name your controls ID property. Try the ‘_’ or any other without special meaning in Javascript.