An assembly’s EXE or DLL file is a standard “Portable Execution” (PE) file, the same file format used for non-.NET executables and code libraries (pretty much any Windows EXE or DLL file). What makes .NET PE files different is all the extra stuff found inside. As a general word, assembly indicates a gathering together of various parts into a single unit. In a .NET assembly, these “various parts” are specifically designed for use with .NET.
A .NET PE file contains three main parts:
A PE header
Required of all PE files, this section identifies the locations of the other sections of the file.
The MSIL code section
The actual code associated with the assembly is stored as semicompiled Microsoft Intermediate Language (MSIL) code. Unfortunately, the Intel or AMD chip in your computer is apparently too brainless to process MSIL code directly (what were they thinking?), so the .NET Framework includes a just-in-time (JIT) compiler that can convert MSIL to native x86 code at a moment’s notice.
The Metadata section
All of the extra detail that .NET needs to rummage through to know about your assembly appears in this essential section. Some of these items, when taken together, make up the assembly’s manifest, a type of document that completely describes the assembly to the world. In the following list of metadata elements, I’ve noted which items appear in the manifest:
The name of the assembly. (Part of the manifest.) This is defined on the Application tab of the project’s properties.
The version number of the assembly. (Part of the manifest.) That’s the four-part version number, as in 1.2.3.4. You’ve probably been wondering all day how you could set this number in your own projects.
Strong name content. (Part of the manifest.) This includes the publisher’s public key.
Culture and language settings. (Part of the manifest.) This is especially useful when you need to create language-specific resource files.
Assembly file listing. (Part of the manifest.) Single-file assemblies will show only the EXE or DLL filename, but some assemblies may include several files in this section. All files in an assembly must appear within the same directory, or in a directory subordinate to the assembly file that contains the manifest.
Exported type information. (Part of the manifest.) Some assemblies “export” some of their types for use outside the application. The details of those types appear here.
References. (Part of the manifest, but in multifile assemblies, each file will contain its own list of references.) The metadata includes a listing of all external assemblies referenced by your application, whether they are private or appear in the GAC. This list indicates which specific version, culture, and platformtarget of the external assembly your assembly expects.
Internal type information. (Not part of the manifest.) All types crafted in your assembly are fully described within the metadata. Also, any additional metadata you added to your types through Visual Basic’s attribute feature appear here.
In multifile assemblies, the manifest-specific elements appear only in the “main” file of the assembly. The manifest is a subset of the metadata within your assembly. The manifest is the public expression of your assembly, and the only way that .NET knows whether it is legit. It’s sort of like the “Nutrition Facts” label put on American food packaging
When you look at the manifest for an assembly, you know at a glance what the assembly contains, and what requirements it has before it can be loaded and run. Even before .NET burst onto the scene, executables and libraries already contained some “metadata,” such as the version number of the file. But this data wasn’t used to manage access between software components, nor was it organized in a generic and extensible way. The metadata in .NET embodies all of these attributes.
The presence of both the MSIL and metadata in each assembly makes these files very readable and understandable. With the right tools, even I seem to understand them. And if I can, anyone can, which leads to a big problem. Companies invest a lot of time and money in their software development efforts, and they don’t want any rinky-dink two-bit startup reverse-engineering their code and getting all their algorithmic secrets. To prevent this casual reading of any .NET application, Microsoft and other third parties include obfuscators, software programs that scramble the contents of an assembly just enough so that it’s hard for humans to understand, but not for the .NET Framework.
Source of Information : OReilly Programming Visual Basic 2008
A .NET PE file contains three main parts:
A PE header
Required of all PE files, this section identifies the locations of the other sections of the file.
The MSIL code section
The actual code associated with the assembly is stored as semicompiled Microsoft Intermediate Language (MSIL) code. Unfortunately, the Intel or AMD chip in your computer is apparently too brainless to process MSIL code directly (what were they thinking?), so the .NET Framework includes a just-in-time (JIT) compiler that can convert MSIL to native x86 code at a moment’s notice.
The Metadata section
All of the extra detail that .NET needs to rummage through to know about your assembly appears in this essential section. Some of these items, when taken together, make up the assembly’s manifest, a type of document that completely describes the assembly to the world. In the following list of metadata elements, I’ve noted which items appear in the manifest:
The name of the assembly. (Part of the manifest.) This is defined on the Application tab of the project’s properties.
The version number of the assembly. (Part of the manifest.) That’s the four-part version number, as in 1.2.3.4. You’ve probably been wondering all day how you could set this number in your own projects.
Strong name content. (Part of the manifest.) This includes the publisher’s public key.
Culture and language settings. (Part of the manifest.) This is especially useful when you need to create language-specific resource files.
Assembly file listing. (Part of the manifest.) Single-file assemblies will show only the EXE or DLL filename, but some assemblies may include several files in this section. All files in an assembly must appear within the same directory, or in a directory subordinate to the assembly file that contains the manifest.
Exported type information. (Part of the manifest.) Some assemblies “export” some of their types for use outside the application. The details of those types appear here.
References. (Part of the manifest, but in multifile assemblies, each file will contain its own list of references.) The metadata includes a listing of all external assemblies referenced by your application, whether they are private or appear in the GAC. This list indicates which specific version, culture, and platformtarget of the external assembly your assembly expects.
Internal type information. (Not part of the manifest.) All types crafted in your assembly are fully described within the metadata. Also, any additional metadata you added to your types through Visual Basic’s attribute feature appear here.
In multifile assemblies, the manifest-specific elements appear only in the “main” file of the assembly. The manifest is a subset of the metadata within your assembly. The manifest is the public expression of your assembly, and the only way that .NET knows whether it is legit. It’s sort of like the “Nutrition Facts” label put on American food packaging
When you look at the manifest for an assembly, you know at a glance what the assembly contains, and what requirements it has before it can be loaded and run. Even before .NET burst onto the scene, executables and libraries already contained some “metadata,” such as the version number of the file. But this data wasn’t used to manage access between software components, nor was it organized in a generic and extensible way. The metadata in .NET embodies all of these attributes.
The presence of both the MSIL and metadata in each assembly makes these files very readable and understandable. With the right tools, even I seem to understand them. And if I can, anyone can, which leads to a big problem. Companies invest a lot of time and money in their software development efforts, and they don’t want any rinky-dink two-bit startup reverse-engineering their code and getting all their algorithmic secrets. To prevent this casual reading of any .NET application, Microsoft and other third parties include obfuscators, software programs that scramble the contents of an assembly just enough so that it’s hard for humans to understand, but not for the .NET Framework.
Source of Information : OReilly Programming Visual Basic 2008
|
|
0 comments
Post a Comment