Mark Gilbert's Blog

Science and technology, served light and fluffy.

Constant Learning

The other day I needed to verify that a particular value had been set for one of the constants in an executable I had deployed to a client’s server.  I decided the quickest way to check it would be to use Reflector to poke into the EXE that I sent them.  I dropped the executable into Reflector, drilled down into my Main() module, and found it in the tree.  I right-clicked and selected “Disassemble”.  What I got was something like this:

Private Shared EXTRACT_PREFIX As String

Sigh.  So close.  This was SUPPOSED to be easy. 

After a little more poking around, I found that the context menu for this constant had another option – Analyze.  I hit that and got another pane with another tree to drill into.  When I expanded the top level (which contained my constant), I saw two items: “Used By” and “Assigned By”.  Expanding the latter showed one place that assigned a value to the EXTRACT_PREFIX constant – the module’s .cctor method.  Right clicking on that gave me an option for “Go to member” which refreshed the Disassembler pane to show me this:

Shared Sub New()
End Sub

At least I got the answer to the question that I started with, but several new ones now appeared on the scene.  Are all constants initialized like that?  What is the “.cctor” method used for?  How is “.cctor” different than the “.ctor” method?  I decided to open another binary file containing constants, this one a class library.  As it turns out, the class library had the constants initialized with the declaration statement (and therefore the value was visible in the Disassembler pane), just like how I would write it in source code, and what I was expecting to see originally.

Ok, now I became really curious.  Why the two different methods for initialization?  What was the difference?  The first was an executable that was built from a module, the other was a class library containing classes.  As an experiment, I looked at another executable, this one a WinForms app whose startup entity was a class (one of the forms in the app, to be precise).  That executable initialized the constants with the declaration, just like the library class did.  The difference appears to be whether the constant was part of a class or a module.

Now, let’s tackle the question of “.cctor” versus “.ctor”.  After doing a little searching on the web, I found a couple of posts that shed some light on the difference between these two.  The first one, published several years ago by “cbrumme”, calls the “.cctor” method the “static constructor”:  The second one, published far more recently (just a few weeks ago, in fact) calls it a “module initializer”.  Both of these seem to point to “.cctor” being necessary when initializing code for a module – in other words, a structure that isn’t a class.  The “.ctor” method, therefore, is used to initialize a class.  I don’t think I can use “classes use .ctor while modules use .cctor” as a hard and fast rule, however – cbrumme’s post refers to the “.cctor” method for a class, too.

I definitely feel like I’ve wandered deeper into the .NET framework than where I’m comfortable, but I think it was a worthwhile trip.  Even if my speculation about the uses of “.cctor” versus “.ctor” are wrong, I’ve at least learned there is more than one place to look for constant initialization.


January 11, 2010 - Posted by | Visual Studio/.NET

Sorry, the comment form is closed at this time.

%d bloggers like this: