Reflection

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I am trying to develop an easy way to manage dll load addresses for my .NET
controls and libraries. I was wondering if through reflection or some other
type of mechanism in .NET that I could examine the compiled dll to determine
what its base load address is and its size? With that information I could
create a visual map to use to organize my dll's and ensure they all play
nicely.

Thanks...
 
Lee said:
I am trying to develop an easy way to manage dll load addresses for my .NET
controls and libraries. I was wondering if through reflection or some other
type of mechanism in .NET that I could examine the compiled dll to determine
what its base load address is and its size? With that information I could
create a visual map to use to organize my dll's and ensure they all play
nicely.
Click to expand...

Read the PE /COFF file format specification:

http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx

The format isn't too hard to work with. A set of indirections will get
you to where you want to go. For example, at offset 0x3C into the file,
there is the offset to the Signature (PE\0\0) followed immediately by
the PE / COFF File Header, which is 20 bytes long. In .EXEs and .DLLs,
it's immediately followed by the Optional header. The Optional Header
has different magic (first word) (0x10B or 0x20B) depending on 32-bit
(PE32) or 64-bit (PE32+) image. At offset 28 (PE32) or offset 24 (PE32+)
is the image base, which is 4 bytes in PE32 and 8 bytes in PE32+.

You should be able to make a combination of FileStream and BinaryReader
read this.

-- Barry
 
Lee said:
I am trying to develop an easy way to manage dll load addresses for my .NET
controls and libraries. I was wondering if through reflection or some
other
type of mechanism in .NET that I could examine the compiled dll to
determine
what its base load address is and its size? With that information I could
create a visual map to use to organize my dll's and ensure they all play
nicely.
Click to expand...

..NET dlls don't have load addresses, because they don't contain compiled
code. The JIT reads the MSIL from the assembly, compiles it, linking
dynamically so there's no need for fixups, and write the compiled code out
(sequentially?) somewhere in memory. The size isn't known, and may vary
from run to run depending on whether all code paths are accessed.

C++/CLI mixed assemblies are a different story. Like native dlls, they do
have compiled code that needs fixups if there is a base load address
conflict.
 
.NET dlls don't have load addresses, because they don't contain compiled
code. The JIT reads the MSIL from the assembly, compiles it, linking
dynamically so there's no need for fixups, and write the compiled code out
(sequentially?) somewhere in memory. The size isn't known, and may vary
from run to run depending on whether all code paths are accessed.
Click to expand...

Sorry, they do. See /baseaddress option for the C# compiler. It's
usually only important for NGEN'd assemblies. See
http://msdn.microsoft.com/msdnmag/issues/06/05/clrinsideout/default.aspx#S4

Austin
<snip>
 
Austin Ehlers said:
Sorry, they do. See /baseaddress option for the C# compiler. It's
usually only important for NGEN'd assemblies. See
http://msdn.microsoft.com/msdnmag/issues/06/05/clrinsideout/default.aspx#S4
Click to expand...

Yes, you're right. In essence, ngen converts a pure MSIL assembly such as
C# generates, into a mixed assembly, and so load addresses and fixups become
important again. I think I did make mention of mixed assemblies, thanks for
pointing out that they aren't necessarily C++/CLI when ngen is used.
 
Lee said:
I am trying to develop an easy way to manage dll load addresses for my .NET
controls and libraries. I was wondering if through reflection or some
other
type of mechanism in .NET that I could examine the compiled dll to
determine
what its base load address is and its size? With that information I could
create a visual map to use to organize my dll's and ensure they all play
nicely.
Click to expand...

For example, SymGetModuleInfo64 and SymEnumerateModules64

Details at http://msdn2.microsoft.com/en-us/library/ms681408.aspx
 
Back
Top