A difficult question.  MS is definite about some things, but the sequencing
of operations is obscure at strategic points like program start and assembly
load.

When I first saw it, I was surprised by the fact that a shared initializer
of mine ran ahead of sub main.  It makes some sense, but it was puzzling at
the time.  I think you can get what you want with a shared initializer.  I'm
using vb jargon because it is what I know.

Consider a class (FirstThingClass) with a shared field (integer iFirstThing)
and a shared initializer (FirstThingInit) that returns an integer (1 sounds
good to me).  You should put all your one time stuff in FirstThingInit.  In
addition, all the effects of the initialization code should appear as other
shared fields in FirstThingClass.  In other words, I don't want you to
initialize shared fields in other classes from code in
FirstThingClass.FirstThingInit.  I want FirstThingClass to be self contained
with no side effects to other classes.

The effect of this design will be as follows.  Whenever a method (shared or
otherwise) in your dll references a shared public field in FirstThingClass
(which is where ALL the effects of FirstThingInit reside), one of two things
will happen.  Either FirstThingInit will already have run, in which case the
method will proceed, or FirstThingInit will not have run, in which case it
will be forced to run ahead of the calling method.

This design won't guarantee that your one-time code will run first, but it
will guarantee that it will run just in time.  What do you think?